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

[burek]

[02:26] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * r76888c64b0 10ffmpeg/libavcodec/x86/rv34dsp.asm: rv34: port x86 SIMD to cpuflags.
[02:26] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * r158744a4cd 10ffmpeg/libavcodec/x86/ (vp56dsp.asm vp56dsp_init.c): 
[02:26] <CIA-41> ffmpeg: vp56: only compile MMX SIMD on x86-32.
[02:26] <CIA-41> ffmpeg: All x86-64 CPUs have SSE2, so the MMX version will never be used. This
[02:26] <CIA-41> ffmpeg: leads to smaller binaries.
[02:26] <CIA-41> ffmpeg: 03Martin Storsjö 07master * r41ecbbc7aa 10ffmpeg/libavformat/tls.c: (log message trimmed)
[02:26] <CIA-41> ffmpeg: tls: Return AVERROR_EOF if the TLS_read/write functions return 0
[02:26] <CIA-41> ffmpeg: OpenSSL returns 0 when the peer has closed the connection. GnuTLS
[02:26] <CIA-41> ffmpeg: doesn't return that though, but returns
[02:26] <CIA-41> ffmpeg: GNUTLS_E_UNEXPECTED_PACKET_LENGTH if the connection simply is closed
[02:26] <CIA-41> ffmpeg: without a clean close notify packet.
[02:26] <CIA-41> ffmpeg: Tested-by: Antti Seppälä <a.seppala at gmail.com>
[02:26] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * r2734ba787b 10ffmpeg/libavcodec/x86/vp56dsp.asm: vp56: port x86 simd to cpuflags.
[02:26] <CIA-41> ffmpeg: 03Martin Storsjö 07master * r8ebacfb598 10ffmpeg/libavformat/hls.c: (log message trimmed)
[02:26] <CIA-41> ffmpeg: hls: Proceed to the next segment at any error code
[02:26] <CIA-41> ffmpeg: Previously, we returned any error code except AVERROR_EOF to the
[02:26] <CIA-41> ffmpeg: caller - only if AVERROR_EOF or 0 was returned, we proceeded to
[02:26] <CIA-41> ffmpeg: the next segment.
[02:26] <CIA-41> ffmpeg: With some setups of web servers, using Connection: close in https
[02:26] <CIA-41> ffmpeg: and GnuTLS, we don't get a clean error code at the end of segments.
[02:26] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * rd07ff3cd5a 10ffmpeg/libavcodec/x86/ (dsputil_mmx.c h264_chromamc_10bit.asm): h264_chromamc_10bit: port x86 simd to cpuflags.
[02:26] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r23565c2641 10ffmpeg/ (Makefile configure): 
[02:26] <CIA-41> ffmpeg: build: support non-standard replacements for -c flag
[02:26] <CIA-41> ffmpeg: This allows non-standard replacements for the -c compiler flag.
[02:26] <CIA-41> ffmpeg: Some compilers use other flags or no flag at all in place of
[02:26] <CIA-41> ffmpeg: the usual one.
[02:26] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[02:26] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * ra5bbb1242c 10ffmpeg/libavcodec/x86/ (h264_deblock.asm h264_deblock_10bit.asm h264dsp_mmx.c): h264_loopfilter: port x86 simd to cpuflags.
[02:26] <CIA-41> ffmpeg: 03Anton Khirnov 07master * refd34918ba 10ffmpeg/libavformat/utils.c: lavf: remove commented out cruft in avformat_find_stream_info()
[02:26] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * r4d777eedfd 10ffmpeg/libavcodec/x86/ (vp3dsp.asm vp3dsp_init.c): 
[02:26] <CIA-41> ffmpeg: vp3: don't compile mmx IDCT functions on x86-64.
[02:26] <CIA-41> ffmpeg: 64-bit CPUs always have SSE2, and a SSE2 version exists, thus the MMX
[02:26] <CIA-41> ffmpeg: version will never be used.
[02:26] <CIA-41> ffmpeg: 03Diego Biurrun 07master * rbfe9f48ad7 10ffmpeg/configure: configure: Move parts that should not be user-selectable to CONFIG_EXTRA
[02:26] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r0aa907cfb1 10ffmpeg/libavcodec/vc1dec.c: 
[02:26] <CIA-41> ffmpeg: vc1dec: Do not ignore ff_vc1_parse_frame_header_adv return value
[02:26] <CIA-41> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[02:27] <CIA-41> ffmpeg: 03Anton Khirnov 07master * r61f8bb74f3 10ffmpeg/libavformat/mp3dec.c: mp3dec: remove commented out cruft.
[04:11] <CIA-41> ffmpeg: 03Paul B Mahol 07master * ra3a0774be8 10ffmpeg/libavformat/ (Makefile allformats.c wvenc.c): WavPack muxer
[04:11] <CIA-41> ffmpeg: 03Paul B Mahol 07master * rbd93f96540 10ffmpeg/libavformat/ (Makefile apetag.h apetagenc.c): APE tag writer
[04:11] <CIA-41> ffmpeg: 03Paul B Mahol 07master * rc25dc1f9c7 10ffmpeg/libavformat/wvenc.c: 
[04:11] <CIA-41> ffmpeg: wvenc: support for ape tags
[04:11] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[04:27] <CIA-41> ffmpeg: 03Paul B Mahol 07master * rc3c9c4d006 10ffmpeg/doc/general.texi: 
[04:27] <CIA-41> ffmpeg: doc/general: add missed WavPack muxing support information
[04:27] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[04:27] <CIA-41> ffmpeg: 03Paul B Mahol 07master * r29ba3aacb1 10ffmpeg/libavformat/smacker.c: 
[04:27] <CIA-41> ffmpeg: lavf/smacker: remove bogus video from .long_name
[04:27] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[04:32] <CIA-41> ffmpeg: 03Paul B Mahol 07master * re4f3a9693d 10ffmpeg/libavformat/ (apetag.c apetag.h apetagenc.c): 
[04:32] <CIA-41> ffmpeg: lavf/apetag: move common stuff between writer and reader to single file
[04:32] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[11:48] <ubitux> is it me or the convergence_duration is actually never used?
[11:49] <ubitux> (since it's been removed from mkv mux & demuxer)
[12:32] <nevcairiel> mkv demux still uses it
[12:32] <nevcairiel> unless duration is changed to int64 some day, it also has to or the duration will just overflow
[12:34] <nevcairiel> or you cant have subtitles longer then 2-something seconds in MKVs with nanosecond timebase
[12:34] <ubitux> mmh what did i smoke again.
[12:35] <ohsix> for when theres 40 million fps video
[12:57] <saste> 40 million fps video: useful when filming the big bang
[12:58] <ubitux> speaking of this, i just saw http://www.ted.com/talks/ramesh_raskar_a_camera_that_takes_one_trillion_frames_per_second.html
[13:10] <iive> wasn't that one that actually was taking one pixel at a time, so it relied on repeating the same event over and over again?
[13:10] <iive> i think they filmed how the light is moving.
[13:11] <ubitux> yeah afaiu they send the light several time with shift
[13:13] <ubitux> lavfi question: assuming i have a filter with same input & output format/sizes, in case of NULL start_frame callback, the out_buf will be set to a new similar buffer; can I assume the linesizes are the same for src & dst?
[13:13] <ubitux> iirc linesize includes the padding, may it differs between the two?
[13:17] <ohsix> if you could assume that, it would be API, and for that it's a poopy thing to guarantee :p
[13:20] <saste> ubitux: no
[13:20] <ubitux> ok :(
[13:20] <saste> ubitux: the default start_frame() will call get_buffer on the next frame
[13:21] <saste> you could have a pad for example, which will allocate a buffer with a big linesize
[13:21] <ubitux> mmh i see
[13:21] <saste> so you can't do predictions on the linesizes
[13:22] <ubitux> ok, thx
[13:37] <maker> uhm, I'm taking some examples from libavfilter/vf_* for creating mine; but (excluding multimedia.cx docs, which as michaelni said, it's obsolete), I see from doxygen that draw_slice should be used for processing
[13:38] <maker> even though most of the filters uses start_frame for processing the link->cur_buf->video->data. Am I missing something?
[13:40] <saste> maker: draw_slice is useful when you can process frame slices independently
[13:41] <saste> that's not true for all the filters, and sometimes it is simpler to do all the processing at once in end_frame()
[13:41] <saste> the idea is that slicing processing should improve overall performance relying on cache locality principle
[13:42] <saste> so it really depends on the filter logic, and if it slice processing is worth the extra complexity
[13:43] <saste> check drawbox for a simple example
[13:46] <maker> Ok, I was referring to crop an vflip, which are nearest to what I intend to do. 
[13:47] <maker> Also, what are planes?
[13:55] <saste> maker: an images usually consists of several planes
[13:55] <saste> a planes contains several related pixels, depending on the pixel layout
[13:56] <saste> for example for RGB you have a single plane containing the sequence of RGBRGBRGB... pixels
[13:56] <saste> with planar YUV you have a single plane for Y, U, and V
[13:56] <saste> you can have planar RGB when you store each "channel" on a different plane
[13:57] <saste> pixfmt.h should explain this, once you get the idea
[13:57] <saste> layout information is stored in lavutil/pixdesc.h
[13:57] <maker> Thanks!
[13:58] <saste> you can choose the better layout which fits with your filtering logic, and let the explicit conversion to the framework
[13:59] <saste> *leave the explicit...
[14:00] <ubitux> http://ubitux.fr/pub/pics/edgedetect.png 
[14:00] <saste> ubitux: sobel?
[14:01] <ubitux> yep
[14:01] <ubitux> do we have that already?
[14:01] <saste> ubitux: no, only in frei0r
[14:02] <saste> but there are several edge detector operators, we could make it configurable
[14:03] <ubitux> i was trying to make a canny edge detector
[14:04] <ubitux> right now i'm just using boxblur filter + manual sobel
[14:04] <saste> also a generic convolution filter may help
[14:04] <ubitux> i also have a gaussian filter but i need to play with several buffers within the filter
[14:04] <ubitux> i'm not sure how to do that yet
[14:05] <saste> ubitux: i'm reading the buffer permission thread, i should reply to it today, then we shall improve documentation on that still somewhat obscure area
[14:06] <ubitux> yeah would be nice :)
[15:55] <saste> ubitux: would you mind posting your rdft patch as a WIP or an RFC, that may also help in the discussion related to buffer perms
[15:55] <ubitux> i already did a month ago or two
[15:55] <ubitux> iirc.
[15:56] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-May/125037.html
[15:56] <ubitux> not much up to date though
[15:56] <ubitux> i'll rebase & resubmit in a few hours
[15:57] <saste> ah ok, i completely forgot, thanks
[15:58] <ubitux> if you want filter examples for the buffer perms stuff
[15:58] <ubitux> color is a nice one
[15:58] <ubitux> (re-use the same local buffer ref)
[15:58] <ubitux> showspectrum is indeed a good candidate because there is the issue of updating a local bufferref
[15:59] <saste> does color do it now?
[15:59] <ubitux> nope iirc
[15:59] <ubitux> Nicolas pointed that out when durandal_1707 was trying to submit the color bars filter
[15:59] <saste> yes indeed
[16:00] <ubitux> and another hypothetical candidate, in the exact same spirit of showspectrum, would be an histogram video filter which i'd like to write
[16:00] <durandal_1707> hey please finish that color bars filter (i'm not going to back to it anytime soon)
[16:01] <ubitux> saste: and btw that might also applies for showwaves; if given N samples you can't raise a complete frame, maybe it could raise a duplicate of the previous
[16:02] <saste> ubitux: no i don't like that very much, at least for the default behavior
[16:02] <ubitux> ok
[16:02] <saste> durandal_1707: ok, i'll try to update your patch
[16:07] <saste> i wonder if it would be a good time to drop the deprecated syntax of color, so I can merge it with testsrc
[16:09] <durandal_1707> saste: drop it
[16:21] <CIA-41> ffmpeg: 03Nicolas George 07master * r5c81a9ff55 10ffmpeg/libavcodec/libx264.c: 
[16:21] <CIA-41> ffmpeg: libx264: list possible profiles.
[16:21] <CIA-41> ffmpeg: The values are listed if setting them fails.
[16:21] <CIA-41> ffmpeg: Using "-profile help" or "-profile list" have that effect.
[16:21] <CIA-41> ffmpeg: Similar to 3aba391.
[16:21] <CIA-41> ffmpeg: Suggested by "rogerdpack" in trac ticket #1529.
[16:32] <nyuhu> I've been getting a grey image when testing my filter port (hue) and Ive just realized that it also does that when I dont do any processing at all in the end_frame function (i.e. just making a call to ff_end_frame) ; any idea of what could be the cause ? this looks like a rookie mistake imo&
[16:33] <CIA-41> ffmpeg: 03Nicolas George 07master * r981d97f697 10ffmpeg/doc/filters.texi: doc/filters: document TB variable for vf_setpts.
[16:34] <ubitux> nyuhu: is there any auto inserted scale filter (look at the cli output)?
[16:35] <ubitux> if so you might have requested a gray input or output somewhere
[16:35] <ubitux> (check your query_formats)
[16:36] <nyuhu> no I didnt put any gray format in my query_formats function
[16:37] <nyuhu> and it doesnt seem like theres an auto inserted scale
[16:37] <durandal_1707> nyuhu: where is output?
[16:38] <nyuhu> what do you mean ?
[16:40] <durandal_1707> for that problem you have
[16:41] <ubitux> nyuhu: what's your command line?
[16:42] <nyuhu> ./ffplay test-2.mp4 -vf hue=0:1
[16:44] <saste> nyuhu: post the code on pastebin
[16:45] <nyuhu> http://pastebin.com/2hd71jTY
[16:50] <saste> nyuhu: ok so you're using the default start_frame, a buffer is requested on the output link, and stored in outlink->out_buf
[16:50] <saste> then you don't write nothing to this buffer, so it will in general contain just random data (or it will be zeroed, can't remember)
[16:51] <nyuhu> oh I see
[16:52] <saste> what happens when you actually *write* into out_buf?
[16:52] <nyuhu> then I would have to put the input link buffer in the output link buffer if I didnt want to do anything right ?
[16:53] <nyuhu> gray image too
[16:53] <saste> you will have to *copy* the data from inlink->cur_buf  to outlink->out_buf
[16:54] <nyuhu> (well this is true when I test it with hue = 0 and saturation = 1, which would of course output the same image ; the other cases need some debugging)
[16:54] <saste> out->data[0]     = in->data[0];
[16:54] <saste> this is wrong
[16:56] <saste> you're making out_buf  pointing to the data contained in cur_buf
[16:56] <nyuhu> yes
[16:57] <saste> forget about the special cases for now, consider the input and output buffers as distinct entities
[16:57] <nyuhu> got it
[16:57] <saste> there are some subtleties involved with buffer management, anyway you're not supposed to change the pointers to data in a buffer
[16:58] <nyuhu> thank you !
[17:33] <ubitux> saste: ok it seems i don't leak anymore actually
[17:33] <saste> heisenbug?
[17:33] <saste> maybe the anton changes helped in that regard
[17:34] <ubitux> possible
[17:35] <ubitux> i'm adding the color and will re-submit
[17:58] <ubitux> saste: isn't insamples->audio->channel_layout always supposed to be set when calling filter samples?
[17:59] <ubitux> seems it is assumed to be correctly set
[18:00] <saste> ubitux: I think so, but that shouldn't be strictly required since most filters don't care about what is written there and assume the configured value in the link
[18:00] <saste> that's the same as for picref->video->w/h
[18:00] <saste> but yes it's better to set it anyway, since a filter may read from it
[18:01] <ubitux> ./ffmpeg -f lavfi -i 'aevalsrc=sin(440*2*PI*t)' -t 5 -ac 2 -y test.wav
[18:02] <ubitux> then try to showwaves it
[18:02] <ubitux> ./ffplay -f lavfi "amovie=test.wav,asplit[out1],showwaves=s=640x480[out0]"
[18:02] <ubitux> ’ div by 0 since the invalid channel layout leads to nb_channels = 0
[18:10] <ubitux> seems like i just found another issue
[18:11] <ubitux> wget 'lucy.pkh.me/samples/6ch.flac' && ./ffplay -f lavfi 'amovie=6ch.flac,aformat=channel_layouts\=stereo'
[18:11] <ubitux> ’ segfault
[18:35] <saste> ubitux: why chlayout is not set in the samples buffer?
[18:55] <ubitux> saste: why do you ask me? :))
[18:56] <saste> ubitux: don't know, maybe you already debugged it ;^)
[18:56] <ubitux> nop i just love raising problems
[18:58] <saste> the problem is that chlayout is not set in the AVFrame
[18:58] <maker> lol
[19:01] <saste> and it is not set in AVFrame because it was not set in the codec context
[19:12] <saste> michaelni: what's the best way to deal with an unknown chlayout in the decoder?
[19:13] <Daemon404> doesnt have have a predefie nd layour for 5ch
[19:13] <Daemon404> er 6ch
[19:13] <Daemon404> doesnt flac*
[19:13] <saste> should be set in avcodec_open() to the chlayout guessed from the number of channels? or should we leave it to 0 in case it is not explicitely defined by the decoder?
[19:15] <saste> Daemon404: the problem is not only with flac, i have the very same problem with pcm and 8svx streams
[19:15] <michaelni> hmm, if the decoder spec specifies some default then that should be used
[19:15] <michaelni> otherwise iam tending to suggest to leave it 0
[19:16] <saste> ok, maybe we should specify that in the docs (chlayout = 0 => unspecified/unknown)
[19:16] <michaelni> yes
[19:18] <saste> on the other hand at the filtering level we always need to set it in the samples buffer
[19:19] <michaelni> why?
[19:21] <ubitux> saste: i've updated my showspectrum branch; but i still have issues with cluttered playback in some cases
[19:22] <ubitux> (i've added the colors and there is no leak though)
[19:22] <ubitux> (i'm sure i've messed the permissions though)
[19:22] <saste> michaelni: some filters read chlayout and use that value for getting the nb channels
[19:23] <michaelni> so it will crash if i set 1 channel layout=stereo ?
[19:24] <saste> michaelni: why, can you really have that situation?
[19:24] <saste> anyway yes, the number of channels info is guessed from the chlayout
[19:24] <saste> same is for links iirc
[19:26] <saste> also in the frame we store the chlayout info, which is then read and passed to the lavfi samplesref
[19:26] <saste> since there is no channels field in AVFrame, the only way to pass the nb_channels info is through the chlayout
[19:28] <michaelni> a decoder surely could set the layout and channels to inconsistent values
[19:31] <saste> i see several possible solutions: we always set the chlayout information in AVFrame, if not specified we use get_ch_layout_nb_channels()
[19:32] <saste> at the decoding stage we're sure that chlayout is consistent with nb_channels, or the open function will complain and fail
[19:32] <michaelni> it could be changed after open
[19:33] <michaelni> i think a channels field shoudl be added to AVFrame
[19:33] <michaelni> otherwise a unknown channel layout with X channels becomes tricky
[19:34] <michaelni> also do we have a sane default channel layout for any number of channels ?
[19:38] <saste> up to 8 channels
[19:48] <michaelni> so 9 channels will fail if theres no channel layout stored
[22:04] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r72dabdfc58 10ffmpeg/libavcodec/ (aacpsy.c psymodel.c psymodel.h): 
[22:04] <CIA-41> ffmpeg: aacenc: new default cutoff
[22:04] <CIA-41> ffmpeg: Improves subjective quality
[22:04] <CIA-41> ffmpeg: Formula and testing by: kamedo2 <fujisakihir90 at yahoo.co.jp>
[22:04] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:09] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * rdcb7ef5483 10ffmpeg/ (avconv.c avprobe.c): avprobe/avconv: fix tentative declaration compile errors on MSVS.
[23:09] <CIA-41> ffmpeg: 03Loren Merritt 07master * r60b9785530 10ffmpeg/libavfilter/vf_hqdn3d.c: 
[23:09] <CIA-41> ffmpeg: vf_hqdn3d: cosmetics
[23:09] <CIA-41> ffmpeg: Change code style to match the rest of libav.
[23:09] <CIA-41> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[23:09] <CIA-41> ffmpeg: 03Loren Merritt 07master * rfb44e7401f 10ffmpeg/libavfilter/ (vf_delogo.c vf_gradfun.c video.c video.h): 
[23:09] <CIA-41> ffmpeg: factor identical ff_inplace_start_frame out of two filters
[23:09] <CIA-41> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[23:09] <CIA-41> ffmpeg: 03Loren Merritt 07master * r1ad715dbf3 10ffmpeg/libavfilter/vf_hqdn3d.c: 
[23:09] <CIA-41> ffmpeg: vf_hqdn3d: support 9 and 10bit colordepth
[23:09] <CIA-41> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[23:09] <CIA-41> ffmpeg: 03Loren Merritt 07master * r85e228c71d 10ffmpeg/libavfilter/vf_hqdn3d.c: 
[23:09] <CIA-41> ffmpeg: vf_hqdn3d: simplify and optimize
[23:09] <CIA-41> ffmpeg: 14% faster on penryn, 2% on sandybridge, 9% on bulldozer
[23:09] <CIA-41> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[23:09] <CIA-41> ffmpeg: 03Anton Khirnov 07master * rfe1c1198e6 10ffmpeg/ (3 files in 2 dirs): (log message trimmed)
[23:09] <CIA-41> ffmpeg: lavf: use dts difference instead of AVPacket.duration in find_stream_info()
[23:09] <CIA-41> ffmpeg: AVPacket.duration is mostly made up and thus completely useless, this is
[23:09] <CIA-41> ffmpeg: especially true for video streams.
[23:09] <CIA-41> ffmpeg: Therefore use dts difference for framerate estimation and
[23:09] <CIA-41> ffmpeg: the max_analyze_duration check.
[23:09] <CIA-41> ffmpeg: The asyncts test now needs -analyzeduration, because the default is 5
[23:09] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r7c26761b81 10ffmpeg/: (log message trimmed)
[23:09] <CIA-41> ffmpeg: Merge commit 'fe1c1198e670242f3cf9e3e1eef27cff77f3ee23'
[23:09] <CIA-41> ffmpeg: * commit 'fe1c1198e670242f3cf9e3e1eef27cff77f3ee23':
[23:09] <CIA-41> ffmpeg:  lavf: use dts difference instead of AVPacket.duration in find_stream_info()
[23:09] <CIA-41> ffmpeg:  avf: introduce nobuffer option
[23:09] <CIA-41> ffmpeg:  fate: make yadif tests consistent across systems
[23:09] <CIA-41> ffmpeg: 03Loren Merritt 07master * r0f583e6cc5 10ffmpeg/libavfilter/vf_hqdn3d.c: 
[23:09] <CIA-41> ffmpeg: vf_hqdn3d: reduce intermediate precision
[23:09] <CIA-41> ffmpeg: 11% faster on penryn, 7% on sandybridge, 5% on bulldozer
[23:09] <CIA-41> ffmpeg: Negligible change to output.
[23:09] <CIA-41> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[00:00] --- Mon Jul 30 2012