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

[burek]

[01:30] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:91253839e14c: avcodec/h264: more completely check the loop filter parameters
[02:41] <cone-926> ffmpeg.git 03Diego Biurrun 07master:b339182eba34: Move all example programs to doc/examples
[02:41] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:1fc74926a5d1: Merge commit 'b339182eba34f28de5f1a477cdd2c84f1ef35d90'
[03:11] <cone-926> ffmpeg.git 03Diego Biurrun 07master:f53e274f4cd2: doc: Fix project name typo
[03:11] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:c97c7c2adf40: Merge remote-tracking branch 'qatar/master'
[03:39] <cone-926> ffmpeg.git 03Lukasz Marek 07master:d3cf9b24cf80: lavd/opengl_enc_shaders: fix gray* shader
[03:39] <cone-926> ffmpeg.git 03Lukasz Marek 07master:81c3f81d6f11: lavd: add list devices API
[03:39] <cone-926> ffmpeg.git 03Peter Ross 07master:a707d18a4889: avcodec/vp8dsp: zeroise input coefficient array after use in vp7 idct functions
[03:39] <cone-926> ffmpeg.git 03Nicholas Robbins 07master:b02b78341799: MAINTAINERS: add myself as vf_dejudder.c maintainer
[03:39] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:38a08e0aea02: Merge remote-tracking branch 'lukaszmluki/master'
[07:21] <llogan> ...could use some additional work.
[07:24] <llogan> since i've never really used such sites, have little experience with VBV, and haven't tested my examples.
[13:23] <BBB> ubitux: any more comments on these 2 patches?
[13:23] <ubitux> no more than what i said first
[13:23] <ubitux> do you want a merge?
[13:23] <BBB> if possible
[13:23] <BBB> blogpost-time!
[13:23] <ubitux> should be possible
[13:23] <ubitux> heh :)
[13:24] <BBB> (also we're still missing prefetch but I guess we can live with that)
[13:24] <BBB> we're ~50% faster than libvpx on ped, ~60% on etv5k on my machine
[13:24] <thardin> nice
[13:24] <BBB> and vp9 is 47% slower than vp8 on my machine, which isn't too bad
[13:25] <BBB> vp9 and h264 have about the same complexity (vp9 is 4% slower for me)
[13:25] <BBB> and with mt we beat the crap out of libvpx in all settings, beating it as much as 2.5x at 4 threads
[13:25] <ubitux> BBB: your vp9-simd branch is up-to-date?
[13:25] <BBB> I think so
[13:25] <BBB> what's the hashes?
[13:26] <BBB> yes it's uptodate
[13:26] <ubitux> fce764b25c8bb19c047002fc4f1432e8035a8039 ff4a00dd0f40a0e8d0d0683cc5bf80b3040e962b
[13:26] <ubitux> ok
[13:27] <ubitux> BBB: you sure about intra pred commit message?
[13:27] <BBB> uhm
[13:27] <ubitux> it looks like you were going to add information to it
[13:27] <BBB> that's about vp9ipred vs. h264intrapred
[13:27] <BBB> it's kinda terse I guess
[13:27] <BBB> feel free to remove it
[13:28] <BBB> except the partially based on
[13:28] <ubitux> it's just that "will measure that separately"
[13:28] <ubitux> it sounds like you were going to add benchmarks or something
[13:28] <BBB> that's vp9ipred vs h264intrapred, yes I want to measure that but probably not for now
[13:28] <BBB> so I guess I'll remove it
[13:28] <ubitux> tell me when it's reworded :p
[13:29] <BBB> fixed
[13:29] <BBB> eabbdeabe7f0c58a50c248786daf7fe9e100883d and c8227b24b504e6fecfe3af03ce97950f833b9102
[13:32] <ubitux> BBB: ah, you sure about the portability of empty macro arg?
[13:33] <BBB> ubitux: I think I've used it before, I think it's fine yes
[13:34] <BBB> ubitux: if not we can fix it easily (s/32/b32/ and s//b/)
[13:34] <ubitux> indeed i see it in vp8
[13:34] <ubitux> ok
[13:36] <BBB> do we have some poor windows user who can do some windows metrics for us?
[13:37] <BBB> also did you have avx or did you use obe2 for that, ubitux ?
[13:37] <ubitux> i have an avx laptop
[13:37] <ubitux> avx2 "soon"
[13:38] <BBB> ah good, no we just need something for metrics that has avx
[13:39] <cone-221> ffmpeg.git 03Ronald S. Bultje 07master:fdb093c4e43c: vp9/x86: intra prediction SIMD.
[13:39] <cone-221> ffmpeg.git 03Ronald S. Bultje 07master:21a0451167bb: vp9: split decode_coeff_b loop inside txsz branch.
[13:39] <BBB> do you have a h264 and vp8 encode at the same bitrate (or more fun: at the same ssim) of etv5k? that might be fun for cross-codec performance metrics at same quality (rather than at same bitrate)
[13:40] <ubitux> no but i can do some encode
[13:40] <ubitux> just give me the cmd line :p
[13:43] <BBB> ok let me do some minimal tests on latest libvpx
[13:43] <BBB> I think their new defaults are actually sane now, just need to verify
[13:44] <ubitux> i can redo a vp9 encode with these defaults if needed
[13:44] <ubitux> an even higher quality
[13:45] <ubitux> also, i can maybe do etv7k or etv10k
[13:45] <ubitux> but we'll probably have to wait a few days :D
[13:57] <BBB> 5k or even 2k is good enough
[13:57] <BBB> it's just for numbers, it's not actually for watching :-p
[13:57] <ubitux> :)
[13:58] <BBB> is that clip 'free'? as in, will people get upset if we redistribute a 2k clip of it?
[13:58] <ubitux> it's not at all free
[13:58] <ubitux> it's from a movie
[13:58] <ubitux> from 2009
[13:58] <BBB> hm...
[13:59] <BBB> ohwell let's just hope people don't get upset
[13:59] <ubitux> ahah
[13:59] <ubitux> i did an encode because it has a lot of interesting motion, noise, and color weirdness
[13:59] <ubitux> as well as funny stuff for prediction, like random blinks
[14:00] <BBB> yeah I prefer "real" videos over standardized ones (I don't quite like using pedestrian, but I don't have anything else to encode :-p)
[14:00] <BBB> and it does the job so I guess it's ok
[14:01] <ubitux> i can do an encode of something else, it doesn't really matter
[14:02] <BBB> nah etv is ok
[14:03] <BBB> what shall I encode then? shall I stick to pedestrian? it's nice and short
[14:04] <ubitux> :D
[14:04] <ubitux> oups
[14:04] <ubitux> yeah sure
[14:04] <nevcairiel> do what everyone does and encode big buck bunny or tears of steel? :p
[14:05] <ubitux> it's special video, animation
[14:05] <ubitux> let's change that for once maybe
[14:05] <nevcairiel> tears of steel is live-action
[14:06] <ubitux> ah this, i remember
[14:06] <ubitux> it sucks :(
[14:08] <BBB> what is tears of steel
[14:08] <nevcairiel> blender foundation project, so free
[14:10] <nevcairiel> http://mango.blender.org/download/
[14:10] <BBB> yeah I don't have 66gigs of space for that
[14:11] <ubitux> i do
[14:11] <nevcairiel> the DCP is only 14gigs :p
[14:12] <BBB> what is dcp?
[14:12] <nevcairiel> digital cinema package
[14:12] <ubitux> nevcairiel: http://media.xiph.org/tearsofsteel/tearsofsteel-4k.y4m.xz this is 66G
[14:12] <nevcairiel> oh yeah
[14:12] <BBB> so what is dcp?
[14:12] <ubitux> i'm gonna make an encode
[14:12] <BBB> ubitux: 2k is enough, don't do a 13k encode :-p
[14:12] <nevcairiel> wonder how big the 1080p pngs are compared to the 4k
[14:12] <BBB> also what bitrates to use?
[14:13] <BBB> 17620 ... omg
[14:13] <BBB> yeah I can't encode that, I have a small macbookpro
[14:13] <nevcairiel> if you need something shourter, you know, just stop after half!
[14:13] <nevcairiel> shorter*
[14:14] <BBB> I don't have diskspace to save it
[14:14] <BBB> I have 4gb free diskspace
[14:14] <BBB> buy me a new macbookpro? :)
[14:14] <BBB> or maybe I should buy my own
[14:14] <nevcairiel> i have plenty space and cpu, if you tell me what to do, i can do that
[14:16] <kurosu__> BBB: add inter-coding to ffv1, store this on a lot less space, that's a win-win situation! or maybe use vp9 lossless, and benchmark it at the same time!
[14:17] <ubitux> BBB: i have some storage here
[14:17] <ubitux> BBB: i can really do various encode
[14:17] <BBB> encode at various bitrates for vp8, vp9 and h264 (like bitrate=2000,4000,8000 or so) using latest libvpx "vpxenc [target bitrate] input.y4m -o output_vp9_$bitrate.webm --target-bitrate=$bitrate --aq-mode=1 --tune=ssim --cpu-used=0", latest x264 "x264 --pass 1/2 -o output_x264_$bitrate.mkv --preset veryslow input.y4m --tune=ssim" and vp8 same settings as vp9 but without --aqmode=1
[14:17] <ubitux> but... libvpx speed.
[14:18] <nevcairiel> I'm sure there are things that they could've used to store it in  much less space then uncompressed y4m files kurosu__ :P
[14:18] <BBB> oh and use --limit=1000 or --limit=2000 for vpxenc
[14:18] <BBB> so it stops after 1k or 2k frames, that's all we need
[14:18] <BBB> maybe start in the middle also
[14:18] <ubitux> ok
[14:18] <kurosu__> those weren't serious suggestions, more of a jest actually
[14:18] <BBB> like, make sure the scene we encode contains something useful, not just silly blends or letters
[14:18] <ubitux> yep
[14:19] <BBB> and check with skyler to ensure he's ok with these settings above
[14:19] <nevcairiel> i dont suppose vpxenc takes a series of pngs
[14:19] Action: ubitux invoke Skyler_ 
[14:19] <nevcairiel> can use ffmpeg wrapper? :p
[14:19] <ubitux> nevcairiel: y4m is fine for libvpx
[14:19] <BBB> we'll use ssim to select a bitrate-for-same-quality so we can do decoder speed comparisons of same-quality (in ssim)
[14:19] <BBB> and then same-bitrate decoder speed comparisons also
[14:20] <nevcairiel> ubitux: so really use the 4k y4m file? :d
[14:20] <BBB> and then perhaps also additional vp9 encodes (just at one bitrate, e.g. only at 4000) using --tile-rows=1 --tile-cols=2, --frame-parallel=1, and --tile-rows=0 --tile-cols=2 --frame-parallel=1 (don't ask)
[14:21] <BBB> nevcairiel: please downsample to 1080p
[14:21] <BBB> 4k is too much
[14:21] <ubitux> Saving to: tearsofsteel-4k.y4m.xz
[14:21] <BBB> libvpx will never finish
[14:21] <ubitux> :X
[14:21] <ubitux> 10% [===>                                  ] 7,595,970,096 12.2MB/s  eta 71m 27s
[14:21] <BBB> ffmpeg can downscale to 1080p right?
[14:21] <ubitux> yes
[14:21] <ubitux> i suppose :)
[14:21] <nevcairiel> thats why i wanted to use the already downsampled pngs
[14:21] <ubitux> i will make a 1080p y4m sample from that
[14:21] <ubitux> with the scene we want
[14:22] <BBB> cool ty
[14:23] <BBB> I forgot --bitrate $bitrate in the x264 command
[14:23] <BBB> please don't forget that :-p
[14:23] <nevcairiel> if you need some extra cpu to encode something, just share the y4m and which encodes to create, i have a avx2 i7 doing mostly nothing
[14:23] <BBB> we probably also need --keyint 125 for x264
[14:23] <BBB> a
[14:23] <BBB> and --kf-max-dis=125 for vpxenc
[14:24] <ubitux> so, what scene should we take?
[14:24] <BBB> otherwise it can't seek which kind of sucks
[14:24] <BBB> scene selection is up to someone with an artistic mind, just not something that has black frames with only letters on it
[14:24] <BBB> anything else is fine
[14:24] <BBB> like etv; select something you like
[14:24] <ubitux> i don't like this video :D
[14:24] <BBB> feel free to do etv ;) then nevcariel can do this one
[14:24] <BBB> (and select options)
[14:25] <ubitux> ah!
[14:25] <BBB> for vp8 we did two clips; we can do that here too
[14:25] <ubitux> ok
[14:28] <ubitux> should i use libvpx/master and x264/master?
[14:28] <ubitux> (for encode)
[14:29] <nevcairiel> I will use the respective masters as of today anyway
[14:30] <nevcairiel> v1.3.0-1288-gcca8a54 for vpx
[14:30] <ubitux> 8-bit encode for h264 or 10?
[14:30] <nevcairiel> 8 seems fairer in comparisons with other 8-bit formats, but what do I know
[14:36] <ubitux> BBB: not 2 pass for vpx?
[14:36] <nevcairiel> so 2000 frame or something is enough?
[14:38] <BBB> yes
[14:38] <BBB> ubitux: 2pass is default now if I understand the changelog
[14:38] <BBB> (assuming you use current git head)
[14:39] <BBB> I'd do a 8bit encode for h264, since that's what youtube would use
[14:39] <BBB> I know 10bit would look better but youtube wouldn't ship it so it's a little academic
[14:39] <ubitux> ok
[14:41] <ubitux>     Option --tune=ssim is not currently supported in VP9.
[14:41] <BBB> make sure you log the commandline used to encode the clips so we can publish that also
[14:41] <BBB> oh, ok, then remove that
[14:41] <BBB> lol
[14:41] <ubitux> in vp8/x264 as well too then?
[14:41] <nevcairiel> now the important question, does ffmpeg support seeking in y4m? :D
[14:41] <BBB> probably not
[14:42] <BBB> :-p
[14:43] <nevcairiel> it indeed does not seem to support it :p
[14:43] <BBB> I also realized etv5k takes >1min to decode (close to 2min with libvpx)
[14:43] <BBB> and I was like, omg that is so long
[14:44] <cone-221> ffmpeg.git 03Michael Niedermayer 07master:341639fe8016: doc/examples: remove pathes from doxy examples
[14:44] <cone-221> ffmpeg.git 03James Almer 07master:07b4b0ca62a1: tta/x86: add ff_ttafilter_process_dec_{ssse3, sse4}
[14:44] <ubitux> try encoding it...
[14:44] <ubitux> i've tried a dummy 5 frame encode one minute ago
[14:44] <ubitux> it just ended now
[14:44] <BBB> lol
[14:44] <nevcairiel> lol
[14:45] <ubitux> BBB: is it relevant to add --psnr for the debug log?
[14:49] <BBB> sure why not
[14:50] <kierank> michaelni: I'm not sure if this guy is right or not: https://trac.ffmpeg.org/ticket/3345#comment:3
[14:52] <av500> the customer is always right
[14:52] <ubitux> BBB: so, http://pastie.org/pastes/8742094/text is that ok with you?
[14:52] <ubitux> (without the --limit ofc)
[14:52] <BBB> ubitux: do --tune=ssim for the vp8 encodes
[14:52] <ubitux> ok
[14:53] <ubitux> (why?)
[14:53] <BBB> also the 2/4/8k targets were totally random, I don't know what you used for the original etv encode you did
[14:53] <BBB> because we'll add basic ssim metrics to do same-quality-decoder-speed comparisons
[14:53] <BBB> so it's only fair if we use ssim for that, then we used --tune=ssim for the vp8 encode
[14:53] <BBB> also use --tune=ssim for the x264 encode
[14:54] <ubitux> BBB: original is  bitrate: 18943 kb/s
[14:54] <BBB> omg 20000?
[14:54] <ubitux> it seems
[14:54] <BBB> how big is the file?
[14:54] <BBB> (in mb)
[14:54] <ubitux> at least that's what ffmpeg says...
[14:55] <ubitux> BBB: 471M for the 5k frames (stream copy from orig)
[14:56] <BBB> yeah 18.84mbps
[14:56] <ubitux> whole movie seems to be at ~15000
[14:56] <BBB> holy crap that's a lot
[14:56] <BBB> ok
[14:56] <ubitux> so, 17G for ~2:40
[14:57] <BBB> so --target-bitrate=5000,10000,15000 then I guess?
[14:58] <ubitux> ok :)
[14:58] <BBB> maybe 5000,10000,20000
[14:58] <BBB> use you gut feeling :-p
[14:59] <ubitux> so, this: http://pastie.org/pastes/8742119/text
[14:59] <ubitux> + logging
[14:59] <ubitux> Skyler_: does those x264 look ok to you?
[14:59] <ubitux> +settings
[14:59] <BBB> --tune=ssim for x264
[14:59] <nevcairiel> vpx does 2-pass internally i guess
[15:00] <ubitux> BBB: are you sure you want to tune for ssim for h264 & vp8 but not vp9?
[15:02] <BBB> well vp9 uses --aq-mode=1
[15:02] <BBB> that's sort of ssim optimization
[15:02] <BBB> it's the best we can do
[15:02] <ubitux> ok
[15:03] <ubitux> for logging, should i just keep stderr?
[15:03] <BBB> sure
[15:03] <BBB> I'd actually keep both
[15:03] <BBB> I don't know if --psnr logs to stdout or stderr
[15:03] <ubitux> "Pass 1/1 frame    5/5     426312B  682099b/f 16370380b/s 3397084 us (1.47 fps)" :/
[15:03] <ubitux> mmh for vp8, 2pass?
[15:05] <kierank> BBB: keyframes don't match
[15:05] <BBB> ugh
[15:05] <BBB> yeah you're right
[15:05] <BBB> --max-kf-dist=125
[15:05] <BBB> and --keyint 125 for x264
[15:05] <BBB> so vp8 does 1pass by default? that kinda of sucsk
[15:06] <BBB> so vp8 default still suck
[15:06] <BBB> only vp9 defaults are good
[15:06] <BBB> blegh
[15:06] <BBB> let me see what the webm guide recommends
[15:06] <ubitux> :D
[15:06] <nevcairiel> luckily i'm still creating the uncompressed source file :d
[15:07] <BBB> lol
[15:07] <BBB> this takes some trial and error
[15:07] <BBB> http://www.webmproject.org/docs/encoder-parameters/ part 10
[15:07] <BBB> look at 2-Pass Best Quality VBR Encoding
[15:07] <nevcairiel> how do i limit frame count with ffmpeg? i barely use the damn CLI ever :p
[15:07] <BBB> use vpxenc, not ffmpeg
[15:07] <BBB> and x264, not ffmpeg
[15:07] <BBB> if you want to use ffmpeg for input, use pipes
[15:07] <nevcairiel> i'm converting a range of pngs into something else!
[15:08] <nevcairiel> was just wondering if i can just cut-off the video easily on the input already
[15:08] <ubitux> nevcairiel: -frames:v 
[15:08] <nevcairiel> ah
[15:09] <nevcairiel> easier to convert the pngs into a y4m once instead of piping it in everytime
[15:09] <BBB> so vp8: --end-usage=vbr --auto-alt-ref=1 --minsection-pct=5 --maxsection-pct=800 --lag-in-frames=24 --kf-min-dist=0 --static-thresh=0 --drop-frame=0 --min-q=0 --max-q=63 --good --cpu-used=0 --arnr-maxframes=5 --arnr-strength=3 ?
[15:09] <BBB> in addition to the stuff you already had
[15:10] <BBB> silly vp8
[15:10] <nevcairiel> i assume we do standard yuv420 right
[15:10] <ubitux> lol
[15:10] <ubitux> nevcairiel: my source is yuv420p
[15:10] <ubitux> so yes i guess 
[15:11] <nevcairiel> my source is rgb
[15:11] <nevcairiel> but i suppose vp9 doesnt do anything else, or was that added yet?
[15:12] <nevcairiel> well i'll just go with 420, thats what youtube would use anyway
[15:13] <ubitux> BBB: still 1pass?
[15:29] <ubitux> ah, i just need --passes=2
[15:31] <ubitux> that vp9 encode is going to be really really funny
[15:31] <nevcairiel> funny how? funny slow?
[15:32] <ubitux> yeah
[15:32] <ubitux> 0.05 fps
[15:32] <nevcairiel> let me know when you have final settings to use, my y4m file is done as well
[15:33] <ubitux> nevcairiel: http://pastie.org/pastes/8742211/text
[15:33] <ubitux> this is the plan
[15:33] <ubitux> unless someone can suggest something else
[15:34] <nevcairiel> no archiving stdout?
[15:34] <nevcairiel> no idea what gets logged where
[15:34] <ubitux> http://pastie.org/8742213
[15:34] <ubitux> stdout is empty
[15:34] <ubitux> for both vpx and x264
[15:34] <nevcairiel> ok then
[15:35] <ubitux> there is not much information though
[15:36] <BBB> ubitux: oh did i forget the actual --passes=2 arg?
[15:36] <ubitux> didn't see it
[15:36] <BBB> sorry
[15:36] <BBB> add --passes=2 to vp8
[15:36] <ubitux> yeah sure i did
[15:36] <ubitux> see http://pastie.org/pastes/8742211/text
[15:36] <BBB> for nevcairiel: select your own bitrates, I don't know which ones are best
[15:36] <ubitux> and tell me if that looks legit to you
[15:36] <BBB> you want to see a fair quality progression from lowest to highest
[15:37] <BBB> yeah lgtm with --passes=2 for vp8 right?
[15:37] <ubitux> it's present
[15:37] <BBB> ok
[15:37] <nevcairiel> not sure there is a big jump in quality from 10 to 20 mbit, i would probably pick the lowest one quite a bit lower
[15:37] <ubitux> log is pretty clumsy btw
[15:37] <BBB> sorry carrying babies so hard to be sure...
[15:38] <BBB> nevcairiel: well we can always add more encodes later (we probably have to for fair same-quality decoder speed comparisons, you can't be 25% off in quality there)
[15:38] <BBB> it's just a rough first pass I guess
[15:38] <ubitux> x264 has no --passes=2 btw? :)_
[15:39] <nevcairiel> nah you have to call it twice
[15:39] <ubitux> too bad
[15:42] <nevcairiel> 442mbit uncompressed, neat :p
[15:44] <nevcairiel> are we sure about the settings now? I'll start encoding the vp9 then
[15:44] <ubitux> gonna start the 3 vp9 one as well
[15:45] <nevcairiel> QQ, it has a ETA of ~110 hours for the first one
[15:45] <nevcairiel> how does anyone use this codec
[15:46] <ubitux> :D
[15:46] <ubitux> i have a few more core available
[15:46] <ubitux> i guess i'll start the vp8 as well
[15:46] <nevcairiel> how many cores does it use?
[15:46] Action: nevcairiel checks
[15:46] <ubitux> only one
[15:46] <ubitux> of course
[15:46] <nevcairiel> intentionally or because it fails
[15:47] <ubitux> in the intention to fail at speed
[15:47] <nevcairiel> hehe
[15:47] <nevcairiel> i guess i can run the 3 vp9 in parallel then at least
[15:48] <ubitux> i started the 3 vp9 and 3 vp8 in parallel
[15:49] <nevcairiel> box has 4 cores/8 threads, but I don't want to kill it entirely for half a week
[15:49] <ubitux> :D
[15:51] <nevcairiel> could do the vp8s on another box i guess, just need an encoder there
[15:53] <nevcairiel> the x264s are probably done in an hour or so :p
[15:53] <BBB> yeah the --cpu-used=0 vp9 encoder is kind of ehm slow
[15:54] <ubitux> it's not like any other value makes it better
[16:04] <nevcairiel> it adjusted its eta, its only 12 hours now :p
[16:05] <ubitux> 68 for me
[16:06] <ubitux> 65, 68, 77
[16:06] <J_Darnley> (Unrelated) What a waste of time...
[16:06] <J_Darnley> I wonder if it is git branches I don't like or the gitorious website/software.
[16:07] <J_Darnley> https://gitorious.org/ffmpeg/jdarnley-ffmpeg/commit/07b4b0ca62a1c8cd0b7b1116bffb4b7c0fe640c8/diffs/eaded085ad7fb5bc2a92def008cbf39451ed01b3
[16:07] <J_Darnley> Also that is one long URL
[16:08] <ubitux> nevcairiel: 2.38 fpm 
[16:08] <ubitux> :(
[16:08] <nevcairiel> 5.6
[16:08] <ubitux> aw
[16:08] <ubitux> what cpu? :)
[16:09] <BBB> lol
[16:09] <nevcairiel> i7 4770, so quite some power
[16:09] <BBB> so uhm shall I encode sintel or so?
[16:09] <BBB> I don't think we have anything cartoony yet
[16:09] <BBB> or better suggestions?
[16:09] <BBB> I don't want to do pedestrian, it's boring
[16:09] <BBB> (baby is in bed)
[16:10] <BBB> what do people typically use for comparisons
[16:10] <BBB> I have a 1250 frames sintel 1080p version locally that I can use
[16:10] <nevcairiel> the usual suspects like parkjoy or crowdrun are often used
[16:11] <nevcairiel> but those are of course all extreme to some  degree
[16:11] <BBB> yeah I don't like those, too much stuff, plus they're almost standard in that everyone uses them
[16:12] <BBB> ubitux: is that 68hrs for 5k or 2k frames?
[16:12] <ubitux> 5k
[16:12] <BBB> ah
[16:12] <nevcairiel> (mine is 3k frames, btw)
[16:12] <ubitux> i actually want 5k
[16:12] <BBB> ok
[16:15] <BBB> ubitux: any preference? parkjoy or sintel?
[16:15] <BBB> or sth else
[16:15] <nevcairiel> sintel is probably fine
[16:15] <ubitux> BBB: maybe some real cartoon?
[16:15] <BBB> like a longer one?
[16:15] <BBB> or which one?
[16:15] <ubitux> like http://vimeo.com/30798517
[16:15] <BBB> big buck bunny? :-p
[16:16] <Skyler_> ubitux: looks okay, though I'd make sure they all have the same keyint
[16:16] <ubitux> ah, not 1080
[16:16] <ubitux> Skyler_: http://pastie.org/pastes/8742211/text
[16:16] <ubitux> i'm using those, with -keyint indeed
[16:16] <BBB> elephant's dream is ok?
[16:17] <BBB> I'll probably have to encode it on obe2 or so
[16:18] <BBB> dzjeeh if only I had actual HD space :-p
[16:20] <BBB> let's see where all that hd space is going
[16:21] <Skyler_> that looks fine.
[16:21] <ubitux> thanks
[16:24] Action: Daemon404 sees something made FATE asplode on windows
[16:29] <BBB> oh I bet some register number is declared wrongly
[16:30] <ubitux> BBB: btw, would that be fine not to share the etv samples on the blog post?
[16:30] <ubitux> i'd like to avoid legal problems eventually
[16:31] <nevcairiel> 2 minutes out of some movie is not fair use? :d
[16:31] <nevcairiel> (ok, 3.5 minutes)
[16:31] <ubitux> i honestly don't know
[16:31] <BBB> neither do i...
[16:31] <BBB> hm can't be xmm, that's win64, this is win32
[16:32] <BBB> Daemon404: care to bisect?
[16:32] <Daemon404> well... not right now
[16:32] <nevcairiel> most of the time creating the x264 encodes was transfering the 6gb y4m file to the other box <.<
[16:32] <Daemon404> im lunch, then meeting with some friends
[16:33] <Daemon404> it was obv some new vp9 asm
[16:33] <Daemon404> since all the windows fates brokeon vp9
[16:33] <Daemon404> ;)
[16:34] <BBB> but why specifically only win32?
[16:35] <BBB> why not win64?
[16:35] <Daemon404> win64
[16:35] <BBB> ?
[16:35] <BBB> only, or also?
[16:35] <BBB> fate shows some vp9 failures on 2 win32 stations
[16:35] <nevcairiel> only win32
[16:36] <nevcairiel> actually, not sure if win64 ran already
[16:36] <nevcairiel> but it should be running now, my box at least
[16:36] <BBB> well if you have more information, let me know
[16:37] <BBB> also, knowing which specific commit (and if it's the intra pred one, which particular function) would help
[16:37] <BBB> since I don't have windows and stuff
[16:37] <nevcairiel> 4 commits ago, everything was still fine
[16:37] <nevcairiel> in those 4 commits, 2 vp9 changes
[16:37] <nevcairiel> so i would guess its intra pred :d
[16:37] <nevcairiel> but lets see what win64 says when its done running
[16:38] <BBB> can you disable the simd functions one by one and see which one causes it?
[16:39] <BBB> (if that's not too much effort)
[16:41] <nevcairiel> i need to get some work done first, but i can try later
[16:41] <BBB> ty
[16:43] <nevcairiel> also, my x264 encodes are done and uploading, the 20mbit version will still need a couple minutes to show up, but here: http://files.1f0.de/encodes/
[16:44] <ubitux> cool :)
[16:45] <nevcairiel> eta for vp9 is 8.5 / 10 / 13
[16:45] <nevcairiel> (hours of course)
[17:02] <BBB> do we have some kind of unified ssim toy that we can use?
[17:02] <JEEB> the daala repo has one
[17:03] <JEEB> feed it two y4ms and it gives you normalized (I think) SSIM
[17:03] <JEEB> or whatever that process was called, I don't remember :P
[17:03] <JEEB> aka it gives you a bit saner numbers
[17:04] <JEEB> https://git.xiph.org/?p=daala.git;a=blob;f=tools/dump_ssim.c;h=3ac54b6fb642cffa76d1514ccd7a612c78eb332a;hb=HEAD
[17:04] <ubitux> tests/tiny_ssim.c?
[17:04] <JEEB> or that
[17:04] <JEEB> lemme see which I built
[17:04] <BBB> doesn't that output floats between 0 and 1?
[17:04] <JEEB> dump_ssim
[17:05] <JEEB> dump_ssim lets you choose the mode in which it gives you the results
[17:05] <JEEB> 10*log10(1/(1-ssim)) is what it outputs by defaut
[17:05] <JEEB> *default
[17:06] <JEEB> -r or --raw give you raw SSIM scores
[17:09] <BBB> bleh it requires libogg stuff
[17:11] <JEEB> it has weird dependencies, yes :P and I think the last time I tried to build it with the build system it failed, too
[17:11] <JEEB> I had to manually build it
[17:19] <BBB> JEEB: hmk I'll try to build it
[17:19] <BBB> how do I check out daala from git? is there a mnual somewhere?
[17:25] <ubitux> it seems to stabilize at 1.45 fpm
[17:25] <ubitux> so yeah, 70 hours :')
[17:28] <nevcairiel> which CPU is that on?
[17:30] <ubitux> i7-2600
[17:30] <ubitux> 3.4Ghz
[17:30] <nevcairiel> hm, would've thought it was faster
[17:31] <nevcairiel> maybe your content is more complex or something, but the speed difference to a 4770 is rather huge
[17:31] <ubitux> vp8 encode are done
[17:32] <nevcairiel> i mean, 1.45 fpm vs 4.93 fpm? must be more then just the cpu difference
[17:33] <BBB> it's probably content complexity yes
[17:33] <BBB> libvpx is very sensitive to that
[17:34] <nevcairiel> tears of steel is rather grain free, i havent seen etv, so if thats grainy maybe it  hurts performance
[17:34] <ubitux> it's a really grainy yes
[17:35] <ubitux> nevcairiel: http://lucy.pkh.me/encodes/etv5k-vp8-b20000.webm
[17:37] <BBB> JEEB: what do I need exactly to build daala? it's asking for stuff like as if it's building a desktop environment or so
[17:37] <BBB> s
[17:37] <BBB> t
[17:37] <BBB> uf
[17:37] <BBB> stuff like pkg-config
[17:38] <BBB> and what is check?
[17:38] <JEEB> pkg-config is just a simple way to check for where dependencies are installed, no?
[17:38] <JEEB> I think the tool you needed only needs libogg and that's it? don't remember fully :P
[17:38] <nevcairiel> ubitux: at first i thought something was broken, as the video was flickering weirdly, but i think thats part of the content? :p
[17:39] <ubitux> nevcairiel: yes :)
[17:39] <JEEB> building the full daala repo, no idea though
[17:39] <BBB> 'check is a unit testing framework'
[17:39] <BBB> omg
[17:40] <BBB> ok it didn't ask for more thank goodness
[17:40] <BBB> let's see if dump_ssim is useful
[17:40] <JEEB> I used it to get some data I could push into stuff like excel or R
[17:44] <BBB> is it kind of slow?
[17:44] <BBB> or is that just b/c I'm encoding some videos also?
[17:44] <BBB> I remember tiny_ssim being a lot faster than this
[17:50] <nevcairiel> hey, vp8 encoding is actually measured in fps :p
[17:51] <nevcairiel> well vp8 should be done in around an hour,
[17:52] <ubitux> vp8 encode is fast enough
[17:53] <nevcairiel> if it were threaded, it might be similar in speed to x264 veryslow
[17:53] <nevcairiel> but alas, its single threaded
[17:53] <ubitux> yeah sure, threading would be welcome
[17:54] <nevcairiel> i really dont want to know what kind of hardware google throws at re-encoding all their video
[17:57] <JEEB> nevcairiel, 'tube and others generally encode in parts nowadays
[17:57] <JEEB> so multithreading in a part is kind of extra
[17:57] <nevcairiel> still gotta encode the whole video
[17:57] <JEEB> of course
[17:57] <nevcairiel> but sure, you can encode parts in parallel and stich them back together
[17:57] <nevcairiel> makes for less waiting on one video
[18:06] <nevcairiel> vp8 encodes are done
[18:38] <cone-221> ffmpeg.git 03Peter Ross 07master:911eb7113383: avcodec/vp8dsp: evaluate CONFIG_VP7_DECODER/CONFIG_VP8_DECODER
[18:42] <BBB> fwiw i egt 4fpm also
[18:59] <superware> I'm decoding an h264 rtsp network stream using libav* (video only), how should I sync frames' pts? I need very low latency..
[19:04] <superware> or.. what's the best way to sync video frames from a live network stream for minimal latency?
[19:05] <nevcairiel> I dont even know what you mean with sync
[19:05] <nevcairiel> you get a timestamp, you usually have a reference clock somehow, so just show the frames accordingly
[19:09] <superware> yeah, I have a clock starting to count as soon as the stream is being opened
[19:21] <superware> nevcairiel: is av_frame_get_best_effort_timestamp(frame) * av_q2d(_video_stream->time_base) ok?
[19:33] <wm4> note that av_frame_get_best_effort_timestamp is ffmpeg only
[19:34] <wm4> and it's not even good (fails for certain container formats)
[19:34] <wm4> fails as in returns slightly incorrect values
[19:43] <Plorkyeran> "best effort" does suggest it's not entirely accurate
[20:20] <superware> wm4: can you please help me with pseudo code for frames syncing? what should I save for the first packet, what should I check against each arriving frame?
[20:20] <wm4> not sure what you mean by that...
[20:20] <superware> something like https://trac.handbrake.fr/wiki/LibHandBrakeSync
[20:20] <wm4> <superware> nevcairiel: is av_frame_get_best_effort_timestamp(frame) * av_q2d(_video_stream->time_base) ok? <- this is probably ok for a start
[20:21] <wm4> but you'll get in pain when you want your code to run on Libav
[20:21] <superware> no libav, only ffmpeg libav*
[20:23] <superware> so for the first video packet I save the initial PTS and start a clock counter (from zero), then what should I do per frame?
[20:29] <wm4> you don't need to care about the packet PTS
[20:29] <wm4> just pass it to the decoder
[20:30] <wm4> and then use the PTS that comes out of the decoder
[20:30] <superware> frame->pts is always zero
[20:32] <wm4> make sure you're passing through the packet PTS correctly
[20:33] <superware> "passing through"?
[20:36] <superware> where's frame->pkt_pts
[20:37] <superware> it turns out frame->pkt isn't always zero, it's simply constant
[20:37] <wm4> yeah I think you want pkt_pts
[20:38] <wm4> not sure, but I think frame->pts is mainly for things like libavfilter
[20:56] <cone-221> ffmpeg.git 03Michael Niedermayer 07master:d42ec8433c68: avcodec/ansi: fix integer overflow
[21:08] <nevcairiel> 2500/3000 frames in the 5mbit vp9 encode, i can nearly see the end!
[21:10] <cone-221> ffmpeg.git 03Vittorio Giovara 07master:614b9e4db8f3: h264: use avpriv_request_sample for chroma_format_idc
[21:10] <cone-221> ffmpeg.git 03Michael Niedermayer 07master:27f55beba2bf: Merge commit '614b9e4db8f3d7c23fc0410fc04745a727a82f4e'
[21:14] <wm4> every time I link ffmpeg, my memory starved machine almost dies
[21:14] <nevcairiel> you should try building chromium
[21:14] <nevcairiel> it'll explode, surely
[21:20] <cone-221> ffmpeg.git 03Diego Biurrun 07master:4d7ab5cfebef: doxygen: Add a number of missing function parameter descriptions
[21:20] <cone-221> ffmpeg.git 03Michael Niedermayer 07master:f3bb5f28d35e: Merge commit '4d7ab5cfebef91820af2933ef2f622ea598e6b53'
[21:25] <wm4> is there something in libavformat or libavutil to skip the BOM?
[21:25] <nevcairiel> BBB: the crash on win32 occurs in intra_recon, directly after intra_pred ran ... i'll debug further
[21:27] <cone-221> ffmpeg.git 03Diego Biurrun 07master:2f2b2efd31f6: doxygen: Replace @parblock syntax with manual linebreaks
[21:27] <cone-221> ffmpeg.git 03Michael Niedermayer 07master:6742614c231b: Merge remote-tracking branch 'qatar/master'
[21:31] <wm4> or a way to peek some bytes in an avio stream?
[21:33] <nevcairiel> all reads are final
[21:36] <BBB> nevcairiel: creepy
[21:38] <nevcairiel> BBB: i fixed it, sending patch in a sec
[21:38] <BBB> oh cool
[21:38] <nevcairiel> register count was one too low for one function
[21:39] <BBB> bleh :(
[21:39] <nevcairiel> just running full fate first
[21:39] <BBB> well thank for debugging
[21:39] <BBB> +s
[21:40] <nevcairiel> win64 didnt fail afterall, I don't know much about the win32 calling conventions, but i guess one clobbered reg didn't agree with it
[21:41] <BBB> it's odd lin32 didn't fail
[21:41] <BBB> becaue calling convention should be identical
[21:44] <nevcairiel> hm ok this only fixed half the failing tests
[21:45] <nevcairiel> on to debug the next!
[21:49] <BBB> possibly the same issue elsewhere
[21:49] <nevcairiel> what does DEFINE_ARGS do exactly? I assume the number of names afterwards has to match the number of regs available?
[21:50] <nevcairiel> ie, similar to the same being used in the cglobal line
[21:51] <BBB> vp9_ipred_dl_32x32 needs 4,5, has 4,4
[21:51] <BBB> DEFINE_ARGS just re-names the named arguments
[21:51] <nevcairiel> thats the first i fixed
[21:51] <nevcairiel> now fixing vp9_ipred_hu_32x32
[21:51] <nevcairiel> needs 7, right?
[21:52] <BBB> vp9_ipred_hu_32x32
[21:52] <BBB> yes
[21:52] <BBB> I just found that too
[21:52] <BBB> (going through code to make sure I did it correctly, which I clearly didn't)
[21:53] <BBB> that seems to be all of it
[21:53] <BBB> well s/7/3/ would indeed definitely break it
[21:54] <nevcairiel> another try at full fate then
[21:54] <BBB> I don't see any other occurrences in a full quick scan
[21:57] <nevcairiel> fate passed, patch on the ML
[22:18] <BBB> JEEB: yeah dump_ssim is really terribly slow and as such unusable
[22:43] <wm4> ubitux: posted some patches about this subtitle stuff we discussed
[23:05] <ubitux> wm4: ah, cool, will have a look tomorrow
[23:05] <ubitux> vp9: ETA 47h for the slowest one (20m)
[23:06] <ubitux> 40 and 36 for the two others
[23:06] <nevcairiel> my first should be done, i closed the terminal and cba to check
[23:06] <nevcairiel> others in the morning
[23:07] <ubitux> joke aside, do they seriously believe anyone will really use it to encode anythin longer than 1min?
[23:09] <BBB> lol
[23:09] <BBB> the encoder needs some work yes
[23:09] <BBB> the decoder isn't doing too badly ;)
[23:10] <BBB> they just need some help with the encoder I guess
[23:10] <BBB> anyway
[23:10] <nevcairiel> you should've stayed and helped!
[23:10] <BBB> ...
[23:10] <nevcairiel> :)
[23:10] <BBB> I added db support to ffmpeg's tiny_ssim btw
[23:10] <BBB> I'll send a patch for that, then we can use that to calculate ssim, it's not exactly identical to the one in daala but at least it's not slow
[23:17] <ubitux> so, if i'm correct
[23:17] <ubitux> for an average movie of 100minutes
[23:17] <ubitux> encoding a movie with libvpx will take more than 2 months
[23:17] <ubitux> on a relatively decent machine
[23:20] <BBB> I think that was the complaint about hevc also
[23:22] <nevcairiel> Well its always a question of a too complex standard or a too slow implementation
[23:22] <nevcairiel> the later can be fixed
[23:26] <beastd> hmm, vp9 segfaults on latest cygwin FATE report
[23:26] <nevcairiel> patch on ML
[23:27] <beastd> good. didn't get that far yet. and probably won't anymore today.
[23:43] <ubitux> BBB: maybe do not print \r if isatty() so it behaves properly in a pipe?
[23:48] <BBB> what's isatty?
[23:48] <BBB> maybe I should look at what ffmpeg does or so
[23:48] <llogan> sounds like Southern American slang
[23:50] <BBB> ubitux: doesn't \r do nothig more but add a character in a pipe?
[23:51] <BBB> i.e. it won't be a linefeed but it will work correctly
[23:51] <BBB> you can sed -e 's|\r|\n|g' if you want newlines
[23:52] <ubitux> if you redirect to a file (for example) you want to avoid printing those char
[23:53] <ubitux> gtg. 'night.
[23:54] <BBB> ubitux: done
[23:59] <cone-221> ffmpeg.git 03Michael Niedermayer 07master:c57fc97e956a: avformat/bink: Check return value of av_add_index_entry()
[00:00] --- Tue Feb 18 2014