[FFmpeg-devel] Re: [PATCH 1/3] avcodec/avpacket: add av_packet_resize()

[Anton Khirnov]

Quoting James Almer (2021-03-14 16:35:48)
> On 3/14/2021 7:34 AM, Anton Khirnov wrote:
> > Quoting James Almer (2021-03-12 18:24:47)
> >>
> >> The padding exists AFAIK because something, like an optimized bitstream
> >> reader that tries to process several bytes at the same time, may end up
> >> reading or writing pass the reported end of the buffer.
> >> That means that if reading and it's not all zeroes, it could in theory
> >> have unpredictable results. Hence why everything always zeroes the
> >> padding, even av_shrink_packet().
> > 
> > On that topic, I've been wondering about eliminating this requirement.
> > Does anyone know which code it is precisely that depends on the padding
> > being zeroed? Is this optimization really worth it?
> > It seems rather silly to jump through all these hoops for an
> > unmeasurable benefit in one decoder.
> 
> Some subtitle demuxers didn't look at pkt->size and depended on the 
> padding to work as a 0 string terminator, but Marton fixed that in a 
> patchset sent yesterday.
> 
> Beyond that, i think the v210 decoder and encoder read and write past 
> the end of the buffer if you use the simd functions.
> 
> > 
> > It would also give us zero-copy packet splitting.
> > 
> > [...]
> > 
> > I would suggest keeping av_shrink_packet() with a big scary warning that
> > it does not check for ownership and it is the caller's responsibility to
> > ensure that writing to the packet is safe.
> 
> If we can remove the zero-padding requirement, or the padding 
> requirement altogether, then that would no longer be necessary.

I don't think we can remove the padding requirement completely, as the
bitstream reader reads 4- or 8-byte chunks at once. I imagine changing
that into single-byte reads would be very slow.
But getting rid of the zeroing requirement should be more feasible.

-- 
Anton Khirnov