Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2014

1 participants
56 discussions

ffmpeg-devel.log.20140217
by burek 18 Feb '14

18 Feb '14

[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/07b4b0ca62a1c8cd0b7b111… [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=3ac54b6fb642… [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

1 0

ffmpeg.log.20140217
by burek 18 Feb '14

18 Feb '14

[00:18] <youmi> hi , is it possible to add to an output flv stream (flash) a subtitles from a file ? [00:21] <llogan> youmi: hardsubs or softsubs? i don't know if flv can handle softsubs. [00:21] Action: llogan is ignorant of the FLV specs and too lazy to read them [00:21] <youmi> huu i don't know, most of them are .srt files [00:22] <llogan> do you want to encode the subtitles into the video? sometimes referred to as "burn in" the subtitles. [00:24] <youmi> well it's a streaming to a flash player (ustream) i just want to add it live to the video when i am streaming it [00:25] <llogan> use the subtitles or ass filter [00:25] <llogan> http://ffmpeg.org/ffmpeg-filters.html#subtitles-1 [00:25] <llogan> http://ffmpeg.org/ffmpeg-filters.html#ass [00:26] <kris_> if i want to enable x11grab, do i just need to include --enable-x11grab on ./configure? [00:26] <llogan> that's half of it. you also need to install some stuff. [00:26] <llogan> youmi: https://trac.ffmpeg.org/wiki/How%20to%20burn%20subtitles%20into%20the%20vid… [00:26] <youmi> thanks but is it possible to do it live to my stream ? [00:26] <llogan> i don't see why not [00:27] <llogan> kris_: such as libx11-dev libxext-dev libxfixes-dev for Dumbian systems [00:27] <youmi> i found the second link but it's for burning the subtitles [00:27] <llogan> i thought that's what you wanted [00:27] <kris_> llogan: I got that from https://trac.ffmpeg.org/ticket/821 however ubuntu only had libx11-dev and not the other two :/ [00:28] <llogan> which Unoobtu version? [00:28] <kris_> llogan: 13.10 - oo i jsut found libxfixes (typo last time) [00:28] <youmi> it's burning if i just add it live to a stream ? thought it was to ass it to a file (burning) [00:29] <youmi> add* [00:29] <llogan> kris_: make sure you get the -dev package: libxfixes-dev [00:29] <kris_> llogan: okay i was making a typo for two of the three ,< its all there [00:30] <llogan> http://trac.ffmpeg.org/wiki/UbuntuCompilationGuide [00:30] <kris_> though oddly, each package was already installed after i stopped mistyping them [00:30] <llogan> blame past kris_ [00:30] <kris_> llogan: I do [00:30] Action: kris_ smacks self [00:31] <znf> Could the showwaves filter be made into a transparent background animation istead of simply black? [00:38] <Merth> Hey everyone, I'm trying to extract a 16 second clip of a movie into pngs, which I can do just fine. My problem is that I'm trying to include the subtitles, which are in an .srt file. That I'm having issues with, and google hasn't been much help. Any suggestions? [00:38] <Merth> Here's what I'm doing: ffmpeg -ss 0:48:18 -i batman.mpg -i batman.srt -t 0:0:16 -f image2 %03d.png [00:39] <Merth> sorry, batman.mp4* [00:42] <Merth> This generates all the pngs, but they don't have the subtitles. [01:23] <DZII> Hello all [01:24] <osmodiar> Hello. [01:33] <DZII> can anyone give me a link to an updated install guide for ffmpeg on ubuntu 12.04 server [01:38] <osmodiar> Why do you need an updated one? [01:40] <DZII> keep getting issue with yasm [01:47] <osmodiar> Which is? [01:48] <DZII> even though i have installed yasm-1.2.0 keeps telling me when trying to install x264 If you really want to compile without asm, configure with --disable-asm [04:37] <kris_> so i compiled ffmpeg from git, enablex libx253 and x11grab and I'm (still) getting black video recorded while audio works fine [04:38] <kris_> I'm kind of tired now and been working on this in between chores all day and I'd be really hapyp if anyone happened to know why it still doesn't work ._. [05:49] <kris_> llogan: I did the other day and didn't get any responses :( so i was hoping someone might just be familiar with the general problem - here is a fresh log from a 10 second video I tried to record just now http://sprunge.us/jIRT [05:51] <llogan> kris_: what player are you using? [05:54] <kris_> llogan: mplayer [05:54] <kris_> also, i noticed in my last one that there appears a mouse cursor this time O.o strange because it does not move even though i moved my cursor around while recording [05:56] <llogan> try changing "-vf scale=-1:720" to "-vf scale=-1:720,format=yuv420p" [05:57] <llogan> kris_: and also add "-acodec copy" [06:02] <kris_> llogan: okay, I tried with those suggestions, here is the output of ffmpeg http://sprunge.us/dTIM and here is a screenshot of that illusive mouse cursor that seems to get recorded for some reason http://i.imgur.com/uxZWdj6.jpg [06:03] <kris_> mouse cursor feels haunting - it just sits there for the entire video, never moving, never mimicking my own movements [06:04] <llogan> what are you trying to record? [06:06] <kris_> llogan: just my desktop - I'm running a custom compiled 'dwm' (suckless) inside xorg that I installed from canonical's repository for aptitude on an Ubuntu 13.10 Minimal [06:07] <kris_> llogan: its all worked before on 13.04 - so I figured it was a xorg related issue that would get resolved by ffmpeg - but maybe I'm wrong [06:07] <llogan> if you're using dwm what are you doing using ubuntu? [06:07] <kris_> llogan: being lazy :) [06:07] <llogan> seems like more work [06:07] <kris_> llogan: this machine has been running ubuntu minimal since 2011, and I've been to lazy to switch to something minimal [06:08] <llogan> i'm not sure why your mouse appears to not move nor why everything is mostly black. [06:08] <kris_> llogan: it's not that bad - old packages and stubborn system, but not so bad [06:09] <llogan> you can add "-draw_mouse 0" as an input option if you want to get rid of it [06:09] <llogan> http://ffmpeg.org/ffmpeg-devices.html#x11grab [06:17] <kris_> got the same results with openbox - so i know its not my dwm [06:17] <llogan> did ffplay also get compiled with your ffmpeg? [06:18] <kris_> llogan: yeah same version - also same results as mplayer [06:19] <kris_> llogan: strange though /tmp/20140217_001102.mkv: error while seeking 0KB sq= 0B f=0/0 [06:19] <llogan> maybe someone on the ffmpeg-user mailing list will have an idea. [06:23] <kris_> llogan: you'd think I was comfortable with mailing lists by now, but I'm completely unfamiliar with how they work - do I need to subscribe to to ffmpeg-user mailing list in order to read replies? [06:24] <llogan> no, you can check the archives, or some third party thing like gmane or nabble. [06:25] <llogan> see https://trac.ffmpeg.org/wiki/MailingListEtiquette and http://ffmpeg.org/contact.html [06:31] <extor> If I want to shrink a 1.2GB avi movie into a lets say 200 MB vid then how would I go about doing it in the shell, any decent CLI apps? Not sure how much CPU power it would take either. I would be doing this in a vmware vm which can be either windows or linux [06:32] <llogan> extor: get a recent ffmpeg build. either compile it (several guides on the wiki) or download a build at http://ffmpeg.org/download.html [06:32] <llogan> then see https://trac.ffmpeg.org/wiki/x264EncodingGuide [06:32] <llogan> results may vary [06:32] <llogan> if you want to try to target a specific output file size then use two-pass mode. [06:33] <extor> I forgot to emphasize that I don't have much of a graphics card in the remote server. So it would be CPU rendering only. Hope that's not an issue. [06:34] <llogan> it is not an issue since there is little a graphics card can offer in terms of encoding if using ffmpeg and x264 (and other existing implementations are generally shit). [06:35] <extor> Are .mkv files anything to do with ffmpeg? I ask because the smallest sizes I've seen around recently appear to be .avi or .mkv [06:36] <llogan> those are just container formats that can contain a variety of various multimedia formats. ffmpeg can output these. [06:37] <kris_> I may be wrong, but you should avoid .avi containers and chose mp4 containers instead whenever possible [06:37] <extor> what is the reason to avoid avi [06:37] <kris_> avi is pretty old and not that great, or from my experience at least [06:38] <extor> ahh there's a lot of utilities out for avi such as avi splitter and such, and vlc offers to rebuild avi indexes too [06:38] <kris_> mp4 tends to compress better when I handle video - I'm no guru though so someone may have an entirely different and more experienced opinion ont he matter [06:39] <kris_> mkv I stand beside though, assuming you are including multiple audio tracks or including subtitles - if you are just including one audio track and one video track, I would prefer mp4 [06:41] <extor> so mkv is just a little organizer shoebox type of deal [06:42] <llogan> here's a long answer that may help: http://superuser.com/a/300997/110524 [06:54] <kris_> that post ... TIL [06:55] <kris_> namely that "the FFmpeg terminology would be to use "format" for the container." I must admit the use of "format" has been throwing me off from time to time [07:09] <relaxed> kris_: format does not always mean container. [08:58] <JamJams> Hi, I keep getting the single error "av_interleaved_write_frame(): Invalid argument" when I try to pipe an avs to x264.exe. Is there any way to get more detail than that? [10:03] <lindylex> what does this mean "Invalid pixel format string '-1'"? [10:41] <zap0> i think it means the pixel format string is invalid [10:41] <zap0> but that's just a hunch [11:36] <termos> are there any well maintained c++ wrappers for libav? The ones I come across on google are all old or incomplete [11:38] <Xeta> Hi guys, Anyone know if there is there any easy way to apply Replaygain headers (which are in the m4a audio file) in ffmpeg to normalize audio? [13:19] <lindylex> zap0: My image sequence I was trying to turn into an image was not divisible by 2. That was the problem. This is my FFMPEG line: ffmpeg -r 29.97 -b 320k -i %d.png -vcodec libx264 output.mp4 [13:50] <termos> I have a problem where avcodec_find_encoder(AV_CODEC_ID_H264) returns null, is there a known reason for this? x264 is compiled and installed, it's also linked against with -lx264. [14:02] <burek> is it possible to encode videos using vp9 as of current ffmpeg? [14:07] <ubitux> burek: there is only a native decoder [14:07] <ubitux> but there is a libvpx wrapper to encode vp9 yes [14:08] <burek> ubitux, using -c:v libvpx with the latest ffmpeg, gives me vp8 encoded videos [14:08] <ubitux> libvpx-vp9 [14:08] <burek> oh... ok, thanks, let me try [14:08] <ubitux> DEV.L. vp8 On2 VP8 (decoders: vp8 libvpx ) (encoders: libvpx ) [14:08] <ubitux> DEV.L. vp9 Google VP9 (decoders: vp9 libvpx-vp9 ) (encoders: libvpx-vp9 ) [14:08] <ubitux> (ffmpeg -codecs) [14:08] <burek> +1 :) [14:10] <burek> ubitux, when I do ./configure --help there is no libvpx-vp9 in the output.. which library do i need for that? [14:10] <ubitux> libvpx [14:11] <burek> oh, i guess i need to update it :) thanks man :) [16:07] <burek> ubitux, thanks again :) I've updated my libvpx and now static builds support vp9 encoding too :) [16:07] <burek> I should update all the used libs these days [16:08] <burek> just to find some free time.. [16:08] <burek> first* [16:36] <thanmai_> does converting from image to timelapse video still available in ffmpeg? [16:38] <osmodiar> Yes. [16:38] <osmodiar> https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images [16:57] <thanmai_> thanks osmodiar [17:04] <thanmai_> I am getting this error: [17:05] <thanmai_> https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images [17:05] <thanmai_> oops sorry not that one. [17:05] <thanmai_> *** THIS PROGRAM IS DEPRECATED *** [17:05] <thanmai_> This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. [17:05] <thanmai_> Unrecognized option 'start_number' [17:05] <thanmai_> Failed to set value '0567' for option 'start_number' [17:05] <thanmai_> my command is : [17:05] <thanmai_> *** THIS PROGRAM IS DEPRECATED *** [17:05] <thanmai_> This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. [17:05] <thanmai_> Unrecognized option 'start_number' [17:05] <thanmai_> Failed to set value '0567' for option 'start_number' [17:05] <thanmai_> oops sorry again [17:05] <thanmai_> ffmpeg -r 1 -start_number 0567 -i IMG_%04d.JPG -c:v libx264 -r 30 -pix_fmt yuv420p out.mp4 [17:06] <JEEB> if you are using stuff based on libav's code, you should use avconv. the ffmpeg binary was left around not updated after elenril did the bigger changes to its code under the name 'avconv' [17:22] <thanmai_> avconv -y -f image2pipe -start_number 567 -r 1 -i "IMG_%%04.JPG" -r 24 -vcodec libx264 out.mp4 [17:22] <thanmai_> Error: [17:22] <thanmai_> avconv version 0.8.10-4:0.8.10-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the Libav developers [17:22] <thanmai_> built on Feb 6 2014 20:59:08 with gcc 4.6.3 [17:22] <thanmai_> Unrecognized option 'start_number' [17:22] <thanmai_> Failed to set value '567' for option 'start_number' [17:23] <osmodiar> #libav is the avconv channel. [17:23] <klaxa> a) use pastebin please, b) this is #ffmpeg not #libav [17:23] <klaxa> you can download a static build though and use ffmpeg instead [17:24] <thanmai_> thanks guys [18:56] <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? [21:54] <NeeDe> trying to use draw text and adjust the fontsize depending on the video height: >>> ffplay -i "F:\TestClips&Co\test.avi" -vf drawtext="fontsize=ceil(h*0.2):fontfile=canaith.ttf:text='Happy Birthday'" <<< give me > Undefined constant or missing '(' in 'h*0.2)' < , can some one tell me how to set the fontsize depending on the input height [21:55] <NeeDe> looks like h is not interpreted as height :( [22:05] <NeeDe> seems like everybody is afk [22:50] <DeadSix27> is there a documentation about what exactly -target does? [22:51] <DeadSix27> i only see what options it will apply, but not their values [22:52] <DeadSix27> what exactly the specific targets will do* [23:14] <llogan> DeadSix27: see ffmpeg_opt.c [23:15] <DeadSix27> llogan: i will, thanks. [23:27] <three_le1s> so is 1.27 released yet ? [23:46] <llogan> three_le1s: what happened to 1.26? [23:46] <llogan> the download page is updated as soon as a release is made. [23:52] <three_le1s> hm [23:52] <three_le1s> alright im trying to git 1.27 but git keeps on retreiving 1.26.5 [23:53] <three_le1s> llogan: it's still there [00:00] --- Tue Feb 18 2014

1 0

ffmpeg-devel.log.20140216
by burek 17 Feb '14

17 Feb '14

[00:04] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:bf2ce19e51fd: avcodec/hevc: Dont turn 32bit timebases into negative numbers [00:04] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:d1e6602665d5: avcodec/hevc: make *ps_id unsigned [00:13] <BBB> ubitux: I'm getting closer to having intra pred simd ready [00:13] <BBB> (that is, simd is written but dr 16x16 is broken, 32x32 untested and all of vl/vr/hu/hd are also untested - the rest works) [00:14] <ubitux> cool :) [00:14] <ubitux> i'm working on some other random ffmpeg work for a third party :p [00:14] <nevcairiel> i hope they pay you [00:16] <ubitux> they can't actually i have no legal status for that :] [00:48] <Compn> cant they send you money in an envelope ? :P [01:01] <kierank> Compn: holland will take his money [01:45] <ubitux> i don't mind the taxes [01:45] <ubitux> i do mind the paperwork though [01:46] <ubitux> so i'd better not see the money at all :) [01:48] <BBB> crazy europeans [01:48] <michaelni> ubitux, just pay someone to do the paperwork if you dont want to do it yourself [01:49] <Compn> do that and then donate your money to charity :P [01:49] <ubitux> Compn: that's somehow what i do [01:49] <ubitux> either i ask for hw, or i ask for donation [01:49] <ubitux> (ffmpeg or random charity i care about) [01:50] <ubitux> speaking of the ffmpeg donation i wonder if that one reached it, i should nag saste about it [01:50] <Compn> ah :) [01:50] <ubitux> anyway, 'night [01:50] <Compn> night [01:50] <michaelni> night [01:53] <ubitux> (michaelni: ah, and well, i don't do enough payed mission to consider this, that's really too punctual - my full time job is enough for income) [01:56] <Compn> we just like to bug you ubitux :) [01:56] <Compn> ehe [01:56] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:e5c722999918: avcodec/utils: set AVFrame format unconditional [02:04] <cone-776> ffmpeg.git 03Tim Walker 07master:9c0e4b3395ca: ac3: update AC3PreferredStereoDownmixMode. [02:04] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:fdf8b59b28cb: Merge commit '9c0e4b3395cad79c560d03d2a94595d89e017885' [02:10] <burek> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=1276 -> ohmk: "Thanks logan, reading your replies around here, you are a huge contributor to this community and I'm sure I speak for everyone that we all appreciate your responses." [02:10] <burek> I also wanted to say thank you for your huge contribution llogan :) :beer: :) [02:12] <Compn> llogan works hard :) [02:19] <cone-776> ffmpeg.git 03Tim Walker 07master:c98f3169bfb5: lavu: add AV_FRAME_DATA_DOWNMIX_INFO side data type. [02:19] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:a2bc6c116ddc: Merge commit 'c98f3169bfb578c1a4e407b44524f0bfa3b4dc0c' [02:25] <cone-776> ffmpeg.git 03Tim Walker 07master:9cd4bc41760f: ac3dec: set AV_FRAME_DATA_DOWNMIX_INFO side data. [02:25] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:1db87da35141: Merge commit '9cd4bc41760f8ad879e248920eacbe1e7757152c' [02:30] <cone-776> ffmpeg.git 03Reinhard Tartler 07master:f58dcfb32e0f: Prepare for 10_beta1 Release [02:31] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:bbd8fd0371a5: Merge remote-tracking branch 'qatar/master' [03:10] <cone-776> ffmpeg.git 03Hendrik Leppkes 07master:45581ed15d2a: oggdec/vorbis: fix stream duration condition [03:51] <BBB> and right now vl/hd/hu are untested and vr32x32 is broken, rest works [03:51] <BBB> so 13 to go [03:51] <BBB> unlucky number [03:52] <BBB> I guess that means it's time to sleep [03:52] <BBB> almost there... [04:14] <cone-776> ffmpeg.git 03Timothy Gu 07master:8fe107609437: doc/ffmpeg: make the ASCII flow charts narrower to fit onto TTY [08:49] <t355u5> ffmpeg from git shows negative fps and I don't know how to debug this. any tips? here is the output: [08:49] <t355u5> ffmpeg 2.1.3: [08:49] <t355u5> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x816, 1976 kb/s, 24 fps, 24 tbr, 24k tbn, 48 tbc (default) [08:49] <t355u5> git: [08:49] <t355u5> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x816, 1976 kb/s, -6.10 fps, 24 tbr, 24k tbn, 48 tbc (default) [12:04] <michaelni> t355u5, look at what avg_frame_rate is set by av_find_stream_info() or before it [12:07] <t355u5> michaelni: how do I do that? -loglevel debug does not give me much info [12:08] <michaelni> t355u5, you use a text editor with utils.c [12:09] <t355u5> michaelni: ok, so the manual way. I'm used to debug code that really gives you all the debg info [12:10] <t355u5> what about gdb? do you have a brakpoint I could use? [12:16] <t355u5> michaelni: there are several utils.c files [12:17] <michaelni> t355u5, grep for avg_frame_rate, and check where its set to a negative value and why [12:17] <michaelni> libavformat/utils.c [12:19] <t355u5> in libavformat/utils.c avg_frame_rate is never set, just accessed/referenced. ok, I'll browse through the code [13:11] <t355u5> michaelni: ok, the framerate in avformat_find_stream_info is always negative. avg_frame_rate: num: -108839912 den: 17834625 [13:11] <t355u5> michaelni: now I check it before avformat_find_stream_info [13:20] <t355u5> michaelni: this will take forever, I am not familiar with the code. have to do some other things now.can you at least reproduce the problem, or are your fps correct? [13:23] <michaelni> t355u5, you would have to provide a sample file and command line to test first [13:25] <t355u5> michaelni: sure, np. where shall I put it. I cut the file off after 4MB. I can either put it on my server or upload it. the commandline is easy: ffmpeg -i fname.mp4 [13:26] <michaelni> trac [13:26] <t355u5> ok, I'll open a ticket in the evening. need to grab some breakfast... ttyl [13:27] <michaelni> you might need to cut it a bit smaller than 4mb though, not sure what the max filesize is or [13:28] <cone-926> ffmpeg.git 03James Almer 07master:ec482e738ddc: x86/fladsp: add missing check to ff_flacdsp_init_x86() [13:28] <t355u5> with 1mb, ffmpeg can't read the header. but I try to make it as small as possible. if not, I put it on my server and put a link in the ticket. no worries, no user/pwd. just public http [13:28] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:18f94df8af04: avcodec/alsdec: check predictor order against block length [15:42] <BBB> yay all simd works [15:43] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commits/vp9-simd [15:45] <BBB> ubitux: can't measure right now b/c I'm watching olympics and that ruins any performance metric [16:06] <ubitux> BBB: waaa :) [16:07] <ubitux> do you want me to review on github/irc? [16:11] <BBB> dunno, probably github is easier b/c then I have a log [16:11] <BBB> irc will get lost [16:11] <BBB> pastebin is ok also [16:12] <BBB> or I can email to the list [16:13] <BBB> do whatever is easiest for you [16:13] <BBB> I'll adapt [16:14] <ubitux> idc [16:14] <ubitux> i'll review in a few hours [16:25] <BBB> ty [17:25] <superware> any idea why AVStream->avg_frame_rate is {0,0} for h264 network streams? how can I reliably get frame rate? [17:27] <BtbN> superware, use timebase. Look at how libx264 does it. [17:30] <superware> BtbN: ok, 1.0 / FFmpegInvoke.av_q2d(st->codec->time_base) equals 180000, what does it mean? [17:32] <BtbN> that something went wrong. timebase is "seconds per frame" [17:32] <superware> av_q2d(st->codec->time_base) is 0.0000055555555555555558 [17:33] <superware> { den: 180000, num: 1 } [17:34] <superware> av_q2d(st->r_frame_rate) is half, 90000 [17:35] <BtbN> yes, h264 usualy does two ticks per frame. There's another variable for that. [17:37] <superware> eh? :) [17:41] <nevcairiel> many streams simply dont have useful fps information, and the only way to get it is to probe it, but that doesnt work on network streams [17:46] <superware> nevcairiel: well, I must know the frame rate to sync rendering :| [17:46] <nevcairiel> thats not always possible, sorry [17:47] <nevcairiel> you can of course delay start up and read ~20-30 frames first to try to guess the framerate from the timestamps [17:47] <nevcairiel> but that makes startup slow of course [17:47] <superware> can't ffmpeg do it automatically? :) [17:48] <nevcairiel> it usually does, but it must be disabled by something [17:49] <superware> maybe AVFMT_FLAG_NOFILLIN or AVFMT_FLAG_NOBUFFER? [17:49] <nevcairiel> if you set those, then it may be the reason [17:49] <superware> hmm [17:49] <BBB> superware: you sync rendering by using the timestamps [17:50] <BBB> superware: not by looking at framerate [17:53] <superware> after removing AVFMT_FLAG_NOFILLIN, st->r_frame_rate is ~25, should I use it? [17:53] <ubitux> r_frame_rate is not what you think it is [17:56] <ubitux> there is not really a reliable way to get the frame rate, and you probably don't need it anyway [17:58] <superware> should I do something like (current_frame.index - last_frame.index) / (current_frame.pts - last_frame.pts) ? [18:01] <cone-926> ffmpeg.git 03Nicholas Robbins 07master:b4d308c04f7a: lavfi: adding dejudder filter to remove judder produced by partially telecined material. [18:02] <superware> BBB: do you mean pts? [18:02] <JEEB> yes, that is the presentation time stamp [18:02] <superware> or best_effort_timestamp [18:03] <superware> JEEB: and how should I check whether two frames are sequencial (without missing frames in between)? [18:06] <superware> JEEB? :| [18:10] <superware> BBB? [18:21] <BBB> superware: pts [18:21] <superware> BBB, ok, how should I check whether two frames are sequencial (without missing frames in between)? [18:22] <BBB> the rtp layer will provide such information [18:32] <ubitux> BBB: 'done with the review [18:32] <ubitux> BBB: i didn't "ditto" a lot of comments, but some things i'm pointing out/asking about are present several times [19:06] <BBB> ubitux: ok, link? [19:06] <ubitux> BBB: github comments [19:07] <ubitux> https://github.com/rbultje/ffmpeg/commit/bb84d5cae677ddbb98a9a65c840b51442f… [19:15] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:05e9e3342fe1: avformat/mov: fix avg_frame_rate calculation [19:17] <BBB> ah yes [19:17] <BBB> responded to most of them [19:17] <BBB> so ... yes the unrolling in general might help, I'm a fan of small codesize for stuff that is mostly irrelevant for performance purposes [19:17] <BBB> we'd probably have to measure it to see if it helps or not [19:18] <BBB> and givent hat we have to look at whole-picture speed and the impact is so small, it might be hard to measure [19:18] <ubitux> "when it's a branch target" [19:18] <ubitux> what's that? [19:19] <ubitux> ok for non-unroll [19:19] <BBB> branch target means something if .. a else b [19:19] <BBB> the .. part [19:20] <BBB> "the result of this is used in a jump statement [19:20] <BBB> " [19:20] <BBB> might mean you want to set condition flags rather than make things unnumbered, as opposed to when the result is used in arithmetic, then you might want to not set condition flags [19:20] <ubitux> ah, conditionnal RET in the middle of the function then? [19:21] <BBB> what do you mean exactly? [19:21] <BBB> I'm missing something [19:21] <BBB> is this re REP_RET? [19:21] <BBB> the relevant ocmmit is "x86inc: activate REP_RET automatically" from loren [19:21] <BBB> so we don't have to write it anymore, x86inc.asm does it for us now [19:23] <ubitux> yes it's still about REP_RET [19:23] <ubitux> my quote was from the commit you mentioned [19:23] <ubitux> and the commit was saying it was still necessary "when it's a branch target" [19:23] <ubitux> i was wondering what it was refering to [19:25] <BBB> I think a jump target [19:25] <BBB> like cmp a, b; jg .end; [some code] .end: REP_RET [19:26] <ubitux> ok [19:26] <BBB> I don't think we ever use that [19:26] <ubitux> thanks :) [19:28] <BBB> michaelni: did you merge the commits from ffmpeg to always use CODEC_FLAG_EMU_EDGE? [19:29] <BBB> michaelni: and if not, is it possible we accidently merged the patch to remove the fate tests with emu-edge enabled (since some code paths are different with that flag set in ffvp8/ffvp9)? [19:30] <BBB> hm the codepaths are gone, so I guess the patches were merged then... [19:30] <ubitux> BBB: vp9_ipred_vl_8x8 is XMM and has 0 for xmm regs [19:30] <BBB> oops [19:30] <BBB> fixed [19:31] <BBB> also label removed (__unused:) [20:02] <michaelni> BBB, all should be merged, i only remember that there where some chnages to some asm that i didnt merge (91e00c4a785d3f4cd44f1044d3e7b1b34fee8b5c) [20:14] <llogan> burek: thanks, but i often don't know the answers. [20:33] <BBB> ubitux: another patch uploaded also [20:33] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commit/9d32fdd65cbd65c67f3a2d05a8f8462b51… [20:40] <ubitux> BBB: zomg speed? [20:44] <cone-926> ffmpeg.git 03Maxim Poliakovski 07master:77fbc0326555: g2meet: validate bpp and bitmasks in the display info [20:44] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:573a8ce8f94f: Merge remote-tracking branch 'qatar/master' [20:55] <ubitux> BBB: anyway, you probably want to macrotize those switch case [20:56] <ubitux> and maybe change "internal" into "generic" or something (that's obviously an internal function) [21:04] <BBB> ok [21:05] <BBB> ubitux: it seems faster, it's 5.3sec to decode my sample file now [21:05] <BBB> used to be 5.5 when I started the simd and 5.4 in between [21:05] <ubitux> cool :) [21:20] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:a392bf657015: avcodec/dxtory: fix src size checks [22:35] <BBB> ubitux: done [22:35] <BBB> oh done with macro [22:36] <BBB> internal->generic still to do [22:36] <BBB> ubitux: done that also [22:39] <cone-926> ffmpeg.git 03Alexander Strasser 07master:db3c9701f46d: lavf/avio: Introduce avio_find_protocol_name [22:39] <cone-926> ffmpeg.git 03Alexander Strasser 07master:2b17c7685fd3: ffmpeg_opt: assert_file_overwrite: Work for all file protocol outputs [22:46] <cone-926> ffmpeg.git 03Alexander Strasser 07master:2218fbe05e6d: doc/APIchanges: Update for new function avio_find_protocol_name [23:49] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:c919e1ca2ecf: avcodec/msrle: use av_image_get_linesize() to calculate the linesize [00:00] --- Mon Feb 17 2014

1 0

ffmpeg.log.20140216
by burek 17 Feb '14

17 Feb '14

[10:48] <wodim> hello, i have a dvd with a "making of" (lots of short clips) but there are only a few .VOB files. The big ones contain a lot of clips/chapters/whatever. The dvd is supposed to be navigated with the dvd menu. how can i know what the offsets and lengths are? [11:14] <Xeta> Is there any easy way to apply Replaygain headers (which are in the m4a audio file) in ffmpeg to normalize audio? [11:41] <wodim> I use -chapter x-x and whatever I choose for x it ends up playing the same chapter. Any idea? [11:41] <wodim> wrong chan [17:02] <coalado> Hi. [17:03] <coalado> Do you know any way to estimate the actual "bitrate/quality" of an audio file? Let's say a file has been encoded to mp3_64kbit and than to aac_192 kbit. I'd like to find a way to estimate the actual "quality" [17:03] <sacarasc> "Shit" [17:04] <coalado> is this an answer to my question? [17:04] <sacarasc> Yes. [17:04] <sacarasc> 64kbps MP3 isn't great, except maybe for voice only. [17:04] <sacarasc> Then another lossy conversion is just going to make it worse. [17:04] <superware> no shit [17:05] <coalado> I did not ask if 64kbps is shit or not. [17:05] <sacarasc> You could run it through a spectrograph and see where it caps out and things, but proper analysis is beyond me. [17:06] <coalado> sacarasc: that's the answer I was looking for :) [17:22] <superware> any idea why AVStream->avg_frame_rate is {0,0} for h264 network streams? how can I reliably get frame rate? [19:31] <bmhm> hi. I'd like to send gst-omx's encoded video to ffserver. Anyone knows how to do that? [21:31] <bmhm> Used pipes so far. [22:37] <kris_> so I compiled ffmpeg from git (just a blind make install without reading much) - it compiled and installed fine, but I ran into errors with libx264 vcodec. I ran ffmepg -formats and didn't see it listed - is there an option I need to tick to enable libx264 at build time? [22:38] <znf> ./configure --help ? ^^ [22:39] <osmodiar> kris_: ffmpeg -codecs would be the one that shows it. [22:39] <osmodiar> -formats is for containers. [22:39] <kris_> is this it? its from an old 2008 post on gogole "./configure --enable-libx264 --enable-gpl --enable-pthreads" [22:39] <kris_> osmodiar: oh :/ [22:39] <kris_> I seem to have h264 but not x264 :/ [22:40] <JEEB> yes, libx264 is a separate library [22:40] <JEEB> you need --enable-gpl and --enable-libx264 after you have built it yourself (or if it is new enough in your repositories, installed the development package for it) [00:00] --- Mon Feb 17 2014

1 0

ffmpeg-devel.log.20140215
by burek 16 Feb '14

16 Feb '14

[02:02] <cone-526> ffmpeg.git 03Lukasz Marek 07master:ffe50a92a8aa: lavc/tiff_common: add const to silent warnings [02:02] <cone-526> ffmpeg.git 03Lukasz Marek 07master:a91d9e4b6355: lavc/ffv1enc: add const to silent warning [02:24] <cone-526> ffmpeg.git 03Peter Ross 07master:b8664c929437: avcodec/vp8dsp: add VP7 idct and loop filter [02:38] <michaelni> Skyler_, should i revert 23a8c63452009df21b3f184936b343593d4ccb04 (x86inc: Extend FMA_INSTR functionality) and apply "Warn about not supported emulation of some XOP instructions. Also add pmacsdql emulation." from x264 ? [02:40] <michaelni> i think it would be best if a 5th argument, that is a temporary for emulation could be specified [02:41] <Skyler_> yeah, that might be a better solution than both, but in that case we should move it out of x86inc and into x86util and capitalize it [02:41] <Skyler_> because its semantics don't match the original instruction [02:41] <Skyler_> e.g. like PALIGNR vs palignr [02:50] <michaelni> ok, ive replied that to James Almer, maybe he will implement it (Re: [FFmpeg-devel] [PATCH 1/2] x86inc: Extend FMA_INSTR functionality) [03:00] <J_Darnley> michaelni: I sent two updated patches to the list. [03:00] <J_Darnley> After fixing what I think is the problem with 1of7 I had to change/merge 6of7 [03:00] <J_Darnley> And now, goodnight everyone [04:17] <cone-526> ffmpeg.git 03Anton Khirnov 07master:f758ea6e99af: buffersink: document special error codes returned from av_buffersink_get_frame [04:17] <cone-526> ffmpeg.git 03Anton Khirnov 07master:ba7dfe5c50b2: lavfi doxy: add buffer{src,sink}.h to the main lavfi doxy group [04:17] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:efe4a06929a8: Merge commit 'f758ea6e99af6ebd24bbe222898a921c222e5593' [04:17] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:baaa6d6785bc: Merge remote-tracking branch 'qatar/master' [06:52] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:d601106ab128: avcodec/x86/lossless_videodsp: fix w type [12:32] <JEEB> hmm, was there there an easy way to picture thread intra-only encoders @ ffmpeg? [12:32] <JEEB> IIRC some flag? [12:40] <cone-776> ffmpeg.git 03Paul B Mahol 07master:709746b6affb: avfilter/af_compand: do not leak frames on error [12:49] <BBB> JEEB: I believe you mark the AVCodec as intra-only [12:49] <BBB> JEEB: see examples in allcodecs.c [12:55] <JEEB> allcodecs.c ? that's just the general types and their registration [12:56] <JEEB> don't see anything specific to intra there [13:01] <Compn> what do you mean picture thread ? [13:01] <Compn> list threaded intra-only encoder ? [13:02] <JEEB> what's usually called 'frame threaded' :P [13:03] <JEEB> I've just switched to the ISO/IEC way of calling a picture a picture, because it can be a field or a frame [13:03] <Compn> oh you want to add frame threading to an encoder ? [13:03] <JEEB> yes [13:03] <JEEB> I hear there's a flag for intra-only things [13:03] <JEEB> that you can just add and have it JustWork [13:04] <Compn> is_threaded ? :P [13:04] <Compn> i dont even know which encoders are intra only [13:04] <Compn> so /me crawls back under his rock [13:25] <J_Darnley> JEEB: The place that flag would be, if it exists, is in the AVCodec struct [13:25] <JEEB> yeah [13:25] <J_Darnley> The capabilities field which marks lossless in the flac encoder I have open [13:26] <JEEB> I know the caps for decoders at least, but I guess I'll have to look up the struct-related info again [13:27] <nevcairiel> JEEB: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=bb7a7111562b3c488be2ee… [13:28] <nevcairiel> so basically, just set caps, make sure it works in all modes :p [13:28] <JEEB> ah [13:28] <JEEB> that's quite simple enough [13:28] <JEEB> danke schön [13:28] <nevcairiel> its a bit ugly that such codec specific checks are in frame_thread_encoder [13:28] <nevcairiel> but i assume ut doesnt need any [13:28] <JEEB> it shouldn't at least [13:40] <cone-776> ffmpeg.git 03Lukasz Marek 07master:776cda748d08: lavc/motion_est: remove unused variable [15:55] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:59279bf21fb0: avcodec/huffyuvenc: only allocate stats_out when it will be used [15:55] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:f7459bcfc5b5: avcodec/frame_thread_encoder: restructure huffyuv checks [15:55] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:3c7220fc605c: avcodec/frame_thread_encoder: warn about huffyuv limitations [16:56] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:042ab7c49ee3: doc/doxy-wrapper.sh: fix execute flags [16:56] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:ed1a6878564a: avcodec/lossless_videodsp: add_hfyu_left_prediction_int16_c: fix harmless integer overflow [17:29] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:d46ef4012948: avcodec/fic: fix slice checks [17:29] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:1db8bc56488c: avcodec/fic: clear slice_data [18:51] <michaelni> ubitux, there seem to be a few fate boxes where sub2video fails [18:51] <michaelni> iam not sure why, i tried to reproduce on one but there seems a random componet to it [18:52] <michaelni> bisect lead to nothing usefull [18:52] <michaelni> the issue also disappeared when i added a av_log() [18:53] <michaelni> and didnt come back after removing the av_log () ... [18:55] <ubitux> http://fate.ffmpeg.org/log.cgi?time=20140215165351&log=test&slot=x86_64-fre… [18:55] <ubitux> the diff is weird [18:55] <ubitux> wouldn't that be related to threading btw? [18:56] <ubitux> also, i didn't write the sub2video thing, Nicolas did [18:58] <michaelni> ill mail nicolas [19:01] <cone-776> ffmpeg.git 03Christophe Gisquet 07master:133b34207c2c: x86: float dsp: unroll SSE versions [19:07] <cone-776> ffmpeg.git 03Christophe Gisquet 07master:5a48caa34b0c: dca: replace some memcpy by AV_COPY128 [20:31] <J_Darnley> Dammit git! Where did those last three commit go? [20:34] <JEEB> git reflog? [20:35] <J_Darnley> Yes a quick search pointed me to that tool [20:37] <J_Darnley> Now I need to read how to get them back [20:37] <JEEB> depends on what exactly you want to do [20:37] <JEEB> if you just want to 'Cancel everything I did and go back to revision asfah!!' [20:37] <JEEB> then git reset --hard hash [20:38] <wm4> look at the reflog, look at the commit which look like what you need, and cherry pick them [20:38] <wm4> git reset --hard is a great way to wipe all your work [20:38] <JEEB> and yes, you can look the history with git log hash [20:38] <JEEB> and cherry-pick commits from it with git cherry-pick hash [20:38] <wm4> I'd just use gitk (gitk <hash>) [20:39] <wm4> gitk is pretty nice for getting an overview of the commit history etc. [20:39] <J_Darnley> Ah cherry-pick sounds like what I want [21:03] <cone-776> ffmpeg.git 03Christophe Gisquet 07master:9ae8e23188fc: dcadsp: scan coefficients linearly instead. [21:04] <cone-776> ffmpeg.git 03James Darnley 07master:91126dc481a4: flacdsp_lpc_template: add comment to explain the CONFIG_SMALL code [21:32] <cone-776> ffmpeg.git 03Vittorio Giovara 07master:dc971acf4aa3: h264_parser: use enum values in h264_find_frame_end() [21:32] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:f3a862935d68: Merge remote-tracking branch 'qatar/master' [22:02] <BBB> michaelni: you're just applying the idct patch for vp7 right, not the decoder itself [22:03] <BBB> michaelni: the decoder needs some more work and tuning, it slows down ffvp8 quite a bit, which isn't acceptable; the idct functions are all inlined (plus the vp8 versions have simd) so their speed is unaffected, so that patch itself is fine [22:03] <michaelni> didnt apply the decoder because of the speedloss mentioned in the therad [22:03] <BBB> ok, cool [22:03] <BBB> thanks [22:03] <BBB> I think in the dsp functions the if (vp7) is inlined so it's ok [22:03] <BBB> I didn't check 100% b/c all vp8 is x86 simd'ed anyway so it's not very relevant [22:36] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:b818637b8494: avcodec/hevc_ps: Use get_bits_long() in decode_vui() [23:21] <ubitux> anyway idea why libav wants to export rotation metadata as... packet side data? [23:22] <ubitux> it's injecting random side data in every packets instead of just a stream metadata (which has various benefits like being exported to ffprobe) [23:22] <ubitux> ...unless i'm missing something [23:23] <ubitux> it seems janne propose the metadata solution but it was rejected with "I do not think it's worthwhile adding a metadata entry too." [23:23] <ubitux> i'm pretty concerned about the side data overhead and uselesness [23:23] <nevcairiel> the reasoning was that it can change and stuff [23:23] <nevcairiel> kinda silly if you ask me [23:24] <ubitux> how can it change? [23:24] <ubitux> it's tkhd [23:24] <ubitux> it's parsed once [23:24] <nevcairiel> for mov sure [23:24] <nevcairiel> but you know, future formats! [23:24] <ubitux> and we have frame metadata for that if needed [23:24] <ubitux> why the hell would that be at packet level [23:25] <ubitux> filters will never access those side data [23:25] <ubitux> metadata has the benefit to be eventually populated up to lavfi to be rotated [23:26] <ubitux> well i guess i'll ask for a revert of that commit if it gets merged [23:29] <nevcairiel> the metadata approach is superior if you ask me, because I can get it right away after opening the file, and dont have to wait for the first frame to be demuxed, it works so much better in so many setups [23:29] <ubitux> what i don't understand is that no one on libav side seems to realize how insane it is, even after several patch iterations [23:29] <nevcairiel> (in fact it perfectly fit into my existing metadata reading function without any troubles) [23:30] <ubitux> and actually, the original patch was picked from ffmpeg, and then changed (NIH?) into this [23:30] <ubitux> i don't get it [23:31] <nevcairiel> like i said, someone complained that it could change mid-stream and the user should always get the up to date value, or something [23:31] <ubitux> lol [23:31] <ubitux> ok [23:31] <nevcairiel> not that i agree, but thats what i remember reading one time [23:32] <ubitux> was that on irc or ml? [23:32] <nevcairiel> irc probably [23:32] <nevcairiel> i read way less of their ml discussions [23:35] <ubitux> ah i actually just missed a discussion about that [23:36] <ubitux> it's indeed all about "future proof" rotation [23:36] <ubitux> lol that's so stupid [23:36] <ubitux> whatever [23:40] <iive> aren't there mechanism for lavf to signal change of parameters? [23:40] <iive> it happens a lot with dvb mpeg-ts. [23:40] <iive> isn't... [23:40] <ubitux> if the rotation happens to be frame specific, we could just add it in addition to the stream rotation metadata [23:40] <ubitux> in mov you would probably have both information anyway [23:41] <ubitux> there is really no point in trying to predict the future with insanity like this [23:41] <iive> unneeded flexibility is the mother of all bloat. [23:43] <cbsrobot> how can I run a specific fate test ? [23:43] <ubitux> make fate-foobar [23:44] <cbsrobot> thanks [23:44] <cbsrobot> is this documented ? [23:44] <cbsrobot> or am I blind [23:47] <ubitux> it's easily guessable by seeing the test running i guess [23:47] <ubitux> fate is all about make rules [23:48] <nevcairiel> there is also make fate-list to get a list of all targets which you can grep through for example [23:48] <cbsrobot> yeah I read that and I knew there was a way [23:48] <cbsrobot> I just did not know how it was done [23:48] <cbsrobot> now it's all clear [00:00] --- Sun Feb 16 2014

1 0

ffmpeg.log.20140215
by burek 16 Feb '14

16 Feb '14

[00:01] <Logicgate> Is there a way to lower the quality of the output when watermarking? [00:02] <znf> what format are you encoding to? [00:02] <Logicgate> it's mov in -> mov out. [00:02] <znf> codec? [00:02] <Logicgate> haven't specified any [00:03] <Logicgate> ffmpeg -i test.mov -vf 'movie=watermark.png [watermark]; [in][watermark] overlay=0:0 [out]' watermarked.mov [00:03] <znf> maybe that's your issue :-) [00:03] <Logicgate> that's what i'm using [00:03] <Logicgate> znf, possibly [00:03] <Logicgate> I want to multithread too if possible [00:03] <znf> well, you're re-encoding the video there, so try to figure out in what format you're encoding to [00:04] <Logicgate> is there a way to watermark without re-encoding? [00:04] <Geha3> When recording as ffmpeg -video_size 1024x768 -framerate 25 -f x11grab -i :0.0+0,0 output.flv , it record a second xserver. How to choose the first xserver ? [00:04] <znf> Logicgate, not that I know of. [00:05] <Logicgate> okay so znf, what do you mean by what format [00:05] <Logicgate> I'm re-encoding to MOV format [00:05] <Logicgate> the format doesn't change [00:05] <znf> No, you're not re-encoding to mov. [00:05] <znf> MOV is a container; [00:05] <znf> what does the ffmpeg output say? [00:06] <Logicgate> http://pastebin.com/Pj55snD6 [00:06] <Logicgate> Thanks for your help by the way znf [00:06] <Logicgate> I'm sorry I'm not that knowledgable about movie encoding. [00:07] <znf> ah, you're doing mjpeg -> libx264 [00:07] <znf> try: [00:08] <znf> ffmpeg -i test.mov -vf 'movie=watermark.png [watermark]; [in][watermark] overlay=0:0 [out]' -acodec copy -vcodec libx264 -preset ultrafast -crf 21 watermarked.mov [00:09] <Logicgate> still super slow [00:10] <znf> ffmpeg -i test.mov -vf 'movie=watermark.png [watermark]; [in][watermark] overlay=0:0 [out]' -acodec copy -vcodec mjpeg watermarked.mov [00:10] <Logicgate> I don't want to change it to libx264 [00:10] <Logicgate> It can be as low quality as possible [00:10] <Logicgate> I want the fastest codec possible [00:10] <znf> try that ^ [00:11] <znf> but that will make a huge video :) [00:12] <Logicgate> That's awesome! [00:12] <znf> if you want to make it look better, add -qscale 2 [00:13] <Logicgate> You are the man [00:13] <Logicgate> okay so can you explain to me why it defaults to libx264? [00:13] <znf> although -qscale 2 will result in ~16mbit/s of bitrate for a 720p video [00:14] <znf> *shrug* I guess that's hardcoded in ffmpeg [00:14] <Logicgate> video quality doesn't matter in this case. These are transcodes for video translation basically [00:17] <Geha3> Logicgate, libx264 -preset ultrafast is fast to encode [00:18] <znf> not on his EC2 instance, apparently [00:20] <Logicgate> Yeah it's not [00:20] <Logicgate> I'm using a small instance [00:20] <clever> Logicgate: how many files are you trying to watermark? [00:20] <Logicgate> only 2 cores [00:20] <Logicgate> clever, the quantity doesn't matter [00:20] <Logicgate> the movies are roughly 300mb in size on average [00:20] <clever> one option you can do to cheat [00:20] <Logicgate> and we need to watermark them under 5 minutes [00:20] <clever> if you have 20 files to watermark, you can spawn 20 small vm's [00:20] <Logicgate> including download -> watermarking -> re-uploading to bucket. [00:20] <clever> and get it done in 1/20th the total time [00:21] <Logicgate> that's an interesting approach clever [00:21] <clever> the total cost will be the same as running a single ec2 for 20 times as long [00:21] <Logicgate> Could I add multithreading to that ZNF? [00:21] <clever> (plus rounding up to the nearest 1h) [00:22] <Logicgate> clever, the ec2 instance is always up [00:22] <Logicgate> so it doesn't matter.. [00:22] <clever> ah [00:22] <Logicgate> it's a dedicated instance for that single purpose [00:22] <znf> Logicgate, it's already multi-threaded [00:22] <Logicgate> would there be a way to make it even faster [00:22] <clever> run top and hit 1 to enable per-cpu usage, and verify if its using both cores or not [00:22] <Logicgate> would a bigger instance make it faster? [00:23] <znf> what fps is it encoding to? [00:23] <znf> s/to/at/ [00:24] <Logicgate> hmmm I'll have to try again. Script running in background I can't see [00:24] <znf> You could try adding -threads [00:25] <znf> ie: -threads 4 [00:25] <Logicgate> cat /proc/sys/kernel/threads-max returns 26122 maximum threads [00:25] <Logicgate> :D [00:25] <Logicgate> could I add 100 threads? [00:25] <Logicgate> lol [00:25] <znf> but for mjpeg don't expect a huge speed boost, the difference for me between 1 thread and 4 threads is ~10fps [00:25] <clever> Logicgate: each cpu can only run 1 thread at a time [00:26] <Logicgate> right [00:26] <clever> so a dual core can only run 2 threads at once [00:26] <Logicgate> so I need more cores? [00:26] <clever> the rest have to wait their turn [00:26] <znf> yeah [00:26] <Logicgate> would having 16 cores be much faster? [00:26] <Logicgate> would it theoretically be 16 times faster? [00:26] <znf> could be [00:26] <znf> no [00:26] <clever> it would be maybe 8x faster then a dual core, at the same freq [00:26] <znf> multi-threading doesn't work that way :P [00:26] <clever> if your really lucky [00:27] <Logicgate> file size increases roughly by 1.5 times [00:27] <znf> I would rather run parallel processes of ffmpeg if you have more than 1 file [00:27] <Logicgate> 300mb files becomes 500mb [00:29] <Logicgate> I'm gonna try the libx264 again [00:30] <clever> znf: its doing one slice per thread? [00:31] <znf> clever, I couldn't explain it [00:31] <znf> but you can try it yourself [00:31] <znf> try to encode a file with -t 1, then -t 2 [00:31] <clever> i'm just thinking, if the file already has 2 slices (tophalf and bottomhalf) [00:32] <clever> and the watermark only covers the bottom half [00:32] <clever> why re-encode the top half?? [00:32] <Logicgate> jesus even worse [00:32] <clever> but you may need to modify the source to allow that [00:32] <Logicgate> 300mb file is almost 800mb!! [00:32] <Logicgate> What the hell [00:32] <clever> lol [00:32] <znf> Logicgate, yup, mjpeg is not exactly friendly in size; did you add -qscale 2 ? [00:33] <Logicgate> I'm adding it [00:33] <Logicgate> added -t 2 -qscale 2 and changed to libx264 [00:33] <Logicgate> the first line you gave me [00:34] <znf> nononono [00:34] <znf> -qscale 2 will produce even bigger files :> [00:35] <znf> -vcodec libx264 takes -crf as quality argument [00:35] <znf> crf 0 == lossless; crf 51 = crap quality [00:36] <Logicgate> holy shit! [00:37] <Logicgate> znf, the libx264 is way faster [00:37] <znf> it is? it's much slower for me :) [00:38] <Logicgate> i added -t2 [00:38] <Logicgate> with mjpeg it was 15+ minutes before [00:38] <Logicgate> with libx264 -> 1 minute [00:40] <Logicgate> fail [00:40] <Logicgate> -t 2 cutted it to 2 seconds lol [00:41] <Logicgate> -acodec copy -vcodec libx264 -preset ultrafast -crf 21 -threads [00:41] <Logicgate> that's what I have [00:41] <Logicgate> -acodec copy -vcodec libx264 -preset ultrafast -crf 21 -threads 2 [00:44] <znf> I said -threads 2 [00:44] <znf> not -t 2 [00:45] <Logicgate> <znf> try to encode a file with -t 1, then -t 2 [00:45] <znf> my bad, sorry [00:45] <Logicgate> what is the loweest quality possible [00:45] <Logicgate> 51? [00:47] <znf> yes [00:48] <Logicgate> okay, what else could make this faster? [00:48] <Logicgate> -acodec copy -vcodec libx264 -preset ultrafast -crf 51 -threads 2 [00:48] <Logicgate> this is where we're at [00:48] <Logicgate> I don't want the files to be 2 times the size. [00:49] <Logicgate> mjpeg seems to be almost 3 times the size [00:49] <Logicgate> would the be a different codec I could use? [00:53] <znf> Wouldn't know what codec to sugest; Getting both fast encoding AND small filesize is not that easy :) [00:53] <znf> plus, you seem constrained to .mov, which doesn't many codecs [00:54] <Logicgate> we can change the output container [00:54] <znf> what resolution are the videos? [00:54] <Logicgate> 640x360 [00:55] <Logicgate> i'm getting 100kb/s encoding, that's way too slow [00:56] <znf> don't look at the bitrate [00:56] <znf> look at the fps [00:56] <znf> bitrate is not relevant to speed [00:58] <Logicgate> 36 fps [00:58] <Logicgate> 46 fps [00:59] <znf> well, 46fps is encoding at almost 2x (if your video's frame rate is 25fps) [01:00] <Logicgate> hmmm [01:01] <Logicgate> isn't 69 the lowest quality for crf? [01:01] <znf> no, 51 is [01:01] <Logicgate> okay [01:01] <Logicgate> all right so should I go back to mjpeg? [01:02] <Logicgate> can we optimize mjpeg? [01:02] <Logicgate> for smaller file size? [01:02] <Logicgate> :D [01:02] <znf> try -qscale 30 [01:04] <Logicgate> is that the lowest quality [01:04] <znf> 32 is, I think [01:05] <Logicgate> lol [01:05] <Logicgate> seems a lot faster than libx264! [01:07] <znf> it is, it's just huge filesize [01:07] <Logicgate> so why does it double in size though [01:07] <Logicgate> watermarking adds 1 frame for ever frame? [01:08] <Logicgate> would it be faster to create a video of the watermark and join the 2 video streams? [01:08] <znf> no, it's simply that mjpeg doesn't really compress that well [01:09] <Logicgate> so ultimately I'm restrained by CPU and Codec capabilities [01:11] <znf> "normal" video codecs are "smart"; they don't create an image for every frame out there; video codecs have this concept of "key frames", whever every X frames a frame will contain the full image, then the next frames contain just enough data to smoothen the movement [01:11] <znf> not sure how to explain this, as english is not my native language [01:11] <znf> but with mjpeg and similar codecs, every frame is basically a keyframe, ie: contains the full image [01:11] <Logicgate> sI see [01:11] <Logicgate> so which codec would you suggest [01:11] <Logicgate> and which container [01:12] <znf> not sure, really, could try xvid in a mkv container? [01:12] <znf> libxvid [01:12] <Logicgate> could you give me the sample code [01:12] <Logicgate> so just change -vcodec to libxvid [01:12] <Logicgate> and output to filename.mkv [01:13] <znf> yyeah [01:13] <Logicgate> or does the input require to be in a different container? [01:13] <Logicgate> Because the input codec will always be Mjpeg [01:13] <znf> no, the input can be anything, ffmpeg takes care of that [01:13] <Logicgate> ok cool [01:16] <znf> Ah, here's an idea. [01:16] <znf> wmv1 [01:17] <Logicgate> wmv1 container? [01:17] <znf> .wmv [01:17] <znf> or .mkv, both should work [01:17] <Logicgate> ok [01:17] <Logicgate> why wmv1 [01:17] <znf> seems fast and produces relatively small files [01:18] <Logicgate> awesome [01:19] <Logicgate> codec name is wmv1 or libwmv1 [01:20] <znf> wmv1; could also try wmv2 [01:20] <Logicgate> any preset? [01:21] <znf> I have no idea how the wmv codec works [01:22] <Logicgate> hahahha [01:23] <znf> faster? better? [01:24] <Logicgate> haven't tried yet [01:24] <znf> -vcodec wmv2 -b:v 2M [01:26] <Logicgate> lol mjpeg 300mb is now 1gb and now finished yet [01:26] <Logicgate> what a joke [01:28] <Logicgate> Decoder (codec eia_608) not found for input stream #0:2 [01:28] <Logicgate> i get that [01:30] <znf> output to .mkv [01:30] <Logicgate> i am [01:30] <Logicgate> ./ffmpeg -i media/test.mov -vf 'movie=media/test.png [watermark]; [in][watermark] overlay=0:0 [out]' -acodec copy -vcodec libx264 -threads 2 media/test2.mkv [01:30] <znf> paste full output [01:31] <Logicgate> Stream mapping: [01:31] <Logicgate> Stream #0:0 -> #0:0 (h264 -> libx264) [01:31] <Logicgate> Stream #0:1 -> #0:1 (copy) [01:31] <Logicgate> Stream #0:2 -> #0:2 (? -> ssa) [01:31] <Logicgate> Decoder (codec eia_608) not found for input stream #0:2 [01:31] <Logicgate> oops [01:31] <Logicgate> ./ffmpeg -i media/test.mov -vf 'movie=media/test.png [watermark]; [in][watermark] overlay=0:0 [out]' -acodec copy -vcodec wmv2 -b:v 2M -threads 2 media/test2.mkv [01:31] <Logicgate> that's what i'm trying [01:32] <Logicgate> .wmv container works [01:32] <Logicgate> .mkv doesn't [01:32] <Logicgate> 78fps/s [01:41] <Logicgate> sorry [01:41] <Logicgate> znf [01:41] <Logicgate> still slow [01:41] <znf> how many fps...? [01:42] <Logicgate> 78 [01:42] <Logicgate> without bitrate specifications 100 fps [01:42] <znf> well, that's 4x the video speed [01:42] <znf> so, not sure how much faster you would expect [01:43] <Logicgate> 10x? [01:43] <Logicgate> haha [01:44] <znf> not unless you upgrade your instance [01:44] <Logicgate> i should try that [02:18] <Logicgate> znf, libx264 with ultrafast preset seems to be 80 fps [02:18] <Logicgate> wmv is only an extra 20 fps [02:59] <Logicgate> znf on a large instance i'm getting 350fps/s [03:02] <Logicgate> that's with 4 cores [03:05] <Logicgate> getting 600 fps with libx264 [04:34] <arb> I am playing an mp3 file and sound is coming only from one ear in the headphone, except the first few seconds when it's in both ears. Now I'm sure that my headphones are fine since playing other songs, sound comes in both ears. So is there an ffmpeg option to make the mp3 sound go to both headphone-ears? [05:26] <zap0> the mp3 is corrupted. [05:26] <arb> zap0: sure? You want the file? [05:27] <arb> Or tell me how to check [05:28] <zap0> ffmpeg doesn't know what headphones are. it only knows channels. [05:54] <bornpilot> So, I am working streaming video from a camcorder via hdmi into a bmd intensity pro card. When I capture the video I see two video images divided by thick green line. What would be causing this? [07:51] <__raven_> rtmp to ustream drops framerate extremely at 2mbit any experience with that? [12:12] <brihat> There are two stable releases of ffmpeg, 1.2.5 and 2.1.3 -- which should i download? [12:13] <JEEB> if you absolutely have to use a release, use the one from the newest branch [12:13] <brihat> both of the above were released mid-Jan [12:14] <JEEB> yes, but the other is for the 2.1 branch, and the other is for the 1.2 branch [12:14] <brihat> is 2.x the newest branch? [12:14] <JEEB> no, master branch is the newest :P [12:15] <JEEB> and then every now and then (relatively randomly) new release branches are made out of it [12:15] <JEEB> which is what those are [12:15] <brihat> what's the difference between 1.x and 2.x series? Has 1.x series reached end-of-life / maintenance-only release? [12:16] <JEEB> you generally shouldn't expect much updates the older the release is [12:17] <JEEB> basically the only reason to use an older release is if your application depends on older APIs and you haven't updated yet [12:17] <brihat> ok, so i'll download 2.1.3 then [12:18] <JEEB> also it seems like the first two versions are used for 'major' releases :P so you can't really say 2.x because 2.0 and 2.1 f.ex. are completely different branching points [12:18] <brihat> confusing [12:18] <brihat> though i get it [12:19] <JEEB> also if you're starting to develop with libav* I recommend you just start out with the current HEAD of master. Just check from fate.ffmpeg.org that the tests pass :) [12:19] <JEEB> (for the architectures that matter for you) [12:20] <brihat> not really, i just wanted a binary with --enable-gpl and --enable-nonfree, so i'll have to compile myself i guess [12:20] <JEEB> in that case too, you generally want to use the current HEAD of master :) [12:20] <JEEB> releases are only for people who want those [12:21] <JEEB> such concept is kind of hazy in the whole OSS multimedia sphere [12:21] <brihat> oh really [12:21] <brihat> i thought master branch is for development only [12:21] <brihat> so some things might be incomplete / boroken [12:22] <JEEB> x264 does not have releases, ffmpeg/libav have them but the attention various releases get with regards to backports can be /very/ varied [12:22] <JEEB> also FATE keeps most things under control [12:22] <JEEB> most people just use master downstream too :P [12:22] <JEEB> except distributions, because they usually /want/ releases [12:22] <JEEB> even if a release is just a random commit in master where tests pass :D [12:23] <relaxed> brihat: you can check http://fate.ffmpeg.org/ to ensure there's no issues with HEAD [12:23] <brihat> i dont want to download the entire Git repo, is there some tarball for a successful build in FATE [12:24] <JEEB> you can just grab a tarball from the gitweb [12:24] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=summary [12:24] <JEEB> the snapshot link [12:24] <JEEB> also git has a way to only clone the current commit [12:24] <JEEB> shallow clone was it? [12:24] <brihat> ok, thanks for the link [12:24] <relaxed> or click on the REV link on fate and then snapshot on the git page for the specific version [12:25] <JEEB> git clone --depth 1 [12:25] <JEEB> would get the current HEAD [12:25] <JEEB> and HEAD only [12:26] <brihat> alright that works too [12:26] <brihat> i just followed relaxed's advice and got a snapshot for a specific version from Fate [12:26] <brihat> thanks guys [12:27] <relaxed> brihat: have a look at https://trac.ffmpeg.org/wiki/UbuntuCompilationGuide too [12:27] <JEEB> do note that stuff can be borked for specific archs only [12:27] <JEEB> so unless you have MIPS or ARM or something [12:27] <JEEB> that doesn't really interest you :) [12:27] <brihat> i'm on x86_64 ubuntu, fate shows all-green [12:27] <JEEB> :) [16:44] <halloah> hi i am getting an error not found when there is a ' in the filename [16:45] <JEEB> escape it according to your command line system's rules [16:46] <halloah> well it takes the path from a java file getter box [16:47] <halloah> a java open file box [16:47] <JEEB> still, exactly what I said [16:47] <JEEB> escape it and it will work [16:47] <JEEB> how to escape depends on the system [16:47] <halloah> well i try to find how to do that thanks [16:47] <halloah> have a good day [17:31] <__raven_> how to use rtmp with udp OR how to increase tcp ack window? [18:33] <JingleBell> i am getting a problem with that file name and i don't know why ""j:/f/ffmpeg/bin/ffmpeg.exe" -i "Les Clowns Tueurs venus dailleurs Fr.avi" not found !!! [18:34] <JingleBell> no such file or directory [18:45] <halloah> i can't open files with 2 spaces in the name , any idea ? [18:46] <sacarasc> Even if you do "file wibble.mkv"? [18:47] <klaxa> halloah, still the java thing? answer is still string escaping :| [18:48] <halloah> i thought the problem was the ' charachter but it was the 2 spaces in the name [18:49] <halloah> so i don't know if it's possible to make ffmpeg open those files with 2 spaces after each other in the name [18:49] <halloah> without renaming those files ... [18:49] <halloah> with one space it works with 2 spaces after each other it doesn't work [19:06] <zurell> can anyone help with ffmpeg on Mac for making a movie out of sequence of still images? [19:06] <zurell> I'm struggling to tell ffmpeg which images to use [19:07] <zurell> Image names are G0011302.JPG ... G0016302.JPG [19:08] <zurell> I tried following command line: ffmpeg -f image2 -i G001%d.jpg -vcodec libx264 -vpre hq -crf 22 video.mp4ls [19:08] <zurell> but get an error message: [image2 @ 0x7fcb03804a00] Could find no file with with path 'G001%d.jpg' and index in the range 0-4 [19:08] <zurell> G001%d.jpg: No such file or directory [19:10] <halloah> can't find any escape code working ... [19:11] <halloah> use a full path or move the files to the ffmpeg directory [19:21] <zurell> halloah full path to the images? [19:22] <halloah> to a video file [19:23] <halloah> the input video file [19:23] <sacarasc> zurell: You'll have to use bash globbing, I think. [19:23] <zurell> halloah my input is a numer of images [19:23] <halloah> one space is ok or many but not after each other is ok, many spaces after each otehr doesn't owrk [19:23] <sacarasc> zurell: https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images… [19:24] <halloah> yes zurell it's the same thing [19:24] <sacarasc> halloah: Does it work outside of java? [19:24] <halloah> add the path to the images or move them to ffmpeg dir [19:24] <halloah> no sacarasc it doesn't work out of java [19:24] <halloah> same problem [19:25] <halloah> if i put many spaces after each other anywhere in the path it doesn't work and i tried all escaping codes i know [19:25] <zurell> sacarasc thanks. That link was helpful. It seems to work now :) [19:25] <sacarasc> \o/ [19:44] <Logicgate> hey is there a way to detect aspect ratio? [19:44] <Logicgate> here's my problem [19:45] <Logicgate> I need to be able to take videos that are 640x360 and resize them to 480x480 keeping the aspect ratio [19:45] <Logicgate> 480x480 is the video format for vine [19:45] <Logicgate> Can I make it so the videos get automatically padded? [19:45] <Logicgate> without having to calculate the padding [19:48] <tsjiller> Logicgate: something like this? http://superuser.com/questions/547296/resizing-videos-with-ffmpeg-avconv-to… [19:48] <Logicgate> yes [19:49] <__raven_> how to use rtmp with udp OR how to increase tcp ack window for librtmp? [19:49] <Logicgate> tsjiller, I only really need it for height padding [19:50] <Logicgate> since the width is always going to be 480 [19:50] <tsjiller> depending on the height, you will have to add stuff on either side [19:50] <tsjiller> if it's too tall you will have to pillar box it [19:51] <tsjiller> unless you want to cut it [19:51] <Logicgate> yeah, that's never going to happen [19:52] <Logicgate> it'll aways be 480 width by a smaller height [19:52] <Logicgate> isn't there a way to automatically pad videos? [19:53] <Logicgate> okay so let's say I want my container to be 480x480 and the video provided 480x360 [19:53] <Logicgate> how can I just make the video provided fit in there? [19:53] <Logicgate> do I really need to add padding? [20:28] <__raven_> how to use rtmp with udp OR how to increase tcp ack window for librtmp? [20:37] <klaxa> rtmp does not support udp [20:49] <__raven_> klaxa: how to solve a tcp window problem? [20:49] <__raven_> keyword "dropping framerate" [20:49] <klaxa> i don't know, sorry [20:49] <klaxa> maybe rtmp is not the right protocol for your usecase [21:20] <bornpilot> attempting to capture video stream from a camcorder via the hdmi out. I can cap\\\\\\\\\\\\\\\\\\\\\\\\\ [21:20] <bornpilot> \ [21:20] <bornpilot> sorry about that. [21:21] <bornpilot> I can capture the stream however after about 650 frames it just stops. sometimes I get an invalid buffer size error [21:24] <bornpilot> what do you mean by do not paste your scripts? [21:26] <bornpilot> http://pastie.org/8737173 [21:29] <bornpilot> So, this was what I received on my last test [21:52] <bornpilot> flogger here is the full output using -loglevel debug this on does have the yadif filter however the results aper the same without it. [21:52] <bornpilot> http://pastebin.com/sYLP3yCN [22:02] <fragamus> hey [22:02] <fragamus> i really need some help [22:06] <Logicgate> fragamus, with what [22:06] <fragamus> i am trying to make a program that emits synthetic video for mplayer to suck up [22:07] <fragamus> in other words I have an algorithm that will spit out video and pipe it into mplayer [22:07] <fragamus> i need to know *any* format [22:07] <fragamus> the docs are always vague in some way [22:08] <fragamus> can you suggest a format, and describe [22:08] <fragamus> 1. the format [22:08] <fragamus> 2. the mplayer command that can suck it up from a pipe [22:09] <fragamus> I want to use one of the YUV formats [22:09] <fragamus> I can emit my samples in any prescribed order [00:00] --- Sun Feb 16 2014

1 0

ffmpeg-devel.log.20140214
by burek 15 Feb '14

15 Feb '14

[00:01] <Daemon404> Skyler_, http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=23a8c63452009df21b3f18… [00:02] <cone-12> ffmpeg.git 03mrlika 07master:e2707a7cf741: avformat/mpegts: DVB subtitles multiple languages support [00:44] <cone-12> ffmpeg.git 03Lukasz Marek 07master:db403023c016: lavd/opengl_enc: add gray8/16 formats [00:44] <cone-12> ffmpeg.git 03Lukasz Marek 07master:db4a704482b0: lavd/opengl_enc: implement uncoded frame callback [00:44] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:70acb1515912: Merge remote-tracking branch 'lukaszmluki/master' [01:20] <JEEB> welp, sent that e-mail before running make fate-utvideoenc on this side. Aand this thing decided to rebuild everything in lavf it seems :| Oh well, at least lavc isn't completely rebuilt [01:20] <JEEB> not that I expect the tests to fail [01:23] <JEEB> yup [01:23] <JEEB> utvideoenc tests pass [01:23] <JEEB> all's fine [01:23] <JEEB> should add some multi-slice tests later [01:40] <cone-12> ffmpeg.git 03Janne Grunau 07master:f795a8a8bf5e: h264: make context_count unsigned [01:40] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:84873794ad92: Merge commit 'f795a8a8bf5e312dad2c2829c543b9d309376ca1' [02:05] <cone-12> ffmpeg.git 03Janne Grunau 07master:8a2250344b19: jv: detect partial packets in the demuxer [02:06] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:abb6821e43e7: Merge commit '8a2250344b19a343d830a902dbcf4c0b929ea49b' [02:33] <cone-12> ffmpeg.git 03Janne Grunau 07master:60e6cecf9bc7: configure: avserver does not need $ldl [02:33] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:fd982f2b40b8: Merge commit '60e6cecf9bc7d6a238e6b316da52edcc6d1ef7f8' [04:02] <cone-12> ffmpeg.git 03Janne Grunau 07master:d261719319a5: configure: do not link libraries against program-specific dependencies [04:02] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:8dc5a46466de: Merge commit 'd261719319a505e1716e8b52fc955bef0503ff96' [04:57] <cone-12> ffmpeg.git 03Janne Grunau 07master:73eca738acd0: mpeg12dec: do not add stereo3D side data to a non-existing frame [04:57] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:abe3f79d62f4: Merge remote-tracking branch 'qatar/master' [05:22] <cone-12> ffmpeg.git 03Lukasz Marek 07master:1e5cb426c687: lavd/avdevice: add param to create window buffer message [09:00] <t355u5> Is it on purpose that ffmpeg -version in git gives this output 'ffmpeg version 2.1.git' instead of the usual 'ffmpeg version N-60836-g8bfa5a5'? This really makes it hard to differentiate the binaries. Can this be changed back? [11:26] <ubitux> Daemon404: so you didn't change the AVERROR into EXTERNAL? [12:39] <pross-au> BBB: if you are about, what VP8 streams are you using for benchmark & profiling [13:23] <michaelni> t355u5, ffmpeg -version should print N-60597-g1e5cb42, try a fresh checkout in a seperate directory [13:25] <t355u5> michaelni: will try that, thx [13:32] <cone-526> ffmpeg.git 03Luca Barbato 07master:f8c507f44b4c: h264: Refactor ff_h264_decode_ref_pic_list_reordering [13:32] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:5cbd7ce016ad: Merge commit 'f8c507f44b4c994895fc7ad954f009f61de69b1c' [13:36] <JEEB> which does FFmpeg prefer when talking about v2 patches? in-reply-to or a new thread? [13:39] <BBB> pross-au: parkjoy is ok, I don't really have a fixed one for vp8 [13:40] <BBB> pross-au: there's also sintel (we used that and parkjoy for the initial ffvp8 announcement post on jason's blog) [13:40] <BBB> JEEB: I think whichever you prefer, most of us parse our mail inbox manually so we will read it regardless [13:42] <JEEB> I don't really have a preference, and I'm already in-reply-to'ing @ Libav, so I guess I'll do that? [13:45] <BBB> sure [13:45] <cone-526> ffmpeg.git 03Vittorio Giovara 07master:73e8fab31dc1: h264: print values in case of error [13:45] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:60b46a00c62d: Merge commit '73e8fab31dc19c4371499e612856accbc00b2820' [13:45] <pross-au> thanks. i have been using those, but they seem rather short given the huge performance gains since the initial ff VP8 work. i will look for something longer. [13:50] <ubitux> hi durandal_1707 [13:50] <ubitux> did you see the ticket for you? [13:50] <ubitux> :) [13:50] <BBB> pross-au: I thought sintel was long? [13:52] <BBB> it's 1253 frames, is that enough? [13:52] <BBB> else get etv5k from ubitux and encode it yourself, that works [13:52] <ubitux> 'want a vp8 encode? [13:53] <pross-au> even on my old core2, sintel decoders in 3.something seconds (mt), or 13s (single thread) [13:54] <BBB> 13s is fine [13:55] <BBB> anyway most vp7 patches look good, I'd like the actual vp8.c touching code to be made such that the condition is inlined though, so vp8 doesn't get slower [13:57] <pross-au> over several runs, the user time variance here on a 13s decode is ~0.5% [13:57] <BBB> that seems ok [13:58] <BBB> (you know it took me 5 tries before I realize your patch [5/6] vp7 decoder is buried under [0/6]) [13:58] <BBB> so I just saw it for the first time [13:59] <BBB> pross-au: what is copy_frame()? [13:59] <pross-au> no worries. so you suggest moving the shared functions to vp78_template.h/c and inlining them [13:59] <BBB> that seems really ugly, can't you use av_frame_ref()? [14:00] <BBB> I guess you could template them, that's one way, yes [14:00] <pross-au> copy_frame copies the AVFframe. there is probably an avutil equiv [14:00] <BBB> why copy and not ref? [14:00] <pross-au> #defines will be too messy! [14:00] <BBB> it's ok, life is messy [14:00] <pross-au> the copy is needed because the fade operation is destructive. [14:01] <pross-au> vp8 is relatively mess-free [14:01] <pross-au> s/is/was/ [14:02] <Skyler_> fade operation? [14:02] <BBB> what is vp7_calculate_mb_offset? [14:02] <BBB> vp7 has a fade? [14:02] <BBB> so wait, you write a copy of the frame and then re-write all pixels post-fade? [14:02] <pross-au> Skyler_: the vp7 codec has a 'fade' operation that adjust the lum of the previous frame [14:03] <BBB> that seems odd, why not just do the fade without the double store? [14:03] <pross-au> BBB: that would make sense. [14:03] <BBB> how are vp7_decode_mvs and vp8_decode_mvs different? [14:03] <pross-au> vp7_calculate_mb_offset. ugh, there are bugs in VP7 that we must emulate [14:03] <Skyler_> does fade replace the original frame in the reference buffer? [14:04] <Skyler_> or does fade only affect it for the current frame, and not again? [14:04] <BBB> do segmentation features in vp7 require an error and return instead of a warning and continue? [14:04] <BBB> if (s->vp7) { //FIXME: clueless as to why VP8 does not require this [14:05] <BBB> we memset in the idct [14:05] <BBB> so all data post-idct and on init is always zero [14:05] <BBB> you probably want to do that in vp7 also - it's faster [14:05] <Skyler_> http://ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154447.html ugh, it's missing the patch, I wanted to look at it [14:05] <BBB> Skyler_: it's there, but gmail orders it in the same thread as [0/6] [14:06] <Skyler_> I was looking at the archives [14:06] <BBB> pross-au: it might be that the memset is required when you predict but the block is skip so you don't use the coefficients; so skip the dc predict if skip=true, so you don't need to zero [14:06] <BBB> pross-au: that's about all the comments I have so far [14:06] <pross-au> BBB: VP7 mv prediction can go far back as (-2,-2) relative to the current macroblock. the decoder doesn't guard this properly. e.g. when mb_x=0, an xoffset -1 is denied, but xoffset -2 is permitted. [14:07] <pross-au> idct: great that solves that riddle [14:07] <BBB> Skyler_: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154452.html [14:07] <cone-526> ffmpeg.git 03Vittorio Giovara 07master:3a0576702825: h264: store current_sps_id inside the current sps [14:07] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:99b12357f47e: Merge commit '3a0576702825423abecb32627c530dbc4c0f73bc' [14:07] <Skyler_> ohhhh there it is, thanks [14:08] <BBB> Skyler_ will likely have more comments, but as I said, the inlining of if (vp7) is the most important, that'll remove most of the speed impact on vp8 [14:08] <BBB> it will make the binary slightly bigger but I don't think anyone cares about that [14:08] <BBB> chrome is like 100s of MBs so a few extra kb for ffmpeg.exe is irrelevant [14:08] <BBB> brb [14:08] <pross-au> Skyler_: the fade (if enabled in the header) is applied to the previous frame. [14:09] <Skyler_> I guess doing the weighting in the MC would be less efficient than copying the whole frame... [14:10] <BBB> looks like fade doesn't replace the reference [14:10] <BBB> if I can see [14:10] <BBB> anyway, brb [14:10] <pross-au> well i have ONE sample with fade. [14:11] <j-b> do you have enough VP7 samples? [14:11] <pross-au> hardly worth optimising that case [14:11] <j-b> I thought it was very rare [14:11] <pross-au> yeah i found a huge archive on the web. non-english :) [14:11] <kierank> lol [14:12] <j-b> crazy :) [14:12] <JEEB> I remember around 2007 a Japanese IRC friend of mine had put some encodes for this new VP7 format up for me [14:12] <JEEB> I had downloaded them, too [14:12] <pross-au> conspiracy, 911, cia, allah stuff [14:12] <cone-526> ffmpeg.git 03Vittorio Giovara 07master:15210354cf27: h264: drop outdated comments [14:12] <JEEB> then didn't take long for it to get bulldozed over by x264 [14:12] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:a7eb93b3671f: Merge commit '15210354cf27cf4e24d91f84d66cf471511ce718' [14:13] <JEEB> too bad the guy didn't have the samples any more :< [14:13] <Skyler_> there's still a public free vp7 encoder isn't there, right? [14:13] <pross-au> yes [14:13] <JEEB> the vfw one most probably, yes [14:13] <pross-au> archive.org [14:13] <JEEB> :) [14:14] <pross-au> the old on2 site with all the downloads is no more. but archive.org has captured many of the exe [14:14] <durandal_1707> ubitux: what happens if you at line 518 change < to <= ? [14:15] <ubitux> what file? [14:15] <Skyler_> someone probably already said this but read_mv_component should be templated into vp8/vp7 versions [14:16] <Skyler_> rather than being passed s->vp7 [14:16] <durandal_1707> ubitux: libavfilter/af_compand.c [14:16] <Skyler_> er, decode_splitmvs should I guess [14:16] <merbanan> JEEB: do you have any UMD movies ? [14:16] <JEEB> yeah [14:16] <pross-au> Skyler_: okay [14:16] <JEEB> merbanan, do you need a full dir structure or you're OK with just the MPEG-PS? [14:16] <ubitux> durandal_1707: line 518 is EOF [14:16] <ubitux> durandal_1707: or i'm missing sth? [14:16] <merbanan> JEEB: the mpeg-ps [14:16] <JEEB> k [14:17] <merbanan> JEEB: or does it already work playing those files ? [14:17] <JEEB> merbanan, http://fushizen.eu/u/jeeb/derp/00002.MPS [14:17] <Skyler_> + } else \n if (s->segmentation.update_map) { [14:17] <JEEB> the audio doesn't get found [14:17] <JEEB> the video works JustFine [14:17] <Skyler_> nitpick but I think we usually drop the \n there? [14:17] <ubitux> (yes) [14:17] <merbanan> JEEB: MUST BE FIXED [14:17] <JEEB> http://up-cat.net/p/dcaccb79 [14:18] <merbanan> the world has been waiting for so long .... [14:18] <JEEB> which stream it is gets pretty obvious as looking at the output of that bbdmux thing :) [14:18] <cone-526> ffmpeg.git 03Vittorio Giovara 07master:304e916a92bc: h264_sei: name buffering period type consistently [14:18] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:1d91af5abae8: Merge commit '304e916a92bc17385a485bec2f957e192257ddb6' [14:18] <durandal_1707> ubitux: 158 :) [14:18] <JEEB> also I tried to parse the packet it begins with, but that seems to be malformed or something? [14:18] <JEEB> (in a hex editor) [14:18] <JEEB> or I'm just failing at parsing MPEG-PS by hand, har har har [14:19] <JEEB> also it seems like UMD videos were encoded with the same early'ish H.264 encoders that brought us the blu-rays with the full range flag on :) [14:19] <ubitux> durandal_1707: testing equality on fp? [14:19] <ubitux> durandal_1707: still failing btw [14:19] <durandal_1707> hmm, you have sox installed? [14:21] <JEEB> merbanan, I hope you will have more luck with lavf/mpeg.c than I had :) [14:21] <merbanan> JEEB: we'll see what we can extract, getting lavf to demux the stream shouldn't be that big a problem [14:21] <merbanan> the smaller stream should be the subtitles [14:22] <JEEB> I should probably dump my spiderman UMD, too [14:22] <cone-526> ffmpeg.git 03Vittorio Giovara 07master:066ad249843b: h264_sei: reorder headers [14:22] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:a062bee1c127: Merge commit '066ad249843bde656265b59110c2521e2b1ce131' [14:23] <Skyler_> wow. I'm surprised by how... undifferent vp7 is from vp8 [14:25] <ubitux> durandal_1707: no but i can install it [14:25] <ubitux> durandal_1707: ok now it's installed [14:25] <pross-au> the on2 engineers have pioneered the tick tock approach to codec manufacturing. 3->4, 5->6, 7->8, 9->... [14:26] <nevcairiel> what was it you said, its vp8 with less features and more bugs? [14:26] <durandal_1707> ubitux: now try to see if with same arguments and sample you get overread.. [14:27] <pross-au> yep [14:27] <BBB> Skyler_: pross-au: I think the whole sequence of calls all the way down from vp8_decode_frame should be templated [14:28] <BBB> (since there's just so many if (vp7)s in there that are per-mb) [14:28] <Skyler_> I wonder if it'd be easier to make a template file and include it in two separate c files or something. that much templating feels ugly either way, I guess [14:29] <pross-au> should there be only vp8.c, or move common stuff to vp78_template spilt in two [14:30] <ubitux> durandal_1707: i have no idea how sox works :) [14:30] <BBB> Skyler_: that would work yes [14:30] <ubitux> durandal_1707: can you provide something i can copy paste? [14:30] <BBB> but I don't mind how it's templated, as long as vp8 doesn't get significantly slower :-p [14:30] <BBB> bbl work [14:32] <pross-au> the upside, this approach will also speed up vp7, for all 3 of its users [14:40] <durandal_1707> ubitux: perhaps you could try random thing from sox manual [14:42] <ubitux> durandal_1707: i think i'll work on sth else instead [14:51] <durandal_1707> what you said? :) carry on! [14:54] <ubitux> durandal_1707: i prefer if you fix your own bug ;) [14:54] <ubitux> i don't mind testing for you ofc [14:55] <durandal_1707> np [14:57] <pross-au> hmmm, there are more vp7 torrents, than there are vp8 and vp9 combined. [14:58] <nevcairiel> who puts stuff in vp7 [14:59] <cone-526> ffmpeg.git 03Diego Biurrun 07master:f1f42cfc6680: build: Do not pass HTML snippets and stylesheet as input to Doxygen [14:59] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:2fd0b5bd60b3: Merge commit 'f1f42cfc66804907d1df9231469e4296472bb0f5' [15:01] <pross-au> on2 [15:01] <nevcairiel> then the other questions, who torrents that [15:03] <durandal_1707> i hope it is something useful [15:05] <JEEB> vp7 used to have some use for a while, but it surely didn't take long for everyone and their dog to notice that using x264 was a much better alternative [15:05] <JEEB> on the other hand, with vp8/9 it's mostly troll torrents [15:08] <ubitux> JEEB: why? isn't vp9 decoder good enough now? [15:08] <ubitux> :) [15:08] <JEEB> oh the decoder is :) [15:08] <ubitux> libvpx, even though it's slow, should provide better results that x264, isn't it? [15:09] <JEEB> I haven't tested it lately, but that's possible since the format seems better than AVC [15:09] <durandal_1707> is James Darnley here? [15:09] <JEEB> it's J_Darnley [15:10] <durandal_1707> J_Darnley: why gpl for flac asm? [15:14] <kierank> ubitux: that's quite a contentious issue [15:14] <kierank> but on paper yes [15:16] <pross-au> 'tuning' [15:23] <cone-526> ffmpeg.git 03Diego Biurrun 07master:19d3127867f0: doxygen: Set EXAMPLE_PATH from within doxy-wrapper.sh [15:23] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:cbf09bb63f31: Merge commit '19d3127867f001d007f98bc8c5a85c5409abf788' [15:27] <J_Darnley> durandal_1707: I greatly prefer the GPL [15:28] <J_Darnley> And on an optional bit of code like this, it doesn't make much difference [15:28] <J_Darnley> To the user of library that is [15:29] <cone-526> ffmpeg.git 03Diego Biurrun 07master:3a26ccbf0d9f: build: doxy: Include code examples in Doxygen documentation [15:30] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:71052d85c16b: Merge commit '3a26ccbf0d9f806d067e76a3f484170abecb36b3' [15:30] <kurosu_> actually, I was thinking naming a file flac_dsp_gpl was bothersome and %if CONFIG_GPL could have achieved the same [15:31] <kurosu_> but then there is the license in the file header [15:31] <kurosu_> so people wishing to write further lgpl flac dsp will probably need another file with a different header [15:31] <kurosu_> that and it's pesky and bothersome for people that should use their time for better things [15:32] <J_Darnley> There is the other James' flac dsp contributions in a non-gpl file [15:34] <J_Darnley> In my opinion you should be very clear about the license of a file in a mixed project like this [15:37] <cone-526> ffmpeg.git 03Diego Biurrun 07master:0b9716c45568: doc/examples: misc Doxygen markup improvements [15:37] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:fba1592f3550: Merge remote-tracking branch 'qatar/master' [15:37] <durandal_1707> J_Darnley: there is code that does same thing but in another license? [15:38] <J_Darnley> No [15:38] <J_Darnley> His is for the decoder [15:38] <J_Darnley> Mine is for the encoder [15:38] <Daemon404> ew, we're adding gpl-only asm? [15:38] <Daemon404> how lovely [15:39] <Compn> you can still sell it , just have to provide source bro [15:39] <kurosu_> why not? I have myself been a pain some years ago and requested a (3-clauses, iirc) BSD license [15:39] <durandal_1707> like it matters..... [15:39] <Compn> china doesnt care for licenses [15:40] <Daemon404> 3-clause bsd doesnt cause any issues [15:40] <kurosu_> yea, actually less, because no configure worries and so on [15:41] <kurosu_> to me, it just means anyone is free to use that code however he likes [15:41] <Daemon404> i, myself, dont subscribe to the rms-style of freedom [15:41] <durandal_1707> we should really switch to AGPL and make big monez [15:41] <kierank> that's what gpac wanted [15:41] <Compn> oh no not another license bikeshed :P [15:41] <kierank> iirc use of AGPL means I would have to stick a notice on all my tv channels [15:41] <J_Darnley> I don't go quite that far either. I'm using Windows after all. [15:41] <Daemon404> gpac can do what they want [15:42] <Daemon404> i dont use their broken software [15:42] <kierank> Daemon404: gpac want a cloud gpl [15:42] <kierank> Daemon404: so people who use it in the cloud need to release source [15:42] <Daemon404> maybe it would teach them to use better software [16:05] <JEEB> talking of GPAC, I just sent this PR to l-smash :) https://github.com/l-smash/l-smash/pull/14 [16:15] <cone-526> ffmpeg.git 03Werner Robitza 07master:1ffac25d31eb: doc/filters/histogram: copyedit for grammar [16:23] <wm4> hilarious when I have to add workarounds for broken files, and then find out that these files were generated by ffmpeg [16:23] <JEEB> :D [16:23] <JEEB> that happens at times [16:23] <j-b> wm4: this never happens [16:23] <j-b> JEEB: at times? [16:24] <wm4> apparently this file was created by transcoding DVB to vobsub [16:24] <j-b> A lot of MKV produces by ffmpeg were not conform (maybe it is fixed). Ogg and ASF were not better [16:24] <JEEB> exactly what I mean :) [16:24] <j-b> TS is broken, but that's normal, it's TS [16:25] <JEEB> yeah, only kierank has given enough love to it [16:25] <nevcairiel> its pretty usual for muxed files to fail, especially MKVs, because it just tries to mux anything, but hardly knows about all the special ways to mux things [16:26] <JEEB> yeah, it has the generic route [16:26] <nevcairiel> I use ffmpeg TS muxer for HLS, seems to work pretty nice on a wide variety of devices so far, so i can't complain :d [16:26] <JEEB> yeah, nothing seems to be strict in that area [16:26] <JEEB> so you're more or less OK :) [16:26] <wm4> I have to say that I'm impressed that transcoding dvb sub to vobsub works at all [16:26] <wm4> but ffmpeg forgot to set the resolution [16:26] <wm4> and also wrote random crap into the idx file (???) [16:26] <wm4> idx file aka matroska vobsub codec data [16:31] <kurosu_> wm4: some people call this "securing opportunities for work in the future" (old joke about paid jobs, may not apply here perfectly) [16:32] <wm4> maybe that applies to stuff like apple's highly expensive applications writing mov files that violate apple's own spec [16:33] <kurosu_> is there a way to do s/Libav/ffmpeg during a cherry-pick ? [16:33] Action: ubitux always chills when hearing about vobsub in ffmpeg [16:34] <JEEB> wm4, quicktime violates its own file format's spec all the time :P [16:34] <ubitux> wm4: that resolution is probably not exported from the dvb sub [16:37] <j-b> btw, what does AppleRottenFruit use for subtitles now? [16:39] <wm4> ubitux: I think dvb and pgs set the resolution on the first subtitle packet or somewhere later [16:39] <JEEB> I don't think they ever moved away from their timed text? [16:40] <Daemon404> hey! safari can use webvtt! [16:40] <JEEB> ÙcWDc [16:41] <JEEB> (that said, webvtt in its simplest is just srt, so I guess it's not The Satan yet) [16:41] <Daemon404> srt is actually very very annoying and error prone to parse [16:41] <Daemon404> despite looking simple [16:41] <Daemon404> :V [16:42] <JEEB> to quote a certain famous singer, "You're the Devil in Disguise" [16:55] <durandal_1707> the srt? [16:56] <Compn> j-b : it looks like you need a plugin to deal with subtitles for final cut pro, so it converts an srt to timed text [16:57] <Compn> http://documentation.apple.com/en/finalcutstudio/workflows/index.html#chapt… [16:59] <Compn> j-b : also , heres how much apple cares about documentation , http://www.apple.com/quicktime/tutorials/texttracks.html has been 404 for years. [17:00] <Compn> hey look, google and apple opensourced it [17:00] <Compn> http://www.opensource.apple.com/source/WebCore/WebCore-7536.30.2/html/track… [17:00] <Compn> whatever the heck that is [17:02] <Compn> ffmpeg site:opensource.apple.com [17:02] <Compn> neat [17:03] <Compn> webkit stuff [17:04] <Daemon404> hey kierank [17:04] <Daemon404> http://www.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper_December_2… [17:04] <Daemon404> did oyu know ffmpeg made it into their latest whitepaper [17:05] <Compn> ehe i saw that a while back [17:05] <Compn> they should have just said 'ffmpeg sucks' [17:05] <Daemon404> some of their authorized products use ffmpeg for prores [17:06] <ubitux> :D [17:06] <Compn> the authorized software 3rd parties or apple stuff itself ? [17:06] <ubitux> haha [17:06] <Daemon404> former [17:06] <Daemon404> duh [17:07] <Compn> is our decoder/encoder faster than apples ? [17:07] <Compn> i forgot benchmarks [17:08] <kierank> Daemon404: not true [17:08] <kierank> what authorised stuff uses ffmpeg [17:09] <Daemon404> hmm maybe i was mistaken [17:09] <Daemon404> i thought i spotted a few that did [18:01] <Daemon404> i see there's an influx of really dum libx265 questions on the user ML... [18:01] Action: Daemon404 is luckily not subscribed [18:10] <J_Darnley> Daemon404: whuch user list? x265's? [18:11] <Daemon404> ffmpeg's [18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:5df2a502f214: ffserver: avoid useless substitution [18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:ba6186d6eb31: ffserver: factor out connection closing from handler [18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:35e525b73263: ffserver: fix some comments [18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:720530e52aec: ffserver: cosmetics [18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:87079bd055e3: ffserver: merge RTSP's teardown & pause routines [18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:9ed876ac92b9: MAINTAINERS: add myself as ffserver maintainer [20:52] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:68a959cb2717: avcodec/utils: improve guess_correct_pts() by considerng mixed dts/pts use caused by NOPTSs [20:52] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:480af3a35ce3: avformat/utils: skip the MPEG-2 style dts/pts code for HEVC [20:59] <J_Darnley> fg [21:06] <durandal_1707> is there way to transfer year-month-day time to pts? [21:21] <Compn> LOL [21:22] <Compn> i picked random sample in sample repo and its porn :\ [21:22] <reynaldo> Compn: \o/ [21:22] Action: Compn picks other sample [21:22] <durandal_1707> Compn: you already watched it.... [21:22] <reynaldo> out of pure scientific interest, what sample was that? [21:22] <Compn> durandal_1707 : yes but should i post it to the list asking people to test it ? [21:22] <durandal_1707> scientific? [21:23] <Compn> reynaldo : http://samples.ffmpeg.org/MPEG1/mpeg_demuxer_crash.mpg [21:23] <Compn> innocent looking name.... :P [21:23] <reynaldo> durandal_1707: sure, I was to make sure it playbacks ok [21:23] <reynaldo> was/want [21:25] Action: Compn picks zelda commercial instead [21:30] <Compn> libavformat version 55.30.100 (internal) [21:30] <Compn> https protocol not found, recompile with openssl or gnutls enabled. [21:30] <Compn> urgh [21:36] <Compn> no native https ? :P [21:36] <cone-526> ffmpeg.git 03Derek Buitenhuis 07master:41836c4e306e: libx265: Fix use of uninitialized input picture [21:36] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:374576d6ee68: Merge commit '41836c4e306e572ecf80d5a714aaec532c7ece60' [21:37] <cone-526> ffmpeg.git 03Derek Buitenhuis 07master:4127e6aeb6e9: libx265: Remove redundant default param call [21:37] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:92225877cee1: Merge commit '4127e6aeb6e9ef53f5acf06e99c06f4b2c0cce34' [21:40] <durandal_1707> are you out of your mind? [21:43] <Compn> it was in jest :) [21:57] <cone-526> ffmpeg.git 03Jan Ekström 07master:3fbad0071469: utvideoenc: Enable support for multiple slices and use them [21:57] <cone-526> ffmpeg.git 03Jan Ekström 07master:efec857c9f70: utvideoenc: Enable support for multiple slices and use them [21:57] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:e136579ca358: Merge commit '3fbad00714698f59c6326edfcc63db87f525e7c0' [22:07] <cone-526> ffmpeg.git 03Janne Grunau 07master:98fdfa99704f: ppc: reduce overreads when loading 8 pixels in altivec dsp functions [22:07] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:f11905763cda: Merge remote-tracking branch 'qatar/master' [23:28] <cone-526> ffmpeg.git 03Peter Ross 07master:c55143179234: avcodec/h264pred: deconflict DC_128_PRED and HOR_VP8_PRED [00:00] --- Sat Feb 15 2014

