GNOME Bugzilla – Bug 685467
mpegdemux: interpolate pts, fixing use with smartencoder
Last modified: 2016-02-21 22:10:30 UTC
Created attachment 225772 [details] [review] fix stop bigger than start in segment clip when start and stop are max (-1) Using pitivi, I get a loop in gop reencode (set to pause then to null and back to pause, etc). It turns out that gst_segment_clip when feed with a start and stop equal to max guint64 (ie -1) stop is assigned segment-stop while start is assigned max (-1). Thus we ends up with a start bigger than the stop.
Created attachment 226084 [details] [review] only update gop start/stop timestamps if we have a valid buffer timestamp This is another way to fix the infinite loop in pitivi due to start > stop. Ie when timestamp is invalid without this safeguard, gop stop and start are updated to GST_CLOCK_TIME_NONE (-1). Then when we have a keyframe we have this sequence: (let us tell keyframe "3" buffer timestamp equal "30" and keyframe "6" buffer timestamp equal "60" in an abstract world: A. keyframe one with buffer timestamp GST_CLOCK_TIME_NONE: start = -1, stop = -1, in gst_smart_encoder_chain : .gop stop is set to the valid buffer value "-1", start to "-1" too. .gst_smart_encoder_push_pending_gop > gst_segment_clip with start valued "-1" and stop valued "-1", change internaly stop to segment->stop let s tell "30" and start to (gutin64)"-1". We have start above stop. .gop start is set to buffer timestampt "-1" B. same for frame two. C. keyframe three with a valid timestamp "30" appears : .gop stop is set to the valid buffer value "30", start is still "-1", ie GST_CLOCK_TIME_NONE .gst_smart_encoder_push_pending_gop > gst_segment_clip with start valued "-1" and stop valued "30" .gop start is set to buffer timestamp "30" D.keyframe four with buffer timestamp GST_CLOCK_TIME_NONE: start = -1, stop = -1 .gop stop is set to the valid buffer value "-1", start stays at "30" too. .gst_smart_encoder_push_pending_gop > gst_segment_clip : with start valued "30" and stop valued "-1", change internaly stop to segment->stop let s tell "60". .gop start is set to buffer timestamp "-1" E. again invalid timestamp for a keyframe: this time: . gop stop set to "-1" .gst_smart_encoder_push_pending_gop > gst_segment_clip : with start valued "-1" and stop valued "-1", change internaly stop to segment->stop let s tell "60", while start stay (guint64)"-1". We have start > stop .gop start is set to buffer timestamp "-1" and so forth. In pitivi this leads to an infinite loop (in render).
So out of curiosity, why are there no timestamps? What does the pipeline look like? Is it a demuxer not putting timestamps on it? Should the parser (is there a parser?) not interpolate it then?
Created attachment 226118 [details] pitivi rendering pipeline (no parser before smartencoder) for vob mpeg-ps to mpeg-ts there is no parser before smartencoder. The buffer which has no PTS comes from the mpeg demuxer and match PES that had nothing in PES optional header (ie PES header len equal 0). In fact most PES are so, only every 10th or so there is one with the optional part of the PES header filled . Those few have a PTS.
found the details: dvd, ie mpeg-ps access (video or audio) units are only required to have a timestamp (pts) every 700ms. The others are to get interpolated by the decoder ...
Created attachment 226148 [details] [review] interpolate non required missing timestamps pts in the demuxer Turns out that we have 33,3333 ie 40ms between each frame. Based on the 90kHz frequency of the pts I interpolate the missing "not required" by the spec (but by smartencoder) pts . Though it looks heavily like this 40ms is in only for 25 frames per seconds. I do not know how to make this interpolation take into accounts the real framerate, or if there is a need to.
Turned out that the 40ms value is the "maximum space per program between individual pcr values" . So the calculus does not dependent on framerate. Only remaining issue, is if we really want to do this interpolation at the demuxer level.
Is this still valid with git ? I think the various audio/video parsers handle this.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!