After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 779347 - First buffer from theoradec always has segment.start timestamp
First buffer from theoradec always has segment.start timestamp
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-02-28 06:44 UTC by Jan Schmidt
Modified: 2018-11-03 11:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jan Schmidt 2017-02-28 06:44:05 UTC
I've encountered an error with splitmuxsrc and reverse playback. The first buffer from oggdemux for a file fragment always has timestamp NONE. Theoradec/ videodecoder guess a timestamp equal to segment->start which is normally OK, except here.

With splitmuxsrc, it each fragment is a separate ogg file, so there'll be a first buffer for each part with timestamp NONE.

TBH, I'm not sure how we should fix it. Either oggdemux needs to be able to work out the correct timestamp to put on the first theora packet in a stream, or theoradec needs to somehow work backward from the 2nd packet to calculate the timestamp for the first. videodecoder might be able to do the 2nd if it defers guessing a timestamp until it's pushing out the reverse buffers.
Comment 1 Tim-Philipp Müller 2018-01-18 18:22:26 UTC
I think oggdemux should always be able to calculate a timestamp.

This only happens in reverse playback?

How can one reproduce it?

I've tried:

1)
gst-launch-1.0 videotestsrc num-buffers=250 ! video/x-raw,framerate=10/1 ! timeoverlay font-desc=Sans,25 ! theoraenc keyframe-force=10 ! splitmuxsink muxer=oggmux max-size-time=5000000000 location=/tmp/ogg-%05d.ogv

2)
gst-play-1.0 splitfile:///tmp/ogg-*ogv

 - let play a little
 - press '-' repeatedly to lower playback speed
 - press 'd' to reverse playback direction

Result: I don't see any problems or skips in the timestamps when crossing file boundaries
Comment 2 Jan Schmidt 2018-02-27 15:08:27 UTC
I'll have to try and remember what the test case was. It was something like that though - gaps and jumps in the timestamps in reverse playback
Comment 3 GStreamer system administrator 2018-11-03 11:54:56 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/340.