Opened 22 months ago

Closed 22 months ago

Last modified 22 months ago

#9953 closed defect (invalid)

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

Reported by: Leon Styhre Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Leon Styhre Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no



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:

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:

Here's an example image of the problem:

And here's what it looks like with the workaround applied:

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!

Change History (6)

comment:1 by Elon Musk, 22 months ago

Resolution: invalid
Status: newclosed

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

comment:2 by Leon Styhre, 22 months ago

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?

comment:3 by Leon Styhre, 22 months ago

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?

comment:4 by Elon Musk, 22 months ago

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.

comment:5 by Leon Styhre, 22 months ago

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.

comment:6 by Carl Eugen Hoyos, 22 months ago

Component: avfilterundetermined
Priority: importantnormal
Note: See TracTickets for help on using tickets.