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

[burek]

[00:09] <michaelni> kurosu, probably the high 16bits contained some intermediate values and where not 0
[00:10] <michaelni> so it shouldnt be needed anymore
[00:10] <kurosu> it's not like it's going to hurt after 12 years of innocuous behaviour, but yeah... I don't see why it is needed
[00:11] <kurosu> and if it is needed, then I don't think any fate test currently exhibits the problem
[00:12] <michaelni> kurosu, ill rerun fate and remove it
[00:13] <kurosu> as you wish
[00:17] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:b50559fc0b2b: libavcodec/x86/dsputilenc: drop and 0xffff that should have becomei redundant
[00:20] <kurosu> as you wish
[00:20] <kurosu> woops
[00:26] <cone-584> ffmpeg.git 03Luca Barbato 07master:6d212599aa68: avformat: Provide a standard compliance flag
[00:26] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:d858ee717bed: Merge commit '6d212599aa684f30511fb08ca30fe2378405304e'
[00:36] <llogan> cehoyos: ef48ac6 breaks speex decoding (found by massdos in #ffmpeg) with http://samples.ffmpeg.org/A-codecs/speex/h264_speex.mp4
[01:18] <cone-584> ffmpeg.git 03Luca Barbato 07master:c94e2e85cb6a: nut: Support experimental NUT 4 features
[01:18] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:a8499cbbe87d: Merge commit 'c94e2e85cb6af8a570d8542a830556243bd32873'
[01:20] <compn> neat
[01:20] <compn> washington attorney general asking for support with SN40 codec :D
[01:24] <cone-584> ffmpeg.git 03Luca Barbato 07master:b2d456542205: avresample: Add avresample_get_out_samples
[01:24] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:bdb2e80e88e7: Merge commit 'b2d45654220503224aa94e78cdff19ec624e9342'
[01:31] <cone-584> ffmpeg.git 03Luca Barbato 07master:ad0fe2f40120: af_resample: Use avresample_get_out_samples
[01:31] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:20343cfb51ea: Merge commit 'ad0fe2f4012031c47268f14b9835088c488e1998'
[01:36] <compn> anyone knwo what this site is or who runs it ? http://ffmpegmac.net/
[01:41] <llogan> compn: i believe Sebastian Tischer $(surname).s at me.com
[01:55] <compn> llogan : so its a legit site then ? :P
[01:55] <llogan> i think so
[01:56] <llogan> i've never tried his builds, but i don't have OSX
[02:18] <UtUser> The Ut Video decoder is still busted in case anybody cares
[02:23] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:99b15f1daae1: avformat/nutenc: fix used version value
[02:23] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:45daae06fd6f: avformat/nutenc: change check to match comment
[02:23] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:170a4d79c04c: avformat/nutenc: bump minor version due to broadcast/pipe
[02:23] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:6b041cb617e5: avformat/nutdec: Fix handling of older 4.0 files
[03:02] <compn> UtUser : we care, decoding or encoding ?
[04:11] <UtUser> sorr for the hours-late response. DECODING, I think
[04:11] <UtUser> compn: as per http://trac.ffmpeg.org/ticket/2661
[04:12] <UtUser> and don't forget I already sent out a 20 MB sample of the kind of Ut Video frames that give errors in ffmpeg
[04:12] <UtUser> maybe you won't here
[04:12] <UtUser> I'll try and find the URL
[04:12] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:df889be0a89a: nutenc: avoid av_tree_find() operation per syncpoint
[04:12] <UtUser> someone should verify this and re-open the ticket IMHO
[04:12] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:82beb46e65e5: avformat/nutenc: add mode that omits the index
[04:12] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:6d1aba6a29b4: avformat/nutenc: limit index table size if no index is going to be written
[04:13] <UtUser> here's one of the mirrors: http://www.sockshare.com/file/EBEC6306126D92F0
[04:14] <UtUser> compn, Daemon404
[04:25] <compn> ehe, i dont dare cross carl the trac warrior by reopening a bug :)
[04:25] <compn> leave it closed , can continue commenting on it however
[04:32] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:78a79a2ceb63: avformat/nutenc: replace conditional by assert
[04:57] <UtUser> compn, I'm not sure if that's the best course of action
[04:57] <UtUser> fixed doesn't mean fixed here
[05:26] <UtUser> now I'll just sit and wait
[05:43] <compn> UtUser : you got latest git ? just making sure you arent using old ffmpeg...
[05:43] Action: compn afk
[05:44] <UtUser> I'll install a build from today to make ure
[05:45] <UtUser> but unless somebod fixed it yesterday, I'm pretty sure
[05:49] <UtUser> yep, it's still broke
[05:54] <michaelni> BBB, posted a patch for a quick n dirty fate test for async
[06:23] <UtUser> how do I get a sample onto ffmpeg's site?
[06:23] <UtUser> I plan to reopen and I wat to have proof to back me up
[06:38] <UtUser> SOMEBODY CONFIRM THIS FUCKING THING SO IT CAN GET FIXED
[10:54] <ubitux> UtUser: this is a development channel you know, not a special support one; you could open a new ticket
[10:57] <ubitux> UtUser: carl just sent a patch btw
[10:58] <ubitux> UtUser: see https://ffmpeg.org/pipermail/ffmpeg-devel/2014-May/158171.html
[12:17] <kurosu> what's the avantage of utvideo over huffyuv+median ?
[12:17] <kurosu> they are both huffman coding and median
[12:18] <kurosu> there's maybe that YCoCg-like transform in utvideo, but that's about it?
[12:23] <J_Darnley> As I recall it started out as someone filling whatever niche they had.
[12:25] <kurosu> from what I see, their prediction enforces int intermediate (no wraparound), so I would expect simd to have around a halved performance
[12:25] <J_Darnley> I think it might have been so they could use some encoding API for which no other codec was then available
[12:26] <kurosu> the existence of that codec is weird - except for filling a niche, I can't make sense of it
[12:26] <J_Darnley> Was this codec also the one that uses floats?
[12:26] <kurosu> no that's algarith arithmetical entropy codec
[12:27] <kurosu> or lagarith, rather
[12:28] <J_Darnley> oh yes
[12:28] <kurosu> I think michaelni added variations of YCoCg to ffv1, but I don't see why a huffyuv 3.0 or whatever couldn't
[12:28] <J_Darnley> If you want to find its origins, I think I first saw it being demoed on Doom9's "alternative codecs" forum
[12:28] <kurosu> then no difference for rgb input
[12:29] <J_Darnley> Lots of redundant or duplicate work happens, unfortunately
[12:30] <kurosu> it's often a lemma in lossless coding it seems
[12:31] <J_Darnley> Here's the thread, I think: http://forum.doom9.org/showthread.php?t=143624
[12:31] <J_Darnley> It didn't surprise me to see thet the author link is to some japanese blog
[12:33] <Daemon404> the niche at the time was sliced threading
[12:33] <Daemon404> iirc
[12:34] <Daemon404> although it supports 10bit now
[12:34] <Daemon404> (i need to add that to the decoder maybe)
[12:34] <kurosu> and frame threading wasn't an option ?
[12:34] <kurosu> all the more for an intra codec
[12:35] <BBB> michaelni: ty!
[12:35] <Daemon404> kurosu, latency vs throughput
[12:35] <Daemon404> the ageold debate.
[12:35] <Daemon404> anyways, beats me
[12:36] <Daemon404> im not the euthor
[12:36] <Daemon404> author*
[12:37] <BBB> kurosu: most of these codecs exist because the author went to college, had nothing to do, didn't google-search before <T> and then T=started to code
[12:37] <kurosu> isn't latency more of a decoding issue? and being intra, I don't think the difference between 1/70s and 1/360 would matter ?
[12:37] <kurosu> anyway, yeah, I'm beating a dead horse here
[12:44] <cone-339> ffmpeg.git 03Roman Savchenko 07master:a53551cba86b: frame: fix the error path in av_frame_copy_props()
[12:44] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:d9c4f61dab2a: Merge commit 'a53551cba86bb67efcb6105fdc337a36c43132bd'
[13:02] <kurosu> ah VfW - explains slice threading
[13:05] <cone-339> ffmpeg.git 03Anton Khirnov 07master:81eec081afea: matroskaenc: base DefaultDuration on the framerate, not the codec timebase
[13:05] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:bc59d39b8249: Merge commit '81eec081afea9fc017a175581ceea7c420a0dfc3'
[13:19] <cone-339> ffmpeg.git 03Anton Khirnov 07master:cf6977712c9e: movenc: write avg_frame_rate as the framerate, not the codec timebase
[13:19] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:a72df4dadc0d: Merge commit 'cf6977712c9e5abe6dc55289f6322ccbf10321a9'
[13:30] <JEEB> <kurosu> what's the avantage of utvideo over huffyuv+median ? <- mostly the fact that the guy doing Ut Video basically went and implemented it for pretty much all of the relatively important multimedia frameworks; VfW, DShow, MF and QuickTime.
[13:37] <cone-339> ffmpeg.git 03Anton Khirnov 07master:43e7f0797f9f: flvenc: only write the framerate tag based on avg_frame_rate
[13:37] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:e46cc1dab05e: Merge commit '43e7f0797f9f821a3866a20f05e512e13c82076a'
[13:49] <cone-339> ffmpeg.git 03Anton Khirnov 07master:962d63157322: matroskaenc: set the stream timebase earlier
[13:49] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:4991eacc064f: Merge commit '962d63157322466a9a82f9f9d84c1b6f1b582f65'
[13:52] <kurosu> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/huffyuvenc.c;hb=HEAD#l54 <- I'm not getting what's happening
[13:53] <kurosu> if w<32, process w elements, otherwise process _16_ elements !?
[13:54] <kurosu> the encoder processes 16 elements a time or something ?
[13:55] <kurosu> michaelni, you're the author, so ... ? ^
[14:00] <michaelni> ... otherwise process 16 elements in C and the rest in SIMD
[14:01] <michaelni> the 16 is needed due to avoiding to read out of array and maintaining alignment for SIMD
[14:02] <michaelni> sure could be done differently of course ...
[14:13] <kurosu> oh... diff_bytes here is used to compute left prediction?
[14:16] <kurosu> anyway ok
[14:16] <michaelni> yes
[14:18] <cone-339> ffmpeg.git 03Christophe Gisquet 07master:c609f803e1c1: huffyuv: avoid duplicated defines
[14:47] <kurosu> michaelni, I was reworking the add_bytes anyway
[14:47] <kurosu> for some reason an initial benchmark showed the sse2 version to bring nothing
[14:47] <kurosu> hence the use of movu /...
[14:48] <kurosu> I wasn't sure it was never called with unaligned positions, as I'm not sure I test all possible cases
[14:48] <kurosu> I'm using fate-lagarith fate-vsynth[12]-huffy
[14:56] <michaelni> the header says: void (*add_bytes)(uint8_t *dst /* align 16 */, uint8_t *src /* align 16 */,
[14:56] <michaelni> so it should be aligned
[14:57] <cone-339> ffmpeg.git 03Christophe Gisquet 07master:25e6310a3ec9: huffyuv: change left prediction access in BGRA
[14:57] <kurosu> and median_pred doesn't say that, and indeed it does unaligned access (first element on line using top pred I guess)
[14:58] <kurosu> but that's probably why I didn't dare the devil
[14:58] <kurosu> will change it
[14:58] <kurosu> the sse2 version is actually twice as fast
[14:58] <kurosu> though it's negligible iirc (a profile on some huffyuv decoding showed < 1%)
[15:16] <kurosu> btw, I found unaligned loads on newer cpus to have a negligible impact
[15:16] <kurosu> sometimes even trying to distinguish between the 2 actually incurs a loss in total
[15:26] <kurosu> what happened to ffv2 (which was worked on by x264 authors)? I guess functionalities-wise it's not up to par with ffv1, but the base was kind of good ?
[15:33] <compn> was it incorporated into ffv1 1.3 ? 
[15:33] <compn> or is this something else i dont remember hearing about ?
[15:36] <JEEB> it's something that pengie was playing with for a while
[15:37] <JEEB> you have some diffs from 2009-2010 @ http://akuvian.org/src/x264/
[15:41] <kurosu> dead a long time ago then
[17:33] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:f518fb33184b: avcodec/dpx_parser: reset index when finding a startcode, not after
[17:33] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:8df5d9aabfbf: avcodec/dpx_parser: fix flushing end out
[17:33] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:fba0ac28055d: avcodec/dpx_parser: Allow frame size to be too small
[18:14] <kurosu> michaelni, reworking add_hfyu_left_pred_bgr32, no need to review for now
[18:15] <michaelni> ok
[18:22] <cone-339> ffmpeg.git 03Martin Storsjö 07master:08cd92144e73: aarch64: Use the correct syntax for relocations
[18:22] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:232959f184e1: Merge commit '08cd92144e73195eecc28ed0348e66e255516b82'
[18:54] <cone-339> ffmpeg.git 03James Almer 07master:05de4d30111e: x86/dsputilenc: implement XOP version of pix_sum16
[20:13] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:40a4ab8ba4bf: rename sub_hfyu_median_prediction_int16 to sub_hfyu_median_pred_int16
[20:13] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:550ae6c02f61: rename add_hfyu_median_prediction_int16 to add_hfyu_median_pred_int16
[20:13] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:7b4c46050e68: rename add_hfyu_left_prediction_int16 to add_hfyu_left_pred_int16
[21:24] <kurosu> jamrial, I benchmarked it be slower
[21:24] <kurosu> though I hadn't written the sse2 version yet
[21:44] <cone-339> ffmpeg.git 03Christophe Gisquet 07master:bf7e9cc82a84: tests: allow passing dimensions to videogen
[21:51] <jamrial> Interesting. I'd expect two less movq/dqa to be faster. paddb speed shouldn't change regardless of using a reg or mem as source
[21:52] <jamrial> at least when i looked at some latency benchmarks online
[21:53] <cone-339> ffmpeg.git 03Christophe Gisquet 07master:226700398105: x86: hpeldsp: better factorization
[21:53] <kurosu> this goes into details above my head
[21:53] <kurosu> usually, I just try and see if it's better
[21:54] <kurosu> but that's sometimes useless
[21:54] <kurosu> because it may actually hurtful to a much older/newer cpu
[21:54] <jamrial> true
[21:54] <kurosu> *be hurtful
[21:55] <jamrial> considering the mmx versions are now only going to be used by old cpus, benchmarking it on new cpus doesn't really give a proper image of a real world scenario
[21:55] <kurosu> yeah
[21:56] <kurosu> on those I remember you had to be really careful about your insn scheduling
[22:07] <kurosu> jamrial, re: add missing guards to ff_pix_sum16_xop, wouldn't an equivalent check be needed in the _init code ?
[22:08] <UtUser> >Have you tried the sample with the official decoder? If that breaks, then its not our decoder which needs to be fixed, but our encoder.
[22:08] <UtUser> I havesome mre testing to do.
[22:12] <jamrial> EXTERNAL_<opt> macros in the _init code take care of that
[22:13] <kurosu> ok, this is set based on detection by configure then
[22:15] <jamrial> yeah, those macros expand to "HAVE_<opt>_EXTERNAL && (cpuflag & AV_CPU_FLAG_<opt>)" which is optimized out when HAVE_<opt>_EXTERNAL is 0
[22:30] <cone-339> ffmpeg.git 03Christophe Gisquet 07master:99a319c4e753: x86: huffyuvdsp: port add_bytes to yasm
[22:35] <fionag> out of curiosity, is there some reason the PIX_SUM doesn't use psadbw already?
[22:35] <fionag> it seems a little weird that it doesn't, unless I'm misunderstanding the purpose of the function
[22:35] <JEEB> UtUser, if it seems like a bug in the encoder, feel free to poke me. I'll try to poke it after I get back from work tomorrow
[22:35] <UtUser> I was just quoting somebody else
[22:35] Action: JEEB is the guy whose name is on the top of utvideoenc.c
[22:36] <UtUser> ok
[22:36] <JEEB> I did enable slices at one point automatically depending on the amount of cores you have, but I did check against the official encoder if I recall correctly
[22:36] <UtUser> how does one use the official encoder, by the way?
[22:37] <JEEB> encoder/decoder, probably via VfW and VirtualDub
[22:37] <UtUser> ah
[22:37] <JEEB> there's a libutvideo wrapper, but I've always felt like using vdub and feeding it exactly the data I wanted to test was simpler
[22:38] <UtUser> well, honestly I'd prefer the CLI
[22:38] <UtUser> I've got a test clip
[22:38] <UtUser> if I try and transcode it with libutvideo I may or may not get errors
[22:38] <JEEB> oh, you only use libutvideo?
[22:38] <JEEB> not the internal encoder
[22:38] <UtUser> I use utvideo
[22:38] <UtUser> internal
[22:38] <JEEB> k
[22:39] <UtUser> never tried libutvideo
[22:39] <UtUser> both in ffmpeg? just to make sure
[22:39] <JEEB> yeah, you need to build the lib and I'm not sure how many updates it got
[22:39] <JEEB> latter needs the ut video library of course
[22:39] <UtUser> :(
[22:39] <UtUser> hmm
[22:39] <JEEB> I just generally want to keep lavf/lavc as far from creating sample/results
[22:40] <JEEB> so I use the official encoder/decoder in vdub when I need to test against a reference
[22:40] <UtUser> ok
[22:40] <UtUser> so I'm firing up vdub
[22:40] <UtUser> wait
[22:40] <JEEB> http://umezawa.dyndns.info/wordpress/?p=4809
[22:40] <JEEB> official ut video
[22:41] <JEEB> also if you can give me a sample that I can repro things with that is an alternative as well
[22:42] <UtUser1> I am so sorry
[22:42] <UtUser1> my webchat client froze again
[22:42] <UtUser1> anyways, I am unsure of how to proceed
[22:43] <JEEB> <JEEB> http://umezawa.dyndns.info/wordpress/?p=4809
[22:43] <JEEB> <JEEB> official ut video
[22:43] <JEEB> <JEEB> also if you can give me a sample that I can repro things with that is an alternative as well
[22:43] <UtUser1> well actually I think somebody already split and uploaded it...
[22:43] <UtUser1> http://trac.ffmpeg.org/ticket/2661#comment:6
[22:43] <JEEB> ok
[22:43] <JEEB> can you tell me if it happens with one slice?
[22:44] <UtUser1> hm?
[22:44] <JEEB> after -i you set -slices
[22:44] <JEEB> to set the amount of sliced used for encoding
[22:44] <UtUser1> oh boy
[22:44] <UtUser1> see, here's the problem
[22:44] <UtUser1> not every frame is bugged
[22:45] <JEEB> well, I just want to know if it borks at all with one slice
[22:45] <UtUser1> so I'll encode like 2 minutes of video and there might be 4 seconds of bgged frames
[22:45] <UtUser1> I see your point though
[22:45] <UtUser1> it may take some time however
[22:45] <JEEB> I put a change in in February because the official Ut Video decoder only threads in slices
[22:45] <JEEB> The official Ut Video decoder only threads with slices, thus until
[22:45] <JEEB> now any files encoded by the libavcodec encoder have only been
[22:45] <JEEB> decodable with a single thread. The default slice count is now
[22:45] <JEEB> set to subsampled_height / 120.
[22:46] <JEEB> before that it was always -slices 1
[22:46] <UtUser1> I see
[22:46] <JEEB> I had tested that things would decode correctly at that point
[22:46] <UtUser1> a likely culprit
[22:46] <JEEB> but you never know, so it's worth a try
[22:46] <UtUser1> ok
[22:46] Action: JEEB is rather dry and down-to-earth in these things
[22:46] <UtUser1> just to confirm
[22:47] <UtUser1> should I be decoding the busted clip or encoding a newone?
[22:47] <JEEB> encode the clip that makes the encoder create files that bork at decoding
[22:47] <UtUser1> ok
[22:47] <JEEB> encode -> decode -> check if it borked
[22:48] <JEEB> also, I'm happy that some people use my encoder :)
[22:48] <UtUser1> I think it's one of the greatest features of ffmpeg
[22:48] <UtUser1> I use it for my masters
[22:48] <JEEB> I was kind of worried about it not getting used because the libutvideo wrapper was already in :)
[22:49] <UtUser1> well, people like me just type in the most obvious thing
[22:49] <UtUser1> like utvideo without the lib part
[22:49] <UtUser1> seriously
[22:50] <UtUser1> you can also type in things like h264, etc.
[22:50] <UtUser1> aac gives you the experimental encoder
[22:50] <UtUser1> the offical name is "ut video", so I just removed the space, and to my amazement, it worked, so I used that :)
[22:58] <JEEB> UtUser1, anyways, after you can confirm if it happens with one slice or not, feel free to poke me with a sample that I can then encode with the encoder and try and feed it to the official decoder
[22:58] <UtUser1> uh
[22:59] <UtUser1> you've lost me
[22:59] <UtUser1> I'm encoding with one slice now
[22:59] <JEEB> yes
[22:59] <UtUser1> it should be done soon
[22:59] <JEEB> since it seems to be taking a while
[22:59] <UtUser1> it's about a minute but I had to get the settings right
[22:59] <JEEB> k
[22:59] <UtUser1> I just had some soup
[23:00] <JEEB> and I'll have to be up in ~6 hours
[23:00] <UtUser1> oh shit it'll be like 5 more minutes
[23:00] <UtUser1> oh no man
[23:00] <UtUser1> well ok
[23:00] <UtUser1> you do that
[23:00] <UtUser1> sleep and whatnot
[23:00] <JEEB> just poke me, I will read through the backlog
[23:01] <JEEB> tell me if it happens with just multiple slices or if just one slice is affected too, and then please link a sample I can throw at my encoder to replicate
[23:01] <JEEB> :)
[23:01] <JEEB> and I can then check the output against the official decoder
[23:02] <UtUser> AHHHHHHHHH
[23:02] <UtUser> my IRC cient crashd again
[23:02] <JEEB> <JEEB> just poke me, I will read through the backlog
[23:02] <JEEB> <JEEB> tell me if it happens with just multiple slices or if just one slice is affected too, and then please link a sample I can throw at my encoder to replicate
[23:02] <JEEB> <JEEB> :)
[23:02] <JEEB> <JEEB> and I can then check the output against the official decoder
[23:02] <UtUser> ok
[23:03] <UtUser> not sure if the encode-able sample part will work
[23:03] <UtUser> too big a file I'm trying right now
[23:03] <JEEB> well if you can limit it to the pictures that are borked
[23:03] <JEEB> and see if they by themselves make it happen
[23:03] <UtUser> so it's always the same behavior and not random?
[23:03] <JEEB> it should be
[23:03] <UtUser> ok
[23:04] <JEEB> unless there's some really weird shit going on, but at least the encoder is fully dependant on only that one picture you're feeding it
[23:05] <UtUser> well, I'll try and let you know
[23:05] <UtUser> I'll probably be nice and cozy at home while you're at work
[23:05] <UtUser> get some sleep now
[23:05] <UtUser> I'll do my best
[23:06] <cone-339> ffmpeg.git 03James Almer 07master:02a3e327f118: x86/dsputilenc: add missing guards to ff_pix_sum16_xop
[23:50] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:b3f461508176: ffmpeg: fix check for muxing overhead being unknown
[23:55] <cone-339> ffmpeg.git 03Diego Biurrun 07master:2ea2612df508: svq1enc: Rename SVQ1Context to SVQ1EncContext
[23:55] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:cb8763bda7e5: Merge commit '2ea2612df508abdd1f97c6a6ef56275a52c5c41e'
[00:00] --- Fri May 30 2014