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

[burek]

[00:15] <funman> 00:15 -MemoServ(MemoServ at services.)- mraulet is not registered.
[00:15] <funman> damned
[00:23] <BBB> ubitux: ofc :) but you can fix 'em too y'know :)
[00:24] <BBB> llogan: oh thanks that's a lot of attention for random stuff. the summary doesn't really mention what the rest of the blog is about (that is, it tells what frame-mt is, but not what the rest of the entry is all about)
[00:25] <BBB> llogan: but this is totally fine also I guess
[00:26] <ubitux> BBB: all (most?) seem related to the threading so...
[00:26] <ubitux> you know my opinion on that ;)
[00:26] <BBB> great opoortunity to learn all evils of threading
[00:26] <BBB> \o/
[00:26] <BBB> or so
[00:26] <ubitux> exactly
[00:26] <BBB> lol
[00:27] <llogan> BBB: i thought it would have been of interest to FFmpeg-geeks, but yeah, i'll just drop the summary
[00:27] <BBB> llogan: I think you're right actually
[00:27] <BBB> but whichever you think is best
[00:27] <BBB> I have no strong opinion either way
[00:27] <ubitux> llogan: you could also just tweet it
[00:27] <llogan> ubitux: ok. i'm feeling lazy anyway.
[00:28] <ubitux> not sure the "ffmpeg news" is relevant for this, it's not about new things in ffmpeg
[00:28] <llogan> i'll just tweet it
[00:28] <ubitux> you're always looking for things to tweet so..
[00:29] <ubitux> BBB: i've send you the samples in query btw
[00:29] <ubitux> anyway, gtg
[00:40] <BBB> fuzzed2 doesn't crash for me
[00:40] <BBB> valgrind is clean
[00:44] <cone-644> ffmpeg.git 03Clément BSsch 07release/2.1:15d7b7d7ccb1: avcodec/libxavs: attempt to fix compilation after b18c7c8d. (cherry picked from commit 71cd83e34cf7ba88d766434e3d2b4d99c14bf0f2)
[00:44] <cone-644> ffmpeg.git 03Clément BSsch 07release/2.1:d9b7557732f1: avcodec/libxavs: 2nd attempt to fix compilation after b18c7c8d. (cherry picked from commit 260fc0d95b025b03b2a15116526e4c83b1ca1a31)
[00:44] <cone-644> ffmpeg.git 03Michael Niedermayer 07release/2.1:c8d43c22dbb1: avformat/utils/av_probe_input_buffer2: Fix pd.buf_size
[00:44] <cone-644> ffmpeg.git 03Michael Niedermayer 07release/2.1:0a055cc62e23: avformat/utils/av_probe_input_buffer2: fix offset check
[00:44] <cone-644> ffmpeg.git 03Michael Niedermayer 07release/2.1:2156d9bd7db1: avformat/utils/av_probe_input_buffer2: fix buffer passed to ffio_rewind_with_probe_data()
[01:25] <cone-644> ffmpeg.git 03Michael Niedermayer 07release/2.1:7ae6229b97f3: Merge commit '0673ede985a6560e7efb86dab1c58fb7f95ce587'
[01:25] <cone-644> ffmpeg.git 03Michael Niedermayer 07release/2.1:bfdfeadf1154: build sys: rename STRIPFLAGS to ASMSTRIPFLAGS
[01:25] <cone-644> ffmpeg.git 03Michael Niedermayer 07release/2.1:16e49d85b6bb: configure: remove code that disables striping in the absence of some flags
[01:25] <cone-644> ffmpeg.git 03Michael Niedermayer 07release/2.1:45900618ae4d: library.mak: only run asm strip if ASMSTRIP flags are set
[01:59] <cone-644> ffmpeg.git 03Michael Niedermayer 07master:05c78f345b62: avformat/utils: av_probe_input_buffer2 decrease difference to libav
[01:59] <cone-644> ffmpeg.git 03Andrey Myznikov 07master:b79bccba8012: avformat/librtmp: Fix memory leak if RTMP_ConnectStream() fails
[05:16] <michaelni> BBB, about the prores IDCT patchset, ok if i apply it ? (it makes both idcts match and if someone provide more information about the prores fdct / reference samples then we can try to make it closer to that but that should be easier when both idcts match)
[05:21] <cone-596> ffmpeg.git 03James Almer 07master:0b54bc24db8b: webp: add support for EXIF metadata chunks
[09:32] <ubitux> 4412 decicycles in ff_vp9_loop_filter_h_16_16_ssse3, 4193462 runs, 842 skips
[09:32] <ubitux> 3010 decicycles in ff_vp9_loop_filter_v_16_16_ssse3, 4193528 runs, 776 skips
[09:32] <ubitux> 3600 decicycles in ff_vp9_loop_filter_h_16_16_avx, 4193621 runs, 683 skips
[09:32] <ubitux> 2678 decicycles in ff_vp9_loop_filter_v_16_16_avx, 4193742 runs, 562 skips
[09:32] <ubitux> indeed BBB 
[09:32] <ubitux> not bad :)
[09:33] <nevcairiel> how much of avx does that really use?
[09:34] <ubitux> just the mov thing i suppose
[09:34] <nevcairiel> still xmm i guess?
[09:34] <ubitux> yes
[09:34] <ubitux> it's not avx2
[09:35] <ubitux> that's pretty nice for a 15-lines diff
[09:37] <nevcairiel> :)
[09:41] <ubitux> i don't know if i need to check for ARCH_X86_64 or if it's implicit
[11:56] <saste> anyone going to review the libvidstab patch?
[11:56] <saste> ^ ubitux?
[11:57] <ubitux> i didn't plan
[11:57] <ubitux> since you were active on it ;)
[11:57] <saste> ubitux, no the filter code
[11:57] <saste> the configure patch depends on the filter changes
[11:59] <ubitux> well except the shitty style it should be fine
[12:01] <ubitux> i have on todo list to port that lib so it can fully benefit from the ffmpeg infrastructure
[12:01] <ubitux> but it will take some little time
[12:23] <ubitux> is there a delay in the seek sometimes?
[12:23] <ubitux> ah, my bad
[12:45] <ubitux> ok there is a delay.
[12:47] <ubitux> http://pastie.org/pastes/8632251/text
[12:48] <ubitux> so, is this a wanted behaviour?
[12:48] <nevcairiel> sounds like something didnt get flushed
[12:48] <nevcairiel> did you flush teh decoder on seek?
[12:49] <ubitux> it's supposed to do it automatically
[12:49] <nevcairiel> how would the decoder know if avformat changes position? :)
[12:50] <ubitux> well, the function is supposed to call the flush
[12:51] <ubitux> mmh maybe it only happens when read_seek2 callback is available
[12:51] Action: ubitux is confused
[12:51] <nevcairiel> it shouldnt happen at all
[12:51] <nevcairiel> avformat doesnt know about the decoder
[12:51] <nevcairiel> how would it
[12:52] <nevcairiel> its not guaranteed that you use the same AVCodecContext that avformat setup, in fact it can be even be problematic to use the smae
[12:52] <nevcairiel> so many setups create a copy of it for the decoder
[12:53] <nevcairiel> hence, an explicit call to avcodec_flush_context or whatwasitsname is required
[12:53] <ubitux> ah..
[12:54] <ubitux> i don't see ffplay doing that
[12:54] <ubitux> is it normal?
[12:55] <nevcairiel> avcodec_flush_buffers was the name
[12:55] <nevcairiel> and i see ffplay calling it
[12:55] <nevcairiel> after a seek ffplay queues a flush_pkt
[12:55] <ubitux> any idea why it's done in a weird place?
[12:56] <nevcairiel> which then causes it to flush later
[12:56] <nevcairiel> its a bit of a odd design, but what do i know about ffplay
[12:56] <ubitux> mmh
[12:56] <nevcairiel> maybe its afraid of a threading thing
[12:57] <nevcairiel> and the packet queue is properly locked, but the avcodeccontext is not
[12:57] Action: nevcairiel is just guessing here
[13:00] <ubitux> ok great
[13:00] <ubitux> nevcairiel: thanks a lot :)
[13:03] <BBB> ubitux: great work
[13:04] <ubitux> you mean the 15-line diff to add avx?
[13:04] <BBB> yes
[13:04] <BBB> who cares how many lines it is
[13:04] <ubitux> :D
[13:04] <BBB> this is all about result
[13:04] <BBB> you got it 20% and 10% faster, if I count correctly?
[13:05] <BBB> that's really good
[13:05] <BBB> michaelni: I'm thinking...
[13:19] <BBB> michaelni: I don't really have much of an opinion either way, I do worry about moving away from the prores code, but I'm inclined to believe we just took whatever we RE'ed to fit in with the original simpel_idct (minus different scaling, hence it's its own function), so this won't make things worse, just differently unknown and at least the bitexact check goes away in the cpuflags
[13:19] <BBB> michaelni: so given that I guess it's fine
[13:38] <BBB> ubitux: are you going to do avx for all simd functions?
[13:38] <BBB> ubitux: I'm sure idct would be helped by it also
[13:39] <Daemon404> isnt avx mostly float?
[13:39] <BBB> three-operand instructions works for int also
[13:39] <Daemon404> ah ok
[13:39] <BBB> but it's still on xmm registers, not ymm, yes
[13:39] <BBB> avx2 does ymm-int
[13:39] <BBB> (haswell)
[13:39] <Daemon404> yeah i know avx2 does
[13:39] <Daemon404> but hardly anyone has it
[13:40] <BBB> buy me a new laptop and I'll write avx2
[13:40] <Daemon404> ;)
[13:40] <BBB> (it has to be a macbook pro, else I won't use it)
[13:40] <Daemon404> im thinking of buying a new laptop in feb, but not a mbp
[13:41] <Daemon404> the current one i have is retardedly locked by the bios
[13:41] <Daemon404> (it disables vt-x)
[13:42] <Daemon404> cant decided between an mbp (then wiping os x) or a lenovo ultrabook
[13:43] <TimNich> vt-x is disabled in a lot of BIOS's by default
[13:43] <j-b> good morning 
[13:43] <Daemon404> TimNich, no i mean i am unable to enable it without hacking the bios
[13:43] <Daemon404> because they want to sell that as a 'feature' in their 'business' laptops
[13:44] <Daemon404> consumers dont need vt-x, DUH
[13:45] <Daemon404> ill likely get it when im in NY in feb
[13:45] <Daemon404> because screw uk kb layouts
[13:45] Action: Daemon404 runs
[14:10] <ubitux> BBB: feel free to :p
[14:17] <BBB> oh
[14:17] <BBB> :/
[14:18] <ubitux> BBB: i can do it if you want :))
[14:19] <BBB> holy crap it's $3.3k
[14:19] <BBB> but then it must be haswell right?
[14:19] <BBB> I hope so
[14:20] <Daemon404> http://shop.lenovo.com/gb/en/laptops/thinkpad/x-series/x1-carbon/ <-- considering thi
[14:20] <Daemon404> s
[14:20] <Daemon404> (us version)
[14:20] <BBB> http://store.apple.com/us/buy-mac/macbook-pro?product=ME294LL/A&step=config
[14:21] <BBB> and then bigger cpu and bigger hd
[14:21] <BBB> =3.3k :/
[14:21] <BBB> ok work time
[14:21] <ubitux> BBB: ok, trying avx, will give you some bench
[14:22] <BBB> \o/
[14:22] <BBB> feel free to send patches, I bet most will be trivial
[14:22] <BBB> also note avx is only xmm, so it won't help for the 4x4 idct
[14:22] <BBB> (just in case you want to try :-p)
[14:22] <ubitux> :(
[14:22] <BBB> we can make a 2x4x4 idct
[14:22] <BBB> that can do xmm -> avx
[14:23] <ubitux> BBB: btw, can we assume X86_64 with avx?
[14:23] <BBB> no sadly
[14:23] <ubitux> mmh ok
[14:23] <BBB> but just put it under %if ARCH_X86_64
[14:23] <BBB> we did with most assembly so far
[14:23] <BBB> I think it's fine
[14:23] <ubitux> okay
[14:23] <Rodeo> can't seem to go bove $8,700 on that Apple configuration page, no way to break the $10k barrier
[14:23] <BBB> also iadst16 is almost done
[14:24] <BBB> Rodeo: try corporate consulting
[14:24] <BBB> ok work for real now, bye
[14:36] <cone-768> ffmpeg.git 03Robert Krüger 07master:4a38eeec38c5: Revert "Revert "vf_yadif: move x86 init code to x86/yadif.c""
[14:36] <cone-768> ffmpeg.git 03Robert Krüger 07master:99c4abfe8862: Revert "Revert "yadif: add parens around macro parameters""
[14:36] <cone-768> ffmpeg.git 03Robert Krüger 07master:61093993668b: Revert "avfilter/yadif: Revert "lavfi: convert input/ouput list compound literals to named objects""
[14:36] <cone-768> ffmpeg.git 03Robert Krüger 07master:194ef56ba7e6: Change license of yadif from GPL to LGPL
[14:44] <cone-768> ffmpeg.git 03Diego Biurrun 07master:7151c5d04aed: arm: Use full filenames as multiple inclusion guards
[14:44] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:7766c7b7a009: Merge commit '7151c5d04aed3b496c21f713dcb603e2cbdb9c49'
[14:51] <cone-768> ffmpeg.git 03Diego Biurrun 07master:46bacb5cc616: x86: Consistently use cpu flag detection macros in places that still miss it
[14:51] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:b148a39d55ee: Merge commit '46bacb5cc6169ff5e8e982495c4925467c1d8bb7'
[15:00] <cone-768> ffmpeg.git 03Robert Krüger 07master:d8e763fda772: vf_yadif: Relicense from GPL to LGPL
[15:00] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:12bc33d7cd04: Merge remote-tracking branch 'qatar/master'
[15:10] <ubitux> BBB: http://b.pkh.me/0001-vp9-x86-add-AVX-for-itxfm-and-lpf.patch
[15:10] <nevcairiel> its nice when x86inc can do something neat like this for you, aint it
[15:11] <ubitux> yeah :)
[15:13] <ubitux> if someone offers me an avx2 cpu i don't mind adding more :p
[15:14] <ubitux> (i'm too lazy to upload to kierank machine :p)
[15:56] <j-b> who is the mxf expert?
[15:56] <ubitux> maybe mateo` 
[15:57] <j-b> mateo`: I got MXF files unsupported in ffplay. Are you interested in getting access to them?
[15:58] <Daemon404> have you tried ffmbc?
[15:58] <j-b> no.
[15:58] <mateo`> j-b: yes
[15:58] <j-b> mateo`: it's a new RDD spec (25?) if I understood correctly
[15:59] <j-b> Daemon404: no. I'm not interested in this fork.
[16:00] <Daemon404> i assume because gplv3 prevents backports
[16:00] <mateo`> oh well, i'm not aware anymore of the new MXF specs but i can take a look
[16:00] <nevcairiel> I still dont understand how this gpl-upgrade can be a good idea. I can take a LGPL project and make it impossible for them to benefit from my development, that seems totally backwards to me
[16:01] <Daemon404> it's *freedom*
[16:01] <nevcairiel> it limits my freedom to take ffmbc code and backport to ffmpeg
[16:02] <j-b> Daemon404: no. It's because I'm not interested in projects that do not collaborate with the community.
[16:02] <michaelni> nevcairiel, you could ask the author if he is ok with backporting the code
[16:02] <j-b> Daemon404: it's like the whole "this-is-open-source-but-I-object-to-any-change-to-it" and "I-m-the-maintainer. Don't-touch".
[16:03] <nevcairiel> thats not the point, i'm complaining about the license BS, not an actual example =p
[16:04] <nevcairiel> anyway back to writing code!
[16:08] <wm4> does ffmbc have contributors? or is it a one man project?
[16:09] <wm4> hard to tell, because they don't seem to have a git repo
[16:10] <Daemon404> j-b, true
[16:10] <Daemon404> and agreed
[16:10] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:d9e556ebd04c: avcodec/proresdsp & idct: move biasing from after the IDCT into the IDCT
[16:10] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:cca2772e1689: avcodec/simple_idct_template: change the idct coefficients so that they match the x86 code
[16:10] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:a7ea733b721e: avcodec/simple_idct_template: fix row rounder
[16:10] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:4b0cad6596bc: avcodec/simple_idct_template: fix rounding of the special DC case for 10bit
[16:10] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:cb613657ee46: avcodec/x86/proresdsp_init: x86 prores IDCT is bitexact again
[16:15] <ubitux> michaelni: CLIP_AND_BIAS could be renamed to CLIP :p
[16:16] <nevcairiel> it could also be renamed to BANANA
[16:17] <ubitux> BANANA is nice as well indeed
[16:34] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:b821def9f5ee: avcodec/proresdsp: rename CLIP_AND_BIAS to BANANA
[16:35] <ubitux> waaat
[16:35] <nevcairiel> haha
[16:35] <ubitux> :D
[16:35] <ubitux> ahaha
[16:35] <nevcairiel> well he didnt actually do it
[16:35] <nevcairiel> but good one :D
[16:35] <ubitux> :)
[16:36] <mateo`> hahaha
[16:37] <TimNich> aja.com
[16:38] <wm4> lol
[16:38] <wm4> the commit message is a lie
[16:38] Action: wm4 is disappointed
[16:39] <wm4> a valueable opportunity for mocking a bad (?) codec is lost
[16:39] <nevcairiel> not sure prores is that bad, its just proprietary, which some might consider bad by design
[16:42] <Daemon404> the tech used in it isnt really proprietary
[16:42] <Daemon404> i call it fanc jpeg
[16:42] <Daemon404> fancy*
[17:03] <ubitux> saste: nice thing the pkg config version check btw
[17:11] <kierank> j-b: can i have a look at the samples?
[17:12] <j-b> kierank: sure.
[17:12] <kierank> nevcairiel: the coefficient rescan is quite interesting
[17:12] <kierank> allows spatial scalability
[17:12] <kierank> in that domain compression isn't everything
[17:13] <kierank> j-b: pure speculation but I think we don't have a tag for aac audio in mxf
[17:13] <j-b> kierank: video is absent too
[17:13] <kierank> oh
[17:24] <kierank> j-b: you can also ask wtf this thing is to the ebu guys at fosdem but i doubt they'll know
[17:30] <mateo`> j-b: did you provide the sample somewhere ?
[17:32] <j-b> mateo`: I'm uploading it
[17:33] <mateo`> ok
[18:44] <ubitux> j-b: they lack a demuxer, not a decoder
[18:46] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:b2ae92110f9e: avcodec/flashsv: check avio_read() return in mov_read_udta_string()
[18:46] <j-b> ubitux: ah
[19:07] <wm4> ubitux: but that means no animated gifs
[19:07] <wm4> the best video codec... not supported
[19:10] <ubitux> i think that's actually pretty cool to support it but well
[19:26] <JEEB> lol
[19:26] <JEEB> intel is distributing ffmpeg
[19:26] <JEEB> with the samples of theirs
[19:26] <JEEB> (media sdk)
[19:27] <nevcairiel> oh right i wanted to check the new sdk
[19:27] <nevcairiel> but first need to upload a new release before i have to setup new hosting with google code file uploads going down tomorrow
[19:33] <{V}> JEEB, cool
[19:34] <JEEB> nevcairiel, I hope you remember your intel account's uname/pw better than I do :P
[19:34] <JEEB> the new SDK and the samples need login to download
[19:34] <JEEB> and I got locked out when guessing mine
[19:35] <nevcairiel> had to change the password on login
[19:35] <nevcairiel> but thats all
[19:37] <nevcairiel> i wonder whats in their HEVC sdk thing
[19:38] <wm4> <nevcairiel> but first need to upload a new release before i have to setup new hosting with google code file uploads going down tomorrow <- huh, already?
[19:38] <nevcairiel> well the upload option gets disabled tomorrow iirc, existing files remain accessible
[19:39] <nevcairiel> "Google Code will not support creating new downloads starting January 15th, 2014."
[19:39] <JEEB> I think the sdk just has a decoder
[19:40] <JEEB> also if you look there you'll notice that they will be offering elecard's mp4 demuxer and vanguard's HEVC dec/encoder
[19:40] <JEEB> in the future
[19:40] <JEEB> (separate to their own HEVC thingy)
[19:40] <nevcairiel> yeah i saw
[21:20] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:2545182c294f: avcodec/mpegaudiodec_template/mp3on4: check that all channels have been decoded before returnig a frame
[21:20] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:afbe8c6a8441: avcodec/mpegaudiodec_template: decode_frame_mp3on4: conceal errors in decoding instead of discarding data
[21:32] <cone-768> ffmpeg.git 03Reimar Döffinger 07master:d84bd4650b1b: mxf: Set AV_FIELD_PROGRESSIVE
[21:32] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:8721dda1c57f: Merge commit 'd84bd4650b1bed882e2ac1651b4a86206aa0e363'
[21:43] <ubitux> mmh we don't have any avx2 code in ffmpeg?
[21:43] <ubitux> that's not serious.
[21:43] <nevcairiel> its new
[21:43] <cone-768> ffmpeg.git 03Luca Barbato 07master:42f9132218ca: mxf: Do not use int to check the seek position
[21:43] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:1171ad647ebf: Merge commit '42f9132218ca11a8e9a3c82a175b46bca092113e'
[21:43] <nevcairiel> does the x86inc framework even have it yet
[21:44] <nevcairiel> guess it does
[21:44] <ubitux> yes there are a bunch of optims in x264
[21:44] <ubitux> we just have the flag
[21:44] <ubitux> sadness.
[21:45] <nevcairiel> at least cpu detection is implemented as well
[21:45] <kierank> I have some patches for swscale
[21:45] <nevcairiel> you can be the first, today!
[21:45] <kierank> one of the bitdepths is broken though
[21:45] <ubitux> nevcairiel: oh you're going to send me a cpu? @_@
[21:46] <nevcairiel> hm ...i can give you a shell on one? :D
[21:48] <ubitux> that's gonna be painful
[21:49] <nevcairiel> low-end cpus are rather cheap though, of course not the most fun to compile on either
[21:50] <nevcairiel> hm looks like the lowest end doesnt have avx2
[21:51] <kierank> nevcairiel: there is ccache
[21:52] <nevcairiel> i guess
[21:53] <nevcairiel> the cheapest cpu with avx2 is the i3-4130 then
[21:54] <nevcairiel> around 100¬
[21:54] <nevcairiel> ask saste for SPI funds :P
[21:59] <cone-768> ffmpeg.git 03Marton Balint 07master:aa0cb16c15a5: mxf: Fix off by one error in d10 aes3 decoding
[21:59] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:d938a013af76: Merge commit 'aa0cb16c15a5b30f78542f18e3fa65de005cf084'
[22:09] <michaelni> nevcairiel, Intel Core i5-4570, 4x 3.20GHz is 157¬ and i wont approv funds being used for cheapest CPUs we want devels to have some decent hw
[22:11] <nevcairiel> sure
[22:13] <cone-768> ffmpeg.git 03Luca Barbato 07master:f5fbbbc022f7: mxf: Drop unnecessary checks
[22:13] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:84ca7c28ce49: Merge commit 'f5fbbbc022f723d3ccf99afd5d658a977b51c08a'
[22:22] <llogan> nice description...
[22:28] <cone-768> ffmpeg.git 03Luca Barbato 07master:1a4e4ad0e0c5: mxf: Use av_malloc_array
[22:28] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:e3c0fcaddabe: Merge commit '1a4e4ad0e0c5486dcab05e54b587672a498dd7cf'
[22:42] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:0d6605c7ef43: mxf: Fix a possible leak of extradata
[22:42] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:bd8788ea17c3: Merge commit '0d6605c7ef43f97a88950542af09078adef33b6d'
[22:50] <cone-768> ffmpeg.git 03Tomas Härdin 07master:8b708f1c6b1b: mxf: Correctly support files from Pinnacle Thunder
[22:50] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:633214667684: Merge commit '8b708f1c6b1baf3b97ed93226bf5dae1a9b13fb7'
[23:09] <cone-768> ffmpeg.git 03Tomas Härdin 07master:cc1e3ace6307: mxf: Fix potential leak in mxf_read_local_tags()
[23:09] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:05fac0b45be2: Merge remote-tracking branch 'qatar/master'
[23:15] <ubitux> http://pastie.org/pastes/8633851/text
[23:15] <ubitux> ok, let's do 8x8.
[23:34] <ubitux> mmh perf doesn't provide the most common callers?
[00:00] --- Wed Jan 15 2014