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

[burek]

[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