GNOME Bugzilla – Bug 791495
h265parse: Messes up timestamps for byte-stream
Last modified: 2018-11-03 14:16:32 UTC
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?
Maybe you could make a unit test for this? :)
Okay, the loop doesn't make any difference because of the following code if (nalu.sc_offset > 0) { *skipsize = nalu.sc_offset; So perhaps changing this to if (nalu.offset > 3) { *skipsize = nalu.offset - 3; would discard the zero_byte, which is what we should do according annex b?
Created attachment 365396 [details] [review] Experimental patch I agree unit test would be nice, but for now at least experimental patch, seems to fix the situation for me
Well, while working this patch probably also introduces DISCONT buffers.
Created attachment 365425 [details] [review] Better patch Inspired by h264parse, should not cause unnecessary discont buffers
I notice this difference between H264/H265parse and was wondering why we did that extra loop. Make sense.
-- 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-bad/issues/641.