elFarto
Workaround for clients like Chromium for AV1, misc fixes
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.
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.