On Wed Feb 12 14:57:44 2025 +0000, Rémi Bernon wrote:
Which it would also do with this arbitrary split. If this works then parsers don't accumulate more than necessary, which is likely frame or sub-frame granularity. Using the parser standalone for splitting is also going to help zero copy: we can only write to the client buffers one frame at a time. Pushing data that decodes to more than one frame will require these frames to be decoded into unix-side buffers and copies to be done later to the client buffers.
re: how `h264parse` splits; if you run `gst-inspect-1.0 h264parse`, you'll see one of the caps is `alignment`, which has two options: 1. `au`; and 2. `nal`
So it can split the buffers in one of two ways: 1. at the `au` boundary (which stands for 'Access Unit', and represents a frame (or a field for interlaced); or 2. at the 'nal' boundary. These are smaller than access units and represent a logical bundle of data (which can be metadata or image data). An AU may have several NALs, but a NAL will never overlap two AUs.