[00:00] <cone-57> ffmpeg.git 03Mickaël Raulet 07master:07b91b8d629d: hevc: cleaning up, remove unused constants(cherry picked from commit 7eed32d076c57aa03011d65a64903e8bdb633978) [00:06] <cone-57> ffmpeg.git 03Mickaël Raulet 07master:c4058b72888f: hevc/cabac: add new context for new syntax elements related to Rext(cherry picked from commit 6d71e2394f52679cfc8b86fb5880f89e6bd311d4) [00:52] <cone-57> ffmpeg.git 03Anshul Maheswhwari 07master:cdc66b651bcb: Adding Maintainer for dvbsubdec [01:03] <Timothy_Gu_> michaelni: do you plan to remove ffserver after this release? [01:03] <michaelni> no, iam hoping that reynaldo fixes the ffserver regression tests [01:04] <michaelni> because without the tests it will only get worse [01:11] <Timothy_Gu_> reynaldo doesn't seem to be very active about fixing ffserver. I'd just remove it after this release. [01:12] <Timothy_Gu_> rightnow he's just doing some refactoring and nits. No bugs are actually fixed. [01:18] <Compn> Timothy_Gu : arent there many users of ffserver right now ? [01:18] <Compn> its nice if we asked first for some user to step up and maintain it [01:18] <Compn> before just rm -rf it [01:19] Action: Compn grumbles about "deletionists" [01:19] <Timothy_Gu_> Yes that's why I said _after_ the release [01:22] <Compn> from your earlier statement it is difficult to guess that you would want to notify users of maintainership requirements of ffserver [01:23] <Compn> tl;dr , someone should post a mail requesting ffserver users to step up [01:23] <Compn> soonish... [01:23] <Timothy_Gu_> email doesn't work cuz we don't know who's using ffserver [01:23] <Timothy_Gu_> ffmpeg.org maybe [01:24] <Compn> sounds ok to me. [01:28] <Timothy_Gu_> feel free to write a patch. I'm afraid I don't have time for that [01:32] <Compn> ok [01:32] <Compn> i thought we did the ffserver thing a few years ago [01:32] <Compn> too many things to remember [01:44] <jehyt> *-0J1 [01:44] <jehyt> warning [01:44] <jehyt> you may be watched [01:44] <jehyt> do usa&israel use the internet(facebook,youtube,twitter, chat rooms ..ect)to spy?? [01:45] <Daemon404> been a while since we had random spam like that. [01:46] <wm4> Daemon404: time to put your OP to good use? [01:47] <Daemon404> hell get klined soon enough [01:59] <Compn> to answer his question, yes. usa and israel spy on internet [01:59] <Compn> also carl spies on us [01:59] Action: Compn waves to carl [02:12] <cone-57> ffmpeg.git 03Michael Niedermayer 07release/2.2:3cf6135729bb: Update for FFmpeg 2.2.5 [02:12] <Daemon404> everyone spies [02:13] <thardin> in war, if you don't spy you're wasting lives [02:13] <thardin> *supposedly* we're not currentlyat war tho [02:14] <Daemon404> thardin, taxes are just a temporary measure [02:14] <Daemon404> to raise money for the war [02:14] <Daemon404> theyll go away after. [02:14] <jamrial> michaelni: can you backport commit 345f2234 for ffmpeg 2.2.5? [02:14] <thardin> bad comparison [02:15] <Daemon404> apt comparison [02:15] <michaelni> jamrial, will do [02:15] <jamrial> thanks [02:15] <thardin> yeah well that's just your opinion, man [02:20] <cone-57> ffmpeg.git 03James Almer 07release/2.2:0edc79962641: x86/scale: fix xmm register count for hscale*_sse2 [02:56] <cone-57> ffmpeg.git 03Anshul Maheswhwari 07fatal: ambiguous argument 'refs/tags/n2.2.5': unknown revision or path not in the working tree. [02:56] <cone-57> Use '--' to separate paths from revisions [02:56] <cone-57> refs/tags/n2.2.5:HEAD: Adding Maintainer for dvbsubdec [02:59] <Timothy_Gu> michaelni: you didnt update ffmpeg.org/download.html [03:01] <Timothy_Gu> sorry if you are doing it right now. didn't notice you only tagged it 6 minutes ago [03:01] Action: michaelni just did :) [03:19] <cone-57> ffmpeg.git 03Timothy Gu 07master:d59536159379: RELEASE_NOTES: Mention Libav and add codename [03:21] <Timothy_Gu> michaelni: when donyou usually sleep? [03:21] <Timothy_Gu> *do you [03:24] <Timothy_Gu> Anshul's [03:24] <Timothy_Gu> last commit had a typo in the author field http://git.videolan.org/?p=ffmpeg.git&a=search&h=d59536159379a1b8c5f7631025edfc4a7d40b048&st=author&s=Anshul [03:39] <michaelni> hmm, the patch on the mailing list had the typo too, i didnt notice it before [05:02] <Zeranoe> I'm trying to compile an older version of FFmpeg but keep running into issues with version.h "cmdutils.c:51:21: fatal error: version.h: No such file or directory". Is there supposed to be a version.h found in an older FFmpeg? [05:07] <drv> it's generated by configure [07:16] <Timothy_Gu> Zeranoe: it is now named "libavutil/ffversion.h" [08:42] <ffffffff11111111> hi, git clone... && ./confgiure --enable-gpl --enable-static --disable-shared --enable-ffmpeg... && make [08:42] <ffffffff11111111> the build completes w/o errors, yet there is no ffmpeg executable created? TIA [08:43] <ffffffff11111111> *./configure [08:46] <plepere> good morning all [08:58] <ubitux> ffffffff11111111: what are you git cloning? [08:58] <ubitux> ffmpeg should be present (and you don't need --enable-ffmpeg) [08:59] <ubitux> ffffffff11111111: btw, someone @ #mplayer-dev wanted to hear about what was wrong and what you fixed [09:03] <ffffffff11111111> ubitux: regarding mplayer: they have commented out line in libvo/vo_xv.c in resize() - i just uncomented it => the window gets repainted correctly [09:03] <ffffffff11111111> ubitux: I'm using git://source.ffmpeg.org/ffmpeg.git [09:04] <ubitux> what hash? can you pastebin the config.log? [09:04] <ubitux> ^hash^revision [09:04] <ffffffff11111111> ubitux: right now I'm looking through your build system to figure out why ffmpeg executable is not being linked / ignored [09:04] <ubitux> start looking at the config.log [09:05] <ffffffff11111111> ubitux: cdc66b651bcb247e778e722a649b10936f1b2326 [09:05] <ffffffff11111111> git clone-d a few hour ago ... [09:05] <ubitux> sounds about right yeah [09:05] <ffffffff11111111> config.log says all is ok and its deps are all built [09:06] <ffffffff11111111> *hours [09:06] <ubitux> what's your full configure line? [09:06] <ubitux> check grep CONFIG_FFMPEG config.{h,mak} as well [09:06] <ffffffff11111111> that will require a pastebin :); one sec. [09:09] <ffffffff11111111> ubitux: the full ./configure command : http://pastebin.com/4q2G7qQ7 [09:10] <ubitux> Timothy_Gu: TYL "git grep CODEC_FLAG_PSNR" ;) [09:10] <ubitux> ffffffff11111111: wow... [09:11] <ubitux> this is insane [09:12] <ubitux> ffffffff11111111: well, firstd try ./configure --enable-gpl [09:12] <ubitux> then iterate slowly starting from this [09:12] <ubitux> you have a tons of insane flags here [09:14] <ffffffff11111111> ubitux: they're all provided by your build system and I want them exactly like that; It will build w/o them :) - "huge" executable with tons of rt deps. I would like ffmepg short, simple, and non-autodetected :) [09:15] <ubitux> i doubt you want to disable optimizations [09:15] <ubitux> ...and --disable-small if you are looking for a small binary [09:15] <ubitux> also, a lot of options are already disabled by default [09:15] <ubitux> like --disable-random (wtf) [09:16] <ubitux> wtf @ --disable-gray --disable-swscale-alpha as welll [09:16] <ubitux> --disable-fontconfig makes no sense, it's an external lib, it won't be autodetected [09:17] <ubitux> explicitely disabling arm makes no sense either if you're on intel [09:18] <ubitux> (btw, you can factor some --disable, like --disable-protocol=md5,concat,subfile,... [09:18] <ubitux> ) [09:19] <ffffffff11111111> 10x for thta last one :) [09:19] <ffffffff11111111> optimizations are enabled [09:19] <ffffffff11111111> I like the build line to wokr in cross-compile environments and even if you decide to change defaults [09:20] <ffffffff11111111> thats shy I leave almost nothing on default [09:20] <ubitux> you don't --disable-everything, so there is no point in expliciting a bunch of the --enable-xxx at the beginning btw [09:20] <ffffffff11111111> the grey thing and the alpha thing are additional processing I don't need [09:20] <ubitux> --enable-static --disable-shared is the default btw [09:21] <ffffffff11111111> an the random thing is related to the build system testing as far as I understand so I don't need it either [09:21] <ffffffff11111111> *that [09:22] <ffffffff11111111> *work [09:22] <ubitux> --enable-random will randomly enable stuff, it's of course not what you want [09:22] <ubitux> and it's of course not the default [09:22] <ffffffff11111111> *thats why I've left almost nothing on default [09:23] <ffffffff11111111> *and the random [09:25] <ffffffff11111111> I'm still trying to find out why is ffmpeg not even started being built [09:27] <ubitux> remove all your flags, add them by dichotomy [09:34] <ffffffff11111111> I'm crafting my own makefile - it will either "tell" me the reason, or it will build ffmpeg :) - it should be faster than ~5 rebuilds. 10x for your time! [11:38] <ubitux> do we have array of zero-length in some struct in ffmpeg? [11:38] <ubitux> i remember seeing one once, but i don't remember what was the portable syntaxe (between type foo[] and type foo[0]) [11:40] <J_Darnley> As I understand it, foo[] just lets the compiler decide the length based on what you assign to it at declaration. [11:40] <J_Darnley> So if you don't assign anything I think it should be equivalent to foo[0] [11:41] <ubitux> i remember one of the two is badly supported by some compilers, and i think it was [] [11:41] <J_Darnley> As for what's portable, I have no idea and I am surprised it isn't an error [13:25] <cone-43> ffmpeg.git 03Mickaël Raulet 07master:1241eb88704f: hevc: simplify SAO computation, delay from one row its computation (cherry picked from commit f2c5f647cec786df26f442a85e6d685a131a50c9) [13:31] <cone-43> ffmpeg.git 03Mickaël Raulet 07master:f5beda3bfd75: hevc: move restore_tqb where it should be. (cherry picked from commit 8fafc96a9805d11bfe32537c8f78a294a5844065) [13:37] <cone-43> ffmpeg.git 03Mickaël Raulet 07master:255086a7e064: hevc: use local variable for split_cu_flag (cherry picked from commit ee71e9e9c12fc47856c452efb278f9f593a923ee) [13:47] <cone-43> ffmpeg.git 03Mickaël Raulet 07master:250430bf2811: hevc: separate residu and prediction (needed for Range Extension) (cherry picked from commit 6b3856ef57d66f2e59ee61fd2eb5f83b6d0d7d4a) [13:56] <cone-43> ffmpeg.git 03Mickaël Raulet 07master:5a41999d8145: hevc/rext: basic infrastructure for supporting range extension - support for 4:2:2 and 4:4:4 up to 12 bits - add a new profile for range extension (cherry picked from commit d3c067fa65bbc871758d28aa07f54123430ca346) [14:08] <cone-43> ffmpeg.git 03Mickaël Raulet 07master:453f8eaee213: hevc/rext: add support for Range extension tools [15:10] <cone-43> ffmpeg.git 03Timothy Gu 07master:7bf5084e3006: doc/utils: add missing `@c man end` title [15:52] <cone-43> ffmpeg.git 03Michael Niedermayer 07master:01c17b5224ce: ffmpeg: Fix copying timebase to muxer context [16:07] <michaelni> nevcairiel, can you explain the file descriptor issue with msvc to kriegero1? (he is the author of the change) [16:07] <kriegero1> Daemon404: nevcairiel: hi [16:08] <Daemon404> simple: passing FDs between libs or procs is a no-go. [16:08] <kriegero1> do i understand correctly that when you call av_bprint_fd_contents() from libavdevice bad things happen? [16:08] <Daemon404> you cannot open a file in one lib, and then pass that fd to a 2nd lib to print. [16:08] <kriegero1> Daemon404: it aborts the process? or what happens? [16:09] <Daemon404> crash. [16:09] <Daemon404> (or undefined behavior, rather) [16:09] <kriegero1> what if we make that function inline? :) [16:09] <Daemon404> you cannot count an such compiler optizations. [16:09] <Daemon404> on* [16:09] <Daemon404> the inline keyword is only a suggestion to the compiler [16:09] <Daemon404> this goes for all compilers. [16:10] <wm4> Daemon404: you mean specifically on windows [16:10] <wm4> on every other OS it works [16:10] <Daemon404> wm4, no [16:10] <Daemon404> even on linux you cannot share FDs between *procs* [16:10] <wm4> so this is not an invalid thing to do; it just doesn't work on windows [16:10] <Daemon404> libs perhaps, not procs. [16:10] <wm4> uh you can [16:10] <Daemon404> you can IF YOU USE SOCKETS [16:10] <wm4> but that's not the point [16:10] <Daemon404> otehrwise, no, you cant [16:10] <wm4> because in this case it's a lib [16:10] <wm4> uh what [16:10] <wm4> fork()? [16:10] <Daemon404> on linux fd tables are per proc, so no [16:11] <wm4> it's a normal thing to do to create a child process and to share some FDs with the parent [16:11] <Daemon404> child ~+ ipc [16:11] <wm4> why do you think O_CLOEXEC was invented [16:11] <Daemon404> !=* [16:11] <Daemon404> also im not sure, but i do not think POSIX guarantees such thigns. [16:11] <wm4> ???? [16:11] <wm4> POSIX specifies it in the first place [16:11] <wm4> unix 101 [16:12] <Daemon404> POSIX guarantees fds must be usable between separate PIDs? [16:12] <wm4> anyway, in this case, it's just between libs [16:12] <wm4> no [16:12] <Daemon404> that is my point. [16:12] <wm4> it allows certain forms of sharing, like between parent and child [16:12] <wm4> fork() copies the FD table from parent to the new child [16:12] <Daemon404> special case != it works [16:12] <kriegero1> calm on men, that's not about processes at all [16:13] <kriegero1> Daemon404: could you please give some doc reference about this? [16:13] <Daemon404> yeah i know, but wm4 just likes to be a slashdot "M$" guy [16:13] <kriegero1> just for commit justification [16:13] <wm4> Daemon404: what [16:13] <wm4> <wm4> so this is not an invalid thing to do; it just doesn't work on windows [16:13] <wm4> that's all [16:13] <wm4> we all know that windows introduces awkward portability issues [16:13] <wm4> this has nothing to do with flaming windows [16:14] <Daemon404> the deper point i was trying to get at is that FD-sharing has issues with *other* usecases on otehr oses, and that fd-sharing is quite ugly [16:14] <kriegero1> what if we ifdef out av_bprint_fd_contents() and its usage for windows, using av_file_map() instead? [16:14] <wm4> Daemon404: no [16:14] <Daemon404> wm4, i can only disagree then [16:14] <Daemon404> fd-sharing for APPLICATIONS is ugly as fuck [16:14] <kriegero1> thus it will work on windows just as it worked before i have introduced that function [16:14] <wm4> nobody claimed using FDs over processes was supposed to work [16:14] <Daemon404> i dont mean os shit liek X> [16:15] <Daemon404> kriegero1, no [16:15] <wm4> and in this case it's just a function to read contents from a file handle [16:15] <Daemon404> ifdef'd stuff like that is silly [16:15] <Daemon404> and we dont do ifdef soup [16:15] <Daemon404> if it works one way on all oses, use it. [16:15] <wm4> Daemon404: except for windows! [16:15] <Daemon404> wm4, read clsoe you troll [16:15] <wm4> (re ifdef soup) [16:15] <wm4> sorry but you're the troll here [16:16] <Daemon404> wm4, most of teh compatability hacks in ffmpeg are not for windows [16:16] <Daemon404> fyi [16:16] <Daemon404> much less than the majority. [16:16] <Daemon404> we dont do ifdef soup for us eof our own api functions. [16:16] <Daemon404> of* [16:16] <Daemon404> api funcs that only work on some os are silly. [16:17] <wm4> anyway, were we to use a HANDLE instead of a fd, it'd work even across library boundaries [16:17] <kriegero1> ok, what about replacing it with api call which would dump a pointed filename into memory? [16:17] <wm4> and in some cases (like HWND) even across process boundaries [16:17] <wm4> kriegero1: I think that would work even on windows [16:18] <Daemon404> wm4, shockingly enough, people think using int FDs isnt terribly great [16:18] <kriegero1> wm4: i suppose HANDLE is just the same as bare int fd on POSIX? [16:18] <wm4> kriegero1: not sure what HANDLE is, but apparently it's pretty similar to fds conceptually, just more obfuscated [16:19] <wm4> and has an underlying type possibly different from int, and uses different APIs [16:19] <kriegero1> Daemon404: so could you please provide some reference to official documentation forbidding fd passing between libs, just for record? [16:19] <Daemon404> i'll have to search [16:20] <Daemon404> nevcairiel might have them handy [16:20] <kriegero1> please [16:20] <wm4> kriegero1: it happens because every DLL can have its own libc [16:20] <wm4> kriegero1: and FDs are emulated on windows [16:20] <kriegero1> and i'll replace av_bprint_fd_contents with av_brint_file_contents [16:20] <wm4> so each libc will have its own FD table [16:20] <wm4> just using avio might also be an idea [16:21] <wm4> then you could pass http links too (!!!111) [16:21] <Daemon404> that too [16:34] <michaelni> avio would make it libavformat dependant sadly [16:35] <michaelni> so it couldnt be relied upon being available in many places [16:35] <Daemon404> well we have a lot of I/O infastructure in lavf [16:35] <Daemon404> i already thought adding I/O to lavu was a bit if-y [16:36] <wm4> michaelni: not sure why anyone would care about that [16:39] <michaelni> well the one usecase that lead to av_bprint_fd_contents() is in libavfilter [16:39] <michaelni> oops sorry libavdevice [16:40] <michaelni> i mixed it up :) [16:40] <michaelni> its libavdevice/lavfi.c: ret = av_bprint_fd_contents(&graph_file_pb, fd); [16:40] <michaelni> so yes lavf might be an option [16:41] <wm4> why can't libavfilter depend on libavformat [16:41] <Daemon404> he said libavdevice [16:41] <Daemon404> which does. [16:41] <Daemon404> seems like just using avio directly in libavdevice is saner [16:42] <michaelni> yes, it seems so [16:43] <michaelni> or moving a av_bprint_fd_contents equivalent with char* insteda of int fd to lavf [17:24] <ubitux> iive: 09:03:14 < ffffffff11111111> ubitux: regarding mplayer: they have commented out line in libvo/vo_xv.c in resize() - i just uncomented it => the window gets repainted correctly [17:24] <ubitux> (you seemed to be interested in that regard - and the guy showed up here for another reason this morning) [17:25] <iive> oh, ok. [17:34] <kriegero1> so is there an agreement on preferred way to replace av_bprint_fd_contents()? [17:35] <kriegero1> passing an AVIOContext instead of fd? [17:45] <michaelni> kriegero1, id vote for AVIOContext and move to lavf (needed due to dependancy) [20:14] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:19e5114eaad9: avcodec/mpegvideo_enc: return proper error instead of failing assertion when max rate is not set [20:14] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:8a91cf857b20: avcodec/options_table: add liberal limits to intra dc precission [20:14] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:97f86cd97604: avcodec/mpegvideo_enc: workaround applications specifying intra dc level based on 8 and othes based on 0bit [20:14] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:339d8fb3532a: avcodec/mpegvideo_enc: check intra dc precission [20:14] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:5bda0467d284: avcodec/mpegvideo_enc: make edge for interlaced mpeg2 encoding smaller [20:31] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:e10b62ab5d35: ffmpeg_opt: remove intra_dc_precision, its handled by AVOptions [20:32] <michaelni> kriegerod, as you maintain vf_drawbox.c/drawgrid you should have OP here [20:35] <ubitux> oh l. is doing K&R again [20:35] <ubitux> why are they fucking aligning totally unrelated data with spaces monsters :( [20:38] <wm4> ubitux: cosmetics are important [20:38] <ubitux> not those [20:39] <ubitux> they're completely retarted and hurt the project [20:41] <JEEB> hmm, can someone else try disabling video encoders and seeing if linking fails @ snow? [20:41] <JEEB> >> undefined reference to ff_mpegvideoencdsp_init [20:41] <Compn> JEEB : carl is usually the one who detects those types of breaks , if you want to ask him [20:41] <JEEB> no [20:41] <ubitux> haha [20:41] <Daemon404> preach sista [20:42] <JEEB> I've had enough of him with my e-mail conversation regarding multimedia frameworks [20:42] <Compn> maybe someone else will test then :) [20:42] <JEEB> and how he completely missed the fact that someone might not be using lavf and lavc together :V [20:42] <JEEB> or more like was completely unwilling to understand such a use case [20:43] <Daemon404> everyone has many carl stories [20:43] Action: Daemon404 pats JEEB [20:43] <JEEB> (or heck, using lavf and lavc together but via that multimedia framework) [20:44] <Compn> you guys do know that you dont have to listen / follow carl right ? [20:44] <Compn> he is but one developer who has his own opinions [20:44] <Daemon404> Compn, except he has been blocking a useful patch for months [20:44] <JEEB> well he e-mailed me [20:44] <Daemon404> literally everyone vs him [20:44] <JEEB> and that started a discussion [20:44] <JEEB> and he was a fucking retard [20:44] <JEEB> :P [20:44] <JEEB> I only got passive aggressive at the end [20:44] <ubitux> JEEB: ./configure --disable-encoders && make fails for me indeed [20:44] <Compn> talk to whomever maintains it to commit :P [20:45] <ubitux> in dirac & snow [20:45] <JEEB> ubitux, ok glad to know it isn't just me [20:45] <ubitux> /home/ubitux/src/ffmpeg/libavcodec/diracdec.c:430: undefined reference to `ff_mpegvideoencdsp_init' [20:45] <ubitux> /home/ubitux/src/ffmpeg/libavcodec/snow.c:436: undefined reference to `ff_mpegvideoencdsp_init' [20:45] <JEEB> :) [20:45] Action: Compn bets a merge caused it to break, since snow was removed from other tree :p [20:45] <JEEB> yeah [20:46] <Daemon404> complainst recieved from actual users: 0 [20:46] <Daemon404> im sure snow's large userbase was devastated :P [20:46] <ubitux> (they don't have a dirac decoder?) [20:47] <JEEB> Daemon404, I think the bigger problem is the failure to build :) [20:47] <ubitux> Daemon404: stop badmouthing, snow works, it's a dep issue when some stuff is disabled [20:47] <JEEB> rather than missing dirac/snow [20:47] <Compn> ubitux : i think hes saying no one complained to libav when they removed snow [20:47] <ubitux> probably no one uses libav [20:47] <ubitux> ;) [20:47] <Compn> ubuntu and debian... [20:47] <Daemon404> vlc is definitely not big [20:47] <Daemon404> right? [20:47] <ubitux> Compn: too old to realize [20:48] <ubitux> Daemon404: vlc is using ffmpeg here [20:48] <Daemon404> anyway [20:48] <Daemon404> if you think snow has users [20:48] <Daemon404> youre on crack [20:48] <ubitux> can be applied to ~70% of our codecs most of the time [20:48] <Compn> game formats [20:49] <Daemon404> game formats have more use than a slow encoder which produces shitty results [20:49] <Daemon404> literally 0 value [20:49] <Daemon404> aside from sideshow spectacle [20:49] <Compn> >no one mentions sonic :p [20:49] <Daemon404> sonic has negative value, Compn [20:49] <Daemon404> it can produce files bigger than teh source [20:52] <Compn> libav still has dirac.c [20:52] Action: Daemon404 explicitly disables dirac during builds and uses libschro [20:52] Action: Compn hasnt seen wild dirac anyways [20:53] <Compn> maybe i've been neglecting the trackers [20:53] <ubitux> it's strange, snow encoder has mpegvideoenc in select [20:53] <Daemon404> Compn, just work for the bbc [20:53] <jamrial> i have dirac big buck bunny [20:53] <Compn> still havent seen BBB :) [20:53] <jamrial> i don't think i ever saw anything else with that codec [20:53] Action: Compn highlights for fun [20:53] <Daemon404> jamrial, VC-2 is intra-only dirac [20:53] <Daemon404> iirc [20:54] <Daemon404> BBC uses it internally [20:54] <jamrial> ah [20:54] <Compn> yes bbc spent all that money coming up with their own codec [20:54] <Compn> and then leaves doctor who to rot in strange countries for 50 years [20:54] <Compn> :P [20:54] <ubitux> JEEB: http://pastie.org/9394469 [20:54] <ubitux> maybe try this? [20:55] <ubitux> a bit ugly to add it to the decoders though [20:56] <ubitux> the dep should probably be fixed [20:56] <ubitux> in both cases it's used for draw_edges [20:58] <ubitux> draw_edges is supposed to only be used in encoders context? [20:58] <michaelni> the question is why is draw_edges in a mpeg specific context and a encoder specific context [20:58] <wm4> apropos game format, descent 2 movies are broken :( [20:59] <michaelni> wm4, regression ? [20:59] <wm4> don't know [20:59] <michaelni> either way open a ticket please [20:59] <ubitux> "dsputil: Move draw_edges() to mpegvideoencdsp" [21:01] <ubitux> where is that supposed to belong then? [21:02] <michaelni> draw_edges is motion estimation and motion compensation related and this impicitly also video [21:03] <michaelni> probably best if its where the emu_edge stuff is [21:12] <JEEB> ubitux, yeah -- that hack works [21:12] <JEEB> links now [21:13] <michaelni> ubitux, LGTM, unless you want to move draw_edges to a better place [21:25] <ubitux> ok [21:26] <cone-756> ffmpeg.git 03Clément BSsch 07master:7a15c22c5f76: build: fix build with --disable-encoders [21:34] <jamrial> i'll look into moving draw_edges to videodsp later [21:41] <ubitux> jamrial: thx [22:06] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:95144729045f: avutil & avdevice: remove av_bprint_fd_contents() [22:07] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:0fc2045d5f4e: avcodec/hevc_ps: prevent stale pointer in malloc failure case [22:07] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:880dbe43ca71: avcodec/hevc: treat current_sps like sps_list [22:59] <Compn> db0 : do you think my suggestion to host the .js files locally is good/bad ? [23:00] <Compn> in the site redesign [23:46] <cone-756> ffmpeg.git 03Stepan Bujnak 07master:895e92eca050: Blackframe video filter now sets metadata accordingly. [00:00] --- Wed Jul 16 2014