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

[burek]

[10:30] <ubitux> can we make output -ss faster transparently? (aka without manual initial input seeking)
[10:43] <ubitux> can't we make sure that -ss X -i ... -ss 0 will be as accurate?
[10:43] <ubitux> (and do it transparently)
[11:03] <ubitux> llogan: so, how is the twitter status?
[11:08] <cone-82> ffmpeg.git 03Maxim Poliakovski 07master:852241561d04: atrac: Add missing av_cold.
[11:08] <cone-82> ffmpeg.git 03Maxim Poliakovski 07master:cc2330fe3a01: atrac: Update copyright info and file description.
[11:08] <cone-82> ffmpeg.git 03Maxim Poliakovski 07master:3d80ab015fa1: atrac: Move doxygen comments to the header
[11:08] <cone-82> ffmpeg.git 03Maxim Poliakovski 07master:746cb9bc53f7: atrac: limit line length to 80 chars
[11:08] <cone-82> ffmpeg.git 03Maxim Poliakovski 07master:dc80e250fc66: atrac3: Rename GainInfo to AtracGainInfo
[11:08] <cone-82> ffmpeg.git 03Maxim Poliakovski 07master:4978be2bc698: atrac3: rename num_gain_data to num_points
[11:08] <cone-82> ffmpeg.git 03Maxim Poliakovski 07master:4fa2484067d1: atrac3/decode_gain_control: cosmetics
[11:08] <cone-82> ffmpeg.git 03Maxim Poliakovski 07master:d49f3fa5794c: atrac3: Generalize gain compensation code
[11:10] <ubitux> erm it seems the double seek isn't that accurate
[11:11] <ubitux> it seems better to only input seek sometimes
[11:54] Action: Daemon404 begins to bisect
[11:54] <Daemon404> perfect way to start my day~
[12:08] <durandal_1707> what broke?
[12:11] <Daemon404> durandal_1707, a file works with libav and not ffmpeg
[12:11] <Daemon404> im fixing it
[12:14] <saste> do we have some way to validate XML strings?
[12:15] <ubitux> saste: you can check for valid utf-8
[12:15] <ubitux> if it's not, drop the char., or maybe there is something like &#FF
[12:17] <saste> i'll drop all the invalid characters, and emit a warning (ffprobe)
[12:19] <ubitux> will you do that only for xml?
[12:19] <ubitux> json should be safe but i'm not so sure
[12:20] <Daemon404> json is required to be utf8
[12:20] <Daemon404> isnt it
[12:21] <ubitux> yes, but what if it isnt?
[12:21] Action: Daemon404 remembers the iconv mess
[12:21] <Daemon404> :/
[12:21] <Daemon404> yeah.
[12:21] <ubitux> the question is if the json output is going to be valid all the time
[12:21] <ubitux> we assume libs will extract utf-8
[12:21] <ubitux> but sometimes, it's "broken" utf-8, and you're fucked
[12:22] <Daemon404> what about e.g. shift-jis tags
[12:22] <Daemon404> in an mp3
[12:22] <ubitux> should be converted in the format
[12:22] <ubitux> IMO
[12:22] <Daemon404> i agree
[12:22] <Daemon404> but do we
[12:22] <Daemon404> is what i meant
[12:22] <ubitux> i don't think so
[12:22] <Daemon404> yeah
[12:24] <saste> ubitux, i'll fix it right at the ffprobe level, but it should be probably done at the library level, right?
[12:24] <saste> somewhere in libavformat, but i don't know well where
[12:25] <ubitux> dict set? :)
[12:25] <ubitux> gonna get slow
[12:25] <ubitux> it's fine at ffprobe level for now
[12:43] <BBB> llogan: the first 2 can go, the last one should probably be approved
[12:45] <cone-82> ffmpeg.git 03Paul B Mahol 07master:7d0ce1e59df8: avfilter/af_silencedetect: use the name 's' for the pointer to the private context
[12:45] <ubitux> lol
[12:46] <durandal_1707> i_can_not_stand_extremly_long_names_for_filter_private_context
[12:48] <saste> s
[12:49] <saste> find a compromise...
[12:51] <GoaLitiuM> icnselnffpc
[12:53] <iive> avpc
[12:56] <cone-82> ffmpeg.git 03Clément BSsch 07master:e31a239fea65: avfilter/vf_removelogo: use the name 's' for the pointer to the private context
[12:56] <saste> please guys, fix actual issues
[12:57] <saste> (unless you're working on some piece of code, and cosmetics simplifies your work)
[12:57] <durandal_1707> having less to type means i will have more times to fix actuall issues
[12:58] <saste> durandal_1707, OTOH s-> is not very readable out of context (e.g. when reviewing a patch)
[12:58] <durandal_1707> if you want to get real commits in tree, you could review patches on ml
[13:00] <durandal_1707> in lavfi: ctx is AVFilterContext and s is private filter context
[13:01] <saste> durandal_1707, ping if you are waiting for some review from me
[13:01] <michaelni_> someone should review the fixed point decoder patches
[13:01] <michaelni_> or ill eventually just apply them (if they pass all tests i end up trying) ...
[13:03] <durandal_1707> i usally do not review stuff i have 0 experience with
[13:04] <ubitux> saste: durandal_1707 is picking my commits
[13:04] <ubitux> from an old branch called...
[13:05] <durandal_1707> i just picked some extremly old ones
[13:05] <ubitux> most-boring-thing-ever-and-i-dont-want-to-finish-this-shit
[13:06] <ubitux> durandal_1707: make sure they are correct btw
[13:06] <durandal_1707> s/old/long
[13:11] <ubitux> hey saste 
[13:11] <ubitux> are you going to fix the examples? :)
[13:11] <ubitux> i know i'm annoying :(
[13:11] <saste> ubitux, not yet
[13:12] <saste> what will I win if I do?
[13:12] <saste> i'm actually fixing some boring validation issues in ffprobe
[13:12] <ubitux> the right to backport it
[13:12] <ubitux> yeah
[13:12] <ubitux> that's also useful
[13:13] <ubitux> on a side note, it still seems no one gives a shit about subtitles
[13:13] <ubitux> :D
[13:13] <ubitux> ...or everyone is smart enough to avoid them :(
[13:13] <durandal_1707> well where is subtilte filtering?
[13:14] <ubitux> durandal_1707: i'm raising the question in my last mail
[13:14] <ubitux> at least that's the first step
[13:14] <ubitux> before it's injected in lavfi
[13:14] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:0425fd7eb218: ffmpeg: dont return reserved values
[13:23] <Daemon404> how nice
[13:24] <Daemon404> ffbisect actually manages to increase "steps left"
[13:24] <Daemon404> during bisecting
[13:25] <Daemon404> now ive been stuck at 6 steps left for about 5 steps
[13:31] <saste> what should I do with invalid chars?
[13:31] <saste> ignore them, or substitute with funny ? chars?
[13:31] <saste> or let the user what to do with it?
[13:32] <saste> decide what...
[13:32] <ubitux> in python you can drop/replace
[13:33] <iive> saste: even iconv have translation modes with the above options.
[13:34] <iive> for subtitles probably funny ? is the best option... silently dropping them may make users think everything works as it should.
[13:34] <ubitux> saste: http://docs.python.org/2/library/functions.html#unicode
[13:34] <saste> uhm, that means i should link ffprobe with external libs just because of that?
[13:35] <ubitux> saste: 'strict' => fails, 'replace' => replace with '?', 'ignore' => replace with ' '
[13:35] <ubitux> no
[13:35] <ubitux> assume utf-8
[13:35] <saste> uhm yes, this will mean more work though...
[13:35] <ubitux> if it's not, pick one mode
[13:35] <ubitux> saste: checking for utf-8 is already possible
[13:35] <ubitux> that's what we do for subtitles
[13:35] <saste> the good thing is that I don't need to check all strings, only metadata
[13:42] <cone-82> ffmpeg.git 03Paul B Mahol 07master:848a1e67381e: avfilter/af_afade: use the name 's' for the pointer to the private context
[13:42] <cone-82> ffmpeg.git 03Clément BSsch 07master:3841e4510b5a: avfilter/avf_showspectrum: use the name 's' for the pointer to the private context
[13:58] <BBB> Daemon404: if stuff breaks/fixes like that, maybe add a fate test to prevent regressions in the future (both one broken by that patch as well as one fixed by that patch, once it's refixed)
[13:58] <Daemon404> BBB, i plan to
[13:58] <BBB> cool
[13:58] <Daemon404> i need to get the sample cleared to be public though
[13:59] <Daemon404> its pretty epic btw
[13:59] <Daemon404> it's a right-wing radio show
[13:59] <Daemon404> with a giant "FREEDOM FARM" sign
[13:59] <Daemon404> too bad i can't dl the original sample that reimar had..
[14:04] <Compn> i dont even know what kind of url that is
[14:04] <Compn> playlist.yahoo.com 
[14:05] <Compn> i dont remember anything like that. with multiple h264 ? 
[14:05] <Compn> sounds like some kind of super hacky yahoo video playlist thing
[14:07] <durandal_1707> michaelni_: for some strange reason mergeplanes filter when encoding to ffv1 get yuv420p replaced by yuv444p causing wrong output
[14:07] <Compn> Daemon404 : looks like yahoo changed their site in 2012, so that url is gone forever :P
[14:07] <durandal_1707> encoding to png works as expected
[14:08] <durandal_1707> same happens to h264
[14:08] <saste> more work than expected...
[14:09] <durandal_1707> why it overwrites format set in config_props for outlink?
[14:10] <durandal_1707> here is command: -lavfi "extractplanes=y+u+v[y][u][v],[y]edgedetect[yy],[yy][u][v]mergeplanes=y+u+v"
[14:13] <durandal_1707> perhaps i need to do same hack is done in scale filter?
[14:16] <durandal_1707> why is config_props for lavfi nowhere explained?
[14:16] <durandal_1707> ahh it is explained in header
[14:16] <durandal_1707> one can not set format in config_output
[14:22] <durandal_1707> this sucks
[14:26] <durandal_1707> why is there silence?
[14:47] <ubitux> i just ran a few tests
[14:47] <ubitux> checking if input seeking + output seeking to get (faster) accurate seek
[14:48] <ubitux> sometimes it's accurate (while a standalone input seek wasn't), but a lot of times it differs
[14:48] <ubitux> so it's not as reliable as a simple accurate/output seeking
[14:48] <ubitux> :(
[14:54] <cone-82> ffmpeg.git 03Martin Storsjö 07master:cc41167aede4: asfdec: Check the return value of asf_read_stream_properties
[14:54] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:8aa6ffd8fa64: Merge commit 'cc41167aede4c101ad17eeffa8f39bb6c23d3dad'
[14:58] <durandal_1707> ubitux: seeking of what?
[14:58] <ubitux> video files
[14:58] <ubitux> failure is not format specific
[14:58] <ubitux> it happens sometimes with mp4, avi, flv, ...
[14:59] <cone-82> ffmpeg.git 03Luca Barbato 07master:ad0560fe7491: mxf: Remove a typo
[14:59] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:c28bca2bdef6: Merge commit 'ad0560fe7491a85c3e71d5a3d6a0443f10b33ab1'
[15:04] <ubitux> durandal_1707: http://pastie.org/8372072
[15:04] <ubitux> see this for instance
[15:06] <durandal_1707> why -strict -2
[15:06] <cone-82> ffmpeg.git 03Luca Barbato 07master:628a17d78ac1: rtmp: alias rtmp_listen to listen
[15:06] <ubitux> it was because i was testing with mp4 previously
[15:06] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:5e253fdfc1a4: Merge remote-tracking branch 'qatar/master'
[15:06] <ubitux> and audio was aac
[15:08] <Daemon404> Compn, which is why you save samples!
[15:08] <Daemon404> and add to fate or mplayer archive
[15:09] Action: ubitux doesn't feel like debugging seeking timestamps in ffmpeg
[15:09] <Daemon404> ubitux, not into BDSM
[15:09] <Daemon404> ?
[15:09] <ubitux> :(
[15:12] <ubitux> i wonder if the mismatch is not due to inaccuracy in audio or other streams
[15:13] <ubitux> at least it's affected by the multiple streams
[15:15] <ubitux> the first video frame looks the same
[15:37] <ubitux> ok i confirm it only affects the audio
[16:54] <ubitux> oh wtf
[16:54] <ubitux> the audio samples match, but they look like resampled differently
[16:55] <durandal_1707> what that means?
[16:57] <ubitux> durandal_1707: 
[16:57] <ubitux> /home/ux/src/ffmpeg/ffmpeg -v 0 -ss 179.130 -i /home/ux/samples/GoneNutty.avi -ss 30 -t 5 -f s16le -vn -y GoneNutty.avi-double-seek-209.130.pcm
[16:57] <ubitux> /home/ux/src/ffmpeg/ffmpeg -v 0 -ss 209.130 -i /home/ux/samples/GoneNutty.avi  -t 5 -f s16le -vn -y GoneNutty.avi-input-seek-209.130.pcm
[16:57] <ubitux> with http://samples.ffmpeg.org/avi/GoneNutty.avi
[16:58] <ubitux> if you try to diff the outputs: http://ubitux.fr/pub/pics/_ss-pcm-diff.png
[16:58] <ubitux> the video frames match
[16:59] <ubitux> the audio mismatch like this ^
[17:00] <ubitux> note that there is the exact same number of samples
[17:01] <durandal_1707> first -ss before -i does not use lavfi
[17:02] <ubitux> durandal_1707: mmh
[17:09] <ubitux> durandal_1707: i see the same auto inserted resamplers
[17:10] <ubitux> but of course, it doesn't have the same input in the resampling context
[17:10] <ubitux> so some previous context history might affect the later resampling
[17:11] <durandal_1707> what happens with no resampling?
[17:13] <ubitux> i'm not sure i can avoid it
[17:16] <durandal_1707> i just want to see if its not swr fault
[17:16] <durandal_1707> by using -f f32le
[17:17] <ubitux> i tried that but i still have a resampling filter auto inserted
[17:17] <ubitux> because input is planar float
[17:19] <durandal_1707> what program is that?
[17:19] <ubitux> i guess it just scales differently because the context of resampling is not the same
[17:19] <ubitux> huh?
[17:19] <durandal_1707> hex viever
[17:19] <durandal_1707> *w
[17:20] <ubitux> vbindiff
[17:22] <durandal_1707> ubitux: you could just save raw
[17:22] <ubitux> how am i supposed to save raw planar?
[17:24] <durandal_1707> -c copy
[17:24] <durandal_1707> -f can be same
[17:24] <ubitux> stream copy timestamps use a different logic
[17:24] <ubitux> -timestamps
[17:25] <ubitux> michaelni_: question about swr; i'm doing 2 audio resampling of the same input but not starting at the same time; comparing the output where time match seems to diff (off by one in a lot of samples)
[17:25] <ubitux> any idea if this is normal and what cause this?
[17:26] <durandal_1707> ubitux: i guess you need to add planar float codec...
[17:26] <ubitux> how are you going to do this? :)
[17:26] <ubitux> (a meaningful one)
[17:26] <durandal_1707> see libavcodec/pcm.c
[17:27] <ubitux> yeah but
[17:27] <ubitux> planar float would be the same output as packed float then?
[17:27] <durandal_1707> only for mono
[17:27] <durandal_1707> it looks like swr issue
[17:28] <durandal_1707> but this kind of resampling should not cause such changes
[17:28] <durandal_1707> perhaps you could try same with *cough* avconv?
[17:28] <ubitux> durandal_1707: how are you supposed to mux planar? oO
[17:28] <ubitux> (per frame?)
[17:28] <durandal_1707> ubitux: into nut
[17:29] <ubitux> mmh
[17:29] <ubitux> :p
[17:29] <durandal_1707> just add entry into libavformat/nut.c
[17:40] <michaelni_> ubitux, there are multiple possible causes of resampling output differing, first is obviously that with a convertion like 8000 -> 8001 sample times wont match often and theres dither that can give slight output difereces
[17:44] <durandal_1707> this is stereo fltp to s16
[17:49] <ubitux> mmh
[17:51] <ubitux> heh i have files where there is also pkt size mismatchs it seems
[17:56] <ubitux> saste: yeaaah :)
[17:57] <saste> so if this is approved i have only 1 pending patch for ffprobe
[17:57] <saste> *pending ticket
[17:57] <ubitux> i'll have a look when i'm home
[18:15] <saste> OTOH i'm not yet convinced validation should be done at the application level...
[18:16] <michaelni_> BuxiNess, do you have time to review the jpeg2000 patches ?
[18:24] <saste> why code #18 is accepted?
[18:44] <durandal_1707> saste: #18 as 0x18 ?
[18:46] <saste> durandal_1707, no, as decimal ASCII 18, aka CANC
[19:24] <cone-82> ffmpeg.git 03Paul B Mahol 07master:2490996f38e0: avcodec: use designated initializers for bitstream filters
[19:29] <llogan> BBB: sorry, i accidentally quit IRC so i didn't see your replies (if any) since i provided links
[19:33] <saste> GET_UTF8 is horribly broken
[19:37] <wm4> saste: is it?
[19:41] <wm4> if you mean that it decodes invalid utf...
[19:41] <wm4> that's true
[19:42] <wm4> there is some code elsewhere used by the subtitle code to verify utf-8, which should be more strict
[19:42] <saste> worse than that, what happens if ERROR is continue; and you're in the while block?
[19:42] <wm4> but just decoding with GET_UTF8 is not enough
[19:42] <wm4> well, as long as you make sure that you make progress...
[19:43] <wm4> also the subtitle utf-8 verification code has a minor bug
[19:43] <wm4> (doesn't allow utf-8 BOM anywhere)
[19:44] <durandal_1707> why out-of-sync happens with fieldmatch+decimate?
[20:01] <wm4> "And please test current git head, there is nothing "stable" about releases, they are simply snapshots for distributors."
[20:01] <wm4> lol
[20:01] <ubitux> it's not exactly accurate since there are some fix backports
[20:02] <wm4> well, a ffmpeg dev said that
[20:02] <ubitux> yeah i know
[20:02] <durandal_1707> wm4: that is true
[20:25] <wm4> why is GET_UTF8 a macro at all
[20:25] <wm4> it's so awkward
[20:25] <ubitux> because reading is conditional
[20:25] <ubitux> (and need to be done several times sometimes)
[20:41] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:95666b22989b: avcodec/imgconvert/get_color_type: fix type for PAL8
[20:41] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:ebb8dd437b7d: mov: fix trun / pseudo_stream_id handling
[20:51] <cone-82> ffmpeg.git 03Reimar Döffinger 07master:af6e232ccf8d: VC1 VDPAU: Mark missing reference frames as such.
[21:03] <ubitux> so it seems spi doesn't allow hw donation (nor fundraising activities)
[21:03] <ubitux> reimar suggested to me to add a webpage to the website for hw/misc donations, just like with mplayer
[21:03] <ubitux> should we add that to the donation page?
[21:05] <michaelni> ubitux, why do you think SPI doesnt allow hw donations ?
[21:05] <michaelni> and what exactly do you mean by hw donations ?
[21:06] <ubitux> "Refunds for legitimate project expenses will be made from funds earmarked for an associated project with the consent of the project liaison. Donations to associated projects by US residents are normally tax deductible. SPI does not assist with fundraising activities."
[21:06] <ubitux> it doesn't sound like it would cover such expense
[21:06] <Compn> companies donating hardware?
[21:09] Action: michaelni interprets "SPI does not assist with fundraising activities" as SPI doesnt go from door to door and ask for donations 
[21:11] <llogan> you can email the SPI treasurer for clarification.
[21:13] <michaelni> "There are tax law restrictions on what SPI can legally pay for as a 501(c)3 Non-Profit.  Common expenses like travel, equipment, flyers, booths, conference expenses and legal help are generally fine, but some items like software development contracting need to be handled carefully.  If the liaison is in doubt they should contact the Treasurer."
[21:13] <michaelni> from http://www.spi-inc.org/projects/associated-project-howto/
[21:13] <ubitux> ah, cool
[21:14] <Compn> hmm
[21:14] <Compn> j-b : wonder if videolan can send travel payment to spi, then spi can pay me ? :)
[21:15] <Compn> course spi takes a percentage iirc
[21:15] <ubitux> maybe we should add a bitcoin donation system too
[21:15] <Compn> but silk road just went down :P
[21:17] <gnafu> "They're worth nothing to me now that I can't use them to buy illegal drugs."
[21:17] <llogan> Silk Road should only sell illegal rugs
[21:17] <Compn> they have alpaca socks, or did at one time
[21:18] <llogan> no Compn beard socks?
[21:19] <Compn> nah i think it cost like 50btc to have a seller account on silk road
[21:19] <Compn> way too much money for me to have an account
[21:20] <durandal_1707> 50btc?
[21:20] <Compn> this was a few years back :)
[21:20] <Compn> i dont know current prices
[21:20] <Compn> and btc price fluctuates as well
[21:21] <Compn> but yes, a bitcoin address for donations would be useful
[21:21] <Compn> someone came in #videolan asking about donating via bitcoin , but videolan has no such thing
[21:21] <Compn> so they are losing out on '$5 every few months' or so
[21:22] <durandal_1707> s/months/seconds/
[21:22] <Compn> well just from that one guy
[21:23] <Compn> obviously there will be more donations
[21:23] <durandal_1707> llogan: can you ban libav folks from ffmpeg-devel?
[21:23] <ubitux> so with a btc donation system, we could steal $5 every few months from vlc?
[21:23] <Compn> ubitux : in theory
[21:23] <durandal_1707> that's not much
[21:23] <ubitux> that sounds like a good commercial strategy
[21:23] <Compn> durandal_1707 : you mean the mailing list ?
[21:23] <durandal_1707> in general
[21:24] <Compn> lou has mod powers, so yes, i think so
[21:24] <durandal_1707> s/m/g
[21:24] <Compn> though we welcome libav folks 
[21:24] <Compn> so why would you want to ban... anyone
[21:24] <Compn> cept that Daemon404 guy, hes been trolling a lot.
[21:24] <Compn> :P
[21:25] <ubitux> llogan: 11:03:26 <@ubitux> llogan: so, how is the twitter status?
[21:26] <gnafu> Compn: Yeah, Daemon404 is such a jerk.  I mean, who does he think he is?
[21:27] <gnafu> Daemon404: Oh, hi there.  Didn't see you.
[21:27] Action: gnafu whistles.
[21:27] <UsChickens> nobody here but UsChickens
[21:37] <ubitux> http://imgur.com/gallery/kE7xE2P # vid.stab v2
[21:38] <durandal_1707> why you need that, buy proper recording eq
[21:38] <Compn> you want to put a steadycam on a chicken ?
[21:38] <Compn> ubitux : i love that gif
[21:39] <durandal_1707> why would anyone put cam on chicken?
[21:39] <Compn> ohhh
[21:39] <Compn> i thought ubitux had made a v2 vidstab
[21:39] <Compn> and this gif was from the chicken camera or something
[21:39] Action: Compn stupid
[21:40] <ubitux> Compn: i plan to continue working on it yes, but still busy with some other stuff
[21:51] <iive> durandal_1707: the chicken functions like gyroscope stabilizer and is cheaper.  
[22:03] <llogan> durandal11707: ban whom? why? i don't want to be a banfag like fork is apparently
[22:05] <llogan> ubitux: twitter. i haven't done much and i think i missed announcing release. do you think it's time for another tip?
[22:05] <ubitux> you could twitt' everyday.
[22:05] <llogan> nein!
[22:06] <ubitux> what about adding a credential system to the ffbot
[22:06] <ubitux> and !twitt hello from irc
[22:06] <ubitux> for a few ppl here ;)
[22:06] <durandal11707> ubitux: for that sample user uploaded i get better results with setfield=prog,pullup
[22:07] <ubitux> durandal11707: i'm not really interested in debugging fieldmatch/decimate again
[22:07] <durandal11707> perhaps i failed to get flags again
[22:07] <ubitux> at least not now, priorities etc
[22:08] <llogan> ubitux: heh. maybe burek can summon something like that with his dark magics.
[22:30] Action: rcombs pokes at https://trac.ffmpeg.org/ticket/1582#comment:8
[22:38] <kierank> iirc it's because with some paths swscale will disable dither
[23:07] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:f4aec348056c: avformat/utils: pass AVFormatContext to find_decoder()
[23:07] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:5082fcc0e2c8: avformat: add support to force specific AVCodecs
[23:07] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:64327aabb96d: ffmpeg: add support to force specific AVCodecs
[00:00] --- Thu Oct  3 2013