Opened 14 months ago

Last modified 13 months ago

#9007 new defect

dash muxer sets invalid bit depth on codecs line with vp9_vaapi encoder

Reported by: Gregory Beauregard Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: dash
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug: The dash muxer will produce a manifest with a codecs line having a "00" value in the bit depth section when using the vp9_vaapi encoder. For ex. "vp09.00.21.00" (third value, after 21). This causes the DASH playlist to be rejected for playback by Firefox and Chrome. Using libvpx with the same muxer settings and such yields "vp09.00.21.08" correctly. Spec says valid values for the bit depth are 08, 10, 12.
How to reproduce:
Generate a dash manifest with the dash muxer while passing a vp9_vaapi encoded video stream to it. Observe the codecs string in the manifest mpd file to see the bit depth line. Problem reproduced on master as of 2020-11-23.

Attachments (1)

ffmpeg-vpcc-hwaccel-bit-depth.patch (411 bytes ) - added by kepstin 14 months ago.
ffmpeg-vpcc-hwaccel-bit-depth.patch

Download all attachments as: .zip

Change History (4)

by kepstin, 14 months ago

ffmpeg-vpcc-hwaccel-bit-depth.patch

comment:1 by kepstin, 14 months ago

I have a suspicion that this is caused by the VPCC get_bit_depth function only seeing the hardware pixel format ("vaapi_vld" or so) rather than the real pixel format.

I've attached a patch (untested - i don't have any hardware capable of encoding vp9) which should make the VPCC functions fail if a hardware pixel format is seen, which should in turn cause the dash encoder to fall back to the generic "vp9" string rather than the ISOBMFF-based codec parameter string. (It will print out a warning "Could not find VP9 profile and/or level" if this happens.)

in reply to:  1 comment:2 by Gregory Beauregard, 14 months ago

Replying to kepstin:

I have a suspicion that this is caused by the VPCC get_bit_depth function only seeing the hardware pixel format ("vaapi_vld" or so) rather than the real pixel format.

I've attached a patch (untested - i don't have any hardware capable of encoding vp9) which should make the VPCC functions fail if a hardware pixel format is seen, which should in turn cause the dash encoder to fall back to the generic "vp9" string rather than the ISOBMFF-based codec parameter string. (It will print out a warning "Could not find VP9 profile and/or level" if this happens.)

The patch works as you described, but the resulting encode gives mp4 metadata decoding errors on Firefox and I wasn't able to play it with streamlink (utilizes ffmpeg, verbose output just said something about no stream data). I was able to play it with streamlink before the patch. I'm going to have to look into this more before making any definite conclusions (particularly the vaapi vp9 encoder in general), but I'm happy to take any suggestions if you have them.

Last edited 13 months ago by Gregory Beauregard (previous) (diff)

comment:3 by Gregory Beauregard, 14 months ago

The mp4 parsing error I get in firefox when I apply kepstin's patch is the same error I get when I pass the dash muxer a -copy'd opus stream (reencoding instead of copying works fine). I haven't filed a bug for the latter currently, but I mention in case it's a sort of related problem of the dash muxer relying on information it doesn't have in certain circumstances.

Note: See TracTickets for help on using tickets.