GNOME Bugzilla – Bug 781401
omxh264enc makes qtmux error out with "Buffer has no PTS."
Last modified: 2018-11-03 13:01:18 UTC
Test Environment: Raspberry Pi2 + Raspbian Apr.2014 (kernel 4.9.21-v7+) The following pipeline works under 1.8.x (gst-omx 1.2) but it fails after going to playing state since 1.10.x (gst-omx 1.10.x). gst-launch-1.0 v4l2src num-buffers=1500 device=/dev/video0 ! 'video/x-raw,format=I420,width=640,height=480' ! queue ! omxh264enc ! h264parse ! mp4mux ! filesink location=/tmp/stream The error message says "Buffer has no PTS." Meanwhile, the following pipeline works under 1.10.x, too. Note that the only difference of the two pipelines is: omxh264enc vs x264enc. gst-launch-1.0 v4l2src num-buffers=1500 device=/dev/video0 ! 'video/x-raw,format=I420,width=640,height=480' ! queue ! x264enc ! h264parse ! mp4mux ! filesink location=/tmp/stream Reverting a993883b (https://bugzilla.gnome.org/show_bug.cgi?id=772143) on the top of 1.10.4 code makes the pipeline to run again. IMHO, the time-handling problem of omxh264enc has come into the open by the stricter checking of qtmux/mp4mux since 1.10.0 (1.9.90 in fact).
The real solution for this is to fix bug #659489 and implement PTS from DTS and vice versa for proper timestamp handling in h264parse. That said, before we have that, I think we should revert a993883b
> That said, before we have that, I think we should revert a993883b Wouldn't that mean we may create broken files? I think we should avoid that, no matter how annoying.
Also, is this not fixable in the omx encoder? Does it not signal frame reordering and dts somehow?
a993883b prevents broken files from being created. Without that commit, qtmux does various calculations with GST_CLOCK_TIME_NONE. So no, reverting that one is not an option. OMX does not have a concept of DTS vs. PTS, you only have a single timestamp. You could do some fallback DTS calculation probably, by assigning as DTS the oldest PTS that is not output yet. Or something similar to that.
I've also seen some OMX components that output the SPS/PPS without a timestamp at the start before the first frame. Those should probably be ok with qtmux.
Since qtmux only takes stream_format=avc where sps/pps are passed in caps as codec_data that should be fine indeed.
Hi all, is there any update for this topic? Thanks in advance!
Though, this seems like a special case, since all input buffer have PTS, if there is a matching frame at output it should always have a PTS. What I think might happen is that we received a empty buffer in gst_omx_video_enc_handle_output_frame(), and in that case I think it's wrong to call gst_video_encoder_finish_frame() as it will drop that reference frame. This leads to "No corresponding frame found" which will not have a PTS. Maybe give that a try, and report ? I've made a similar fix for nvidia omx, but as Nvidia a hard to reconcile port, I didn't got the time yet to backport and test on the Pi. On the Zynq this zero lenght buffer case does not seem to exist.
-- 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-omx/issues/13.