GNOME Bugzilla – Bug 704193
avidemux: no PTS nor DTS on decoded frame
Last modified: 2013-07-24 07:29:06 UTC
In some cases the libav decoders do not output any timestamp on decoded frames in 1.1. This seems to be due to a regression compared to 1.0 in the videodecoder base class. To reproduce: gst-launch-1.0 -v pushfilesrc real-filesrc::location=<path_to_avi_file> ! avidemux ! avdec_mpeg4 ! fakesink silent=false When avidemux is activated in pull mode it works: gst-launch-1.0 -v filesrc location=<path_to_avi_file> ! avidemux ! avdec_mpeg4 ! fakesink silent=false I can see that in the second case the videodecoder logs outputs the following: videodecoder gstvideodecoder.c:2252:gst_video_decoder_prepare_finish_frame:<avdec_mpeg4-0> no valid PTS, using oldest DTS 0:00:00.291958333
Confirmed here, happens with every AVI file probably. In push mode avidemux puts only DTS on buffers, in pull mode both... for whatever reason. Probably related https://bugzilla.gnome.org/show_bug.cgi?id=691481
The problem happens after commit 31312d58 (videodecoder: Don't blindly assign DTS to PTS) in base.
Makes sense :) The problem here is that avidemux puts PTS on buffers depending on if it is in push mode or pull mode. That doesn't feel right to me and should probably be fixed. I don't know why it does that yet
Does it know anything about PTS anywaya? Shouldn't it just put DTS?
Right, we're talking about avi here... I wonder how it magically guesses the PTS in pull mode :)
In pull mode, the demuxer can know when a buffer is a keyframe by looking into the index. In this case PTS is set to the same value as DTS.
The video base decoder doesn't set timestamps when only DTS is set on input buffers.
Created attachment 249645 [details] [review] something like this Maybe something like this, set PTS to DTS on sync points if all else fails
For video shouldn't there be a parser as well to fix things up? (Which it doesn't actually do yet though, does it?)
Though I have not looked at the details, but how does the proposed video base decoder patch relate to something we had there before and got chucked out in commit http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=31312d586e2f5282aa95fa7abbf9413c7f1bda34 ? While it may not be constructive to note as such (and am somewhat "out of the loop"), this seems another episode in "need to sort out the timestamp stuff", and we seem to have gone as far as possible in that area by means of (only) some "local" patches sprinkled here and there ...
Comment on attachment 249645 [details] [review] something like this We had that before and it's not valid as David pointed out. PTS is not necessarily equal to DTS for keyframes. I think the real solution here is to add the required calculations for mapping DTS to PTS to the parsers (and probably additionally the decoders) as discussed in previous discussions about the same topic.
I thought that the PTS recovery code in videodecoder handled this case correctly. It appears it doesn't like the case where there are *no* valid PTS values. Wim's patch fixes this exact case, which I think is correct.
Comment on attachment 249645 [details] [review] something like this <slomo> ds: isn't wim's patch settings PTS=DTS in any case if there's no PTS? isn't that exactly what your commit was supposed to change? <ds> "if there's no PTS" <ds> previously, it was "always set PTS=DTS" <slomo> only if !GST_CLOCK_TIME_IS_VALID (frame->pts) <ds> hrm, maybe I'm confusing this with something else <ds> in any case, I think handling it later is smarter. <slomo> ok
commit 409cb22253c59e25838a7d57507cbbe980ec102a Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Wed Jul 24 09:24:45 2013 +0200 videodecoder: Take DTS as PTS for keyframes as a last resort if we can't calculate any PTS https://bugzilla.gnome.org/show_bug.cgi?id=704193