1 0

ffmpeg.log.20140214
by burek 15 Feb '14

15 Feb '14

[00:10] <eZpl0it> hey llogan [00:10] <eZpl0it> http://pastebin.com/jTTYJgd4 [00:47] <houms> can ffserver take rtsp url and rebroadcast? [00:55] <llogan> eZpl0it: what player shows it incorrectly? [00:56] <llogan> why do you set -qscale:a and then -ab? they are mutially exclusive. i believe -qp is a libx264 private option [01:02] <houms> say multicast? [01:04] <eZpl0it> i only got a greyscale image when i set libx264 codec [01:04] <eZpl0it> forgot to remove it [01:04] <eZpl0it> mplayer [01:04] <eZpl0it> i recorded it with ffmpeg [01:04] <eZpl0it> mplayer shows it correctly when i watch directly via /dev/vide0 [01:04] <eZpl0it> videoß [01:04] <eZpl0it> video0* [01:20] <llogan> eZpl0it: ffmpeg -f v4l2 -i /dev/video0 -f alsa -ar 44100 -ac 2 -i hw:2 -vcodec libx264 -crf 18 -vf "yadif=1,format=yuv420p,setsar=1:1" -acodec libmp3lame -q:a 4 geburtstag.mkv [03:05] <Magiobiwan> Hey guys. Has anyone ever used ffmpeg to transcode video coming from a TV tuner card (on Linux) to an RTMP stream? [04:40] <funyun> hi. if a mediainfo says my video is interlaced, but i can't see a single line, should i deinterlace when encoding? or is the info incorrect? [04:52] <z1lt0id> just wondering if there is a way to remux a .ts file so it doesn't relative audio to video delay in ffmpeg [04:54] <z1lt0id> i have two .ts files one with 6ms and another say 16ms i want to encode both of these files to h264 and the paste them together in MP4Box [04:54] <z1lt0id> the audio will demuxed to .wav file and concat together and then encoded to say aac [04:54] <z1lt0id> and then muxed into the MP4 [05:13] <BtbN> z1lt0id, so, you have two ts file you want to concat and mux as mp4? [05:15] <z1lt0id> i do [05:15] <z1lt0id> but there is an audio delay sometimes it can go up to 30-40ms [05:16] <z1lt0id> do i need to add an audio delay into the audio file [08:37] <Keestu> could someone help me out. http://pastebin.com/4SVJGudD i am unable to find the pts of frame. [09:40] <relaxed> Now with libx265, hevc: http://johnvansickle.com/ffmpeg/ [10:45] <Keestu> can some one help me out the concept behind it please? i dont get much information from the net. rather i would say i am unable to understand. i tried getting the frames after avcodec_decode_video2 (), by checking one of the variable passed in it. i get the frames like IPPPPPPPPPPIPPPPPP.... Now mu question is Can i send the this 'P' frame directly to the UI? [10:45] <Keestu> or do i need to do any calculation > [10:52] <relaxed> Keestu: you might try the libav-user mailing list: https://lists.ffmpeg.org/mailman/listinfo/libav-user/ [10:52] <relaxed> oh, you already did :) [11:00] <Keestu> relaxed, if i ask there they are redirecting me here... [11:00] <Keestu> it is happening third time for me :(. Just because of the information/knowledge about the system, it takes huge amount of time. [11:38] <relaxed> Keestu: It's fine to ask here. I was just giving you another avenue to pursue. [11:53] <brontosaurusrex> playing around with davinci resolve and noticed that "4:2:0 avc > 4:2:2 prores" clips kinda grade better than original "4:2:0 avc" stuff, any rational explanation (I converted all using ffmpeg to 10bit prores 4:2:2) ? [11:54] <zap0> brontosaurusrex, why wouldn't they? [11:54] <zap0> 4:2:2 is more betterer than 4:2:0 [11:55] <zap0> 10 bit is 4x better than 8bit [11:55] <brontosaurusrex> lol, yes, but this is upscaled 4:2:0 avc [11:55] <brontosaurusrex> "upscaled" [11:56] <brontosaurusrex> a fake 4:2:2 10 bit stuff [12:04] <zap0> but it wont be 4:2:0 just duplicated horizontolly.. it'll have interpolation in the extra horizontal bits [12:05] <zap0> and 10 bit will give you far more room to grade in [12:06] <zap0> and is 10bit proress a linear 10bits.. or some wacky log scale? [12:10] <zap0> brontosaurusrex, if you have 0,1,2,3,4..256.. and just "dumb upscale" it to basically 0,4,8,12.. 1023. you then say add 1/1024th.. that 0 will become 1.. but then you display it on a 8bit display it'll display as 0 again.. but with some interpolation, you would get an upscaling that is not just 0,4,8,12.. you get odd numbers in there too. [12:11] <zap0> so when you then add 1/1024th.. some of those odds round upto next 8bit value.. this means even small changes like adding 1/1024 will actually show you something when displayed on a 8bit display [12:12] <zap0> this is aliasing! [12:14] <zap0> http://en.wikipedia.org/wiki/Quantization_error [12:15] <zap0> brontosaurusrex, may i ask, did you purchase a camera and get Resolve free ? [12:24] <Keestu> thanks relaxed. any input to my question ?. [12:35] <brontosaurusrex> zap0, no, i use the free edition (lite) [12:36] <zap0> ah. does it have limitations? (being the lite ver) [12:36] <brontosaurusrex> i'd expect from grading software to do wonderfull magical upscale to 10bit or whatever, but obviously this doesn't happen [12:37] <brontosaurusrex> zap0, yes, like no noise reduction [12:37] <brontosaurusrex> and probably more [12:37] <zap0> oh :( [12:38] <brontosaurusrex> its actually pretty powerfull [12:38] <brontosaurusrex> but i'am not a pro-grader, so i have nothing to compare it to [12:38] <zap0> if you look at it's set of DLL files.. it's mostly based on OSS code [12:39] <brontosaurusrex> like what? [12:42] <zap0> av*.dll all the lib*.dll [12:43] <zap0> Qt*.dll [12:47] <brontosaurusrex> and it doesn't like my aja card obviously, maybe there is a way to use hdmi somehow, but haven't actually test that [20:01] <houms> can anyone help me get sytax right for getting rtsp to multicast? something like http://pastie.org/8734159 [20:02] <houms> the rtmp/rtsp is mpeg4 10 [20:03] <houms> it seems it is flv and 15 frames [20:03] <houms> trying to figure out how to rebroadcast over udp [20:03] <houms> not sure what params i am missing [21:31] <znf> How could I loop a video used in an overlay? :-/ [21:40] <znf> -loop 1 seems to work only for images (so disappointing!) [23:33] <Logicgate> hey guys [23:33] <Logicgate> is there a way to accelerate watermarking [23:36] <relaxed> buy the fastest haswell cpu you can afford [23:37] <Magiobiwan> How do I tell ffmpeg to take audio input from a tuner card through ALSA? [23:37] <Magiobiwan> The card shows up in arecord as a capture device, but I need to capture it via ffmpeg [23:38] <relaxed> Magiobiwan: https://trac.ffmpeg.org/wiki/Capturing%20audio%20with%20FFmpeg%20and%20ALSA [23:38] <Magiobiwan> Ooh, fancy. A wiki [23:39] <Magiobiwan> That makes it so much easier [23:40] <Magiobiwan> I was thinking I'd have to use arecord and pipe it to a socket as an oss output, then have ffmpeg pull from that input [23:41] <Magiobiwan> Now that that's figured out... Is there a way to specify the input resolution from a tuner card to ffmpeg? It defaults to thinking it's 320x240 which is wrong; it's 720x480 [23:43] <Logicgate> relaxed, right now it takes about 3 hours to watermark an 125mb video. [23:43] <Logicgate> on a small EC2 instance [23:43] <Logicgate> will multithreading help? [23:44] <clever> only if the file is being sliced i think [23:46] <znf> Is there any way to make a source generated with the showwaves= filter to have a transparent background, or simply modify it's alpha channel? [23:46] <znf> Been trying to figure this out for hours now [00:00] --- Sat Feb 15 2014

