Feb. 12, 2025
3:24 p.m.
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7288#note_94381