GNOME Bugzilla – Bug 774136
mpegtsmux: PES payload size overflow for unbounded video streams bigger than 65K per frame
Last modified: 2018-11-03 13:56:36 UTC
Created attachment 339372 [details] [review] PES payload size overflow for unbounded video streams 65K per frame Hi, In mpegtsmux when dealing an unbounded video streams the PES packet payload size should be 0. Every frame should be stored in single PES packet. Which is also mentioned in tsmuxstream.c:tsmux_stream_consume() In tsmuxstream.c:tsmux_stream_initialize_pes_packet() at the beginning there is copy of the current PES payload size from 32bit integer into 16 bit integer. When single video exceed 65K per frame the frame size is lost due to overflow of cur_pes_payload_size variable, which is wrong. Later the cur_pes_payload_size is used in loop for creating the PES packets stream->cur_pes_payload_size = stream->bytes_avail; bytes_avail correspond to the buffer size or the video frame size, and it should be 32 bit instead of 16
Nice catch, thanks. I believe the intention of the code is to only make the payload size 0 if the packet size can't be expressed in 16 bits, and set it for smaller frames, which makes sense to me. I don't think the spec mandates or recommends always setting it to 0 regardless? And we have framed input so we know.
-- 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/438.