h265parse: Breakage converting byte-stream/au format to hvc1/au format between 1.16.3 and 1.18.3
We have a camera which outputs an H265 stream in byte-stream/au format. With gst-plugins-bad 1.16.3, h265parse works fine - for instance we can record an MP4 successfully using:
gst-launch-1.0 -e ourvideosrc ! video/x-h265,width=1920,height=1080,framerate=30/1 ! queue ! h265parse ! mp4mux ! filesink location=test.mp4
However, with 1.18.3, this is broken - the pipeline fails, with the error:
ERROR: from element /GstPipeline:pipeline0/GstMP4Mux:mp4mux0: Could not multiplex stream. Additional debug info: ../gst-plugins-good-1.18.3/gst/isomp4/gstqtmux.c(5010): gst_qt_mux_add_buffer (): /GstPipeline:pipeline0/GstMP4Mux:mp4mux0: Buffer has no PTS.
Further, if instead of trying to record to MP4, the video is sent over RTP, then the received output on the other end is corrupted, with only the lefthand third of the video working - see attached recording
I've identified that this breakage was introduced by the commit e88d8480 - which is part of !399 (commits). Specifically, if I revert those changes, then it works fine again. I've further narrowed it down, so that if I partially revert that commit, with the following diff, then it works fine:
So I think there is an issue with the above change to h265parse functionality, in particular relating to how byte-stream H265 streams are handled. I'm not certain if my above diff is the correct fix, or if something further is required?