Webm sequence header doesn't match AV1 bitstream, causing problems on playback #5081
Comments
jmitz5
changed the title
|
Can you try an HandBrake snapshot and see it if helps? https://github.com/HandBrake/HandBrake-snapshots |
|
BTW it could also be a problem in FFmpeg. I don't know if the code responsible to write the private header in WebM/MP4 is within Handbrake or FFmpeg (libavcodec+libavformat) which is used here to create the file. It may also be an issue of SVT-AV1 not reporting the proper AV1 Sequence Header on startup. |
|
It could be, but the SVT-AV1 integration has been reworked in the snapshots, so it's worth a try at least. Line 329 in 9a1c896 |
I tried it again with the snapshot (took some time, av1 is mega slow). Same results in vlc. I don't know how to check if the sequence header mismatch situation has improved. Maybe I'll send the files over through the Videolan thread. |
|
Please do. |
|
It just looks like SVT-AV1's svt_av1_enc_stream_header does give us a different sequence header than what he encoder includes in the bitstream; this probably needs to be reported to and discussed with their developers. Adding it to my list. |
ghost
self-assigned this
If the AV1 extra data in the container don't match the bitstream (invalid file) we end up missing some pictures when using extra resolution. This can be triggered by this bug in Handbrake with SVT-AV1: HandBrake/HandBrake#5081 Ref. #28002
|
Does the latest SVT-AV1 still exhibit this? |
Problem Description
I'm gonna be honest, this is a bit over my head. I'm passing this along from a VLC dev who is working through a bug I found over there. There is a problem with VLC's decoding of AV1 with the "super-resolution" anamorphic feature. The dev says that at least part of the problem has to do with the output of my handbrake encode:
"I can confirm the
sequence headerin the WebM part doesn't match the one in the bitstream:header:
0A 0E 00 00 00 42 A7 BF E3 E0 17 C2 80 80 80 96
bitstream:
0A 0E 00 00 00 42 A7 BF E3 E7 DF DE 80 80 80 96
So technically the file is invalid. It's unrelated to our issue, but it makes fixing harder. You should report the bug to Handbrake so they fix the issue.
One important reason to fix this is that if we want to use hardware decoding, we need to have the proper sequence header before starting decoding, so we can tell if the hardware can decode it or not."
Here is the link to the Videolan thread for more context: VLC cannot properly display this SVT-AV1 webm file with "Super resolution" feature
Basically, there is some issue with VLC's dav1d causing the "super-resolution" scaling to be glitchy, and it is exacerbated by this header issue from the handbrake. The file in question can be found there as well. The logs I provided are correct, but I renamed the file after encoding, so it doesn't appear to match.
Activity Log, Crash Log or any other details
What Operating System are you running?
MacOS 10.13.6
What version of HandBrake are you running?
1.6.1
Where did you download HandBrake from?
handbrake.fr
The text was updated successfully, but these errors were encountered: