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

[burek]

[00:36] <Daemon404> kierank, ah.
[01:30] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:843d93d286ee: doc/codecs: document nomc flag
[02:04] <BBB> does anyone know why ffmpeg doesnt display in ohloh/openhub?
[02:22] <compn> BBB : ohloh.net/p/ffmpeg worked yesterday for me
[02:23] <BBB> I think I figured it out, it somehow lost the link between my account and ffmpegs rbultje committer
[02:23] <BBB> veyr odd
[02:23] <BBB> and after claiming it, it doesnt add it up to my personal account
[02:23] <BBB> I think theres a delay or so
[02:38] <compn> maybe it has to rescan
[03:34] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:a8bc901033e8: avcodec/wmadec: also print the number of bits left in the nb_frames <= 0 case
[03:34] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:e2db9a736fd9: avcodec/wmadec: fix 0 frame bit_reservoir
[04:59] <pross> hmmm, Managers: Diego Biurrun
[05:07] <Timothy_Gu> pross: yeah
[05:07] <Timothy_Gu> pross: I actually had a ~20-mail conversation about giving the manager rights to be or someone else who actually reads ffmpeg-devel but he refused
[05:07] <Timothy_Gu> *to me
[05:13] <wm4> lolwut
[05:14] <wm4> this behavior makes no sense, other than...
[05:17] <pross> the part about 'making no sense', actually makes sense.
[06:02] <wm4> so what still uses ATSC closed captions?
[06:46] <kierank> A lot of stuff does
[06:46] <rcombs> wm4: US terrestrial and cable TV, I'd expect
[06:47] <rcombs> (and maybe satellite as well, but not sure on that)
[06:50] <rcombs> wm4: know of anything that actually uses 708 in H.264 or H.265?
[06:50] <rcombs> erm, kierank: ^
[07:01] <kierank> Yes there are broadcasts with 708
[07:01] <kierank> In h264
[07:25] <wm4> kierank: apparently ffmpeg can't handle it, though?
[08:21] <espes__> multimedia is hard and I'm sad :(
[08:23] <espes__> the mpeg-ts im trying to make crashes quicktime and vlc
[08:23] <espes__> nothing supports latm and aac-eld
[11:47] <ubitux> michaelni: sorry about the delay
[11:47] <ubitux> done
[11:55] <ubitux> ffmpeg -f lavfi -i testsrc=hd1080 -c:v $C -pix_fmt yuv444p -f null -  i get 27 fps with C=ffv1, and 50 fps with C=ffvhuff
[11:55] <ubitux> is this the expected performance?
[12:43] <kierank> wm4: for some definition, yes
[12:46] <iive> ubitux: yes. ffv1 uses cabac/cavlc
[12:50] <ubitux> iive: i'm more surprise not to see ffvhuff faster, but yeah ok
[12:51] <iive> ubitux: it could be made faster, if simd pixel median is implemented.
[13:13] Action: michaelni gets 95 and 43 fps for that
[13:13] <michaelni> iive, doesnt huffyuv already use simd median or did i misunderstood what you meant
[13:13] <michaelni> ?
[13:16] <iive> michaelni: i honestly don't know. i remember somebody (skaal from xvid?) was talking about doing median on 8 pixels simultaneously using mmx, however this required a little bit of trickery, because the result of one median is used for its neighbors 
[13:17] <iive> so the optimal simd would be performing simd median on 8 diagonal pixels at a time.
[13:17] <iive> or something like that. I don't know if that have been implemented.
[13:18] <michaelni> thats for the decoding side the benchmark here was for encoding
[13:18] Action: michaelni gets 53fps with ffv1 and  -level 3 -slices 12 -threads 12
[13:18] <iive> you don't do median on both?
[13:19] <iive> I don't remember how huffman worked...
[13:21] <av500> he worked at his desk
[13:21] <iive> yes, but how ;)
[13:22] <av500> he thought a lot
[13:22] <av500> and wrote a lot down on paper
[13:22] <av500> then he ate lunch
[13:22] <iive> yeh, i get it, all pixels are available on encoding, so they are easy to be done in parallel, on decoding, you need to decode them in order.
[13:23] <michaelni> ubitux, your benchmarks are faulty
[13:23] <av500> unless you slice the frame
[13:23] <michaelni> if i store the video in ffv1.nut and convert that again to ffv1 then i get 200fps
[13:23] <michaelni> sorry ffv1 -> ffvhuff
[13:24] <michaelni> actually ffvhuff->ffvhuff, but still its twice the speed than with testsrc and convert to yuv444
[13:25] Action: michaelni is a bit sleepy stiill 
[13:27] <michaelni> ffv1 -> ffv1 is 79fps, ffvhuff->ffvhuff is 200fps
[13:31] <iive> with the ubitux command i get ffv1 19fps with 75% cpu load. ffvhuff gives me 40% with about 50% cpu.
[13:31] <iive> i3 ,4 virtual cores.
[13:35] <michaelni> i7 12 virtual cores for my numbers
[13:39] <michaelni> ubitux, thx for the review!
[13:42] <iive> s/40%/40fps
[13:53] <cone-80> ffmpeg.git 03Michael Niedermayer 07master:4f664d8aae8c: avcodec/ccaption_dec: Fix typos and cosmetics
[14:07] <ubitux> michaelni: you mean it's faulty because of the rgb’yuv convert occuring after testsrc? if so, it's proportionnal between the 2 tests anyway, isn't it?
[14:15] <cone-80> ffmpeg.git 03Michael Niedermayer 07master:365ef88d5df4: avcodec/wma: Print more details in case of spectral RLE overflows
[14:16] <michaelni> ubitux, yes
[14:16] <michaelni> that is if you cann (C+x) / (C+y) proportional to x/y
[14:16] <michaelni> caLL
[14:17] <ubitux> yeah sure ok
[14:17] <ubitux> :)
[16:08] <thardin> does anyone know if there's a test RTMP stream somewhere?
[16:10] <compn> BBB : librtmp isnt a fail , just have to use ksv's fork , it has updates.
[16:10] <compn> thardin : multimedia.cx wiki rtmp page may have some active urls ?
[16:11] <compn> http://wiki.multimedia.cx/index.php?title=RTMP#Samples
[16:11] <compn> course those are very old now
[16:12] <compn> rtmp://directv.fcod.llnwd.net/a517/d1/com/lp/testdrive/active_channel-hack.flv works
[16:18] <thardin> hey, as long as it works :)
[16:18] <thardin> also thanks
[16:23] <compn> BBB : i might be wrong about librtmp. i was thinking of the rtmpdump program itself :p
[16:24] <compn> librtmp isnt used much
[16:24] <compn> except probably vlc again ?
[17:51] <cone-265> ffmpeg.git 03James Almer 07master:3aaff803489a: avutil/opencl: don't include config.h
[19:33] <llogan> Timothy_Gu: your repository is the correctone one for libilbc, right? dekkers is old?
[19:34] <llogan> oh, it just redirects to yours. i should have just tried it
[19:36] <cone-265> ffmpeg.git 03Lou Logan 07master:e9f8780381fe: doc/general: update libilbc link
[19:42] <cone-265> ffmpeg.git 03James Almer 07master:59ac93f6af3e: x86/swr: add SSE/AVX unpack_6ch functions
[19:57] <aetasx> bsfs are only invoke explicitly correct?  Im trying to do a stripped down build for linking into x264
[19:58] <nevcairiel> yes
[20:35] <cone-265> ffmpeg.git 03Mark Reid 07master:b08b5f4be2cc: libavformat/mxfdec.c: read project_name metadata
[21:29] <kierank> "Support dynamic loading of third-party libs"
[21:29] <kierank> wtf
[21:31] <compn> kierank : oh nice :)
[23:39] <pross> mmm. what next, VfW loader
[23:41] <nevcairiel> kierank: personally i think it would be nice to dynamically load at least libva, so that i can distribute binaries without the hard-dep :p
[00:00] --- Tue Jan 13 2015