Workaround for clients like Chromium for AV1, misc fixes #407
Conversation
This is from Nvidia's own SDK code, MIT licensed for reference.
Chromium, at the very least, is a known client which sends one data block, then multiple params blocks for that one data block. Firefox, and FFmpeg, and other known clients, send one params block, then one data block. Handle both possibilities.
Chromium, and possibly other clients, do not fill out the superblock dimensions arrays if the bitstream is set for uniform tile dimensions. Take a note from Mesa, and intel media driver, and go a step further: Calculate the rounded tile dimensions for most of the columns, then calculate the remainder for the last column. This finally fixes AV1 in Chromium and all Chrome derived browsers.
kode54
changed the title
|
This is no longer a draft. Fully fixed. |
|
Is this PR good to go, or do you need some other fixes for the 10/12-bit issues? Also, I'd be interested in how you came up with the code to compute log2GobsPerBlockY, that variable has been a pain from the start. |
|
The code for the log2GobsPerBlockY code came from some MIT licensed Nvidia driver code. This still apparently needs work for 10/12 bit video, I don't know what's up with that. Clients requesting NV12 on CreateContext, but then requesting P010 surfaces. Really annoying trying to debug it. |
|
I think the issue with P010 and P012 formats is that the caller is not setting the config right for initializing the CreateContext. So it ends up initializing a decoder for 8bpc, but then sees that the video is 10bpc and creates surfaces for that. I really need something that logs every API call, so I can see where each browser is getting a config that tells it to try creating a context for 8bpc. For instance, Firefox and Chrome both at some point create configs with no parameters at all. |
|
Blah, I may as well close this. I'm having random AV1 videos just devolve into looping the reference frames in a stuttering mess after about 20 seconds of play time. I really wish the browsers would just use fricking Vulkan instead of libva. |
|
Okay. For reference: https://www.youtube.com/watch?v=VLdj9ZwpKfo&t=706s This video, from this timestamp. Chrome Dev channel plays it for 6-10 seconds, then for unknown reasons, decides to reinitialize the VA-API decoder, only this time, without the 10 bits per channel hint, so the decoder decides to emit 3840 (rounded up to 4096) pitch Y plane, which mismatches with the 7680 pitch Y array output surface, which is still primed for P010 decoding. Edit: I see what it's doing. It's pissing me off by randomly switching video formats 7 seconds into the video. |
2 participants
Clients like Chromium and company will send a single slice data buffer, followed by multiple slice params buffers. Work around this by handling both possible cases, including sending multiple series of params/data interleaved.
Intended to fix #405
This doesn't seem to work fully, so there's probably something else broken. It works with Firefox still, so at least I didn't break it.
Note that this handling behavior and offsets per data slice is what Mesa/Gallium does to accommodate similarly designed clients.