1 0

ffmpeg-devel.log.20140213
by burek 14 Feb '14

14 Feb '14

[00:22] <cone-480> ffmpeg.git 03Derek Buitenhuis 07master:50ea93158d4c: Add libx265 encoder [00:22] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:c3204856331b: avformat/asfdec: pass on error code from avio_seek() [00:22] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:86316039ab06: Merge commit '50ea93158d4c480f64069e8bd1da388486dcf4ba' [00:38] <cone-480> ffmpeg.git 03Ronald S. Bultje 07master:91be8df20b57: vp9: add fate sample for parallelmode. [00:38] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:89c5de66523b: Merge commit '91be8df20b57a18307e90f1c4886a35ea7b28880' [00:47] <cone-480> ffmpeg.git 03Ronald S. Bultje 07master:dff1c19140e7: vp9: add a new segmentation sample. [00:47] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:e03c1af55eae: Merge remote-tracking branch 'qatar/master' [01:27] <llogan> Daemon404: you already have a fan http://ffmpeg.org/pipermail/ffmpeg-user/2014-February/020004.html [01:30] <cone-480> ffmpeg.git 03Lukasz Marek 07master:9c3478c23434: tools/uncoded_frame: fix double free [01:32] <Daemon404> yes they didnt rtfm [01:33] <Daemon404> crf is a private option for x264 [01:33] <Daemon404> i chose to make the options as autoated as possible for libx265 [01:33] <Daemon404> -preset veryslow -x265-params crf=15 [01:34] Action: Daemon404 will maybe map crf if people constantly complain [01:34] <llogan> they will [01:34] <Daemon404> i absolutely refuse to do what the x264 wrapper does though [01:35] <Daemon404> which is duplicate every single option by hand [01:35] <Daemon404> thts already in x264opt [01:35] <llogan> crf is also a private option for libvpx [01:36] <BtbN> btw., can someone take a look at my nvenc encoder, if i made any major mistakes, also regarding ffmpeg code guidlines. It seems to be working fine now. [01:36] <BtbN> Code is on my github fork: https://github.com/BtbN/FFmpeg/tree/nvenc [01:36] <Daemon404> i need to map a few generic options in avctxlike bframes, + crf, nothing more i think [01:39] <J_Darnley> Daemon404: Does x264 support 9 and 12 bit per sample? [01:39] <J_Darnley> ih x265 [01:40] <cone-480> ffmpeg.git 03James Almer 07master:429f742a61e7: tta: split off hybrid filter processing as ttadsp [01:40] <Daemon404> no 9 [01:40] <J_Darnley> But yes to 12? [01:40] <Daemon404> 12 in the future [01:40] <Daemon404> i believe [01:40] <Daemon404> im not sure we have a 12 bit colorspace defined [01:40] <J_Darnley> oh, okay [01:40] <J_Darnley> nevermind [01:41] <J_Darnley> I just thought I saw some extra PIX_FMT defines that could be added [01:41] <Daemon404> high bit depth support is sketchy in x265 right now [01:43] Action: J_Darnley changes topic [01:44] <J_Darnley> I'm not sure all this extra code is worth it to maybe save a reg or two [02:06] <llogan> 6.69 KB/s...downloading snapshot tarball from ffmpeg.org. [02:34] <Compn> http://mirrors.dotsrc.org/fosdem/2014/Janson/Sunday/NSA_operation_ORCHESTRA… [02:53] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:ccc48b318b56: avcodec/arm/int_neon: fix handling sizes % 16 != 0 [03:37] <Timothy_Gu> You guys can make it a GSoC project. If not, then I'd do it with a fee. [03:38] <Timothy_Gu> The spec itself costs money too: http://sale.gb168.cn/Saleagent/Customer/Shopping/StandardDetails.aspx?Stand… [03:38] <Timothy_Gu> But it's cheap enough (62 CNY, ~$6) [10:13] <leperep> hello, small question in vp9 asm [10:13] <leperep> in vp9mc.asm from line 158, the 8 tap filter [10:14] <leperep> you do 8 loads. Is it not more efficient to do less loads then shuffle the data ? [11:39] <Skyler_> leperep: it /really/ depends; you'd have to bench it [11:39] <Skyler_> newer CPUs have a lot of very very fast load hardware, and unless you're load bound, it may often be better to do "wasteful" loads to avoid doing lots of extra palignrs. [11:41] <Skyler_> though I think the sbutterfly steps could probably be removed by doing something like what happens in x264's hpel_filter_h (munging the order of the coefficients you multiply by to avoid rearranging the inputs) [12:25] <leperep> thanks Skyler_ :) [12:54] <BBB> leperep: I tested the palignr-approach, and found it slower [12:55] <BBB> leperep: in fact, I tested many approaches (and I bet so did Skyler_ in vp8), and this is for some reason just faster [12:55] <BBB> leperep: note that vp8 mc does the same approach for the h 4/6tap filter [13:09] <Compn> leperep : patches welcome to speed it up :) [13:11] <leperep> Compn : I'm on HEVC, I'm looking up vp9 to see how you guys do it. :) [13:13] <leperep> but yeah, I was taught that memory moves are the most expensive things that you can do, so I was trying to minimize them as much as possible. [13:14] <leperep> so seeing all the redundant loads is counter-intuitive [13:15] <BBB> leperep: you can only learn so much; in the end, it's all about measuring it [13:16] <BBB> I yes I remember seeing your name in th eopenhevc repository in that intrinsics branch [13:16] <leperep> on hands experience is much better. :) [13:16] <BBB> can hevc share the mc assembly? [13:16] <BBB> it's 8-tap also right? [13:16] <leperep> the qpel is 8-tap [13:16] <BBB> sharing that would be really cool [13:17] <BBB> I wrote the interface to be relatively ... non-vp9'y, i.e. it takes coefficients as input parameter in the assembly (see wrapper in x86/vp9_init.c) [13:17] <leperep> in some instances, it's a 7-tap, but we use it as a 8 tap filter [13:17] <BBB> and then the coefficients live there too (see top of file), but that can be split into its own file to be vp9-specific if the mc asm itself is shared [13:17] <BBB> right, that's the same for vp9, it's sometimes 8-tap with one zero coefficient [13:19] <leperep> it's the subpel1 define ? [13:19] <leperep> in the dsp_init ? [13:19] <BBB> filter_8tap_2d_fn [13:19] <BBB> on top [13:19] <leperep> ok [13:20] <BBB> it basically calls the 1d h or v filter function in the assembly with a subpel position-adjusted coeff array [13:20] <leperep> hmm [13:20] <BBB> so the asm function is quite literally just h/v_filter(uint8_t *dst, stride, const uint8_t *src, sstride, int16_t filter[8*?] [13:21] <BBB> oh the coeff array is int8_t, not int16_t, I guess [13:21] <BBB> and then it's 8*16 [13:22] <leperep> we use (dst, dststride, src, srcstride, width, height, mx, my) with mx and my for the h and v filters (idx in a filter table) [13:22] <BBB> right, so that means the function needs ot be table-aware [13:22] <leperep> in vp9 it's always 8x8, right ? [13:22] <BBB> that was the reason I did it differen tin the assembly, so the asm itself cna be shared, since it's now specific-coefficient unaware [13:23] <BBB> no vp9 takes any height and width also [13:23] <leperep> ok [13:23] <BBB> height is indeed an input parameter [13:23] <BBB> width is embedded in the function signature [13:23] <leperep> ok [13:23] <BBB> h4, h8, h16, v4, v8, v16 [13:23] <BBB> and 32/64 are wrappers in the c that call 16 twice or 4x [13:23] <leperep> ok [13:24] <BBB> that's mc_rep_func in vp9dsp_init.c [13:24] <leperep> but that means that for the 32, you shift the src and dst between calls ? [13:24] <BBB> and the 8tap-macro to set up the tables is F8_TAPS in vp9mc.asm [13:25] <BBB> leperep: yes; you could probably gain a little by doing that directly in assembly on e.g. avx2 hardware [13:25] <BBB> leperep: but I don't have avx2 hardware so I didn't do it yet [13:25] <leperep> we have no AVX2 here. :p [13:25] <leperep> but looking at the AVX2 functions, using it must be amazing [13:26] <BBB> I haven't tried it yet, I believe ubitux wanted to play with it [13:26] <ubitux> still waiting the hw [13:26] <ubitux> ("soon"©®") [13:26] <nevcairiel> is AVX2 that different? I figured its just SSE2/3 in 256-bit [13:26] <Skyler_> it's a little bit tricky because of the lanes [13:26] <leperep> I feel we're a bit insane, thinking of asm as "wanting to play" [13:26] <Skyler_> and because of the pain of cross-lane shuffles things get a little more complicated when trying to optimize [13:27] <Skyler_> leperep: don't worry, that's pretty normal! at least think I hope [13:27] <Skyler_> *I think [13:27] <leperep> we're the ones having fun. :) [13:29] <Skyler_> regarding the loads, consider that a modern i7 can typically do ~3 SIMD ops per cycle and ~2 SIMD loads, and very often only one of those ops can be a shuffle [13:29] <leperep> are unpacks considered OK ? [13:30] <Skyler_> so as long as you're doing less than 2 loads per cycle and your loads aren't artificially slow for any reason, you can add loads without even taking one more cycle [13:31] <leperep> thanks for the info, Skyler_ [13:31] <Skyler_> unpacks are okay -- like any op you want to minimize them but they're not artificially slow, though on many modern chips only one shuffle per clock is possible, so a function consistent of mostly-shuffles will be slower than you'd want. [13:34] <leperep> BBB : here's our 8-tap filter in intrinsics : http://pastebin.com/PxYhFvbt [13:34] <leperep> the filter load will be changed. :p [13:35] Action: ubitux just sold his soul to the devil by doing some threading work [13:39] <ubitux> 14 34 fps [13:39] <ubitux> yay. [13:39] <kierank> nice [13:40] <leperep> how many threads ? [13:40] <cone-12> ffmpeg.git 03Clément BSsch 07master:13aec744c204: avfilter/lut3d: support slice threading. [13:40] <ubitux> leperep: dunno, about 8 i suppose [13:41] <leperep> from a single thread to 8, you go from 14 to 34 fps ? [13:42] <ubitux> 9 threads actually, yes [13:42] <leperep> cool. :) [13:42] <ubitux> but it was tested with a 1080p h264 input, so decoding was probably threaded as well [13:43] <ubitux> anyway, i can now use lut3d in real time :p [13:45] <BBB> oh filter threading [13:46] <ubitux> gonna make the filter a bit more faster [13:46] <ubitux> i wonder if anyone will add gpu accel to that filter at some point [13:47] <leperep> gpu accel is only done in openCL, right ? [13:47] <leperep> (or CUDA) [13:48] <BBB> leperep: I still think it'd be really cool if the mc 8tap filter code could be shared between vp9 and hevc, but obviously up to you, let me know if you're interested in that and I'll help move things around until it fits [13:48] <leperep> BBB : I am all for sharing the code [13:49] <ubitux> leperep: we only somehow support opencl [13:49] <ubitux> but i've heard gpu love 3d lut [13:50] <cone-12> ffmpeg.git 03mrlika 07master:af786236cc61: mpegts muxer: DVB subtitles multiple languages support [13:50] <leperep> BBB : I'm looking at the 8 tap filter, I think I'll try to use a wrapper function from HEVC to your code. [13:51] <leperep> I don't know how to call you code, so I'll copy your code in my file for the moment [13:55] <leperep> BBB : do you do the (un)weight operations at the same time as th 8-tap filter ? [13:56] <BBB> hm... [13:56] <BBB> so vp9 has no weighting [13:56] <BBB> is mc in hevc always weighted? [13:57] <leperep> it has some sort of weighting. [13:57] <leperep> it can be a simple shift to a complex thing [13:57] <leperep> for the moment we do the 8-tap, and another function for the weighting. [13:59] <leperep> so as output of the 8-tap filter, we have int16_t, which is used as input of the weighting which gives te result back to uint8 [13:59] <leperep> *the [14:01] <Skyler_> is h265 like h264 in that it does mc -> 8bit -> weight -> 8bit [14:01] <Skyler_> or does it do mc -> weight -> 8bit? [14:02] <leperep> 8bit -> mc -> weight -> 8bit [14:03] <leperep> we tried putting the weighted in the same function of the mc, but the number of functions increased just too much [14:03] <leperep> and the gain wasn't there [14:03] <Skyler_> aahhh. so mc outputs to 16-bit instead of 8-bit like in h264 [14:04] <Skyler_> that sounds vaguely ickier to implement. and way smarter. [14:04] <leperep> the weighted is considered part of the mc, I think [14:05] <leperep> Skyler_, but in the end, we have 4 types of weighting, so you have o multiply by 4 the number of functions. [14:06] <Skyler_> 4 types??? [14:07] <leperep> put_unweighted_pred, put_weighted_pred_avg, weighted_pred, weighted_pred_avg [14:07] <Skyler_> ah, okay [14:10] <leperep> sure it looks cleaner, and it means that you don't have to do 2 loops or even need a temp 16-bit table for the mc results [14:11] <leperep> but when we tried, the results weren't there and it meant a lot of trouble for an asm implementation. [14:13] <leperep> BBB : is it possible in vp9 for the width to be 12 or 24 ? [14:14] <BBB> leperep: no, only powers of 2 [14:15] <BBB> I think putting weight in the mc eventually isn't such a bad idea [14:15] <BBB> I mean, mc simd is typically very small [14:15] <BBB> and takes by far most of runtime [14:16] <BBB> (in c) [14:16] <BBB> so... [14:16] <BBB> putting weight in there might not be such a bad idea [14:16] <BBB> what's the diff between put_unweighted and put_weighted_avg etc? [14:16] <BBB> isn't it put/avg_un/weighted? [14:17] <leperep> yes [14:17] <leperep> put_unweighted_pred, put_weighted_pred_avg, weighted_pred, weighted_pred_avg [14:17] <leperep> oh wait the differences [14:17] <BBB> there's 1 unweighted and 3 weighted [14:17] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:842b6c14bcfc: avformat/mpegtsenc: Check data array size in mpegts_write_pmt() [14:17] <BBB> and one is avg and put [14:17] <BBB> I'm confused [14:18] <leperep> http://pastebin.com/wE6yGE3V if you want the details of each function [14:19] <BBB> put_weighted_pred_avg is unweighted [14:19] <BBB> right? [14:19] <BBB> so the function name is odd [14:19] <leperep> oh right. :/ [14:20] <leperep> no [14:20] <leperep> mraulet just told me it's considered as weights of 1. [14:20] <leperep> kinda silly [14:22] <BBB> well that's unweighted [14:22] <BBB> anyway, up to you [14:22] <BBB> me work [14:22] <BBB> bbl [14:23] <leperep> ok ok [14:32] <kurosu__> are vp9 intermediates 8 bits? hevc's are 16, whatever the bitdepth [14:32] <leperep> seems so [14:33] <kurosu__> and iirc, it's mc -> 16bits -> weight -> 8 bits [14:33] <JEEB> yeah. I guess that is one of the ways they tried to make 8bit encoding suck a bit less [14:33] <JEEB> because having the intermediates go down to output bit depth all the time certainly didn't help :) [14:33] <JEEB> (in AVC) [14:34] <kurosu__> there was also a rounding issue [14:35] <cone-12> ffmpeg.git 03Clément BSsch 07master:0e97ec54dea9: avfilter/curves: support slice threading. [14:35] <ubitux> 92 129 fps [14:35] <ubitux> threading is insane @_@ [14:36] <nevcairiel> 1/3 boost? doesnt sound like it threads well [14:36] <kurosu__> depends if the amount of work per pixel is non-constant [14:37] <kurosu__> (and if the filter is simple) [14:37] <ubitux> nevcairiel: yeah, but i'd say it's good enough for now :) [14:39] <kurosu__> can filters be threaded by frame? (like for decoders, even more so if there is no inter-frame dependency) [14:39] <ubitux> no, unfortunately [14:40] <ubitux> would be nice to have some "branch" threading in a filtergraph [14:41] <nevcairiel> slice threading was a much easier goal, so it was implemented first [14:41] <nevcairiel> works really well for yadif, too [14:41] <nevcairiel> which is the only thing i use. :D [14:42] <Daemon404> it the only thing many use :P [14:57] <Balteck> hi all. Any1 can help me about an unsupported stream? [15:27] <JEEB> the longest thread gets longer /~o/~ [15:35] <wm4> lol [15:35] <Daemon404> i wonder wh no intermediate wrk gets submitted [15:35] <Daemon404> (or is it even possible?) [15:36] <JEEB> well, he could post the M/S encoding part I guess? not sure tho [15:36] <JEEB> this looks like a JW32 situation to me tho [15:36] <JEEB> although in a smaller scale [15:37] <Daemon404> schizo? [15:37] <JEEB> no [15:37] <JEEB> as in "here's a huge dump of code that does nice stuff, please merge" [15:38] <Daemon404> yeah [15:38] <JEEB> basically JW32's fork ended up being too large [15:38] <Daemon404> i will reply on the ticket and ask [15:38] <JEEB> and no-one is able to review it in a sane time [15:40] <nevcairiel> he always said he does plan to submit it in smaller parts once he is happy with it. when that is, is another question. [15:40] <JEEB> yeah, someone already poked him in the thread [15:40] <JEEB> I think it was ubitux [15:40] <Daemon404> ah. [16:16] <ubitux> 'seems changing if else if into switch case is now called a refactor... [16:17] <durandal_1707> how would you call it? [16:17] <ubitux> a change switch from if/else to switch [16:17] <ubitux> or whatever, but not a refactor [16:18] <durandal_1707> tell them to get back to school [16:21] Action: durandal_1707 stop caring long ago [18:19] <superware> I'm using libav to decode a live network stream, what's the most simple way to sync incoming frames for rendering? [18:25] <superware> I meant libav* [18:33] <superware> how should I sync video frames from a live network stream? [18:39] <Compn> superdump : ask on libav-user mailing list for help with developing application with libav* libraries [18:39] <Compn> err [18:39] <Compn> superware : http://ffmpeg.org/mailman/listinfo/libav-user [18:40] <Compn> is the url to the mailing list with info how to subscribe [19:01] <superware> Compn: do you know of a more relevant IRC channel? [19:13] <Compn> superware : you can ask in #ffmpeg and #libav channels [19:14] <Compn> this channel is more for development of the program and libs itself, not for 3rd party software [19:56] <Daemon404> interesting [19:56] <Daemon404> so THATS why trac was down [19:58] Action: J_Darnley screams [19:58] <J_Darnley> I can't work out what these XOP instruction macros are doing [20:03] <Skyler_> which ones? [20:04] <J_Darnley> specifically pmacsdd [20:05] <J_Darnley> I've been trying to get A = A + B * [MEM] [20:06] <Skyler_> that won't work [20:06] <Skyler_> or actually wait, maybe it will? trying to think of whether xop supports memory arguments in both of the rightmost positions [20:07] <Skyler_> oh, hmm, I see. it has the problem of clobbering A in the first step in the non-xop emulation. [20:10] <Skyler_> eesh. I think that particular calculation is actually impossible without either a) clobbering A b) clobbering B c) clobbering a temp [20:10] <Skyler_> I guess the xop macros are kind of useless for general-purpose use then [20:11] <Skyler_> I wonder why I didn't run into that before. [20:11] <J_Darnley> They were designed for your use in x264 not my use in flacenc? [20:12] <J_Darnley> I'll try and get my own working, or rather assembling. [20:14] <Skyler_> more like "they happened to work in the one place I used them, but I didn't notice they would break in lots of other places because I was very stupid" [20:39] <J_Darnley> Is there some kind of penalty for mixing AVX and older instructions on an AVX cpu? [20:39] <J_Darnley> Something like: pmulld A, B, C; paddd D, A [20:39] <J_Darnley> Rather than: pmulld A, B, C; paddd D, D, A [21:01] <Skyler_> J_Darnley: first of all, x86inc automatically handles selection between AVX and non-AVX instructions [21:01] <Skyler_> secondly, the rule is as follows: [21:01] <Skyler_> 1) SSE + AVX 128-bit: okay [21:01] <Skyler_> 2) AVX 128-bit + AVX 256-bit: okay [21:02] <Skyler_> 3) SSE + AVX 256-bit, on the same registers, without a vzeroupper in between: bad bad bad bad bad bad bad horrible terrible awful [21:33] <cone-12> ffmpeg.git 03James Darnley 07master:623f380a1844: lavc: fix flac encoder and decoder dependencies [21:37] <J_Darnley> Skyler_: Thanks [22:19] <cone-12> ffmpeg.git 03James Almer 07master:23a8c6345200: x86inc: Extend FMA_INSTR functionality [22:19] <cone-12> ffmpeg.git 03James Almer 07master:e87974bc00e9: flac/x86: add ff_flac_lpc_32_xop() [22:41] <wm4> I just found ff_cropTbl [22:41] <wm4> what does it do? [22:41] <ubitux> clip [22:41] <ubitux> (iirc) [23:21] <J_Darnley> If I use a [mem] operand with pshufd (pshufd xmm, [mem], q0123), does the address have to be aligned? [23:22] <Skyler_> yes [23:22] <Skyler_> (with SSE, at least) [23:23] <cone-12> ffmpeg.git 03Derek Buitenhuis 07master:955544e4d031: libx265: Fix use of uninitialized input picture [23:23] <cone-12> ffmpeg.git 03Derek Buitenhuis 07master:25bc8390bb50: libx265: Remove redundant default param call [23:23] <cone-12> ffmpeg.git 03Derek Buitenhuis 07master:c107769c680b: MAINTANERS: Add myself as libx265 maintainer [23:25] <J_Darnley> You mean sse though to sse42 [23:25] <J_Darnley> ? [23:26] <Skyler_> I mean SSE instructions (vs AVX) [23:26] <Skyler_> AVX allows unaligned memory refs, though in my experience it doesn't really make any speed difference (vs a separate movdqu) [23:27] <J_Darnley> what about movq in that case? [23:29] <Daemon404> Skyler_, do you plan to backport the vpmacsdql emulation stuff to x264? [23:42] <Skyler_> sure, do you have a patch/link to commit/etc? [00:00] --- Fri Feb 14 2014

