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

[burek]

[00:09] <J_Darnley> seanDuncan: The wrong channel but that is because qpfile is a feature in x264.c
[00:09] <J_Darnley> not in the library
[00:12] <seanDuncan> darn.  I'm sure I can pipe into x264 via ffmpeg to get this feature but that bugs me because it defeats the purpose behind ffmpeg's 'x264opts' argument.  
[00:12] <seanDuncan> do you know if ffmpeg will ever have qpfile available through x264opts?
[00:16] <J_Darnley> No.
[00:16] <J_Darnley> The qpfile just forces the encoder to be called with the given frame types
[00:17] <J_Darnley> You could probably add this feature to ffmpeg
[00:17] <J_Darnley> Or rather, one could.
[00:19] <seanDuncan> yes, I fully understand the beauty of "patches welcome" in the world of ffmpeg. :)
[00:19] <seanDuncan> ok, looks like piping may be my only option if I want to use this feature
[00:21] <seanDuncan> In case you're curious , I'm trying to do keyframe aligned transcodes across multiple frame sizes while making use of the quality enhancements that come from MB-tree (like so: http://pastebin.com/u0FYfZnT)
[00:23] <J_Darnley> You should have a look at the ffmpeg docs.  I vaguely recall a feature for forcing keyframes.
[00:23] <cbsrobot> seanDuncan: try: &.. :no-scenecut=1:qpfile=homeMovie1080p.stats.qp: &&
[00:23] <J_Darnley> Perhaps I'm imagining it though
[00:26] <seanDuncan> @J_Darnley you are correct there is a force keyframes feature in ffmpeg, however that one will only force keyframes at a 'seconds' level (from the ffmpeg docs " first frames after each specified time")  and that isn't precise enough for my needs
[00:27] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:7edb984dd051: avutil/log: Fix context pointer used for get_category()
[00:27] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:c3bd306e78f9: h264_ps: check croping values
[00:27] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:5299ee54a73f: h264: assert that croping values at slice level are consistent
[00:27] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:fbaf75b166cd: h264: Use the correct croping values.
[00:27] <J_Darnley> Do you have varying frame rates?
[00:28] <J_Darnley> Between the different encodes I mean.
[00:28] <seanDuncan> no, constant frame rates across all.  but scene detect is on in the first transcodes.  so sometimes I won't be able to specify , with right amount of preciseness, the correct frame to put an IDR
[00:29] <cbsrobot> seanDuncan: did it work ?
[00:29] <seanDuncan> @cbsrobot,  haven't tried it yet, but I don't think that will cause it to recognize the qpfile option
[00:30] <seanDuncan> brb
[01:06] <seanDuncan> @J-Darnley: Did you have a suggestion given the fact that I have constant frame rates across all bitrates?
[01:07] <J_Darnley> No, I just thought that ffmpeg's feature would be accurate enough in that case
[01:43] <seanDuncan>  @J-Darnley ok, thanks anyways.  It seems like the force_keyframe feature just wont fit my needs.  I'll test if allows for something like setting keyframes at times like 1.001 or 00:05:10.042 but even if it does my command line string will become huge for anything that has more than 15 keyframes
[04:58] <cone-739> ffmpeg.git 03Clément BSsch 07master:e3e66568ccee: doc/filters: replace hqdn3d with smartblur in timeline section.
[04:58] <cone-739> ffmpeg.git 03Clément BSsch 07master:14f45bcbe73f: doc/filters: fix scale example equivalence.
[07:53] <kierank> there used to be yuv blending support in drawtext, has that gone?
[09:51] <cone-670> ffmpeg.git 03Anton Khirnov 07master:95220be1faac: indeo3: fix off by one in MV validity check
[09:51] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:71091698a231: Merge commit '95220be1faac628d849a004644c0d102df0aa98b'
[10:00] <cone-670> ffmpeg.git 03Anton Khirnov 07master:bda9e6d923df: indeo3: use put_pixels instead of put_no_rnd_pixels in copy_cell()
[10:00] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:d8b6557c866d: Merge commit 'bda9e6d923df6d46cc5cafb30a59a01d2514fa61'
[10:11] <cone-670> ffmpeg.git 03Anton Khirnov 07master:3d10614529b0: FATE: add an additional indeo3 test
[10:11] <cone-670> ffmpeg.git 03Anton Khirnov 07master:e036bb7899d0: lavc: clear AVBuffers on decoded frames if refcounted_frames is not set
[10:11] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:52fa2945b594: Merge commit 'e036bb7899d0faca9159206be9bf5552e76e7633'
[10:17] <cone-670> ffmpeg.git 03Anton Khirnov 07master:1012155722fc: vf_split: fix description
[10:17] <cone-670> ffmpeg.git 03Anton Khirnov 07master:949c603ed921: af_channelmap: remove now unnecessary goto
[10:17] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:a1b887971441: Merge commit '949c603ed9210df0e1b8e1aa82c71b93543d8071'
[10:23] <cone-670> ffmpeg.git 03Anton Khirnov 07master:8aaab1113c00: af_channelmap: ensure the output channel layout is valid.
[10:23] <cone-670> ffmpeg.git 03Anton Khirnov 07master:c22263d3e813: graphparser: only print filter arguments if they are non-NULL
[10:23] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:e41d3aba0123: Merge commit 'c22263d3e813d442df8fa5f5ba8993573fe775d8'
[10:31] <cone-670> ffmpeg.git 03Anton Khirnov 07master:2548834b2248: vf_setpts: cosmetics, reformat
[10:31] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:0061ba044a44: Merge commit '2548834b2248ad4d7da9bd0afed09d7d0cddeeb0'
[11:22] <cone-670> ffmpeg.git 03Anton Khirnov 07master:b472938233b9: lavfi: add an asetpts filter
[11:22] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:1cba7fa364a9: Merge commit 'b472938233b98178ed6c1353c37e0dc7ab585902'
[11:47] <cone-670> ffmpeg.git 03Anton Khirnov 07master:a1e05b0487a1: lavfi: add trim and atrim filters.
[11:47] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:3319679d0a36: Merge commit 'a1e05b0487a1939334c2920fc7f9936bc9efe876'
[12:17] <cone-670> ffmpeg.git 03Anton Khirnov 07master:3d624420086e: avconv_opt: allocate an OutputFile before the streams.
[12:17] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:1924a61a0a39: Merge commit '3d624420086ed3cd0c74f4510f0285968e21c117'
[13:39] <cone-670> ffmpeg.git 03Clément BSsch 07master:24939d567b8a: fate/pixfmts: use the appropriate variable names for temporary files.
[14:02] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:1a94d7c7c8ca: avfilter/trim: improve rounding precission
[14:17] <ubitux> saste: i'm done with the fate-run.sh/filter*.mak thing, but the overlay and alphamerge rgb versions started to fail on msvc for some reason
[14:18] <ubitux> so far, the only relevant diffs are that the tests are using the filter complex system, framecrc instead of a md5, and no fifo
[14:18] <ubitux> the fifo doesn't seem to be the case
[14:19] <ubitux> md5 would have mismatch also, so i doubt it's the framecrc/md5 thing
[14:19] <ubitux> so possibly the problem is because of the switch to the filter complex system
[14:19] <ubitux> there is some kind of chroma shift issue of some kind
[14:25] <cone-670> ffmpeg.git 03Anton Khirnov 07master:a83c0da539fb: avconv: make -t insert trim/atrim filters.
[14:25] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:76c1f9200fa3: Merge commit 'a83c0da539fb07260310bc3b34056239d2b138b2'
[14:28] <ubitux> michaelni: -s or -ss?
[14:46] <cehoyos> j-b: Any news on c99-to-c89 ? Should we try to find another place to host it?
[14:46] <cehoyos> (Same question for ftp...)
[14:47] <ubitux> is it that much trouble to host it ourselves?
[14:47] <ubitux> i mean, it's just a little tarball isn't it?
[14:48] <cehoyos> Did you read the license terms? (I didn't.)
[14:48] <cehoyos> And, even more important: Did you try to build it?
[14:48] <ubitux> ah, right there is the auto build part
[14:52] <cehoyos> nevcairiel: Do you have many (interlaced) vc1 samples? We only have one sample left that shows artefacts. (Or are you using the binary decoder?)
[15:02] <michaelni> ubitux, -ss
[15:32] <ubitux> i wonder if overlay shouldn't belong as a pixfmt test..
[15:36] <cehoyos> michaelni: Is the MPlayer homepage on svn?
[16:52] <michaelni> cehoyos, i dont remember, i dont think i ever did anything with the mp hp
[16:54] <cehoyos> michaelni: I found the repo, thank you!
[17:03] <cehoyos> michaelni: A user posted an aac encoding patch on libav-user: http://thread.gmane.org/gmane.comp.video.ffmpeg.libav.user/10693/focus=10709
[17:31] <cone-151> ffmpeg.git 03Anton Khirnov 07master:8cd472d3f947: avconv: make output -ss insert trim/atrim filters.
[17:31] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:4818388e6c21: Merge commit '8cd472d3f947a6233e7dc628f0dc71c74e62413a'
[17:52] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:2514b80045d5: sws: share xyzgamma tables.
[17:57] <cone-151> ffmpeg.git 03Diego Biurrun 07master:643e433bf744: mpegaudiosp: More consistent names for ppc/x86 optimization files
[17:57] <cone-151> ffmpeg.git 03Diego Biurrun 07master:6b110d3a739c: ppc: More consistent names for H.264 optimizations files
[17:57] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:3ad5d8694c76: Merge commit '6b110d3a739c31602b59887ad65c67025df3f49d'
[18:01] <cone-151> ffmpeg.git 03Diego Biurrun 07master:f5eecee865a7: ppc: util_altivec: Surround AltiVec-related code by appropriate ifdefs
[18:01] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:148f69eb4e4c: Merge commit 'f5eecee865a731d2412fde2f73c29f8f8115c499'
[18:06] <cone-151> ffmpeg.git 03Diego Biurrun 07master:a053dbfcfb3a: ppc: Move AltiVec utility headers out of AltiVec ifdefs
[18:06] <cone-151> ffmpeg.git 03Diego Biurrun 07master:42b9150b0d4f: fft: Remove pointless #ifdefs around function declarations
[18:06] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:ebd99ff112e8: Merge commit '42b9150b0d4f0a130c1d93dc991fd5412743a8cf'
[18:11] <cone-151> ffmpeg.git 03Diego Biurrun 07master:38282149b6ce: ppc: More consistent arch initialization
[18:11] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:cae8f469fee7: Merge commit '38282149b6ce8f4b8361e3b84542ba9aa8a1f32f'
[18:21] <cone-151> ffmpeg.git 03Diego Biurrun 07master:088f38a4f9f5: avcodec: Drop unnecessary ff_ name prefixes from static functions
[18:21] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:04fa81877913: Merge commit '088f38a4f9f54bb923405c67c9e72d96d90aa284'
[18:25] <cone-151> ffmpeg.git 03Diego Biurrun 07master:383fd4d47807: arm: Drop unnecessary ff_ name prefixes from static functions
[18:25] <cone-151> ffmpeg.git 03Diego Biurrun 07master:f2e9d44a5757: x86: Drop unnecessary ff_ name prefixes from static functions
[18:25] <cone-151> ffmpeg.git 03Diego Biurrun 07master:7f75f2f2bd69: ppc: Drop unnecessary ff_ name prefixes from static functions
[18:25] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:dbcf7e9ef7f8: Merge commit '7f75f2f2bd692857c1c1ca7f414eb30ece3de93d'
[18:32] <cone-151> ffmpeg.git 03Diego Biurrun 07master:e926b5ceb196: avformat: Drop unnecessary ff_ name prefixes from static functions
[18:32] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:a5ba4e186bcb: Merge commit 'e926b5ceb1962833f0c884a328382bc2eca67aff'
[18:40] <cone-151> ffmpeg.git 03Derek Buitenhuis 07master:4cdb3c50b538: avcodec: doxy: Clarify what get_buffer2 must fill in buf[]
[18:40] <cone-151> ffmpeg.git 03Derek Buitenhuis 07master:00b8e650e83b: avcodec: doxy: Clarify how to use buf[] when implementing get_buffer2()
[18:40] <cone-151> ffmpeg.git 03Derek Buitenhuis 07master:af8a47905a3f: avutil: doxy: Small clarification for av_buffer_create()
[18:40] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:67731ef40f9f: Merge remote-tracking branch 'qatar/master'
[19:56] <durandal_1707> is dupe asetpts gonna be removed?
[19:57] <durandal_1707> *documentation
[19:59] <ubitux> durandal_1707: do you plan to merge alphaextra with plane* filters?
[20:00] <ubitux> alphaextract* alphamerge
[20:02] <durandal_1707> well for alphaextract yes - exceppt i would need to add rgba slow code..., alphamerge - maybe if you explain what planesmerge or better name for filter would do
[20:02] <durandal_1707> alphaextract would just become what negate is - alias
[20:03] <durandal_1707> and i also need to add 16 bit support
[20:04] <ubitux> would be nice
[20:07] <durandal_1707> it would be also nice if I could know outlink number from config_output, so sscanf is not needed and I could name pads more user friendly
[20:08] <durandal_1707> some pointer trickery could be done...
[20:20] <gnafu> So it looks like ffmpeg has three ProRes encoders.  Which one is the best at this point?
[20:22] <cone-151> ffmpeg.git 03Nicolas George 07master:276fcbde6c55: lavf: data muxer and demuxer.
[20:22] <cone-151> ffmpeg.git 03Nicolas George 07master:ceb33f3aee15: lavc: copy subtitle_header when copying context.
[20:22] <cone-151> ffmpeg.git 03Michael Niedermayer 07master:d602f16a377a: Merge remote-tracking branch 'cigaes/master'
[20:22] <durandal_1707> gnafu: really? there are 2 only with 3 names
[20:23] <gnafu> Aah, okay.  I was just looking at -codecs output without looking further :-P.
[20:27] <gnafu> Seems the default, prores_anatoliy, is much faster than prores_kostya.
[20:27] <gnafu> ~5 times as fast on my machine :-P.
[20:28] <ubitux> what about the output size?
[20:29] <gnafu> I didn't really pay attention to anything else at this point.  I don't have any need for ProRes encoding; I just had a sudden urge to see what was there XD.
[20:29] <gnafu> I'll probably compare them more when I'm more bored.
[20:30] <gnafu> 15 fps vs. 3 fps was all I paid attention to so far.
[20:30] <ubitux> :)
[20:30] <JEEB> afaik kostya's implementation is one that sets its defaults for better compression
[20:30] <gnafu> (720p video on an older AMD64.)
[20:30] <JEEB> you could make it faster with settings IIRC
[20:31] <gnafu> Yeah, that's what I get from the blog post I just found :-).
[20:48] <smj> http://pastebin.fi/raw/vc4z05gn5v is the OpenCL detection a bit inaccurate? It worked fine a few commits ago, but sure, it might all be just my system.
[20:49] <smj> I might have broken my x264 for now
[20:50] <durandal_1707> is OpenCL really that good?
[20:50] <JEEB> if that's x264's configure then see its configure's help about disabling opencl
[20:51] <JEEB> durandal_1707, no
[20:51] <JEEB> also I think x264's opencl shouldn't get enabled on !windows to begin with for now :s
[20:51] <JEEB> or wait...
[20:51] <JEEB> no
[20:52] <JEEB> o_O
[20:52] <smj> it's ffmpeg
[20:52] <JEEB> try adding the ldflag to link to whatever gives you dlopen and friends
[20:53] <smj> I like the idea of moving some load off my i3 to GTX650
[20:54] <JEEB> no idea what ffmpeg does with opencl, but the x264's opencl is not really worth it in general
[20:54] <JEEB> it's a nice example of something actually workable being implemented, but nothing more :s
[20:54] <smj> but if it's not currently in much use, I guess I compile without it
[20:56] <smj> that's ffmpeg's ./configure and to me it looks like broken libx264 prevents OpenCL from being detected correctly
[20:56] <JEEB> well the errors just mean that it can't find those "dl*" things from the currently linked libraries
[20:57] <JEEB> it's possible that it just was linked against some other CRT or whatever if you're on one of those "on-the-edge" distros
[20:57] <JEEB> but I really don't know, which is why I said you should try to add the ldflag which would link whatever provides those functions first
[21:17] <smj> okay, ffmpeg finds opencl after libx264 is linked with -ldl
[21:29] <durandal_1707> why http://ffmpeg.org/projects.html mentions qemacs?
[23:07] <cehoyos> gnafu, JEEB: Afair, Anatolyi's prores encoder is both faster and produces smaller output, the person who tested it initially didn't realize and implemented interlaced encoding for the other encoder;-( (iirc)
[00:00] --- Thu May  2 2013