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

[burek]

[00:38] <cone-613> ffmpeg.git 03Michael Niedermayer 0725a21c587c07: eval-test: add some otherwise untested functions.
[00:38] <cone-613> ffmpeg.git 03Michael Niedermayer 076a712e7f6296: sws: bump micro for range bugfix
[01:06] <durandal_1707> in case of direct rendering changing outdata for .decode is not allowed
[01:31] <cone-613> ffmpeg.git 03Paul B Mahol 07bb9bc1fc9848: flicvideo: return more meaningful error codes
[01:35] <durandal_1707> michaelni: what avctx->internal->is_copy does? i see that for the first time
[01:35] <ohsix> is it related to -avcodec copy?
[01:37] <durandal_1707> nope, i found explanation in header, it is used for mt
[01:46] <cone-613> ffmpeg.git 03Carl Eugen Hoyos 077139f0e6bef4: Fix typo in platform documentation.
[03:03] <cone-613> ffmpeg.git 03Michael Niedermayer 07841bf0ef240f: cmdutils: allow specifying the file for -report
[03:03] <cone-613> ffmpeg.git 03Michael Niedermayer 076204ea17f16d: rational: test add/sub too
[11:53] <cone-448> ffmpeg.git 03Stefano Sabatini 0714f1fa56b2ae: doc/filters: add "Notes on filtergraph escaping" section
[13:21] <cone-448> ffmpeg.git 03Kostya Shishkov 0738fdf7258035: swscale: do not forget to swap data in formats with different endianness
[13:21] <cone-448> ffmpeg.git 03Diego Biurrun 07d8eda3708023: x86: mmx2 ---> mmxext in function names
[13:21] <cone-448> ffmpeg.git 03Diego Biurrun 07fa8fcab1e0d3: x86: h264_chromamc_10bit: drop pointless PAVG %define
[13:21] <cone-448> ffmpeg.git 03Michael Niedermayer 07add7513e64e6: Merge commit 'fa8fcab1e0d31074c0644c4ac5194474c6c26415'
[13:31] <cone-448> ffmpeg.git 03Diego Biurrun 07c37322e68c52: x86: Move optimization suffix to end of function names
[13:31] <cone-448> ffmpeg.git 03Diego Biurrun 0702e427518086: avconv_opt, cmdutils: Add missing function parameter Doxygen
[13:32] <cone-448> ffmpeg.git 03Janne Grunau 076b07830a7772: fate: add ac3/eac3 tests to FATE_SAMPLES_AVCONV
[13:32] <cone-448> ffmpeg.git 03Michael Niedermayer 077fd9d49ba7fa: Merge remote-tracking branch 'qatar/master'
[14:05] Action: Compn wonders if diego renaming mmx stuff broke mplayer compilation again
[14:18] <divVerent> 13:21:33       cone-448 | ffmpeg.git Diego Biurrun d8eda3708023: x86: mmx2 ---> mmxext in function names
[14:18] <divVerent> love it ;)
[14:18] <divVerent> multimedia extensions extension
[14:19] <divVerent> and the best part, this isn't Diego's fault ;)
[14:29] <nevcairiel> could've just stuck with mmx2 =P
[14:29] <nevcairiel> his obsession with changing the name is silly
[14:32] <iive> it is to make it consistent... i think.
[14:32] <nevcairiel> with what? =p
[14:33] <iive> with the define?
[14:34] <divVerent> still, he didn't coin the name, as far as I see
[14:35] <nevcairiel> iive: this define? :) http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=239fdf1
[14:35] <nevcairiel> he renamed it first :P
[14:37] <divVerent> fun fact: English Wikipedia doesn't even know MMXEXT
[14:37] <nevcairiel> some functions apparently carried the mmx2 name before the rename, so it was indeed a bit inconsistent, but considering mmx2 was the far more widely used thing in av*, i would've used it
[14:37] <divVerent> Russian Wikipedia does, though
[14:37] <nevcairiel> divVerent: probably doesnt know mmx2 either, though
[14:37] <iive> nevcairiel:  yes, but it was mmx2 and mmxext used at the same time, he just made it consistent...
[14:38] <nevcairiel> yes, but to the one thats much more work and far less used in this codebase at least =P
[14:38] <divVerent> nevcairiel: it actually does
[14:38] <iive> or at least the message  indicates so.
[14:39] <nevcairiel> divVerent: when i try mmx2, i get mega man x 2 :P
[14:39] <divVerent> http://en.wikipedia.org/wiki/3DNow! mentions MMX2 ;)
[14:39] <divVerent> and yes, AMD apparently screwed up that one
[14:39] <iive> I know Diego is king of the unsubstantial cosmetic commits.
[14:39] <divVerent> and failed to establish a name for it
[14:40] <iive> For now I'm just happy nobody tries to use the official name for "3DNow!" with the "!" exclamation mark.
[14:41] <divVerent> hehe
[14:41] <ubitux> diego is just working on making git blame impossible :))
[14:41] <divVerent> 3DNOW1
[14:41] <divVerent> works for me
[14:41] <iive> ubitux: the whole libav masters team works on that.
[14:41] <divVerent> did you know: you can now write C code without using any digits other than zero, by using unary number encoding
[14:41] <divVerent> 0, -~0, -~-~0, -~-~-~0, ...
[14:41] <divVerent> work too :P
[14:42] <nevcairiel> soudns fun
[14:42] <divVerent> hope libav won't switch to that style
[14:42] <iive> well, stop giving them ideas :P
[14:43] <divVerent> can also use 1-1, 1-~-1, 1-~-~-1, ... and the value is the number of tildes ;)
[14:43] <divVerent> that way you can say "this number is SOOOOOOOO big"
[14:51] <Tjoppen> madness
[15:06] <saste> man pages system sucks hard
[15:06] <saste> anyway what's the supposed section number for "libraries", if any?
[15:07] <divVerent> Tjoppen: https://gist.github.com/3993812
[15:07] <divVerent> done with it now :P
[15:08] <saste> (3) should be good enough
[15:08] <Tjoppen> divVerent: :D
[15:09] <Tjoppen> something like that would probably raise eyebrowse at IOCCC
[15:09] <divVerent> doubt it
[15:09] <divVerent> IOCCC uses more clever tricks :P
[15:10] <divVerent> but at least this code fits the rectangle
[15:10] <divVerent> had to cheat and add a space before [], though
[15:10] <divVerent> but just got the idea to avoid this issue :P
[15:12] <cone-448> ffmpeg.git 03Michael Niedermayer 07e5cf100d3daa: mpegvideo_probe: check slice order
[15:15] <divVerent> https://gist.github.com/3993863 this is funnier, mixes a modern C feature with K&R declaration :P
[15:18] <Tjoppen> why not ~~0 on the end?
[15:18] <divVerent> would work too :P
[15:18] <Tjoppen> or ~~~~~~~~0
[15:19] <divVerent> http://dpaste.com/822175/ the generator script
[15:21] <Tjoppen> hm. silly ideas for ioccc. let's see
[15:22] <Tjoppen> maybe a vm whose byte code is produced by convolving a seemingly random table with another table, that then does something?
[15:22] <divVerent> git archive --remote=git://git.videolan.org/ffmpeg | mail submit at ioccc.org
[15:22] <divVerent> should do ;)
[15:22] <Tjoppen> per the judges words, "math" is the most opaque obfuscation of all
[15:22] <divVerent> recently did this BTW: http://rm.sudo.rm-f.org/~xonotic/temp/256.com
[15:23] <divVerent> and indeed, math :P
[15:23] <divVerent> it's a 256 bytes program that contains a DCT-like encoded image
[15:23] <divVerent> and decodes it with animation
[15:23] <divVerent> by slowly turning sines into cosines
[15:23] Action: Tjoppen launches dosbox
[15:23] <divVerent> slow as hell, though
[15:23] <divVerent> ESPECIALLY in dosbox :P
[15:23] <divVerent> takes like 2 minutes there
[15:24] <divVerent> while it's done in like 1 sec on a real PC
[15:24] <Tjoppen> http://www.pouet.net/prodlist.php?type[]=256b
[15:24] <divVerent> on some celeron box on winxp :P
[15:24] <Tjoppen> one pass done.. looks plasma-ish
[15:24] <divVerent> when done, the image may roughly resemble "42"
[15:24] <divVerent> yes
[15:24] <divVerent> you know what a DCT is, and that it's quite blurry when using high compression
[15:25] <divVerent> and this encoded the whole image in about 128 bytes
[15:25] <Tjoppen> yep. not a bad idea actually
[15:25] <divVerent> and the decoder is 128 too
[15:25] <divVerent> the whole image is also a single DCT :)
[15:25] <divVerent> not 8x8 blocks like JPEG
[15:25] <Tjoppen> I have some similar ideas for 4k and 64k. do DCT + quantization in a generator, stick it in a table
[15:25] <Tjoppen> then let kkrunchy (or some other packer) deal with entropy coding
[15:26] <divVerent> hehe
[15:26] <divVerent> I still didn't quite meet what I wanted with it, but it was fun doing it
[15:26] <divVerent> am somewhat disappointed by how slow dosbox is with real mode stuff
[15:26] <Tjoppen> submit it in a 256 byte compo at some demoparty that allows remote entries
[15:27] <Tjoppen> and maybe reduce the resolution so it renders faster
[15:27] <divVerent> hehe, maybe
[15:27] <divVerent> it's still not impressive compared to other 256b ones
[15:27] <divVerent> also, needs a better image than this 42 :)
[15:27] <divVerent> the compressor for this is BTW in perl
[15:28] <Tjoppen> compress klämrisk
[15:28] <Tjoppen> or an amiga ball
[15:28] <Tjoppen> or two balls touching
[15:29] <divVerent> damn, the com file doesn't match the version I have here ;) now wonder if I have the latest source here or not
[15:29] <Tjoppen> yeaha, it kind of looks like a mess. no 42 at all
[15:29] <divVerent> that's the main problem
[15:29] <divVerent> if you know it, you see it... but only then
[15:30] <Tjoppen> ctrl+f12 to speed up dosbox doesn't work on ubuntu :(
[15:30] <divVerent> ah, the one I have here says FOO :)
[15:31] <divVerent> http://rm.sudo.rm-f.org/~xonotic/temp/256.asm - no guarantee that it matches though ;)
[15:32] <divVerent> this version had the attempt to use 2 bytes per DCT sample
[15:32] <divVerent> in retrospect not sure if it was a good idea
[15:32] <Tjoppen> edited dosbox conf, upped cycles to 1000000
[15:32] <divVerent> because that means frequency is between 0 and 15
[15:32] <Tjoppen> now it renders at a decent speed
[15:32] <divVerent> how many fps?
[15:32] <Tjoppen> uh.. maybe one frame per five seconds?
[15:32] <divVerent> hehe
[15:32] <Tjoppen> I see a 42 :)
[15:32] <divVerent> for me about one per 2 sec
[15:33] <divVerent> in the dynamic core
[15:33] <divVerent> while the whole thing finishes in one sec on an actual PC
[15:34] <divVerent> yes, this asm version also says 42 :) so that's before I screwed it up totally by trying the FOO image
[15:37] <Tjoppen> btw, the -~-~0 trick won't work on all machines. C doesn't mandate twos complement logic
[15:38] <divVerent> right
[15:38] <divVerent> neither does using puts() without declaration
[15:38] <divVerent> I was actually amazed that it did on this 64bit machine
[15:39] <divVerent> I had assumed it'd auto declare it with int argument, and then a 64bit pointer won't fit in a 32bit int
[15:40] <Tjoppen> btw, you should check out fsqrt's stuff if you like 256b
[15:40] <Tjoppen> for instance, http://www.pouet.net/prod.php?which=60050
[15:42] <divVerent> wtf, wonder how that works
[15:42] <Tjoppen> raymarching probably (just like puls)
[15:43] <Tjoppen> http://www.pouet.net/prod.php?which=53816 puls
[15:43] <divVerent> even renders to a back buffer
[15:43] <Tjoppen> http://www.pouet.net/prod.php?which=59776 is similar
[15:46] <divVerent> http://www.youtube.com/watch?v=OuWEKSg4jsc - also currently working on this... espeak abuse :P http://www.youtube.com/watch?v=Lo_X8n4MBic&feature=relmfu too
[15:47] <divVerent> which reminds me of the DailyWTF post I wanted to write today ;)
[15:48] <divVerent> but probably tomorrow
[15:48] <divVerent> about VSQ and UST file format insanity
[15:48] <Tjoppen> ah, a tool to make a speech synth sing?
[15:48] <divVerent> yes
[15:48] <divVerent> it uses espeak, but probably can be easily adapted to use other ones too
[15:49] <divVerent> but espeak is interesting because it's fully synthetic, no recorded voice at all
[15:49] <divVerent> and thus no copyright restrictions on the output
[15:49] <Tjoppen> I want to make a 4k thing with speech synth, then have it sing daisy bell
[15:49] <divVerent> haha
[15:49] <divVerent> THAT will get hard... in 4k, really hard
[15:50] <Tjoppen> 64k maybe
[15:50] <divVerent> probably less
[15:50] <divVerent> I'd guess this in the 16k range
[15:50] <divVerent> if it's enough if it sounds awkward
[15:50] <divVerent> but can be recognized
[15:51] <divVerent> espeak's phondata file with phonemes -> synth input mapping for all supported languages is 384k
[15:51] <Tjoppen> the music could fit in 4k. really lo-fi singing might fit (think vocoder)
[15:51] <divVerent> and you would hardcode the phonemes, not the words
[15:51] <divVerent> so you don't need any dictionary stuff
[15:51] <divVerent> and only the phonemes you use of course
[15:52] <divVerent> so even if you use espeak's tech, you'd probably fit all the data in 32k, and the code maybe 8k
[15:52] <divVerent> but then, you can do a lot simpler in many places
[15:52] <Tjoppen> I wonder how big the original ibm 360 program was
[15:53] <divVerent> to go really minimalistic, I'd expect somewhere around 32 bytes of data per phoneme
[15:53] <divVerent> for a song, I'd estimate you need about 20 to 50
[15:53] <divVerent> that's below 2k :P
[15:53] <divVerent> but wonder how bad it will sound then
[15:53] <divVerent> not human at all
[15:53] <divVerent> but may be enough to understand it
[15:53] <Tjoppen> https://www.youtube.com/watch?v=41U78QP8nBk in case you haven't seen it
[15:53] <Tjoppen> actually, I could just code it using my 1-bit DPCM codec
[15:54] <saste> libavcodec is full of undocumented options
[15:54] <saste> kinda fun
[15:54] <Tjoppen> https://www.youtube.com/watch?v=tEYH1-MY9s8 = slightly over one minute of PCM in 32 KiB on Atari 2600 :)
[15:54] <divVerent> Tjoppen: haha
[15:55] <divVerent> indeed... that's probably the worst part of it
[15:55] <divVerent> a speech synth for a single demo is probably not worth it
[15:55] <divVerent> if you can encode it with some audio codec too
[15:55] <divVerent> and hit the size
[15:55] <divVerent> kind of what makes 64M demos hard to be impressive
[15:55] <Tjoppen> feels like cheating though :)
[15:55] <divVerent> I failed at making a good one too... and in retrospect found 64M quite pointless
[15:56] <divVerent> none of them - even the winning one - did anything that's really impressive in comparison to a 63M H.264 video
[15:56] <Tjoppen> I like how the output of the codec in the video above made the song more interesting :)
[15:57] <divVerent> reminds me of... how people after a long time finally learned how to use the PC speaker
[15:57] <divVerent> for PCM
[15:57] <divVerent> http://www.youtube.com/watch?v=qTkxmE2AAoo - you probbaly remember the game
[15:58] <Tjoppen> ooh, 3d tetris
[15:58] <divVerent> the first "widespread" one using PC speaker PCM
[15:58] <divVerent> but only for the intro music
[15:58] <divVerent> and pitch varying between the systems a lot :P
[15:58] <divVerent> I remember it slower and lower
[15:58] <divVerent> and eventually then some guy made a Windows 3.1 speaker audio out driver... which was total crap
[15:59] <divVerent> as then one noticed what'S bad about PC speaker PCM
[15:59] <divVerent> any interrupt - i.e. keyboard, mouse move - broke it
[15:59] <divVerent> on today's CPUs it would work again, though :)
[16:00] <Tjoppen> https://www.youtube.com/watch?v=TWvKYkN3qOQ#t=40s you may have heard this
[16:01] <divVerent> no, but I'm not surprised demoscene did it first
[16:01] <divVerent> and blockout took it from there :)
[16:02] <saste> and a lot of questions to be answered (for example why we have the frame_number option?)
[16:08] <michaelni> saste, do you have time to look at the coverity issues in things you maintain (i see xface and ffprobe for example with untriaged issues)?
[16:08] <saste> michaelni, yes i'll try to have a look at them
[16:08] <saste> most of them are false positive, how should i mark them?
[16:09] <michaelni> as false positive in that case :)
[16:09] <saste> is there an option for that?
[16:09] <michaelni> Tjoppen, there are 3 untriaged coverity issues in mxfdec, can you take a look ?
[16:09] <saste> i get to familiarize with the interface
[16:09] <michaelni> saste, yes
[16:10] <michaelni> saste, "Classification" -> "False Positive"
[16:10] <saste> michaelni, what's your point on the libav* documentation thing?
[16:10] <michaelni> ?
[16:10] <michaelni> you mean the genaretd file?
[16:10] <saste> i'm starting to document libavcodec, but it's a lot of work
[16:10] <saste> i sent an email a few hours ago
[16:10] <michaelni> i thought its a bad idea if we replace machine work by human work
[16:10] <saste> I mean about that
[16:10] <Tjoppen> uhm, those are the same ones as before. I think
[16:11] <michaelni> Tjoppen, they are still marked as Classification=unclassified
[16:11] <Tjoppen> where?
[16:11] <saste> michaelni, the point is, sometimes you can't explain a complex option with a line
[16:11] <saste> also many options are not documented at all
[16:11] <Tjoppen> the "inferred use of enum" should be fixed
[16:11] <Tjoppen> I don't see my patch applied
[16:13] <michaelni> Tjoppen, you should mark things as bug+fix submitted in the web interface if you submit a patch
[16:13] <michaelni> and assign to you (for statistics mostly)
[16:14] <Compn> saste : i made a wish for framestep filter or way to start encoding on an exact frame > http://ffmpeg.org/trac/ffmpeg/ticket/1877
[16:14] <Compn> i think it can be done with framestep filter anyways...
[16:14] <Tjoppen> uh.. it should figure out that they're fixed
[16:14] <Tjoppen> IMO
[16:15] <michaelni> saste, true, but if you add copy a generated file and add improvments it cant be updated automatically anymore
[16:15] <saste> michaelni, I know
[16:15] <michaelni> improvments should be added somehow in the generation stuff
[16:15] <michaelni> Tjoppen,  it does figure this out when it tests things next time
[16:15] <saste> The point is
[16:15] <saste> do we want to document options?
[16:16] <michaelni> saste, yes we want
[16:16] <saste> current documentation sucks hard, with lot of cryptic or completely undocumented options
[16:16] <saste> noone knows how they work, apart (maybe) the original developers
[16:16] <saste> this is the current state of affairs
[16:16] <michaelni> true
[16:16] <saste> the inline documentation is meant to provide a short explanation
[16:17] <saste> that is an option is explained in just one line, which may or not suffice
[16:17] <saste> another thing that we lack, usually there is no hint about the range of the accepted values
[16:17] <michaelni> we could add longer explanations somewhere somehow and have the texi generator add them
[16:17] <michaelni> AVOptions has max/min
[16:18] <saste> another point is that there is no perfect mapping between option name, and variable name
[16:19] <saste> a possibility would be to do like I'm doing for libavfilter, I'm documenting each option in the manual
[16:19] <saste> the problem is that it implies some redundancy
[16:24] <Tjoppen> michaelni: fixed, afaict
[16:24] <Tjoppen> the js stuff is really slow
[16:26] <cone-448> ffmpeg.git 03Tomas Härdin 0784e7d368d6b4: mxfdec: Fix inferred misuses of enums
[16:27] <michaelni> Tjoppen, the owner list ? yes a trick for that is to just type your name in or part of it as it is faster when there are a few letters
[16:29] <michaelni> nevcairiel, do you want a coverity account ? i think you dont have one yet
[16:30] <nevcairiel> sure, why not
[16:34] <michaelni> nevcairiel, done, you should find login details in your spam folder within the next 24h or so i hope
[16:41] <nevcairiel> already got it, thanks
[16:41] <saste> Compn, framestep is already integrated
[16:42] <saste> Compn, also, what's wrong with using select?
[17:05] <saste> -qmin 0 => FPE
[17:10] <saste> why bitrate can be negative?
[17:10] <av500> some stuff is just to awful
[17:10] <av500> too*
[17:13] <saste> negative bitrate => steal bandwidth from your neighbors
[17:19] <av500> or, the movie watches you
[17:45] <cone-448> ffmpeg.git 03Michael Niedermayer 07304ebed58683: mpegts_probe: detect files with garbage at the begin.
[17:48] <saste> ubitux: why don't we link "platform" on the documentation section?
[17:48] <saste> in the website
[17:48] <saste> also, maybe we should move "official" documentation *before* community-contributed docs
[17:55] <saste> also linking very outdated tutorials in the main page doesn't look like a good idea
[17:55] <saste> maybe we should move them to the wiki and be done with that
[17:56] <ubitux> saste: why should i know? :D
[17:56] <saste> ubitux, before you was the last one which worked on that page
[17:56] <ubitux> please forget that i did :(
[17:57] <ubitux> iirc it really was in a pretty bad shape, so i just "fixed" a few things that came to my mind
[17:57] <ubitux> didn't thought much about it
[18:06] <cone-448> ffmpeg.git 03Michael Niedermayer 074695ee71b017: lavfi/fifo: add assert to ensure request was successfull.
[18:14] <ubitux> saste: note that i'm not a web maintainer, so maybe wait a little more
[18:16] <Compn> saste : select ? does it allow you to start on frame 343 exactly ?
[18:17] <saste> Compn, yes, but you have to *decode* all the frames
[18:18] <saste> there is no way to skip that, because our seek is not frame-accurate
[18:20] <saste> ubitux: I'm Following All Capitalized Stuff Convention
[18:20] <saste> consistency...
[18:21] <ubitux> ok, that really is just a nit, i don't really mind 
[18:21] <Compn> saste : thats acceptable, i just didnt know it were possible
[18:22] <Compn> saste : do you have a command line i can have, so i can put it in mplayer faq? :)
[18:25] <saste> Compn: select=gt(n, 342)
[18:26] <saste> Compn: select=gt(n, 341)
[18:26] <saste> depending on where you start to count from
[18:27] <ubitux> and now, sync the sound! :)
[19:00] <Compn> saste : thanks
[19:16] <saste> ubitux: going to push web changes
[19:17] <ubitux> as i said, i'm not web maintainer, but it doesn't look like these patches will hurt
[19:17] <ubitux> (as long as you don't forget tags.. :-°)
[19:21] <saste> yeah, already upped
[19:33] <saste> http://thread.gmane.org/gmane.comp.video.ffmpeg.user/16235/focus=16304
[19:33] <saste> still contains some useful comments about bitrate control in FFmpeg
[19:38] <cone-448> ffmpeg.git 03Stefano Sabatini 077669144adae9: doc/platform: Comply With All Capitalized Words Convention
[19:39] <ubitux> saste: where did that file end up?
[19:40] <ubitux> looks interesting
[19:40] <saste> which file?
[19:40] <saste> anywhere
[19:40] <ubitux> "This file tries to document the ratecontrol mechanism as implemented
[19:40] <ubitux> by ffmpeg."
[19:41] <ubitux> doesn't look like to be part of our documentation as is
[19:41] <saste> no and never will
[19:41] <ubitux> :(
[19:42] <saste> that period i was working with stuff related to bitrate control and I had to read some documents about it
[19:42] <saste> but never managed to figure out how the FFmpeg mechanism works
[19:42] <ubitux> :D
[19:42] <saste> now bitrate control documentation may end up in libavcodec.texi
[19:42] <saste> if people don't bikeshed too much
[19:43] <saste> soon or later, but don't hold your breath
[20:19] <joelataylor> can anyone help me with this: http://pastie.org/5168125
[20:28] <cone-448> ffmpeg.git 03Michael Niedermayer 07bacebe1f952d: avienc: force a valid timebase for video
[21:30] <cbsrobot> joelataylor: check #ffmpeg
[21:31] <joelataylor> I did, thx :)
[22:02] <cone-448> ffmpeg.git 03Michael Niedermayer 07f742c7b2cef7: lavf: fix integer overflow in rfps calculation
[22:15] <cone-448> ffmpeg.git 03Marton Balint 0700b70f8d2996: ffplay: add update parameter to fill_rectangle
[22:15] <cone-448> ffmpeg.git 03Marton Balint 0765f6c42a9f12: ffplay: fill the unused part of the window with black
[22:15] <cone-448> ffmpeg.git 03Marton Balint 07abd49a75240f: ffplay: always free inputs and outputs in configure_filtergraph
[22:15] <cone-448> ffmpeg.git 03Marton Balint 07afd9e705dea7: ffplay: check for buffersink_params allocation success
[22:15] <cone-448> ffmpeg.git 03Marton Balint 0709214f494b2c: ffplay: remove uneeded format filter, buffersink format is set
[22:15] <cone-448> ffmpeg.git 03Marton Balint 078cb740245daf: ffplay: always free buffersink_params in configure_video_filters
[22:15] <cone-448> ffmpeg.git 03Marton Balint 07fdb933444add: ffplay: only initialize codec opts before using it
[22:15] <cone-448> ffmpeg.git 03Marton Balint 07fec39d99d636: ffplay: remove redundant !codec check
[22:15] <cone-448> ffmpeg.git 03Michael Niedermayer 07099786a638cf: Merge remote-tracking branch 'cus/stable'
[23:48] <Pinhole> We are considering running libavcodec on a slave processor (no OS, shared memory) to accelerate playing mpeg video.  Any thoughts, warnings, gotchas, etc?
[00:00] --- Fri Nov  2 2012