[FFmpeg-trac] #10158(avcodec:new): bsf 264_metadata removes stuffing bytes from NAL units - destroys original bitrate
FFmpeg
trac at avcodec.org
Sat Jan 28 13:14:56 EET 2023
#10158: bsf 264_metadata removes stuffing bytes from NAL units - destroys original
bitrate
-------------------------------------+-------------------------------------
Reporter: emcodem | Type:
| enhancement
Status: new | Priority: normal
Component: avcodec | Version: git-
Keywords: bsf | master
264_metadata H264 filtering | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Summary of the bug:
When using the h264_metadata bsf, "trailing zero bytes" of all NAL's are
removed. This leads to the output having a different bitrate than the
input.
This seems to be by design so i guess we talk about feature request not a
bug. I tried to check and workaround in a custom branch but had no luck,
it is just too complex. From feeling it starts in
cbs_h2645_fragment_add_nals (cbs_
h2645.c) but when i just comment the section "Remove trailing zeroes",
output is garbage.
How to reproduce:
{{{
% ffmpeg -i INPUT.h264 -codec copy -bsf:v
h264_metadata=colour_primaries=9,h264_metadata=delete_filler=0 OUTPUT.h264
}}}
I created a simplified source stream for testing that only contains a
single h264 frame in raw format, for playing with this it does not matter
if we have one or multiple source frames or a container or elementary
stream.
The example source file has 2 NAL's with "trailing_zero_bytes":
PPS: Original length 9472 bytes, length after bsf: 5 bytes
Last IDR slice: Original length ~1 MB, length after bsf: ~80kB
Just for explaination: the reason why the last IDR slice contains that
much zeros is that the pic content is a colorbar but the output bitrate is
constant 500Mbit/s (XAVC Class 300).
--
Ticket URL: <https://trac.ffmpeg.org/ticket/10158>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list