"GStreamer" (GNOME Bugzilla)
2016-01-25 14:51:04 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=761086
Bug ID: 761086
Summary: splitmuxsrc: use the max ts of all streams as the
offset to align the next stream with
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-good
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@collabora.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---
Created attachment 319684
--> https://bugzilla.gnome.org/attachment.cgi?id=319684&action=edit
splitmuxsrc: use the max ts of all streams as the offset to align the next
stream with
Splitmuxsrc currently finds and uses the minimum timestamp of all streams
(audio/video/subtitle) as the first timestamp for the next part, but this is
incorrect and gets noticed when you have subtitles, which are sparse. (In
audio/video cases it can easily go unnoticed because the ending timestamps are
very close together)
So for example if the current part ends at t=5s and the last subtitle was at
t=1s, then the next part's timestamps start from t=1s and you lose 4 seconds of
data in the output.
The attached patch fixes the issue.
Bug ID: 761086
Summary: splitmuxsrc: use the max ts of all streams as the
offset to align the next stream with
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-good
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@collabora.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---
Created attachment 319684
--> https://bugzilla.gnome.org/attachment.cgi?id=319684&action=edit
splitmuxsrc: use the max ts of all streams as the offset to align the next
stream with
Splitmuxsrc currently finds and uses the minimum timestamp of all streams
(audio/video/subtitle) as the first timestamp for the next part, but this is
incorrect and gets noticed when you have subtitles, which are sparse. (In
audio/video cases it can easily go unnoticed because the ending timestamps are
very close together)
So for example if the current part ends at t=5s and the last subtitle was at
t=1s, then the next part's timestamps start from t=1s and you lose 4 seconds of
data in the output.
The attached patch fixes the issue.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.