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

[burek]

[01:58] <cone-137> ffmpeg.git 03Michael Niedermayer 07master:8f853159f6ea: avutil/opt: preserve fractions in set_string_number()
[02:24] <cone-137> ffmpeg.git 03Luca Barbato 07master:96f9fbe10933: h264: fix slice_type value reported in decode_slice_header()
[02:24] <cone-137> ffmpeg.git 03Michael Niedermayer 07master:2d93f76f8ab6: Merge commit '96f9fbe10933944b3eba86efa1d1ca094f2c28f8'
[02:32] <cone-137> ffmpeg.git 03Luca Barbato 07master:fea6db064b00: h264: informative error reporting in decode_slice_header()
[02:32] <cone-137> ffmpeg.git 03Michael Niedermayer 07master:d0e236292d24: Merge remote-tracking branch 'qatar/master'
[02:47] <cone-137> ffmpeg.git 03Ronald S. Bultje 07master:b9936e59e8e0: tiny_ssim: add per-frame metrics and final ssim db number.
[02:50] <BBB> nevcairiel: I see the smaller vp9 files are still encoding? :-p
[06:50] <anshul> guys I was adding av_cleanup_on_lib_unload() in ffmpeg, which file would we most suitable for this purpose
[09:59] <ubitux> nevcairiel: encoder and decoders should be able to do whatever they want to! :D
[10:15] <nevcairiel> ubitux: its a lost cause, i should just submit revert commits to ffmpeg instead of trying to argue over there
[10:31] <nevcairiel> also, all my encodes are done now, will try to create the SSIM values later today
[10:31] <JEEB> need a win32 binary of the dump_ssim tool?
[10:31] <JEEB> I built one a few months ago
[10:31] <nevcairiel> nah, using tiny_ssim
[10:31] <JEEB> k
[10:31] <nevcairiel> BBB patched it to produce the values we want
[10:32] <ubitux> 5k and 10k are done for me
[10:32] <ubitux> 20k should be done in a few hours
[10:32] <nevcairiel> i added 500 750 1k and 2.5k
[10:32] <nevcairiel> the high bitrates were boring
[10:32] <ubitux> ah, should i add them as well?
[10:33] <nevcairiel> dunno
[10:33] <nevcairiel> my source was rather clean so that the high bitrates didnt change much
[10:33] <ubitux> you're using these bitrate with 1080p?
[10:33] <nevcairiel> yeah
[10:33] <nevcairiel> 1mbit looks surprisingly well
[10:33] <nevcairiel> but yeah, extremely clean source material
[10:35] <nevcairiel> anyway everything up here now http://files.1f0.de/encodes/ .. in case someone wants to see a scene from ToS in 500kbit :p
[10:43] <JEEB> that makes me notice that my copy of mpv has a bugged vp9 decoder
[10:43] <JEEB> non-intra pictures get whoopsie-daisie'd
[10:43] <nevcairiel> does it use libav? :P
[10:43] <JEEB> nope
[10:58] <aca> ubitux: I got 'make check' working by exporting LD_LIBRARY_PATH to the local build directories. Now I wonder, how this works for everyone else. Do you run 'make install' first?
[10:59] <ubitux> i never make install, except when doing random configure/build tests
[10:59] <ubitux> i'm just running make check (actually make fate) from the build dir
[10:59] <aca> ubitux: strange...
[10:59] <ubitux> but i'm not building with --enable-shared
[10:59] <ubitux> so& ;)
[11:00] <aca> ubitux: That may be the cause.
[11:00] <ubitux> i have a shared fate instance, let me check how i do that&
[11:01] <ubitux> extra_ldflags="-Wl,-rpath=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample"
[11:01] <ubitux> heh.
[11:01] <aca> ubitux: Ah!
[11:01] <ubitux> i think there is an option for this nowadays
[11:01] <ubitux> --enable-rpath probably
[11:02] <aca> ubitux: Would it not be simpler to export LD_LIBRARY_PATH in fate-run.sh (my current workaround)?
[11:02] <ubitux> well, you may want to run ffmpeg without fate
[11:02] <ubitux> :p
[11:02] <ubitux> so there is no point in having that env variable at fate level
[11:03] <aca> ubitux: I mean just for the tests.
[11:03] <ubitux> well, just do LD_LIBRARY_PATH=... make fate then
[11:04] <ubitux> it would be evil to set it in fate-run.sh
[11:04] <ubitux> anyway, rpath is probably going to cause issues for packaging
[11:06] <aca> ubitux: I will try adding 'export LD_LIBRARY_PATH=...; ' to the Makefile now.
[11:07] <ubitux> why export? won't do as a command prefix?
[11:08] <aca> ubitux: That's probably better.
[11:38] <aca> ubitux: It doesn't work without export, at least not for ffprobe-test.nut.
[12:49] <ubitux> huh, libav is re-implementing the replaygain filter?
[12:50] <wm4> there's a replaygain filter?
[12:50] <JEEB> yes
[12:50] <JEEB> but as far as I see it, they're just talking about how to handle the side data
[12:50] <JEEB> it could mean that elenril was reimplementing that filter, but I have NFI
[12:51] <wm4> isn't that filter about generating replaygain data?
[12:51] <wm4> instead of applying it
[12:51] <JEEB> yup
[12:53] <ubitux> adding side data... from the filter side? wut?
[12:53] <wm4> no, reading it from the demuxer
[12:54] <ubitux> aah
[12:54] <ubitux> oh well, then in volume filter
[12:54] <ubitux> and read metadata from there
[12:56] <BBB> ubitux: we'll see how the high ones look; if you look at my graphs, you can sort of see the range of ssim values (in dB) we're interested in, and if you go way beyond that, we should lower your rates a little also
[12:57] <BBB> ubitux: the good thing is that lower bitrates tend to encode faster
[12:57] <BBB> and yes tiny_ssim is ok now, and much easier to build than dump_ssim, so let's stick to tiny_ssim
[12:58] <JEEB> nice
[12:58] <BBB> I figured patching tiny_ssi would be faster than building dump_ssim
[12:59] <BBB> plus dump_ssi itself ended up being terirbly, terribly slow
[13:06] <JEEB> yeah, it's not exactly fast if I recall correctly
[14:00] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:36fb07d1abc7: avcodec/mpeg4videodec: set field durations to safe values when they are invalid
[14:07] <cone-632> ffmpeg.git 03Martin Storsjö 07master:543156d7518f: arm: Mark the stack as non-executable
[14:07] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:53d11f7b2d38: Merge commit '543156d7518f5e5d731123da066d86278f9fa492'
[14:13] <ubitux> http://gcc.godbolt.org/ fun, probably old
[14:15] <wm4> ubitux: what should I name the avoption for microdvd, and what should it do?
[14:15] <ubitux> keep the same name as aqtitle
[14:16] <ubitux> "subfps"
[14:16] <wm4> and how does this solve the problem at hand?
[14:17] <ubitux> if it's set in the file and not by the user, you override the value
[14:17] <ubitux> you set a default one of 0/1 or something
[14:17] <ubitux> or 0/0
[14:20] <wm4> what if the user wants to override it, but only if the format is frame based?
[14:31] <cone-632> ffmpeg.git 03Martin Storsjö 07master:1e142d5b4842: movenc: Add a fallback fragmentation method for plain mp4 as well
[14:31] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:ef1aae6ea9aa: Merge commit '1e142d5b4842dcb39fcb0e92e4aacbc9977bfa66'
[14:31] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:3f461566b707: avformat/movenc: simplify code, decrease difference to libav
[14:32] <nevcairiel> BBB: does the order of inputs matter to tiny_ssim? i used tiny_ssim original.yuv decoded.yuv now without thinking about it until now :p
[14:43] <BBB> nevcairiel: no, shouldn't
[14:44] <cone-632> ffmpeg.git 03Diego Biurrun 07master:294a51e18ab7: gitignore: Add all examples below doc/examples
[14:44] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:d808dce4a98f: Merge commit '294a51e18ab7df4d658249361a03f0d716a4e9f0'
[14:44] <nevcairiel> BBB: well then, all my encodes and ssim info is up here now: http://files.1f0.de/encodes/
[14:46] <BBB> can you tail the last line of each .ssim file in a ssim.summary?
[14:46] <BBB> for now we only need the total line
[14:46] <nevcairiel> sure
[14:46] <BBB> like grep ^Total *.ssim > ssim.summary
[14:46] <ubitux> nevcairiel: you didn't keep the log?
[14:46] <BBB> (I hope that includes the filename, else it sucks)
[14:46] <nevcairiel> ubitux: i have the logs locally, they cluttered up the web folder :p
[14:47] <ubitux> :)
[14:47] <ubitux> oh, 20k done \o/
[14:47] <BBB> how many cores do you guys have?
[14:48] <ubitux> 4HT
[14:48] <nevcairiel> 4+4
[14:48] <BBB> I really only have 2 so any sort of mt comparison stops at 2 :-p
[14:48] <BBB> 4ht = 4+ht, or 2x2ht?
[14:48] <BBB> (I have 2x2ht)
[14:48] <BBB> maybe you guys should do the mt comparisons then
[14:48] <BBB> I get good numbers from 1 to 2
[14:49] <BBB> but from 2 to 4 it sort of crumbles
[14:49] <nevcairiel> the tiny_ssim tool is weird
[14:49] <nevcairiel> it produced files with \r line endings
[14:50] <nevcairiel> not \n .. not \n\r
[14:50] <BBB> sed -e 's|\r|\n|g' :-p
[14:50] <BBB> and yes I use \r, it's shelly
[14:50] <smarter> tr '\r' '\n' :]
[14:50] <nevcairiel> tail didnt like those files
[14:50] <nevcairiel> :P
[14:51] <j-b> good morning
[14:51] <BBB> nevcairiel: for file in *.ssim; do sed -e 's|\r|\n|g' $file | grep ^Total; done > ssim.summary
[14:51] <smarter> what are you doing all these encodes for? Decoding performance benchmarks?
[14:51] <BBB> smarter: basically same-quality decoder performance benchmarks
[14:51] <BBB> smarter: but it also shows you ow the encoders compare (ignoring encoder performance, obviously)
[14:51] <smarter> same quality between what and what?
[14:52] <BBB> e.g. same quality vp9 and h264; which decodes faster?
[14:52] <smarter> oh I see, nice
[14:52] <ubitux> so isatty doesn't work well for the \n \r thing?
[14:52] <smarter> I might be interested in putting the resulting encodes on http://exp.martres.me/splitview/ :)
[14:52] <BBB> some google exec came out saying vp9 wouldn't be more than 50% more complex than vp8; so is that true? for same-filesize, or same-quality?
[14:53] <BBB> (oh it was 40%, not 50%)
[14:53] <BBB> smarter: yeah, I want to do that actually
[14:53] <BBB> smarter: but not there yet... lots of work to do
[14:53] <smarter> okay, cool
[14:54] <BBB> work
[14:54] <BBB> bbl
[14:54] <nevcairiel> BBB: summary file up now
[14:55] <nevcairiel> hm i should sort it, file system sort doesnt do well with numbers
[14:58] <nevcairiel> in quality per bitrate vp9 seems to beat x264 at least ...igorning that it took like 20x the time to encode though
[15:06] <ubitux> eval $(ffprobe -v 0 -of flat=s=_ -select_streams v:0 -show_entries stream=height,width $1)
[15:06] <ubitux> size=${streams_stream_0_width}x${streams_stream_0_height}
[15:06] <ubitux> i love ffprobe e
[15:09] <smarter> what settings are you using for your encodes?
[15:17] <ubitux> BBB: weren't you supposed to isatty(1) instead of isatty(0) && isatty(2)?
[15:19] <ubitux> you're only interested in stdout piping
[15:20] <ubitux> it fixes the issue nevcairiel was talking about
[15:20] <nevcairiel> the \r ? :p
[15:20] <nevcairiel> i was redirecting to a file when that happened, in case it matters
[15:20] <ubitux> yes
[15:20] <ubitux> it happens all the time
[15:20] <ubitux> the isatty check can't work
[15:21] <ubitux> nevcairiel: http://pastie.org/8748691
[15:21] <ubitux> try this
[15:21] <nevcairiel> lazy, files are done now :(
[15:21] <ubitux> then "tiny_ssim ..." vs "timy_ssim ... | cat" will work as you expect
[15:26] <ubitux> http://ubitux.fr/pub/pics/_ssim-art.png
[15:27] <ubitux> http://lucy.pkh.me/encodes/
[15:27] <ubitux> smarter: see encode.sh
[15:27] <ubitux> 'will print the encode commands
[15:28] <ubitux> ’ http://pastie.org/pastes/8748711/text
[15:28] <smarter> thanks!
[15:29] <smarter> I'm not sure if I would recommend --aq-mode=1
[15:29] <nevcairiel> not re-doing the vp9 encodes now!
[15:29] <ubitux> :D
[15:30] <ubitux> i blindly listened to BBB :)
[15:30] <ubitux> btw, ssim script: http://lucy.pkh.me/encodes/ssim.sh
[15:30] <smarter> it probably does not have a big impact, though it'd be interesting to do one encode without it at least
[15:30] <ubitux> (based on BBB script)
[15:31] <smarter> you should put all that stuff on a git repo somewhere for reproducibility :)
[15:32] <ubitux> i actually don't want to share the samples for a long time :p
[15:33] <smarter> for bandwidth reasons?
[15:33] <ubitux> legal
[15:33] <nevcairiel> he is afraid because his sample is a  movie clip
[15:33] <nevcairiel> while BBB used sintel and i used ToS
[15:34] <smarter> oh yeah, not a great idea :p
[15:34] <ubitux> it's a relatively long, HD, and from recent source
[15:34] <ubitux> so... welll :)
[15:34] <nevcairiel> 3 minutes should be well into fair use, but shrug
[15:34] <smarter> I haven't looked very much but I suspect there's some creative commons stuff that could be used for that
[15:35] <ubitux> of course
[15:35] <ubitux> but i like that sample :D
[15:35] <nevcairiel> which movie is that anyway
[15:36] <ubitux> http://www.imdb.com/title/tt1191111/
[15:38] <ubitux> smarter: is splitview supposed to work with firefox?
[15:39] <smarter> ubitux: you need firefox >= 28
[15:39] <smarter> the beta
[15:39] <smarter> for VP9 support
[15:39] <smarter> also H.264 support in your OS
[15:39] <ubitux> obviously... ok
[15:40] <smarter> I'll try to make it usable on browsers without VP9 or H.264 soon
[15:40] <ubitux> by integrating a jsffmpeg?
[15:40] <smarter> (so that you can use it with your own URLs/files at least)
[15:40] <smarter> hah no :p
[15:40] <ubitux> :(
[15:40] <smarter> just display something by default instead of exploding
[15:40] <ubitux> did mozilla nih a vp9 decoder btw?
[15:41] <smarter> they use libvpx
[15:41] <ubitux> ok
[15:41] <smarter> 1.3.0
[15:41] <mateo`> smarter: through gst ?
[15:42] <smarter> I think so
[15:42] <smarter> I think rillian on #vp8 did the integration
[15:53] <ubitux> > Also, recent versions of ffmpeg (we use 2.0) come with a segmenter tool, but we found it introduces significant latency to our pipeline.
[15:53] <ubitux> :(
[15:53] <ubitux> and they didn't use -movflags +faststart :(
[15:53] Action: ubitux is sad
[15:53] <ubitux> (https://tech.dropbox.com/2014/02/video-processing-at-dropbox/)
[15:54] <nevcairiel> never used segmenter with mov
[15:56] <ubitux> BBB: ssim results available
[15:56] <ubitux> (http://lucy.pkh.me/encodes/)
[15:56] <nevcairiel> lacks a summary file!
[15:56] <nevcairiel> (http://files.1f0.de/encodes/ssim.summary)
[15:57] <ubitux> heh
[16:03] <ubitux> nevcairiel: for f in *.ssim; do printf "%-18s %s\\n" $(echo $f|sed 's/\..*//'): "$(tail -n1 $f)"; done > ssim-summary.txt
[16:03] <ubitux> here you go.
[16:03] <ubitux> http://lucy.pkh.me/encodes/ssim-summary.txt
[16:03] <nevcairiel> \o/
[16:03] <nevcairiel> vp9 did a rather good job at this grainy video
[16:04] <nevcairiel> it took ages, but still
[16:04] <ubitux> well, it could given the time it had
[16:08] <ubitux> btw
[16:09] <ubitux> should we make hevc encodes?
[16:09] <ubitux> because i'm pretty sure the single first comment will be about that
[16:10] <ubitux> that would be a good opportunity to make a slowpoke race between libx265 and libvpx
[16:10] <nevcairiel> heh
[16:10] <nevcairiel> i was th inking about that
[16:11] <ubitux> though our hevc decoder is not optimized yet, so it won't be relevant for the main thing we're trying to show; aka decoder speed
[16:11] <smarter> it'be a good way to benchmark it :)
[16:11] <nevcairiel> it lacks a 2-pass mode though, and 1-pass cbr is kinda unfair crap mode
[16:12] <smarter> still no 2 pass?
[16:15] <nevcairiel> no
[16:15] <cone-632> ffmpeg.git 03Diego Biurrun 07master:b23bc95920e2: x86: dca: Add missing multiple inclusion guards
[16:15] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:130c33af35c5: Merge commit 'b23bc95920e2f10b9621857e829c45b064f356c0'
[16:16] <nevcairiel> constant qp, average bitrate or crf so far
[16:52] <plepere> ubitux, I'm working on the HEVC ASM right now. we did quite a bit of changes so I had to start from scratch
[16:53] <plepere> but hopefully I'll be able to do a diff at the end of the month and be able to submit the code for review
[16:53] <smarter> yay
[17:03] <cone-632> ffmpeg.git 03Vittorio Giovara 07master:35b05c5184fb: vf_interlace: deprecate lowpass option
[17:03] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:b14517d3cd37: Merge remote-tracking branch 'qatar/master'
[17:29] <cone-632> ffmpeg.git 03Carl Eugen Hoyos 07master:9c070ae03e15: Fix dctdnoiz dependencies, the filter should select dct, not fft.
[17:29] <cone-632> ffmpeg.git 03Carl Eugen Hoyos 07release/2.1:ac38860ec959: Add decoder dependency to the HEVC parser.
[18:53] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:2969fb43939e: avformat/utils: av_guess_frame_rate() favor avg_frame_rate if r_frame_rate has a comparably unlikely value
[18:53] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:3734c3ea51ae: ffmpeg: reduce frame rate for mpeg4 to be within the spec limits
[19:39] <j-b> BBB: is chrome using ffvp9 or libvpx for vp9 decoding?
[19:56] <cone-632> ffmpeg.git 03Carl Eugen Hoyos 07master:a88dee8eea19: Add decklink_enc.h to SKIPHEADERS.
[20:28] <llogan> JEEB: see anything retarded in EncodingForStreamingSites? i see you've been helping out users in that area lately.
[21:53] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:4332b01c30a4: avcodec/huffyuv: simplify allocation of temporaries
[21:58] <cone-632> ffmpeg.git 03Diego Biurrun 07master:874c751cc5b9: threads: Check w32threads dependencies at the configure stage
[21:58] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:0a30ad347357: Merge commit '874c751cc5b99cd68932e21c2c3a0d21134207e0'
[22:07] <cone-632> ffmpeg.git 03Luca Barbato 07master:a7b3216cbdc7: doc: Sort the muxer documentation
[22:07] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:ca5b45b9b3cb: Merge commit 'a7b3216cbdc7796a9d14cd22a863fae3556098ba'
[22:09] <cone-632> ffmpeg.git 03Luca Barbato 07master:93632a70f9ac: doc: Name the MOV muxer as it should be called
[22:10] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:4ba03e37fd16: Merge commit '93632a70f9ac2cb2ebf0e69d21fdfaae68ff02fd'
[22:52] <BtbN> How do i tell the configure script to link libavcodec against libdl if my encoder is enabled?
[22:52] <BtbN> i tried nvenc_encoder_extralibs="$ldl" but it doesn't work
[22:53] <BtbN> oh, of course. Because the ldl variable is generated AFTER the encoder lines
[22:53] <BtbN> or is that variable evaluated later on?
[23:01] <cone-632> ffmpeg.git 03Luca Barbato 07master:521726ff577c: hevc: Always consider VLC NALU type mismatch fatal
[23:01] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:ca9f7e183278: Merge remote-tracking branch 'qatar/master'
[00:00] --- Thu Feb 20 2014