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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
