Issues playing some files in 5.1.x (regression for yuv444p videos on x86 architecture?)

[Leon Styhre]

Hi!

It seems as if there was a regression introduced in the 5.1.x release as some files won't play properly when using avfilter_graph_create_filter() on x86 processors.

I don't have conclusive information of exactly when this happens, but it seems as if it's possibly only affecting yuv444p files as yuv420p works fine according to my testing. I've seen the problem on Linux, Windows and macOS x86. macOS M1/ARM works fine though.

You can find the relevant code for my application here:
​https://gitlab.com/es-de/emulationstation-de/-/blob/master/es-core/src/components/VideoFFmpegComponent.cpp

The problematic function is VideoFFmpegComponent::setupVideoFilters() where the video width seems to trigger the issue. When using FFmpeg 4.4, or 5.0.1 it works fine but with 5.1.1 and 5.1.2 the video output is garbled. If I manually add 16 pixels to the video width for the problematic videos and pass that to avfilter_graph_create_filter(), then the rendering will look almost correct but a bit blurry as I guess something is slightly off with the channel alignment?

Here is one problematic video file that you can test with:
​https://es-de.org/temp/grdians.mp4

Here's an example image of the problem:
​https://es-de.org/temp/video_issues.png

And here's what it looks like with the workaround applied:
​https://es-de.org/temp/video_workaround.png

Note that these are just screenshots from a virtual machine so not direct output from the application, it's just meant as an illustration of the problem.

As the problem occurs on macOS x86 and not on macOS M1/ARM I guess this is somehow restricted to the x86 architecture?

I also tried building FFmpeg from the master branch (last commit b0c7352cd494c88d33f032be60b5e1c4e8b092a0) and it's the same problem as in the stable releases.

This is a pretty serious issues as it makes some files unplayable. The workaround mentioned above is not a feasible solution for my application as I'm not sure under what circumstances the issue occurs and there are some adverse side effects as well.

Thanks in advance!

[Elon Musk]

Your code is invalid, it assumes linesize==width. This is generally not true.

[Leon Styhre]

What do you mean it's invalid? What should I pick as filter parameter if not the width of AVCodecContext?

As well, if it's wrong why does the issue gets triggered only on x86 architecture with FFmpeg 5.1.x and later when it's been working perfectly for a long time across multiple operating systems, architectures and FFmpeg releases?

[Leon Styhre]

I think I figured it out, instead of using the width of AVFrame after calling av_buffersink_get_frame() I use linesize divided by four. This seems to work correctly on both older FFmpeg versions as well as 5.1.x for all the videos I've tested.

Could you please confirm whether this is a proper solution?

[Elon Musk]

There are functions to get required image stride for each pixel format.

All of this is off-topic as this is not programming help center but bug tracker.

[Leon Styhre]

Thanks, I got it sorted out, I always use the same output pixel format which has 4 bytes per pixel so it seems like everything is working fine now.