[Ffmpeg-devel-irc] ffmpeg-devel.log.20140715

[burek]

[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