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

[burek]

[00:41] <BtbN> Are named filter arguments changed/broken in current master?
[00:56] <Compn> what error you get BtbN ?
[00:57] <BtbN> it trys to use the filter line as output filename, like -vf wouldn't be there
[00:57] <Compn> can you copy and paaaste ?
[00:57] <BtbN> i'm not yet sure why, i suspect a bash escaping hell
[00:58] <BtbN> it's a script which generates the commandline, i guess something goes wrong with that
[00:58] <Compn> yes i blame your script :)
[00:58] <Compn> ehe
[00:58] <BtbN> oh, yea
[00:58] <BtbN> -vf is not missing, it's there twice...
[00:59] <BtbN> yeah, first scaling, then deinterlacing helps a lot!
[01:56] <cone-632> ffmpeg.git 03Anton Khirnov 07master:6bb8720f00e2: AVOptions: deprecate unused AV_OPT_FLAG_METADATA
[01:56] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:f4c8d002231a: Merge commit '6bb8720f00e2e6209665f819fb351fd42b82d5d0'
[02:07] <cone-632> ffmpeg.git 03Anton Khirnov 07master:c3ecd968f0e7: AVOptions: add flags for read/read-only options
[02:07] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:6a24d77929e0: Merge commit 'c3ecd968f0e78da6e77f0c06c2f785b266d83cf1'
[02:17] <cone-632> ffmpeg.git 03Leandro Dorileo 07master:8370a6fa5942: libavformat/mpegts: expose raw packet size
[02:17] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:c849b00b804c: Merge remote-tracking branch 'qatar/master'
[02:35] <BBB> j-b: libvpx
[02:37] <BBB> ubitux: I guess
[02:37] <BBB> nevcairiel: thanks!
[02:37] <BBB> ubitux: will add your results soon
[02:39] <BBB> ubitux: we should throw in some more bitrates for you, like, I don't know, 50000kbps for vp8/x264
[02:40] <BBB> ubitux: and maybe a few lower bitrates
[02:40] <BBB> ubitux: like 2500, 1000 for all
[02:40] <BBB> (don't need to do 50000 for vp9, the 20k gives good enough results)
[02:42] <BBB> did anyone notice the vp9 bitrate is like WAAAAAAAAAAAAAAY off on that clip? like 2x or so
[02:46] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:8f33810ed26f: avfilter/vf_fps: fix rounding error accumulation
[02:57] <cone-632> ffmpeg.git 03Nicolas George 07master:6c27aea81163: lavfi/pan: use extended_data instead of data.
[02:57] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:cbd9cc5997ec: Merge remote-tracking branch 'cigaes/master'
[03:06] <cone-632> ffmpeg.git 03Nicolas George 07master:916a79227e0d: lavf/mux: check av_dup_packet() return value.
[03:27] <smarter> BBB: try encoding without --aq-mode 1 to get closer to the target bitrate
[03:27] <Daemon404> O.o
[03:27] <Daemon404> thats some pretty derpy rc
[03:27] <smarter> also it might make things better at low enough bitrates
[03:31] <smarter> Daemon404: AQ makes it harder to predict the bitrate right in VP9 very limited first pass, but yeah, 2x seems rather crazy
[03:32] <Daemon404> just encode N times and use NewtonRaphson
[03:32] <Daemon404> duh
[03:32] <Daemon404> perfectly feasible.
[03:32] <BBB> smarter: nah we'll use --aq-mode=1, I don't mind if it's off
[03:33] <BBB> smarter: we'll just re-encode another one at a lower target rate ;)
[03:33] <BBB> it's really 2x off
[03:33] <BBB> smarter: maybe you should try to debug if --aq-mode=1 has something to do with it? I'm not sure
[03:33] <BBB> x264 actually beats vp9 on this clip at high bitrates
[03:34] <Daemon404> metric wise or psy?
[03:34] <BBB> metric ofc, I'm not going to go into arguments with people over which clip looks better
[03:34] <smarter> (for my tests, I first encoded with libvpx then did 3- or 4-pass encodes with x264 to get as close as possible to the vp9 bitrate)
[03:34] <BBB> it'll never ends
[03:34] <smarter> what's the clip?
[03:34] <BBB> etv5k
[03:34] <BBB> ask ubitux
[03:34] <BBB> http://lucy.pkh.me/encodes/
[03:35] <BBB> there's the source clip also
[03:35] <smarter> yeah, but I don't know if he'll be happy if I download that huge file from his host :]
[03:36] <BBB> he put it there for a reason
[03:36] <Daemon404> people need to start compressing these things
[03:36] <Daemon404> its such a pain in the butt to dl them
[03:36] <smarter> lossless VP9 :D
[03:36] <Daemon404> the 4k clip i have comrpesses from 25gb to 9gb with lzma2
[03:36] <Daemon404> thats very nontrivial
[03:37] <Daemon404> (yuv444p10le, so lots of redundancy)
[03:52] <Compn> what about compression-in-container ? why has no video container done that ?
[03:52] Action: Compn trolls and runs away
[03:54] <BBB> Compn: well the cntent is compressed already, so low-overhead is all that's left
[03:55] Action: Compn would like rar/zip/xz/7z demuxer in ffmpeg too
[03:55] Action: Daemon404 barfs
[03:56] <BBB> I'll just keep focussing on real things
[03:56] <BBB> like it'd be nice if chrome used ffvp9
[03:56] <Daemon404> dont the even still use libpx for vp8
[03:56] <Daemon404> due to error concealment
[03:57] <Daemon404> they*
[03:57] <BBB> for webrtc yes
[03:57] <BBB> for html5 and stuff related to that (including media source api), no, they use ffvp8
[03:57] <BBB> mediasource/html5 is over tcp so error concealment isn't an issue
[04:19] <BBB> kierank: how many cores does obe2 have?
[04:24] <BBB> looks like 8?
[04:24] <BBB> can I play with that?
[06:01] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:3edc3b159503: avcodec/mpeg4videodec: Check for bitstream overread in decode_vol_header()
[10:04] <ubitux> <@BBB> did anyone notice the vp9 bitrate is like WAAAAAAAAAAAAAAY off on that clip? like 2x or so // yeah... :/
[10:07] <ubitux> smarter: do you want the h264 source of etv?
[10:08] <ubitux> BBB: so, is that due to aq mode?
[10:10] <ubitux> smarter: i don't mind if you grab the y4m, it will just take some time :p
[10:12] <ubitux> -rw-r--r-- 1 ux ux 497M Feb 17 16:47 etv5k-vp8-b20000.webm
[10:12] <ubitux> -rw-r--r-- 1 ux ux 940M Feb 19 13:45 etv5k-vp9-b20000.webm
[10:12] <ubitux> -rw-r--r-- 1 ux ux 494M Feb 17 20:49 etv5k-x264-b20000.mkv
[10:12] <ubitux> that really is freaky
[10:15] <nevcairiel> vp9 fails to achieve the bitrate target?
[10:15] <ubitux> by a factor 2 yeah
[10:15] <nevcairiel> did 10000 work better?
[10:15] <ubitux> it's closer to 2 ;)
[10:15] <ubitux> -rw-r--r-- 1 ux ux 249M Feb 17 16:45 etv5k-vp8-b10000.webm
[10:15] <ubitux> -rw-r--r-- 1 ux ux 501M Feb 19 07:27 etv5k-vp9-b10000.webm
[10:15] <ubitux> -rw-r--r-- 1 ux ux 248M Feb 17 19:44 etv5k-x264-b10000.mkv
[10:15] <nevcairiel> heh
[10:16] <nevcairiel> no wonder your ssims  looked pretty good
[10:16] <ubitux> and before you ask, yeah 5000 as well
[10:16] <nevcairiel> so encode a 2500 which comes out at around 5000, and everything is fine?!?
[10:17] <ubitux> :D
[10:17] <nevcairiel> seems like a serious bug, above all a 2-pass should hit its target bitrate
[10:18] <ubitux> don't have the issue with your samples?
[10:18] <nevcairiel> nah, perfect sizes
[10:18] <ubitux> 'love my sample ;)
[10:18] <nevcairiel> its the grain i tell you
[10:19] <ubitux> :)
[10:19] <nevcairiel> i wonder why h264 film grain synthesis was never used by anything, i'm sure it could've helped on such samples
[10:22] <ubitux> ah there is actually such flag?
[10:24] <nevcairiel> its technically a post-processing step in the decoder, the source is stripped of grain (or doesn't have any to begin with), and the decoder synthesis it back, but its not supported by anything i know
[10:24] <nevcairiel> maybe it didn't work out as expected
[10:27] <wm4> that sounds awesome, if it works
[10:27] <ubitux> nevcairiel: there is not only grain in that video btw; motion is relatively creepy, there are also flashes scene cut killers, random color madness and creepy motion
[10:27] <ubitux> oups quoting twice motion.
[10:41] <cbsrobot> what movie is it ?
[10:41] <cbsrobot> it's a good example of POV madness
[10:43] <cbsrobot> s/what/which/
[10:43] <ubitux> http://www.imdb.com/title/tt1191111/
[10:44] <ubitux> cbsrobot ^
[10:44] <ubitux> 5000 frames starting at about 135 seconds
[10:59] <kierank> BBB: ask ifb
[10:59] <kierank> who for some reason is not online
[14:25] <plepere> hmmmmm. apparently, doing multiple SWAP in ASM gives wrong results
[14:25] <plepere> took some time to find that bug. :/
[14:27] <ubitux> you can use them in a loop
[14:27] <ubitux> can't*
[14:28] <ubitux> otherwise it's not a problem at all
[14:37] <ubitux> BBB: 2.42 fpm [ETA 45:17:  21]
[14:37] <ubitux> (2500, 1000 just a little less)
[14:37] <ubitux> i never remember if it's 45 minutes, 45 hours or 45 days
[14:37] <ubitux> but all three are indecent
[14:38] <wm4> so who writes a fast encoder? is that planned for libavcodec or something?
[14:39] <plepere> ubitux : actually, I'm using them in a loop and it works
[14:39] <plepere> just not when they are one after another;
[14:39] <ubitux> swap is only applied once
[14:39] <ubitux> it's a pp
[14:39] <plepere> had 3 SWAPS, but changed them to movdqa
[14:40] <BBB> lol
[14:40] <BBB> plepere: right, between-iterations cannot depend on each other if you use SWAP
[14:40] <BBB> anyway
[14:40] <BBB> ubitux: sounds good, I'm starting to have some good numbers, once we have all the correct clips let's do speed measurement son a bunch of machines
[14:41] <ubitux> vp8 and x264 ones are available (1000, 2500 and 50000)
[14:41] <ubitux> as you said, i won't run a 50000 one in vp9 or we'll still be on it next year
[14:44] <BBB> well we already have a 50k vp9 one
[14:44] <cone-677> ffmpeg.git 03Diego Biurrun 07master:192ccc5034ad: build: The MPEG-4 video parser depends on h263dsp
[14:44] <ubitux> :D
[14:44] <cone-677> ffmpeg.git 03Michael Niedermayer 07master:fdba564585e5: Merge commit '192ccc5034ad4ac1b5022fc16c1162267add6a0f'
[14:44] <BBB> it's the one you encoded at 20k
[14:44] <BBB> it was just slightly off
[14:44] <BBB> oh 50k? I was thinking 40k, so it hits the 20k vp9 clip
[14:45] <BBB> I guess 50k is ok also
[14:45] <BBB> it doesn't matter much
[14:45] <ubitux> i can do 40k as well
[14:45] <ubitux> vp9 are 20x slower so...
[14:45] <BBB> if it's not too much effort
[14:45] <BBB> lol
[14:45] <BBB> I'll look at the results tonight, thanks
[14:45] <BBB> and then hopefully this weekend it's all done
[14:46] <BBB> I have most of the figures we need, we just need the vp9 vs libvpx comparisons of a few selected clips (same-quality per codec probably) on a bunch of machines
[14:46] <cone-677> ffmpeg.git 03Diego Biurrun 07master:61e7c7f27b0a: svq3: Adjust #endif comment
[14:46] <cone-677> ffmpeg.git 03Michael Niedermayer 07master:e948f17369d4: Merge commit '61e7c7f27b0a2652bf5cd282b97762ee99d025ef'
[14:46] <BBB> work now though
[14:57] <cone-677> ffmpeg.git 03Diego Biurrun 07master:ba42c852477e: bit_depth_template: Use file name as multiple inclusion guard
[14:57] <cone-677> ffmpeg.git 03Michael Niedermayer 07master:a0cfec2e2bbb: Merge commit 'ba42c852477e87f6e47a5587e8f7829c46c52032'
[15:11] <sspiff> can anyone tell me if the teletext subtitle decoder actually works?
[15:11] <ubitux> it depends on an external lib
[15:11] <ubitux> make sure you have it and linked ffmpeg against
[15:11] <sspiff> ubitux: libzvbi right?
[15:11] <Compn> yes zvbi
[15:11] <sspiff> and I can use the codec ID CODEC_ID_DVB_TELETEXT or should I use LIBZVBI_TELETEXT?
[15:11] <ubitux> sspiff: did you register codecs?
[15:11] <ubitux> does it work with other codec id?
[15:11] <sspiff> ubitux: yeah, plain DVB subtitles work
[15:11] <ubitux> is ffmpeg recognizing them?
[15:11] <sspiff> yes, I'm generating PNG's from them
[15:11] <Compn> sspiff : are you playing a stream or a file with teletext ?
[15:11] <Compn> playing/encoding whatnot
[15:11] <Compn> uploading a sample goes a long way in us reproducing any bugs...
[15:14] <sspiff> Compn: it contains this: Stream #0:14[0x157f](eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006)
[15:15] <sspiff> but it seems like configure isn't picking up zvbi
[15:15] <sspiff> so that's the problem I suppose
[15:15] <ubitux> it's not enough to say the decoder is build with
[15:15] <ubitux> ./ffmpeg -codecs|grep teletext
[15:15] <ubitux> and check if there is the D flag
[15:15] <ubitux> if not, then that's not built correctly
[15:15] <sspiff> nope, it's not there, thanks!
[15:15] <sspiff> I really should repay you guys by improving the dvb subtitle encoder!
[15:22] <cone-677> ffmpeg.git 03Diego Biurrun 07master:017a06a9ee86: x86: dsputil: Use correct file name as multiple inclusion guard
[15:22] <cone-677> ffmpeg.git 03Michael Niedermayer 07master:8372aaf7210e: Merge commit '017a06a9ee86b047079166c2694c9c655ff03356'
[15:41] <cone-229> ffmpeg.git 03Diego Biurrun 07master:984e3398662d: avcodec: Consistently name encoder init functions foo_encode_init
[15:41] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:add54280bfc1: Merge commit '984e3398662d460e15904f9e4a6df9ef759070cb'
[15:47] <cone-229> ffmpeg.git 03Diego Biurrun 07master:4bcca3611da2: mpeg4video_parser: Drop pointless av_-prefix from static function
[15:47] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:c427b2b86e72: Merge remote-tracking branch 'qatar/master'
[16:20] <ubitux> any news on bayer support?
[16:27] <Compn> ubitux : ask pross? but also someone made it into a GSOC task for some reason
[16:29] <ubitux> > This makes the helgrind error disappear.
[16:29] <ubitux> yay \o/
[16:34] <Daemon404> helgrind clean fate is onl 9 years away now
[16:42] <cone-229> ffmpeg.git 03Nicolas George 07master:299a56879d2d: ffmpeg: make reading packets from thread blocking.
[16:42] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:d089e9a4d125: Merge remote-tracking branch 'cigaes/master'
[16:58] <ubitux> Daemon404: huh?
[18:29] <wm4> michaelni: so what _is_ the reason that this lock manager stuff exists?
[18:31] <wm4> other than historic reasons (when ffmpeg didn't have any locking or atomics)
[18:39] <michaelni> iam pretty sure that was discussed on the ml at least once. but its basically, 1. difficulty to proof that all global init of codecs is thread safe, 2. av_find_stream_info() using codecs (and thus their init) 3. uncertainity of lock compatibility (in case a specific one like pthreads is used) and then theres 4. dfficulty of deallocating the lock
[18:39] <michaelni> there are many ways out but each is a compromise of some kind
[18:42] <michaelni> in that way the existing lock manager is a compromise too
[18:42] <michaelni> lock manager system
[18:53] <wm4> you don't need to deallocate the lock, and you can easily do it in a way that hides the log from valgrind to avoid the user questions
[18:53] <wm4> lock compatibility (3.) seems very questionable; even if pthread is a wrapper, it will use the operating system's mutexes
[19:59] <michaelni> wm4, please do hide it from the users valgrind log
[20:03] <michaelni> if theres anythng i can do to help, like applying a patch, iam happy to do so
[20:39] <llogan> ubitux: RE: dropbox, "The faststart option of ffmpeg does a second pass on the file that is output of ffmpeg. This is unfortunately not useful for us because we need to rearrange the moov atom *before* it gets into ffmpeg. This is because we want to avoid the latency involved in fetching the whole content from the storage system before starting transcoding."
[20:41] <Daemon404> the article wasnt that interesting
[20:41] <Daemon404> nothing surprising or novel
[20:42] <llogan> that's because it didn't have any cats in it for you
[20:42] <Daemon404> ?
[20:48] <Compn> llogan : then you write a special mov muxer that writes a fake header index 
[20:49] <Compn> thats i think, the only way to hack a mov without re-writing the index
[20:52] <wm4> how did they manage to misdesign mov that it can't be streamed?
[20:53] <wm4> even mkv got this right
[20:54] <JEEB> you can, it's just that no-one does it right
[20:54] <JEEB> no-one uses the fragments feature
[20:54] <JEEB> and even less people implement it in their demuxers
[20:55] <Compn> iirc apple only does keynotes over rtsp
[20:55] <Compn> the only other mp4 streaming is that adobehds or apple hls or silverlight or all that nonsense with 1000 mp4 files cut up into 200k chunks
[20:56] <Daemon404> hls and dash both satisfy the latter
[20:56] <JEEB> HLS is mpeg-ts
[20:56] <Daemon404> and by silverlight you mean smoothstreaming
[20:56] <Daemon404> ah yes
[20:56] <Daemon404> true
[20:56] <Compn> wm4 : i had an argument with a user in #mplayer how .avi was not made for streaming either. there were and are no live .avi streams :P
[20:57] <Compn> its just so old that the internet (and even networked computers) werent ready for streaming video
[20:57] <wm4> having the player concatenate small files for streaming sounds pretty retarded
[20:57] <wm4> even worse than mkv ordered chapters
[20:57] <wm4> maybe they should just use .ts or so...
[20:58] <wm4> not fragments of it of course
[20:58] <Compn> i actually dont mind ordered chapters, its just i havent seen a compelling argument for watching the opening and ending to each anime episode.
[20:58] <Compn> which happens to be ordered chapters' only big use case 
[21:00] <Compn> oh well complaining about old stuff again
[21:00] <Compn> hows GSoC going ?
[21:04] <llogan> no news until Feb 24: List of accepted mentoring organizations published on the Google Summer of Code 2014 site.
[21:04] <llogan> then on Feb 28 they will tell us "why" we got rejected.
[21:04] <Compn> ehe
[22:47] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:0c803eba2f56: avformat/mov: make invalid sampledelta error more verbose
[23:07] <cone-229> ffmpeg.git 03Janne Grunau 07master:982b596ea664: h264: avoid undefined behavior in chroma motion compensation
[23:07] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:4d943cec68f3: Merge commit '982b596ea6640bfe218a31f6c3fc542d9fe61c31'
[23:08] <cone-229> ffmpeg.git 03Christophe Gisquet 07master:ef010f08ae53: dca: replace some memcpy by AV_COPY128
[23:08] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:1bef9c5e83c0: Merge commit 'ef010f08ae53479c54e2f16be5a7e1a809a9e268'
[23:12] <cone-229> ffmpeg.git 03Christophe Gisquet 07master:996697e266c8: x86: float dsp: unroll SSE versions
[23:13] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:1859b1de31bd: Merge commit '996697e266c8adc0ad9b7fc7568406c7529c97cf'
[23:17] <cone-229> ffmpeg.git 03Janne Grunau 07master:9c029f67ca82: aarch64: use EXTERN_ASM consistently for exported symbols
[23:17] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:490215cbd70e: Merge commit '9c029f67ca82147ddfa83a1546ee1e109e11fbd4'
[23:21] <ubitux> should i add a valgrind + cpuflags none?
[23:26] <cone-229> ffmpeg.git 03Diego Biurrun 07master:6adf4290ebcf: configure: Move inet_aton check into network function check block
[23:26] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:36eec0321182: Merge commit '6adf4290ebcf65ac8243d74f34ba0a508f561633'
[23:37] <cone-229> ffmpeg.git 03Diego Biurrun 07master:2b0bb69997c2: configure: Move cpunop into ARCH_EXT_LIST_X86
[23:38] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:5176e9651bda: Merge commit '2b0bb69997c2416e74f41aa1400ce983bf8775c0'
[23:39] <BBB> ubitux: cool, I see the encodes are finished?
[23:39] <ubitux> BBB: not vp9
[23:39] <ubitux> in progress
[23:39] <ubitux> but yeah of course all the others are done
[23:40] <ubitux> ETA 24:15:  23
[23:40] <ubitux> you can follow on http://lucy.pkh.me/encodes/logs/etv5k-vp9-b1000.log and http://lucy.pkh.me/encodes/logs/etv5k-vp9-b2500.log
[23:41] <BBB> I see a vp9 1000, 2500, 5000
[23:41] <BBB> or is that inprogress files? :)
[23:41] <ubitux> yeah in progress
[23:41] <BBB> ah
[23:41] <BBB> sneaky
[23:41] <ubitux> 5000 is done though
[23:41] <ubitux> check the related log file
[23:41] <ubitux> you can see if it's done there
[23:42] <ubitux> BBB: http://lucy.pkh.me/encodes/ssim-summary.txt
[23:42] <ubitux> those are done
[23:43] <ubitux> i should have run a 500 for vp9...
[23:43] <ubitux> but hey, fuck the speed
[23:43] <ubitux> that's not fun anymore :(
[23:44] <Daemon404> hmm
[23:44] <Daemon404> -vf alphaextract doesnt extract alpha from pal8 png
[23:44] <Daemon404> :/
[23:45] <BBB> ubitux: i know, the encoder is slow
[23:48] <cone-229> ffmpeg.git 03Luca Barbato 07master:d6a27f885b5d: configure: Add usan to the toolchain presets
[23:48] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:9026c49c82dc: Merge commit 'd6a27f885b5d4cba7a82e50af423c741d2f37c3e'
[23:49] <Daemon404> lol... convertign to rgba, and piping to a 2nd ffmpeg works
[23:50] <michaelni> ubitux, is your gcc on your fate client new enough for usan and all that stuff ?
[23:50] <ubitux> what version do i need?
[23:51] <ubitux> seems i have 4.8.2
[23:51] <nevcairiel> usan is only 4.9 iirc, which isnt even released yet
[23:52] <ubitux> k
[00:00] --- Fri Feb 21 2014