qtdemux changes between 1.10.4 and 1.18.5

[Marcin Twardak]

Hello, GStreamer dev team!

We are developing a product that uses one of GStreamer plugins - qtdemux - and encountered problems after switching from version 1.10.4 to 1.18.5. I have a couple of questions related to the logic of qtdemux and would appreciate your support or redirecting me to the people who might be able to help.

Problem description

qtdemux struct contains a segment member and the segment in turn has (among others) two members described in the header:

  *   duration - the duration of the segment is the maximum absolute difference between #GstSegment.start and #GstSegment.stop if stop is not set, otherwise it should be the difference between those two values. This should be set by elements that know the overall stream duration (like demuxers) and will be used when seeking with #GST_SEEK_TYPE_END.
  *   stop - the stop time of the segment (in buffer timestamps)  [(PTS)](GstBuffer.pts), that is the timestamp of the last buffer to output inside the segment (first one during reverse playback). For example decoders will [clip](gst_segment_clip) out buffers after the stop time.

In the qtdemux function `check_update_duration` there is a logic updating:

  *   qtdemux->duration
  *   qtdemux->segment.duration
  *   qtdemux->segment.stop

and this logic seems to have changed in 1.18.5 compared to 1.10.4.

In GStreamer 1.10.4 both, qtdemux->segment.duration and qtdemux->segment.stop had the same value read from mvhd or mehd box in qtdemux_parse_tree. I observe that it always has reasonable values, a duration of the content in timescale units, e.g. 730000000000 which corresponds to 730 seconds.

In Gstreamer 1.18.5 a logic of assigning qtdemux->segment.duration and qtdemux->segment.stop in qtdemux_parse_tree was put under if (!qtdemux->upstream_format_is_time), which in my case is always false (we use segments with GST_FORMAT_TIME). This in turn leads to updating qtdemux->segment.duration and qtdemux->segment.stop in check_update_duration method to unreasonable values of duration, like 1669982447883159000. As per the description in the header segment.duration should hold the absolute difference between stop and start values, and it's not the case anymore.

Questions

  1.  Do I understand correctly that qtdemux->segment.duration should always hold the duration of the segment, even if segment.start is not 0?
  2.  If so, how can one explain logic in check_update_duration, where under specific conditions segment.duration and segment.stop will be equal? Isn't that true only if the start is 0?
  3.  I checked the commit introducing the beforementioned if (!qtdemux->upstream_format_is_time) in qtdemux_parse_tree - https://bugzilla.gnome.org/show_bug.cgi?id=752603 - and in the commit description there is the following statement:

qtdemux->segment.duration is no longer modified when
upstream_format_is_time, respecting in this way the durations provided
by dashdemux and fixing bugs in reverse playback tests where mangled
durations appeared in the emitted segments.

      do you know, which changes in dashdemux it refers to?

Thanks in advance for your help!

Marcin Twardak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20221216/aef2dd98/attachment.htm>