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

[burek]

[00:04] <burek> is trac down?
[00:18] <Rodeo> burek: someone mentioned not too long ago, so I guess it is
[00:20] <burek> +1
[01:06] <michaelni> llogan, ubitux latest page of merged formatting, links and stuff: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2014
[01:07] <michaelni> if trac will be up again in time we can move it back
[01:08] <michaelni> but having it on multimedia.cx allows editing for all who have an account which is better than if its nowhere
[01:12] <llogan> michaelni: ok. i'll try take a look at it tonight
[01:12] <michaelni> thx
[01:27] <cone-703> ffmpeg.git 03Vittorio Giovara 07master:d509ae5be0a9: jvdec: K&R formatting cosmetics
[01:27] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:dcbc748ad11b: Merge commit 'd509ae5be0a9bac35a4cedbe68b774a74446bb27'
[01:29] <cone-703> ffmpeg.git 03Diego Biurrun 07master:190d4a447bc6: avcodec: Suppress deprecation warnings from avcodec_alloc_frame()
[01:29] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:bd9492174d97: Merge commit '190d4a447bc6ae4ecbbbb1c70f482a9c1fb6026c'
[01:35] <cone-703> ffmpeg.git 03Justin Ruggles 07master:0e830094ad0d: samplefmt: avoid integer overflow in av_samples_get_buffer_size()
[01:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:d80b9ea11da1: Merge commit '0e830094ad0dc251613a0aa3234d9c5c397e02e6'
[01:56] <cone-703> ffmpeg.git 03Anton Khirnov 07master:5430839144c6: eacmv: clear references on frame dimensions change
[01:56] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:e7724f346a92: Merge commit '5430839144c6da0160e8e0cfb0c8db01de432e94'
[02:16] <cone-703> ffmpeg.git 03Anton Khirnov 07master:1713eec29add: shorten: pad the internal bitstream buffer
[02:16] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:cd04f0da60bf: Merge commit '1713eec29add37b654ec6bf262b843d139c1ffc6'
[02:41] <cone-703> ffmpeg.git 03Anton Khirnov 07master:2240e2078d53: truemotion1: check the header size
[02:41] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:2b88cb2f4653: Merge commit '2240e2078d53d3cfce8ff1dda64e58fa72038602'
[02:53] <cone-703> ffmpeg.git 03Anton Khirnov 07master:4c3e1956ee35: lagarith: reallocate rgb_planes when needed
[02:53] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:6a4cc5098078: Merge commit '4c3e1956ee35fdcc5ffdb28782050164b4623c0b'
[03:16] <BBB> ubitux: will check
[03:24] <BBB> ubitux: I think lgtm
[03:26] <cone-703> ffmpeg.git 03Luca Barbato 07master:d9ae1031f5ed: lavf: improve handling of sparse streams when muxing
[03:26] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:3adb5f8d8b40: Merge commit 'd9ae1031f5edbd25c8526b4cb51aba66d3bee931'
[03:26] <BBB> I'm kinda shocked that decode_coeffs_b is so high in the profile, is that -O0 or so? anyway, some of my optimizations (vp9-context-opts branch) should help in that function, and also in decode_b and memset
[03:27] <BBB> for me, decode_coeffs_b is 9.4% or so, with another 9.5% for decode_b
[03:27] <BBB> and 15.6% for 8tap_1d_h_16
[03:27] <BBB> if you want to decrease that, add prefetch handling like h264/vp8 have
[03:36] <cone-703> ffmpeg.git 03Luca Barbato 07master:9ecb85877548: doxy: Format @code blocks so they render properly
[03:36] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:6e380cc28f25: Merge commit '9ecb858775483a76c137e8e1ad45a95e318bca61'
[04:13] <cone-703> ffmpeg.git 03Vittorio Giovara 07master:a91d3658d9a7: mpeg: K&R formatting cosmetics
[04:13] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:acd7505351d1: Merge remote-tracking branch 'qatar/master'
[07:18] <ubitux> BBB: no, no -O0, but --assert-level=2 and debug syms
[07:26] <cone-989> ffmpeg.git 03Clément BSsch 07master:91d85bb167a9: x86/vp9lpf: add ff_vp9_loop_filter_[vh]_44_16_{sse2,ssse3,avx}.
[07:26] <cone-989> ffmpeg.git 03Clément BSsch 07master:9a3b05b0a989: x86/vp9lpf: save a few mov in flat8in/hev masks calc.
[07:26] <cone-989> ffmpeg.git 03Clément BSsch 07master:97dde561dec0: x86/vp9lpf: remove braindead double pxor.
[07:26] <cone-989> ffmpeg.git 03Clément BSsch 07master:d92a725329e5: x86/vp9lpf: remove 8 SWAPs in 84/48 transpose.
[07:37] <ubitux> BBB: no assert level: http://pastie.org/pastes/8700306/text
[07:38] <ubitux> (another machine than previous test btw)
[07:39] <ubitux> i'll try your vp9-context-opts branch
[07:48] <ubitux> BBB: http://pastie.org/pastes/8700324/text with the vp9-context-opts branch (which i rebased on master to be consistent with previous test)
[07:48] <ubitux> that's indeed much better for decode_b(), but decode_coeffs_b() is still slow :p
[09:30] <pross-au> michaelni: i am removing vp7 from the gsoc 2014 list as i have just finished decoder for it
[09:33] <JEEB> oh
[09:33] <JEEB> nice
[09:34] <JEEB> that's actually the thing I originally wanted to do in 2012, but was poked towards a Ut Video encoder :)
[09:37] <pross-au> ut would be way more interesting. vp7 is essentially "vp8 with bugs".
[09:37] <pross-au> vp4 still needs love
[10:13] <ubitux> BBB: and btw, i just tried with clang instead of gcc, and that's even worse :p
[10:14] <ubitux> (just in case it was a random miscomp or something)
[13:08] <BBB> odd
[13:08] <BBB> well eiter your simd is really fast or your regular assembly is really slow compared to mine
[13:08] <BBB> the funny thing is that overall runtime is roughly the same
[13:09] <ubitux> maybe there is a difference in the metering
[13:09] <ubitux> like some function inlined or something
[13:09] <BBB> possibly yes
[13:10] <ubitux> BBB: what sample are you testing btw?
[13:10] <BBB> ped1080p.webm
[13:10] <ubitux> yeah, that sample is a bit short
[13:10] <ubitux> try a longer one, like etv5k
[13:10] <BBB> you're testing etv5k?
[13:10] <ubitux> yes
[13:10] <BBB> ok, will test that one and compare
[13:11] <ubitux> BBB: http://pastie.org/pastes/8701093/text this is with ped1080p.webm
[13:11] <BBB> what do you think of the vp9-context-opts patches? the commit messages are kinda messy and the code can probably be cleaned up a bit, but do you feel it helps? for me it helped about 0.2sec or so
[13:11] <BBB> yeah that's a little more like what I get, so I guess it makes sense then
[13:11] <BBB> should work more on decode_coeffs_b I suppose
[13:12] <ubitux> i didn't look at the vp9-context-opts patches, will
[13:12] <ubitux> i'll bench as well to see the benefit
[13:12] <BBB> ok
[13:12] <BBB> I'll clean up the commit msgs and try to make the code more consistent
[13:15] <ubitux> 3.85s ’ 3.68s (best scores)
[13:15] <ubitux> (1 thread)
[13:17] <BBB> ok not bad
[13:17] <BBB> I'll clean and send out
[13:17] <BBB> I have almost all intra pred functions simd'ed also
[13:52] <ubitux> BBB: 40 ’ 38 with vp9-context-opts on etv5k.webm
[13:56] <ubitux> (seconds)
[13:59] <BBB> \o/
[13:59] <BBB> yeah so that's about the same percentage I saw also (5.5->5.3 or so)
[14:13] <ubitux> BBB: according to perf, most of the time is spent on... a shift. wth. http://ubitux.fr/pub/pics/_wtf-shl-perf-timing.png
[14:26] <cone-691> ffmpeg.git 03Marton Balint 07master:cec6dec7c8b2: ffplay: reorder the filters to ensure that inputs of the custom filters are merged first
[14:26] <cone-691> ffmpeg.git 03Marton Balint 07master:23e77f0e33b7: ffplay: flush subtitle codecs as well with null packets
[14:26] <cone-691> ffmpeg.git 03Michael Niedermayer 07master:95b13fb96f7e: Merge remote-tracking branch 'cus/stable'
[15:16] <burek> did anyone fix trac.ffmpeg.org
[16:09] <thardin> *stirs mxf pot some more*
[16:10] <kierank> thardin: there are many libmxfs
[16:11] <kierank> thardin: the bmx one is the latest one i think
[16:11] <kierank> the ingex one is old
[16:14] <cone-691> ffmpeg.git 03Timothy Gu 07master:9a4a559d6fbe: configure: use real libfdk-aac version instead of API version in help text
[16:16] <thardin> ah
[16:16] <thardin> well, using one written by people who actually work with mxf on a daily basis makes lots more sense
[16:17] <thardin> regardless of what it's called
[16:35] <j-b> +// EDIT JB thread_await for multi_threading
[16:35] <j-b> omg
[16:37] <ubitux> > [FFmpeg-devel] [WIP] H.264 MVC decoder
[16:37] <ubitux> michaelni: we'll have to remove one entry in the gsoc page :(
[16:39] <ubitux> nice horror diff btw
[16:40] <ubitux> wth is this... o_o
[16:40] <nevcairiel> its something a student wrote for a thesis without a care in the world for style or whatnot
[16:41] <nevcairiel> koda from libav has been trying to untangle the decoder for a while as well
[16:41] <ubitux> well there are thousands and thousands of commented line
[16:42] <Daemon404> ...
[16:42] <kierank> huge diff
[16:42] <Daemon404> ubitux, this is a piece of crap
[16:43] <Daemon404> in multiple ways
[16:43] <michaelni> does it work and how can it be tested ?
[16:43] <Daemon404> michaelni, all they did is make the ancient patch apply to the current codebase
[16:43] <Daemon404> and comment out random stuff, liek a printf in ffplay
[16:43] <Daemon404> it's completely broken/useless
[16:43] <Daemon404> and insane
[16:43] <Daemon404> :D
[16:43] <michaelni> core                         |binary
[16:43] <j-b> ubitux: I mean, even _I_ can see the patch is pure horrible
[16:44] <michaelni> libavcodec/stG88jwK          |binary
[16:44] <wm4> a coredump file?
[16:45] <michaelni> yes, seems though its missing in the attached patch "Binary files /dev/null and b/core differ"
[16:48] <Compnn> gasp mvc decoder
[16:49] <nevcairiel> I hope noone will do any rash decisions and merge something half-assed :p
[16:49] <j-b> ubitux: "pure horror"
[16:49] <kierank> nevcairiel: never :)
[16:50] <Compnn> nevcairiel : you want to sit on it until it rots ? 
[16:50] <ubitux> j-b: sorry i forgot your copyright
[16:50] <nevcairiel> Compnn: rather then merge something that will haunt us for years
[16:50] <Compnn> oh master thesis :)
[16:50] <nevcairiel> Either someone cares enough to do it properly, or noone cares enough so it also shouldnt be merged :)
[16:50] <j-b> IMHO, you should merge this patch without looking at it :)
[16:50] <Compn> those words arent good 
[16:51] <nevcairiel> But like I said, koda  from libav has been poking the same decoder indepdently and is in the process of cleaning it up and also deciding on the API how to even expose multiple views from the decoder
[16:52] <nevcairiel> so whoever wants to clean it up should probably talk to him, double work is useless
[16:53] <michaelni> nevcairiel, who is koda ?
[16:53] <Daemon404> the guy working on MVC properly
[16:53] <nevcairiel> Vittorio Giovara
[16:53] <Daemon404> and actually planning out how to return it from decode_video3
[16:53] <JEEB> I think koda got the MVC code before, and was poking at it to make it saner?
[16:54] <JEEB> and still is of course
[16:54] <nevcairiel> its been out there for a while
[16:54] <JEEB> true
[16:54] <michaelni> why was it not posted to ffmpeg-devel before ?
[16:54] <nevcairiel> because the author didnt care
[16:54] <nevcairiel> he just wanted his thesis
[16:54] <Daemon404> welcome to academia
[16:55] <Daemon404> proof of concept is all you ever need
[16:55] <Daemon404> practical things considered harmful (to your career)
[16:55] <Compn> i seem to remember someone talking about doing a thesis
[16:55] <Compn> some people just dont talk on the mailing list every day
[16:55] <Compn> but they do enormous amounts of code...
[16:55] <nevcairiel> iirc, he wanted to take part in gsoc because the timing coincided with his thesis, but ffmpeg wasnt in gsoc that year, so he just vanished completely
[16:55] <Daemon404> Compn, hiding in your hole silently and then dumping on the ML isnt very good
[16:56] <Daemon404> nobody will accept such patches
[16:57] <Compn> he did want to develop with us
[16:58] <Compn> if nevcairiel's memory is correct
[16:58] <nevcairiel> he could've done it without google giving him moneyz he really cared
[16:58] <nevcairiel> alas he didnt
[16:59] <Compn> Daemon404 : http://ffmpeg.org/pipermail/ffmpeg-devel/2012-June/126139.html
[17:00] <Compn> "it would be great to get tips how to do this best."
[17:00] <ubitux> "The patch applies against commit 69cc119d (0.11.x release branch, I think)" oh shit i missed that part
[17:00] <Compn> Daemon404 : how come you failed to help him in 2012 ?
[17:00] <nevcairiel> he got an answer from michael, but he never responded to that on the ML as far as i can see
[17:01] <ubitux> Keestu: are you the one submitting the mvc patch?
[17:01] <wm4> ubitux: so 100% useless
[17:05] <ubitux> BBB: btw, do you want me to work on the _8 lpf variants or i can look at something else?
[17:05] <ubitux> given the benchmarks, it doesn't look like a priority
[17:05] <ubitux> (and i wonder if it will ever be)
[17:19] <smarter> koda's cleaned up version of the MVC decoder is at https://github.com/kodabb/libav/commits/MVC_orig_clean
[17:20] <smarter> he has also started a document on how the API should be designed: https://wiki.libav.org/Blueprint/MultiAVFrame
[17:24] <kurosu__> I think the openhevc guys working on shvc would be interested by such new api, if they haven't yet participated
[17:25] <kierank> shvc :(
[17:26] <wm4> what would be the best API for mvc decoder output? I actually like 2 + padding if resolution mismatches
[17:27] <nevcairiel> yeah build-in SBS might be useful, and you can always cheat with stride and width changes to reference them individually if you want to
[17:28] <nevcairiel> i'm not sure how shvc is supposed to work exactly
[17:29] <smarter> I think you first call the base layer decoder to get a frame and then the enhancement layer decoder
[17:29] <smarter> https://github.com/OpenHEVC/openHEVC/commits/shvc
[17:29] <nevcairiel> but the goal is to get one image out, not two, isnt it
[17:30] <smarter> and yes, some sort of common API would be nice
[17:30] <smarter> depends
[17:50] <Daemon404> ...
[17:51] <Daemon404> did the openhevc people just go ahead and hack it in?
[17:52] <kierank> Daemon404: of course
[17:52] <kurosu__> I don't think their goals are aligned with ffmpeg/libav (why should they?), more likely they want to be able to showcase the decoder as soon as possible
[17:53] <Daemon404> of course
[17:53] <kierank> I don't think their goals are aligned with ffmpeg/libav (why should they?) --> because they took smarter's code
[17:53] <Daemon404> standard corproate practice
[17:53] <smarter> I think they are interested into getting it in libav/ffmpeg at some point
[17:53] <smarter> they're not corporate people but academia people
[17:53] <Daemon404> isnt ateme involved
[17:54] <smarter> not really
[17:54] <ubitux> j-b: v.o is a bit laggy it seems
[17:54] <kierank> Daemon404: just in the PR
[17:54] <ubitux> j-b: randomly..
[17:54] <Daemon404> smarter, then why did one guy from openhevc say he implemented stuff in intrinsics "because his boss told him to"
[17:54] <kurosu__> the code is (l?)gpl, except publishing it, they aren't bound by anything else - but yes they did push and get it integrated - it's more that the notion that they might have an obligation sounds strange to me
[17:54] <Daemon404> kurosu__, its called not being a bag of dicks
[17:54] <j-b> ubitux: releases days
[17:54] <Daemon404> and working with the community
[17:55] <ubitux> j-b: ah, ok
[17:55] <kierank> kurosu__: they don't have an obligation but working with the community > working on your own
[17:55] <Daemon404> when they so graciously provide you with your entire foundation
[17:55] <smarter> Daemon404: mraulet is a researcher in Rennes and he has some grad students or something  working for him
[17:55] <Daemon404> biting the hand that feeds.
[17:55] <Daemon404> thats the term.
[17:55] <Daemon404> smarter, well academics are the only people i hate more than corporate types
[17:55] <Daemon404> thats not a plus
[17:56] <Daemon404> so...
[17:56] <smarter> :p
[17:56] <Daemon404> (my SO is a researcher, so i get all the fun insdie stuff)
[17:56] <kurosu__> working with the "community" has always been a lot of time wasted for me - not efficient at all, so that doesn't really count as an argument
[17:56] <kurosu__> (for me)
[17:56] <Daemon404> so basically youre an asshole...
[17:56] <kurosu__> and you are being rude
[17:56] <Daemon404> so is wat you do
[17:56] <kurosu__> but that doesn't matter to each other so it is ok
[19:53] <llogan> cehoyos: are you enjoying the vacation from the bug tracker?
[19:53] <cehoyos> LOL
[19:53] <cehoyos> Actually not...
[19:53] <llogan> also, i got a long rant from our resident troll involving you via a long email
[19:54] <cehoyos> The last ts->mkv ticket is a duplicate iirc, on the forum there is a new sample for an existing ticket and on -user, a hevc ticket (drop initial non-key frame) was suggested. I wonder how many of those I will forget...
[19:54] <cehoyos> Resident troll??
[19:55] <cehoyos> But please forward it, I like reading!
[19:56] <cehoyos> Sorry, gtg
[20:08] <Compn> llogan : people write you long troll emails? heh
[20:08] <Compn> i'm glad i dont get those :)
[20:09] <llogan> so far i haven't had the time or motivation to do reply. maybe in my spare-spare time.
[20:09] <llogan> "to do reply". i've turned russian
[20:10] <Compn> kurosu_ : Daemon404 doesnt speak for the project :)
[20:11] <kurosu_> Compn: I don't mind, this was probably a spark of anger and I probably was not correctly presenting my point
[20:11] <Compn> we have people that work with us and people that just work on the code and do dumps. we work with everyone we can
[20:13] <Compn> we wont turn away people just because they didnt kiss our butts :)
[20:13] Action: Compn pulls out double negatives
[20:14] <kurosu_> I understand the origin of the thinking - it's morally wrong. But my issue is that for most people, first they need to achieve something then they can try contributing
[20:14] <Compn> its fine, theres no right or wrong way to contribute
[20:46] <J_Darnley> Who owns the cygwin machine that runs fate?
[20:46] <llogan> what does the 129 mean in "Stream #0:1[0x101]: Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 192 kb/s"?
[20:49] <nevcairiel> its the "fourcc"
[20:49] <nevcairiel> with 129 being the first character :p
[20:49] <nevcairiel> (numeric value of it)
[20:49] <nevcairiel> ie 0x81
[20:49] <J_Darnley> ...  Nevermind I see the history page lists the owner as "beastd"
[20:50] <beastd> hi
[20:51] <llogan> nevcairiel: thanks. any idea why remuxing apparently changes it from 6 to 129? http://ffmpeg.gusari.org/viewtopic.php?f=11&t=1264#p3441
[20:51] <beastd> J_Darnley: I am the owner of what?
[20:51] <Compn> cygwin box
[20:51] <Compn> fate cygwin box
[20:52] <nevcairiel> llogan: mpegts has a fixed list of stream ids, it must pick it from that list
[20:58] <J_Darnley> beastd: the machine that runs fate on Cygwin, or is the page wrong?
[21:01] <beastd> J_Darnley: yes, that is mine. I was just joining and was missing context.
[21:04] <J_Darnley> Yes I see that and it explains why I couldn't tab-complete you name when I first went to do it.
[21:05] <J_Darnley> Now my question.  What do you use to run fate regularly?
[21:07] <beastd> I think the program is named at.exe
[21:08] <beastd> it is from Microsoft and comes with windows AFAICT
[21:09] <beastd> oh seems i am wrong it is named taskschd.msc (maybe the program is named task scheduler in english, i see only the translated name here)
[21:10] <J_Darnley> Yes, I think that's Windows own sheduler
[21:10] <beastd> task scheduling can be configured extensively
[21:11] <Skyler_> BBB / ubitux (?): http://privatepaste.com/01423e301f   this makes that top function ~6% faster, at least on my system (x86_32, gcc 4.8)
[21:11] <J_Darnley> I was considering setting up and running a cygwin64 instance.  I might need to ask you some more questions later.
[21:14] <beastd> nice, i wanted to try that for some time
[21:15] <beastd> but didn
[21:18] <ubitux> Skyler_: seems even slower in decode_coeffs_b() here
[21:19] <Skyler_> huh, strange.  I was using start/stop timer
[21:19] <Skyler_> what test file are you using?
[21:20] <cone-691> ffmpeg.git 03Vignesh Venkatasubramanian 07master:129e24f78e5d: lavf/oggparseopus: Setting seek_preroll in AVCodecContext
[21:21] <ubitux> Skyler_: http://lucy.pkh.me/samples/vp9/etv5k/etv5k.webm
[21:24] <ubitux> overall decode time goes from 30.743 to 31.413
[21:29] <ubitux> before: 3169 decicycles in decode_coeffs_b, 64834422 runs, 2274442 skips
[21:29] <ubitux> after: 3369 decicycles in decode_coeffs_b, 64881776 runs, 2227088 skips
[21:29] <ubitux> Skyler_ ^
[21:29] <Skyler_> huh, on mine it was ~11250 -> 10500 dezicycles
[21:29] <Skyler_> anyways, downloading this on rather slow internet, I'll try with your sample
[21:51] <durandal_1707> what about dejudder filter?
[21:56] <Skyler_> ubitux: bizarrely, 
[21:56] <Skyler_> 7816 decicycles in decode coeffs, 32800764 runs, 753668 skips/A
[21:56] <Skyler_> 8242 decicycles in decode coeffs, 32793514 runs, 760918 skips/A
[21:56] <Skyler_> (after, before)
[21:58] <Skyler_> though I guess I only timed calls from the Y decode,  maybe I shold try the UV too.
[22:09] <Skyler_> 1121 decicycles in uv decode, 33458798 runs, 95634 skipsate=N/A
[22:09] <Skyler_> 7838 decicycles in y decode, 32802663 runs, 751769 skipsate=N/A
[22:09] <Skyler_> 1163 decicycles in uv decode, 33448279 runs, 106153 skipste=N/A
[22:09] <Skyler_> 8235 decicycles in y decode, 32790846 runs, 763586 skipsate=N/A
[22:09] <Skyler_> weird.
[22:35] <ubitux> Skyler_: so always faster in your case?
[22:36] <Skyler_> strangely, yeah.  I suspect the timer is a little inaccurate in maybe both of our cases (a very large number of skips due to variance in call time, since like, a 32x32 takes way longer than a 4x4 and might get skipped)
[22:36] <Skyler_> but I'm not sure if that can fully account for yours being slower and mine being faster.
[22:45] <Skyler_> okay, I fixed the timer to not skip everything
[22:45] <Skyler_> 1224 decicycles in uv decode, 33554419 runs, 13 skipsitrate=N/A
[22:45] <Skyler_> 10389 decicycles in y decode, 33554341 runs, 91 skipsitrate=N/A
[22:45] <Skyler_> 1276 decicycles in uv decode, 33554409 runs, 23 skipsitrate=N/A
[22:45] <Skyler_> 11052 decicycles in y decode, 33554294 runs, 138 skipstrate=N/A
[22:45] <Skyler_> weird :/   I wonder if 64-bit and 32-bit give different results
[22:46] <ubitux> i'm on 64, gcc 4.8
[22:47] <ubitux> test cmd was simply ffmpeg -threads 1 -i etv5k.webm -f null - iirc
[23:17] <Compn> someone wants chromecast support in ffmpeg
[23:18] <Compn> someone who sends a mail to webmaster@
[23:48] <cone-691> ffmpeg.git 03Ben Boeckel 07master:7eb84f2c3b30: ogg: allow streams to update metadata
[23:48] <cone-691> ffmpeg.git 03Ben Boeckel 07master:0dc66553adb8: vorbis: append data from tags together
[23:48] <cone-691> ffmpeg.git 03Ben Boeckel 07master:5a633ec2dd45: vorbis: extract metadata from the middle of a stream
[23:59] <cone-691> ffmpeg.git 03Janne Grunau 07master:a1e1f35203bb: lavu: add missing log.h include in timer.h
[23:59] <cone-691> ffmpeg.git 03Michael Niedermayer 07master:a3be0c334e8b: Merge commit 'a1e1f35203bbcbea0efb51d93e96769c826b8c64'
[00:00] --- Thu Feb  6 2014