1 0

ffmpeg.log.20140213
by burek 14 Feb '14

14 Feb '14

[00:00] <rufsketch1> relaxed: note I'm declaring camera1.flv as an input twice, but one of them will eventually be changed to camera2.flv. [00:01] <rufsketch1> the console output is as follows [00:02] <rufsketch1> relaxed: http://pastebin.com/raw.php?i=7x6v57Lq [00:03] <relaxed> ok, the latest version of ffmpeg is 2.1.3. You're using 0.10. [00:05] <relaxed> Many things have changed since then, notably the inclusion of -filter_complex to handle multiple inputs with -i $1 -i $2 instead of using movie=$1 [00:06] <relaxed> rufsketch1: http://johnvansickle.com/ffmpeg/ [00:06] <relaxed> rufsketch1: http://trac.ffmpeg.org/wiki/FilteringGuide [00:07] <rufsketch1> relaxed: ah, I was using the version in the ppa [00:10] <relaxed> stable linux distro's software are very much a snapshot in time [00:14] <wolfman2000> Evening. I'm trying to upgrade a Mac program from ffmpeg 0.10.x to 2.1.3. I've included the new header files required in the include directory, but the issue now is that files that used to link no longer. http://pastebin.com/jZBSb71 Any idea where I'm going wrong? [00:15] <relaxed> BtbN: I prefer using map: "-map 0 -map -0:s -map -0:t" (include everything but subs and attachments, such as fonts) [00:15] <BtbN> relaxed, i ended up with -map 0:v:0 -map 0:a:0 [00:15] <BtbN> to map only the first audio and video stream, and throw away everything else [00:16] <relaxed> yeah, it's best to specify exactly what you're after. [00:16] <BtbN> that stream has like 7 audio streams, which are all basicaly the same [00:24] <wolfman2000> ...I mistyped my own pastebin. wow. [00:24] <wolfman2000> http://pastebin.com/jZBSb7YI <-- let's try this again. [00:35] <relaxed> wolfman2000: nothing [00:35] <wolfman2000> relaxed: did you view the proper pastebin link? or do you just not have a clue why I'm failing? [00:36] <relaxed> the last link you pasted is not proper [00:36] <wolfman2000> I thought I fixed that with the second [00:36] <relaxed> copy and paste [00:37] <wolfman2000> http://pastebin.com/jZBSb7Y1 the joys of using two computers at once... [00:38] <relaxed> are you cross compiling? [00:39] <wolfman2000> relaxed: no. building on Mac for Mac. [00:39] <relaxed> I don't have any experience with xcode [00:39] <wolfman2000> I'm just using windows IRC because my other active channels are there right now. [00:39] <luaduck> hey hey folks, longshot question, but is it possible to get ffmpeg to continue outputting (a video stream) even if one of two inputs goes offline? [00:40] <klaxa> i have no idea either, but it looks like the ffmpeg libraries were not compiled for the correct architecture [00:40] <llogan> wolfman2000: compiling via homebrew might be easiest: http://trac.ffmpeg.org/wiki/MacOSXCompilationGuide#Shortcut:CompileFFmpegth… [00:40] <wolfman2000> well, let's ignroe the xcode part and focus on the undefined symbols part. I did a search for _avcodec_find_decoder and couldn't find anything in the c++ methdod. [00:40] <klaxa> which is why xcode (?) ignores them and therefore nothing gets linked [00:40] <relaxed> this has man hits, google: xcode "ld: symbol(s) not found for architecture i386" [00:41] <relaxed> many* [00:41] <wolfman2000> llogan: don't take it the wrong way, but I am under instructions to not enable the decders OR gpl. Not sure how many of these instructions I cn actually follow [00:42] <llogan> "You can run brew info ffmpeg to see additional configuration options" I assume that should let you modify it? i don't know. [00:42] <wolfman2000> I can brew install dependencies just fine. [00:42] <relaxed> wolfman2000: you should be able to modify the homebrew build script to --disable-* if not [00:42] <relaxed> and omit --enable-gpl [00:42] <wolfman2000> but I purposefully insisted on compiling maually through ./configure and make [00:43] <wolfman2000> so really...the only question here is the arch. what is the right one? [00:44] <relaxed> I would say amd64 [00:44] <klaxa> probably the one you are using... does uname -a on os x display the system's architecture? [00:44] <relaxed> apple doesn't even ship i386 hardware anymore [00:45] <wolfman2000> x86_64 [00:45] <wolfman2000> relaxed: this project file is very old...I would have upgraded it already if it didn't cause other problems. [00:45] <relaxed> your output has "-arch i386" [00:46] <relaxed> so you are, in fact, cross compiling [00:46] <relaxed> or trying to [00:46] <wolfman2000> ...you mean this whole time I've been building universal apps? [00:51] <relaxed> wolfman2000: this might be helpful: http://fate.ffmpeg.org/report.cgi?time=20140212105539&slot=x86_64-darwin-cl… [00:52] <relaxed> obviously you don't need --enable-memory-poisoning --samples=/Users/jeremy/src/ffmpeg/fate/fate-suite [00:53] <wolfman2000> ...so th exta cflags and ldflags? [00:54] <relaxed> yes [00:55] <relaxed> make sure you specify yasm too if it's not picked up [00:55] <wolfman2000> yasm is picked up on my system, so that's not an issue. just have to go back and investigate somethng first bfore switching to this plan. [00:57] <relaxed> good luck, I'm off to dinner. [01:12] <wolfman2000> relaxed: when you get this...bigger underlying issue that's out of scope with this channel. Joys of maintaining an old project when others helped with older versions and are now in hiding. [05:43] <bornpilot> question: when I do "ffmpeg -encoders" I use a listed encoder such as mpeg4 so that my last commands would be -f mpeg4 test.mp4 I receive the following error mpeg4 is not a suitable output format. What I am missing here? [07:38] <Logicgate> why is watermarking so slow with ffmpeg [07:38] <Logicgate> can I somehow speed it up [07:38] <Logicgate> vsync? [07:55] <zap0> watermarking.... lol.. and the point of it? [08:14] <Logicgate> zap0, it's for work [08:14] <Logicgate> I'm simply doing what I'm told lol [09:27] <ItsMeLenny> is there some sort of command line editor that will give me a frame by frame view at the same time [09:27] <ItsMeLenny> i want to chop out 3 sections of a long video but need to do it down to the frame [09:40] <zap0> ItsMeLenny, consider something like virtualdub [09:43] <ItsMeLenny> zap0, ubuntu linux [09:43] <zap0> WINE ;) [09:52] <steem> good day everyone [09:54] <steem> do someone have experience with celp wav files? [10:09] <excalibr> ItsMeLenny, avidemux [10:13] <ItsMeLenny> excalibr, yeah i ended up using it, its just finicky and doesnt have much export options [10:23] <znf> Hello. Does the drawtext filter have something like overlay=eval=init? [12:14] <OrNix> hello. tell me please, what's wrong in this command? http://pastebin.ca/2639897 [12:15] <sacarasc> OrNix: Wrong username or password, it looks like. [12:16] <OrNix> sacarasc, no, credentials are correct. VLC eats this URL normally [12:18] <OrNix> i haven't got any experience in ffmpeg. I want to use stream from rtsp-camera on website with swf and ffserver. [13:01] <Taoki> Hello. [13:01] <Taoki> I have a question. How do you make a video from a png image sequence, but also add a wav file as the audio? http://en.wikibooks.org/wiki/FFMPEG_An_Intermediate_Guide/image_sequence explains how to make a video file from a png sequence, but not how to add the audio (wav to it) [13:02] <Taoki> ffmpeg -f image2 -i image%d.jpg output.mpg - What should I add to that to specify my wav file for the sound? [13:02] <sacarasc> Just add an extra -i blah.wav to the inputs. [13:02] <Taoki> Ah, so -i is the sound. Thanks [13:02] <sacarasc> You might have to use -map too, but I don't think so. [13:02] <sacarasc> -i means the next argument is an input file. [13:03] <Taoki> oh [13:05] <Taoki> So I can have multiple -i arguments? [13:05] <Taoki> ffmpeg -f image2 -i image%d.jpg -i audio.wav output.mpg [13:05] <sacarasc> Yes. [13:05] <Taoki> Thanks [13:14] <Taoki> For some reason it's still not working. It seems to attempt overriding the image files themselves, instead of packing them to a video [13:14] <Taoki> ffmpeg -f image2 -i ${file}/video/*.png -i ${file}/audio.wav ${file}/render.avi [13:14] <Taoki> Where ${file} is path to the folder [13:15] <Taoki> Anyone know what's wrong with that line? [13:16] <sacarasc> Which version of ffmpeg are you using? [13:17] <Taoki> 2.1.2 [13:17] <sacarasc> That should support globbing, but I am not sure how to turn it on. :D [13:17] <Taoki> globbing? [13:18] <sacarasc> https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images… [13:18] <sacarasc> Using * to represent more than one file. [13:18] <Taoki> Ah [13:19] <Taoki> I tried %d but it didn't seem to work [13:19] <Taoki> Said the file can't be found [13:19] <sacarasc> ffmpeg -pattern_type glob -f image2 -i ${file}/video/*.png -i ${file}/audio.wav ${file}/render.avi [13:19] <sacarasc> That *should* do it. [13:20] <Taoki> Same error [13:20] <Taoki> File './video/0002.png' already exists. Overwrite ? [y/N] [13:20] <Taoki> It should be using it, not attempting to write to it [13:21] <sacarasc> ffmpeg -f image2 -pattern_type glob -i '${file}/video/*.png' -i ${file}/audio.wav ${file}/render.avi [13:21] <sacarasc> That, maybe. [13:21] <Taoki> Same [13:21] <__raven_> rtmp to ustream drops framerate extremely at 2mbit any experience with that? [13:30] <Taoki> sacarasc: Something is really off. ffmpeg believes it's writing to an input [13:30] <Taoki> I don't know what sort of bug can cause something like that [13:31] <Taoki> Yes. ffmpeg does generate an avi file, but also overwrites the image sequence. Which I cannot get [13:32] <znf> How do I rotate a drawtext= filter? [13:36] <Taoki> sacarasc: How can ffmpeg attempt to write to an input? This is kinda mind-blowing for any program to do, when you specify a clear input and output [13:36] <Taoki> I think there's a major bug somewhere [13:37] <sacarasc> Taoki: Because there's something going wrong with globbing. FFmpeg didn't used to support * at all, so if you do it wrong, it things that the second file is the output./ [13:39] <Taoki> sacarasc: ok. Why doesn't %d work then? I tried it but it says the file can't be found [13:40] <sacarasc> That would look for 1.png [13:40] <sacarasc> image1.png [13:41] <Taoki> Ah. In my case it starts from 0001.png and goes to 0786.png or so [13:41] <Taoki> How should I adapt it? [13:42] <sacarasc> %4d I think. Maybe %3d. [13:42] <Taoki> Ah, got it! [13:42] <Taoki> Yes, %4d [13:42] <Taoki> Now it works at last :) Thanks for the help [14:32] <karab44> hello [14:34] <karab44> I want to conver a:mp2 v:mpegts *.mpg to mpeg4 or other popular editable format [14:35] <karab44> what I get is that avconv and ffmpeg freezes after few minutes of conversion [14:35] <karab44> some people suggested me that file can be corrupted but it works on VLC very well without causing any problems or artifacts occurs. [14:36] <karab44> Is there a possibility for ffmpeg to fix corrupted AVfiles? [14:57] <Balteck> hi all. Any1 can help me about an unsupported stream? [15:00] <durandal_1707> what stream? [15:03] <fschuetz> I would like to do some reading to better understand ffmpeg, especially stuff like resampling. What would be a good place to start? [15:04] <JEEB> depends from which side of things. ffmpeg-all and the trac examples open up some stuff for the cli [15:04] <JEEB> and the doxygen is for the code [15:04] <Balteck> hi durandal. I have bought Monster University bluray that have a E-AC3 audio. I tried to play on my raspberry and my windows but ffplay give me error: [eac3 @ 0417e3a0] unsupported frame type : skipping frame [15:04] <Balteck> [eac3 @ 0417e3a0] Dependent substream decoding is not implemented. Update your F [15:04] <Balteck> Fmpeg version to the newest one from Git. If the problem still occurs, it means [15:04] <Balteck> that your file has a feature which has not been implemented. [15:05] <Balteck> So I've downloaded a dolby digtal plus demo and I got the error. [15:05] <Balteck> But on documentation ffmpeg support e-ac3. So what's wrong? [15:05] <JEEB> yeah, libavcodec only partially supports E-AC3. It will play only the core. [15:06] <Balteck> so this is the problem. [15:06] <Balteck> Infact with raspberry i'm only hear 3 channel (left/right and center) [15:07] <Balteck> If I sent the demo of dolby digital plus, there is possibility to support it? [15:08] <durandal_1707> i dunno if we already have such samples [15:08] <JEEB> there are some [15:08] <durandal_1707> i doubt there is specification... [15:09] <Balteck> this is the site with demo: http://www.demo-world.eu/trailers/high-definition-trailers.php [15:09] <fschuetz> @JEEB: I want to understand, how the underlying data works. That is 'channel layouts, layers, etc.'. But I also get the idea that one has to know ffmpeg well, to be able to write say a piece of code that takes any audio data as an input stream and writes pcm data. [15:09] <Balteck> look at Dolby Digital Plus Channel Check (Lossless) [15:10] <JEEB> durandal_1707, I at least see 52_b_ pdf as a spec [15:10] <fschuetz> I would like to get some overview as to what has to be considered regarding all the different workings of ffmpeg decoders/encoders muxers/demuxers, etc. [15:10] <JEEB> and the _b_ part is supposed to be the E-AC-3 part [15:10] <Paranoialmaniac> there is the spec of eac3 [15:11] <Balteck> So, if i want to see my new bluray, I need to rip it, demux audio, convert in ac3 and remux it? [15:13] <Paranoialmaniac> libavcodec can decode ac3 compatible substreams inside eac stream. your eac3 has no compatible substream? [15:17] <Balteck> On Raspberry with openelec that use ffmpeg decode the stream and send pcm audio on my avr. Only 3 channel and not bitstrem (On AVR I see pcm audio, not Dolby digital Plus) [15:17] <Keestu> why is so to get pts of packet is always 0? [15:17] <Keestu> does it have any meaning or it is wrong ? [15:18] <Balteck> On windows ffplay stream it with difficulty (audio, pause, audio, ecc) [15:18] <Balteck> The demo on windows is mute, on raspberry the same result [15:21] <Paranoialmaniac> patches welcome? libavcodec eac3 decoder has no support of additional independent substreams and any dependent substreams. [15:22] <JEEB> basically someone has to get off his arse and implement those extra features :) [15:23] <Paranoialmaniac> i think the latest spec of eac3 is Document A/52:2010, 22 November 2010 [15:23] <JEEB> surprising, available straight from atsc [15:24] <JEEB> the one on multimediawiki is from 2005 :D [15:25] <Paranoialmaniac> another spec is published from etsi [15:25] <Paranoialmaniac> ETSI TS 102 366 V1.2.1 (2008-08) [16:01] <_Leo_> Hello, I am using FFmpeg in windows, I used the prores_ks encoder to generate mov file, when played in QT 7.x player I get "Apple Prores 422 (HQ)" in movie inspector but when I play with QT 10.x it says "prores_ks" in movie inspector, why is this difference? Is it can be fixed in some way? [16:52] <fschuetz> I am writing an audiodecoder in C and want to output pcm (to Android AudioTrack). Does this mean that I can just use the data field of a decoded frame (avcodec_decode_audio4) or do I have to encode/mux to pcm codec/format? [16:59] Last message repeated 1 time(s). [18:19] <superware> I'm using libav to decode a live network stream, what's the most simple way to sync incoming frames for rendering? [18:24] <Rathann> superware: this is #ffmpeg, not #libav [18:25] <sacarasc> They could be using libav* from FFmpeg, not the libav project. [18:25] <superware> yes, sorry! [18:33] <superware> how should I sync video frames from a live network stream? [18:40] <asdfmaster> hey could anyone give some help [18:40] <asdfmaster> please [18:40] <asdfmaster> i'm stuck compiling ffmpeg [18:44] <jnvsor> what's your process? [18:45] <asdfmaster> well i'm building a ffmpeg to encode mp4 videos to webm [18:47] <asdfmaster> on a server of my company and i'm not alowed to change or update a lot of packages [18:47] <asdfmaster> and the'r using debian 6 [18:48] <asdfmaster> and they dont want to upgrade, and the ffmpeg from the repositories doenst support wemb [18:48] <asdfmaster> with vp8 and aac [18:49] <asdfmaster> so i went the linux way to do things and tried to compile it with configuration "./configure --enable-libvpx --enable-libvorbis --enable-pthreads --disable-swscale" [18:50] <asdfmaster> the --disable-swscale is because it generates error and does nothing [18:52] <asdfmaster> so when i add the "--disable-swscale" it go through and gets done but there is no ffmpeg binary [18:53] <asdfmaster> so, i'm stuck with no ffmpeg to encode webm [19:04] <ChocolateArmpits> If anyone is wondering about deinterlacing with default filters, here are my personal results: For final image quality: yadif+mcdeint > w3fdif > yadif. For rendering speed: yadif > w3fdif > yadif+mcdeint. For least artifacting: yadif > yadif+mcdeint > w3fdif. [19:06] <ChocolateArmpits> If anyone has furthers questions, I think I could answer them [19:06] <ChocolateArmpits> further* [19:14] <aphirst> Hi; I thought I'd show my face since we've encountered a minor but interesting bug over in #mpv-player, which seems to occur depending on ffmpeg/libav version [19:14] <aphirst> https://github.com/mpv-player/mpv/issues/547 [19:15] <aphirst> some VobSub subtitles glitch up [19:21] <JEEB> I think such stuff is better to be brought up in #ffmpeg-devel [19:21] <aphirst> ah [19:21] <superware> how should I sync video frames (no audio) from a live network stream? I need minimal latency... [19:21] <aphirst> JEEB: should I copy-paste it there? [19:22] <JEEB> aphirst, make it replicate'able with ffmpeg cli if possible, and then note on which versions of FFmpeg it happens or doesn't happen? [19:22] <JEEB> if that is possible, of course [19:22] <JEEB> given it's a subtitle issue and subtitles are hurr and durr in libavcodec [19:24] <aphirst> JEEB: I'm not really in a position to put too much time into installing several different versions of ffmpeg, older prebuilt versions in the repo occasionally require downgrade dependency hell; and building one version from scratch takes forever [19:24] <JEEB> yeah, I do understand [19:24] <JEEB> just noted that such would be the best if the thing is already fixed in HEAD [19:24] <JEEB> so it would be known which currently supported branches should have something backported [19:24] <JEEB> if HEAD has a problem, then that's a whole separate bag of beans [19:45] <Guest78736> hello, can ffserver pull external stream and serve it? [20:53] <superware> how should I sync video frames (no audio) from a live network stream? (with minimal latency) [21:46] <ChocolateArmpits> How can I set framerate for ffplay ? "-r" throws an error [21:56] <llogan> ChocolateArmpits: ffplay -vf fps=12 input [21:57] <ChocolateArmpits> llogan, will that alter playback rate or drop frames ? [22:02] <dashcloud> so, I am in the process of capturing my VHS tapes, some of which have closed captioning (visible as line noise at the bottom of the video). I'd like to have my capture card pre-crop that area out ahead of time- what should I set? [22:03] <llogan> ChocolateArmpits: probably drops frames i'd guess. [22:04] <llogan> dashcloud: are you using ffmpeg? [22:04] <dashcloud> to do the capturing yes [22:04] <llogan> you can use the crop filter [22:04] <llogan> http://ffmpeg.org/ffmpeg-filters.html#crop [22:06] <dashcloud> the card normally captures 720x480- which includes the close captioning bars. What should I use to keep as much of the picture as possible? [22:07] <karab44> hello [22:08] <karab44> I edit video and sound with screen is good in editor. After render both are desynchronized [22:08] <karab44> I tried many things. Any hints how to fix that? [23:12] <eZpl0it> hey guys [23:12] <eZpl0it> I'm trying to grab some vhs to my computer [23:13] <eZpl0it> the recording works actually quite good, the sound and colors work. The quality is also okay. The one thing that bugs me is that [23:13] <eZpl0it> my output video is cropped somehow. The original format is 4:3 and it looks like it is cropped to 16:9. [23:13] <eZpl0it> My command line looks like this: [23:13] <eZpl0it> ffmpeg -f video4linux2 -i /dev/video0 -f alsa -ar 44100 -ac 2 -acodec pcm_s16le -i hw:2 -vcodec mpeg4 -vtag xvid -qp 0 -qscale:v 1 -flags +ilme+ildct -alternate_scan 1 -qscale:a 1 -acodec libmp3lame -ar 44100 -ab 128k -deinterlace -y geburtstag.avi [23:14] <eZpl0it> Could someone help me saving my birthday cassete ? :) [23:25] <llogan> karab44: are you using ffmpeg? [23:25] <karab44> yes [23:25] <karab44> ffmpeg avconv [23:25] <llogan> that's not ffmpeg. [23:25] <sacarasc> karab44: avconv is not from FFmpeg, it's from LibAV. Their channel is #libav [23:26] <llogan> it's a fork of FFmpeg. when they forked they used some of our names (ffmpeg, libav*) so it's confusing to users. [00:00] --- Fri Feb 14 2014

1 0