[Bug 791495] New: h265parse: Messes up timestamps for byte-stream
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Dec 12 00:22:37 UTC 2017
https://bugzilla.gnome.org/show_bug.cgi?id=791495
Bug ID: 791495
Summary: h265parse: Messes up timestamps for byte-stream
Classification: Platform
Product: GStreamer
Version: git master
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-bad
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: matej.knopp at gmail.com
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
It happens when previous frame has trailing zero. Parser split frame too early,
leaving trailing zeros as prefix for new frame, which results in messed up
timestamps.
Caused by following code in gst_h265_parser_identify_nalu
/* Mini performance improvement:
* We could have a way to store how many 0s were skipped to avoid
* parsing them again on the next NAL */
while (off2 > 0 && data[nalu->offset + off2 - 1] == 00)
off2--;
Annex B does says that there should be zero byte before AU startcode, however
it also says that during parsing the zero byte should be discarded. So maybe
determining the timestamp from zero byte is not a very good idea.
The stream already parsed by FFMPEG HEVC parser, which seems to leave zero byte
trailing, but that doesn't mean such files can't be encountered in the wild.
Btw. Why's there loop? Why skipping more than 1 zero byte? Doesn't that just
increases chance of messed up timestamps?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list