[01:21] <kierank> do we have any samples with aac drc [01:53] <cone-757> ffmpeg.git 03Michael Niedermayer 07master:630c005b879a: avcodec/flac_parser: export sample_rate also when PARSER_FLAG_COMPLETE_FRAMES is set [01:53] <cone-757> ffmpeg.git 03Michael Niedermayer 07master:8f2386b5894d: avformat/oggparseflac: fix handling of old flac in ogg [01:53] <cone-757> ffmpeg.git 03Michael Niedermayer 07master:38e13f55a5a3: ffmpeg: dont detect slight (0.1sec) backward moving dts as discontinuity [03:05] <Compn> kierank : Daemon404 probably does [09:47] <wm4> any explanation about that last commit? (ffmpeg: dont detect slight (0.1sec) backward moving dts as discontinuity) [10:14] <ubitux> michaelni: we seem to often use '|' as list separator in filters AVOptions [10:31] <cone-430> ffmpeg.git 03Paul B Mahol 07master:ce26a016cd34: avfilter/vf_phase: remove dead initialization [10:40] <michaelni> wm4, theres a sample that has slightly bad timestamps that needed this, (it was given to me with "private dont share" so i cant share it [10:40] <durandal_1707> you can share it in private [10:40] <michaelni> no [10:41] <durandal_1707> by share, he/she meant do not put on torrent [10:41] <cone-430> ffmpeg.git 03Paul B Mahol 07master:ad934bc353b2: avfilter/vf_drawtext: remove dead initialization [10:45] <ubitux> durandal_1707: i don't think so [10:46] <michaelni> he didnt litterally say "share" i think, i dont remember the exact wording. If someone wants to see the sample i can forward your request to who sent me the sample. [10:50] <durandal_1707> yes, that seems reasonable [11:13] <cone-430> ffmpeg.git 03Paul B Mahol 07master:62078f25ee9a: avcodec/dpx: return different error code for unsupported depths [11:16] <durandal_1707> michaelni: i think using gbrp for dpx was bad idea [11:16] <durandal_1707> it would be much simpler if 10 & 12 bits are done like 16 bit rgb [11:33] <durandal_1707> is there some dpx exporter that does not sucks? (imagemagick sucks) [11:37] <cone-430> ffmpeg.git 03Diego Biurrun 07master:9adbc3f3a177: bmv: Remove unused variable [11:37] <cone-430> ffmpeg.git 03Michael Niedermayer 07master:57f0f86f72a1: Merge commit '9adbc3f3a1770fec9d24b8f5be3438a6c8e9e6a6' [11:42] <cone-430> ffmpeg.git 03Diego Biurrun 07master:ce1e8045e04e: x86: fdct: Employ more specific ifdefs [11:42] <cone-430> ffmpeg.git 03Michael Niedermayer 07master:b67cb58520ff: Merge remote-tracking branch 'qatar/master' [11:51] <cone-430> ffmpeg.git 03Niv Sardi 07master:49ba6e56bd32: lavu/parseutils: add more resolutions [12:02] <cone-430> ffmpeg.git 03Lukasz Marek 07master:c21be5845fa6: doc/indevs: make pulse dev formatting consistent with other devices [12:03] Action: Daemon404 sudders at the sight of pulseauio [12:04] <ubitux> wm4, saste, problem with av_get_channel_layout2() is the clash with libav if they decide to use a different behaviour [12:04] <ubitux> name needs to be completely changed [12:05] <Daemon404> av_get_less_retarded_channel_layout() [12:05] <Daemon404> ? [12:05] <saste> ubitux, get_channel_layout() is already different from libav [12:05] Action: Daemon404 runs [12:06] <ubitux> saste: ok.. [12:07] <ubitux> i didn't follow what exactly changed in the behaviour [12:07] <wm4> once more I'm glad that I didn't use this API [12:07] <ubitux> (was it a documented behaviour anyway?) [12:09] <Daemon404> wm4, ;) [12:15] <saste> ubitux, yes it is documented in the doxy, not in the manual [12:15] <saste> i plan to update utils.texi once we finalize this [12:15] <saste> the change should be explained in the commit log, and is related to the opt channel layout utils [12:15] <ubitux> well i'd be more for a av_get_channel_layout2() then, but well [12:17] <saste> ubitux, this only affects people who specify number of channels with "N" rather than "Nc" [12:17] <saste> i'll add a warning in the code, so they will get a warning in that case [12:18] <ubitux> i'd like to see the patch first anyway :p [12:20] Action: durandal_1707 do not want to see single nit kind of review any more [12:21] <wm4> <rant>with proper APIs, this would be a non-issue</rant> [12:22] <durandal_1707> proper API is like holy grail [12:23] <saste> ubitux, i'll already sent a patch [12:23] <ubitux> i guess i'm blind [12:24] <saste> *I already ... [12:45] <saste> durandal_1707, can you provide a commandline to reproduce the interleave issue? [12:58] <durandal_1707> ffmpeg -f lavfi -i testsrc -f lavfi -i testsrc -lavfi interleave -vcodec ffvhuff /tmp/x.nut [12:59] <durandal_1707> drops half of frames [13:04] <saste> durandal_1707, that's ffmpeg which is dropping frames in that case [13:05] <saste> since it doesn't like two frames with the same PTS [13:05] <durandal_1707> and how to fix that? [13:05] <saste> durandal_1707, there is nothing to fix, that's how ffmpeg is supposed to behave [13:05] <saste> what's your objective? [13:06] <durandal_1707> what I should do to let ffmpeg not drop frames? [13:06] <durandal_1707> what about this one: [13:06] <durandal_1707> ffmpeg -f lavfi -i testsrc -f lavfi -i testsrc -lavfi interleave,stereo3d=al:sbsl -vcodec ffvhuff /tmp/x.nut [13:06] <wm4> frames with same PTS doesn't seem to make sense? [13:07] <durandal_1707> you switch between both very fast when rendering [13:08] <wm4> that doesn't make sense either [13:09] <durandal_1707> maybe for you... [13:09] <Daemon404> [12:07] <@durandal_1707> you switch between both very fast when rendering [13:10] <Daemon404> this violates the definition of PTS [13:10] <durandal_1707> citation needed [13:11] <wm4> one frame would be displayed for the duration of 0 seconds, i.e. not at all [13:11] <saste> ffmpeg -f lavfi -i testsrc -f lavfi -i testsrc,setpts=PTS+10 -lavfi interleave,stereo3d=al:sbsl -vcodec ffvhuff -y /tmp/x.nut [13:11] <saste> but this is not yet working [13:11] <wm4> so why encode that frame (or why was that pts even generated?) [13:12] <saste> so the question is why ffmpeg is not happy with that? [13:27] <durandal_1707> doing gray8->gray16->gray8 changes brightness [13:28] <cone-430> ffmpeg.git 03Michael Niedermayer 07master:b8866783c6a8: avfilter/lswsutils: dont override the default scaler [13:33] <durandal_1707> hmm brightness is actually same (i was using different vo) [13:36] <saste> ffmpeg -f lavfi -i testsrc -f lavfi -i testsrc,settb=1/50,setpts=PTS+1 -lavfi interleave,stereo3d=al:sbsl,showinfo -vcodec ffvhuff -vsync passthrough -y /tmp/x.nut -loglevel debug [13:37] <saste> durandal_1707, looks like stereo3d is wiping the timestamps [13:46] <durandal_1707> why swscale doesn't support only red/green/blue/alpha formats? [13:47] <durandal_1707> saste: perhaps because frame_rate is not set? [13:50] <saste> durandal_1707, with vsync passthrough that should not be a problem [13:50] <saste> may be a stereo3d issue? [13:52] <saste> why pts = pts_time = 0 in the output? [13:58] <cone-430> ffmpeg.git 03Paul B Mahol 07master:e745dc2d6f3b: avcodec/dpx: refactor pixel format selection [13:58] <cone-430> ffmpeg.git 03Paul B Mahol 07master:23824b9698bb: avcodec/dpx: support for 8 and 16 bit luma only files [14:08] <durandal_1707> michaelni: did you backported a27227d401adf12 to relevant branches? [14:16] <michaelni> just cherry picked to 2.0 & 1.2 locally, i dont maintain older branches, feel free to backport to older or take over their maintaince [14:19] <durandal_1707> i barely maintain master [14:56] <durandal_1707> saste: its because fps is not set [14:57] <saste> how's that? [14:58] <saste> durandal_1707, anyway, how should it be fixed? [14:58] <saste> my guess is that there is something wrong in stereo3d, since it's not setting output PTSs [14:59] <durandal_1707> interleave set fps to 1/0 [15:03] <saste> durandal_1707, yes, that means "undefined" [15:06] <Daemon404> isnt that 0/1 [15:07] <Daemon404> not 1/0 [15:09] <durandal_1707> saste: because its 1/0 ts_unit is 0 [15:09] <durandal_1707> workaround is using fps filter after interleave, [15:12] <saste> Daemon404, 7b42036b [15:12] <saste> i wonder if that was a typo from Nicolas [15:13] <Daemon404> saste, allowing 1/0 is quite bad idea [15:13] <Daemon404> only bad things can come from /0 [15:14] <saste> durandal_1707, yes singularities are bad [15:14] <saste> durandal_1707, shouldn't you add an exception to handle 1/0? [15:14] <durandal_1707> to what? [15:14] <saste> stereo3d [15:15] <durandal_1707> but to what? [15:15] <Daemon404> [14:14] <@saste> durandal_1707, shouldn't you add an exception to handle 1/0? --- this is retarded [15:15] <Daemon404> the proper fix is not have /0 [15:15] <Daemon404> in the first place [15:15] <saste> 1/0 == undefined [15:15] <saste> the frame rate is not always defined [15:15] <Daemon404> [14:13] <@Daemon404> only bad things can come from /0 [15:16] <Daemon404> lets allow accidental division by 0! [15:16] <Daemon404> because of a poorly hosen special constant [15:16] <Daemon404> and litter the coebse with checks [15:16] <Daemon404> but we forget? UH OH [15:16] <wm4> why does the filter chain have the concept of a framerate? [15:16] <saste> wm4, was introduced by Anton [15:16] <Daemon404> well that too [15:16] <wm4> curse him [15:16] <saste> that's required for several reason [15:16] <saste> i think for introducing the fps filter in the first place [15:16] <durandal_1707> i wonder how to do it without f* with frame rate... [15:17] <Daemon404> libav has avg_frame_Rate only [15:17] <Daemon404> so it's always there [15:17] <Daemon404> afaik [15:19] <durandal_1707> for proper interleave operation you need same rates on all inputs anyway [15:19] <durandal_1707> and than output rate is just number of inputs * input rate [15:20] <durandal_1707> but even if they are different filter should not need to buffer frams [15:20] <durandal_1707> *frames [15:22] <Daemon404> so how do you define interleaving on vfr content [15:22] <Daemon404> since libav* have no concept of vfr/cfr at all [15:22] <Daemon404> seems liek a total crapshoot. [15:22] <durandal_1707> i think framesync could allow to ignore pts... [15:22] <Daemon404> cant filters set the fps? [15:22] <durandal_1707> Daemon404: the filters start counting from 0 [15:23] <Daemon404> you could ignore the timestamps and take an input fps directly to the plugin [15:23] <Daemon404> instead of screwing with the whole framework [15:30] <durandal_1707> yadif=1 doesn't use this approach, i wonder what solution is really correct [15:30] <wm4> did MPlayer yadif even have correct pts handling [15:31] <wm4> ret |= vf_next_put_image(vf, dmpi, pts /*FIXME*/); [15:31] <wm4> haha. [15:31] <wm4> pts += vf->priv->buffered_i * .02; // XXX not right [15:31] <wm4> looks like it didn't [15:32] <durandal_1707> i amazed by such XXX/FIXME that do not say why something needs fixing [15:32] <Daemon404> welcome to mplayer [15:38] <durandal_1707> libavcodec//cabac.c: flush_put_bits(&c->pb); //FIXME FIXME FIXME XXX wrong ---> the king [15:39] <Daemon404> rofl [16:21] <saste> the fixme is there since forever (first commit in 2003) [16:22] <saste> so basically nobody felt the need/urge to fix it, and never will [16:27] <JEEB> reminds me of VSFilter [16:28] <JEEB> that thing has had a fixme: b0rken message that pops up during compilation for like ten years, too [16:30] <Daemon404> [15:22] <@saste> so basically nobody felt the need/urge to fix it, and never will [16:30] <Daemon404> i think you mean [16:30] <Daemon404> nobody knows *what* to fix [16:30] <Daemon404> since it doenst give any clue [17:10] <teratorn> is there any api for telling how many data planes are expected by a pix format? [17:11] <durandal_1707> yes there is [17:11] <kierank> there's a struct [17:11] <teratorn> oh what file is that in? [17:12] <wm4> libavutil/pixdesc.h [17:12] <durandal_1707> av_pix_fmt_count_planes [17:12] <teratorn> very cool, ty :) [19:51] <michaelni> BBB, ubitux it seems nasm doesnt like the vp9 code (http://fate.ffmpeg.org/log.cgi?time=20131007121022&log=compile&slot=x86_64-archlinux-gcc-nasm) [19:52] <durandal_1707> it could be nasm bug? [19:52] <Compn> its undefined reference [19:52] <Compn> so probably missing include ? [19:53] <Compn> weird it works in yasm then... [19:54] <ubitux> the undefined are linker errors Compn [19:54] <Compn> oh i'm in the wrong part [21:41] <cone-430> ffmpeg.git 03Michael Niedermayer 07master:abf2d53d807c: avcodec/options_table: add field_order [21:41] <cone-430> ffmpeg.git 03Lenny Wang 07master:2779b7b30a0d: avfilter/deshake [21:44] <durandal_1707> michaelni: can you at least eddit commit logs of stuff you push? [21:45] <durandal_1707> michaelni: have you tested deshake patch? [22:03] <michaelni> durandal_1707, yes i tested it, the filter works as well as before [22:04] <michaelni> also the code was obviously buggy [22:18] <cone-430> ffmpeg.git 03Michael Niedermayer 07master:728bb910ec04: avfilter/vf_deshake: fix block_contrast() lower brightness value [00:00] --- Tue Oct 8 2013