#8622 closed defect (fixed)

Bitstream filter hevc_metadata fails with "bit_equal_to_one out of range" on Linux but works on Windows for hevc_nvenc

Reported by: Sonic-Y3k Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: vbsf
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: yes

Description

Summary of the bug:

When setting the hevc_metadata bitstream filter in combination with hevc_nvenc the following error message appears:

[AVBSFContext @ 0x558a46855680] bit_equal_to_one out of range: 0, but must be in [1,1].
[AVBSFContext @ 0x558a46855680] Failed to read unit 0 (type 39).
[AVBSFContext @ 0x558a46855680] Failed to read packet.
Error applying bitstream filters to an output packet for stream #0:0.

Strangely enough, if the same ffmpeg version is cross compiled for Windows it just works without any issues.

How to reproduce:

% ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v hevc_nvenc -bsf:v "hevc_metadata=colour_primaries=9" -f hevc -y -t 00:00:10 /dev/null

ffmpeg N-97380-g55d830f69a
built on 17.04.2020

linux nvidia driver: 440.82
windows nvidia driver: 445.75

Attachments (5)

ffmpeg_linux.log.xz (426.5 KB ) - added by Sonic-Y3k 18 months ago.
Linux Log-File
ffmpeg_windows.log.xz (494.6 KB ) - added by Sonic-Y3k 18 months ago.
Windows Log-File
error_applying_bsf_hevc_metadata_while_using_hevc_nvenc.mp4 (2.4 MB ) - added by Sonic-Y3k 18 months ago.
Example Input
nvenc_encoded_hevc_stream.hevc (1.0 MB ) - added by Sonic-Y3k 18 months ago.
nvenc_encoded_hevc_stream.hevc
difference_between_linux_windows.png (102.0 KB ) - added by Sonic-Y3k 18 months ago.
Difference between Nal Units in Windows and Linux

Change History (14)

by Sonic-Y3k, 18 months ago

Attachment: ffmpeg_linux.log.xz added

Linux Log-File

by Sonic-Y3k, 18 months ago

Attachment: ffmpeg_windows.log.xz added

Windows Log-File

comment:1 by Sonic-Y3k, 18 months ago

Version: unspecifiedgit-master

comment:2 by Carl Eugen Hoyos, 18 months ago

Keywords: hevc_nvenc nvenc hevc_metadata nvidia colour_primaries bitstream filter bsf bit_equal_to_one removed

You do realise that compressing the logs is a certain way to make understanding a ticket as difficult as possible?

Is encoding necessary to reproduce or can you provide an input file that leads to the same behaviour?

comment:3 by Sonic-Y3k, 18 months ago

I think that encoding is necessary to reproduce this behavior. As an input file I used the big buck bunny example (link). But I really experienced this behavior with every single file I tried.

If you want, I can upload a dd-ed sample to the ftp.

comment:4 by Carl Eugen Hoyos, 18 months ago

So if you first encode the raw hevc file and then stream-copy it into another hevc file using the bitstream filter, the issue is not reproducible?

in reply to:  4 comment:5 by Sonic-Y3k, 18 months ago

Replying to cehoyos:

So if you first encode the raw hevc file and then stream-copy it into another hevc file using the bitstream filter, the issue is not reproducible?

If I first encode the file with

ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v hevc_nvenc -f hevc -t 00:00:10 test_hevc.hevc

and afterwards execute the following:

ffmpeg -i test_hevc.hevc -c:v copy -bsf:v "hevc_metadata=colour_primaries=9" -f hevc test_out_hevc.hevc

the error occurs again:

[hevc_metadata @ 0x55620167e880] bit_equal_to_one out of range: 0, but must be in [1,1].
[hevc_metadata @ 0x55620167e880] Failed to read unit 3 (type 39).
[hevc_metadata @ 0x55620167e880] Failed to read packet.
Error applying bitstream filters to an output packet for stream #0:0.
[hevc_metadata @ 0x55620167e880] bit_equal_to_one out of range: 0, but must be in [1,1].
[hevc_metadata @ 0x55620167e880] Failed to read unit 3 (type 39).
[hevc_metadata @ 0x55620167e880] Failed to read packet.
Error applying bitstream filters to an output packet for stream #0:0.

So it is reproducible.

I attached the raw hevc stream to this ticket as "nvenc_encoded_hevc_stream.hevc"

Edit: With that encoded file, the error also occurs in windows.
Edit2: The NALs seem to have a different Length aswell:
Difference between Nal Units in Windows and Linux

Last edited 18 months ago by Sonic-Y3k (previous) (diff)

by Sonic-Y3k, 18 months ago

nvenc_encoded_hevc_stream.hevc

by Sonic-Y3k, 18 months ago

Difference between Nal Units in Windows and Linux

comment:6 by mkver, 18 months ago

Analyzed by developer: set

The cbs_h265 code completely ignores the possibility of reserved_payload_extension_data that may be present at the end of every SEI message. The uploaded sample has 8 zero bits of reserved_payload_extension_data present.

(The current version of the spec says that reserved_payload_extension_data shall not be present in bitstreams conforming to this version of the specification, so its presence may very well be a bug somewhere. But even then cbs_h265 should not error out and has to treat this as potential reserved_payload_extension_data; right now this seriously impairs cbs_h265's forward compatibility.)

comment:7 by Carl Eugen Hoyos, 18 months ago

Keywords: vbsf added

Additionally, isn't it a fundamental issue that the bitstream filters do not know that containers exist which allow unreliable transmission and damage (like transport streams)?

comment:8 by mkver, 18 months ago

The cbs-stuff is designed to be picky so that they indeed may drop whole packets when fed with invalid input (which may be a result of errors during transmission). So while it would be easily possible to relax this a bit (e.g. don't fail if an inessential unit like a SEI seems invalid; instead just drop the unit), it has therefore not been added to master.

comment:9 by James, 18 months ago

Resolution: fixed
Status: newclosed

The extra byte in the SEI message is most assuredly bogus, so it would probably be worth looking into why nvenc generated it.

Nonetheless, reserved_payload_extension_data parsing has been implemented in 3d51d3b42d0eee10301b06aaa814454c5e38eed6, so the sample should no longer fail with CBS based bitstream filters.

Note: See TracTickets for help on using tickets.