Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

The_Connaisseur · 2024-11-11 05:14:55

Hello Archers,

I'm using a Lenovo T530 (3rd Gen i7-3630QM with HD 4000 GPU). Was falling a little back with "pacman -Suy", but did it recently.

When using mpv for accelerated video playback a h264 720p TV-Recording I'm confronted with greenish blocks. They go away, when I switch off video acceleration, but that's a bad use case. :-(

After rolling back ffmpeg to 7.0.2-3 and x265 to 3.6-1 situation is completely back to normal.

Of course mpv needed an downgrade as well (back to 1:0.39.0-1, due to rubberband dependency (downgraded back to 3.3.0-2).

After all above mentioned downgrades accelerated video playback is 100% fine again!

Where to look? Where to turn to?

CU,
--connaisseur

PS: If this not the right forum for the question, please move it to an approbate one.

seth · 2024-11-11 08:21:04

a h264 720p TV-Recording

What about a youtube video?

mpv -ytdl-raw-options='format="140+136"' 'https://www.youtube.com/watch?v=Px6S0RxfAHg'

Do you get any errors? (Post the full output)
You're not using some vdpau shim, are you?

The video incidentally has a lot of black blocks, is there any pattern to those "greenish" blocks? Is it maybe the color key?

The_Connaisseur · 2024-11-11 09:17:24

Updated back to recent versions:

4  extra/ffmpeg      2:7.0.2-3  -> 2:7.1-2
3  extra/mpv         1:0.39.0-1 -> 1:0.39.0-3
2  extra/rubberband  3.3.0-2    -> 4.0.0-1
1  extra/x265        3.6-1      -> 4.0-1

seth wrote:

What about a youtube video?
mpv -ytdl-raw-options='format="140+136"' 'https://www.youtube.com/watch?v=Px6S0RxfAHg'
Do you get any errors? (Post the full output)

Plays back with above installed versions perfectly.

Output:

[530 tmp]$ mpv -ytdl-raw-options='format="140+136"' 'https://www.youtube.com/watch?v=Px6S0RxfAHg'
● Video  --vid=1               (h264 1280x720 24 fps) [default]
● Audio  --aid=1  --alang=eng  (aac 2ch 44100 Hz 128 kbps) [default]
File tags:
 Date: 20240624
 Uploader: Universal Pictures UK
 Channel_URL: https://www.youtube.com/channel/UCQLBOKpgXrSj3nPU-YC3K9Q
Cannot load libcuda.so.1
[ffmpeg] AVHWFramesContext: Failed to write image to surface 0x4000001: 20 (the requested function is not implemented).
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 1280x720 vaapi[nv12]
AV: 00:00:20 / 00:01:44 (20%) A-V:  0.000 Cache: 83s/6MB 
Exiting... (Quit)
[t530 tmp]$

seth wrote:

You're not using some vdpau shim, are you?

Err, yes.

pacman shows:

libvdpau 1.5-3
mesa-vdpau 1:24.2.6-1

Remove them?

seth wrote:

The video incidentally has a lot of black blocks, is there any pattern to those "greenish" blocks? Is it maybe the color key?

I could provide a screenshot. How is image posting (1280x720, 550KB) handled / allowed here?

seth · 2024-11-11 09:26:35

Upload to imgur.com or so (you can also paste images t o0x0.st) and post a link, embedded images are supposed to be <= 250x250

libvdpau isn't one of the vdpau shims but the API and mpv uses VAAPI, so that's not a problem.
Do you get any errors w/ "mpv -v path/to/recording.mp4" and what's the general output of that?

The_Connaisseur · 2024-11-11 14:05:29

Yes, I get same errors (blockish green screen) when using "mpv -v".

Collected some requested data and uploaded them.

mpv-green-blockish-screenshot:
https://0x0.st/Xk-V.png

my ~/.config/mpv.conf :
http://0x0.st/Xkoh.txt

and the output of "mpv -v" of the video playback:
http://0x0.st/Xko7.txt

Last edited by The_Connaisseur (2024-11-11 14:07:30)

seth · 2024-11-11 14:29:40

[ffmpeg/video] h264: Increasing reorder buffer to 1
[ffmpeg/video] h264: Increasing reorder buffer to 2
[ffmpeg/video] h264: co located POCs unavailable
[ffmpeg/video] h264: Increasing reorder buffer to 3

Are you getting those w/ the older versions?

The video is actually a matroska w/ also an mp2 and an ac3 and an srt stream…
=>

mkvextract 'Nicole Kidman - Eyes Wide Open.mkv' tracks 0:test.h264
mpv test.h264 # same green stuff blocks?

ffmpeg -v error -i test.h264 -f null - 2>error.log # this will re-encode the video nowhere and print all errors

How was the video recorded/encoded? Probably using some hardware encoder?

The_Connaisseur · 2024-11-11 18:14:20

Rolled installation back...

seth wrote:

[ffmpeg/video] h264: Increasing reorder buffer to 1
[ffmpeg/video] h264: Increasing reorder buffer to 2
[ffmpeg/video] h264: co located POCs unavailable
[ffmpeg/video] h264: Increasing reorder buffer to 3

Are you getting those w/ the older versions?

Yes. See next code block (with rolled back ffmpeg / mpg / x265 / rubberband):

Cannot load libcuda.so.1
[ffmpeg] AVHWFramesContext: Failed to write image to surface 0x4000001: 20 (the requested function is not implemented).
Using hardware decoding (vaapi).
AO: [pipewire] 48000Hz stereo 2ch s16p
VO: [gpu] 1280x720 vaapi[nv12]
[ffmpeg/video] h264: Increasing reorder buffer to 1
[ffmpeg/video] h264: Increasing reorder buffer to 2
[ffmpeg/video] h264: co located POCs unavailable
[ffmpeg/video] h264: Increasing reorder buffer to 3

seth wrote:

[The video is actually a matroska w/ also an mp2 and an ac3 and an srt stream…
=>

mkvextract 'Nicole Kidman - Eyes Wide Open.mkv' tracks 0:test.h264
mpv test.h264 # same green stuff blocks?

ffmpeg -v error -i test.h264 -f null - 2>error.log # this will re-encode the video nowhere and print all errors

Result: http://0x0.st/Xk8N.txt

seth wrote:

How was the video recorded/encoded? Probably using some hardware encoder?

Recording: tvheadend (git latest) + sundtek USB DVB-S2 Twin-Tuner (userland-"driver" is most recent version) --> TS-File
Cutting / Trimming / Demuxing: Cypheros TSdoctor 4.1x w/ wine 8.1-1.
Remuxing: mkvtoolnix-gui (mkv in question was done with v79.0).

No HW x264 re-encoding was triggered, h.264 ES was taken as-is from demuxed stream.

The_Connaisseur · 2024-11-11 18:26:39

Took the occasion to sync other personal gear to recent arch version levels with "pacman -Suy" and testing that same MKV-File in question for greenish-blocks.

All systems where freshly booted after pacman-sync.

This gear was available:

Intel NUC13ANH i7-1360P Raptor Lake - Intel Iris Xe --> OK
Lenovo X1C6 i7-8550U Kaby Lake - Intel UHD Graphics 620 --> OK
Acer B116 N3700 - Braswell - Intel HD Graphics for Intel Celeron Processor N3000 Series --> OK

The messages of ffmpeg/video stayed same everywhere. Here an example from the Acer B116:
http://0x0.st/Xk8H.txt

Currently only the Lenovo T530 with it's Gen3 i7 and Intel HD 4000 GPU, which shows the issue.

seth · 2024-11-11 20:24:40

The video seems mildly corrupted (it's essentially a dvb streamdump, not sure how well TSdoctor works), apparently the older ffmpeg is better and mitigating this.
The errors seem pretty early on, do the blocks go away when you skip around in the video or "mpv --start=60 Nicole\ Kidman\ -\ Eyes\ Wide\ Open.mkv"
Do you get this w/ other videos (and are they all out of the same pipeline)?

Regardless of the ffmpeg regression, you could try to re-encode it, even using https://wiki.archlinux.org/title/FFmpeg … Sync_(QSV) for hardware ENcoding

Sure the Acer system used (intel) HW decoding?

[vaapi] libva: /usr/lib/dri/iHD_drv_video.so init failed

pacman -Qs intel-media-driver
glxinfo -B

The_Connaisseur · 2024-11-15 19:40:42

seth wrote:

The video seems mildly corrupted (it's essentially a dvb streamdump, not sure how well TSdoctor works), apparently the older ffmpeg is better and mitigating this.

That's for sure the case!

But again - for the record - only on old > 10 years old Lenovo T530 with it's Gen3 i7 this has serious visible(!) effects when using ffmpeg 7.1.

With all more recent Intel CPU / GPU Combos this "forgiveness" with ffpmeg 7.1 seems still to be the case.

seth wrote:

The errors seem pretty early on, do the blocks go away when you skip around in the video or "mpv --start=60 Nicole\ Kidman\ -\ Eyes\ Wide\ Open.mkv"

That didn't had any positive effect! Unluckily, no.

seth wrote:

Do you get this w/ other videos (and are they all out of the same pipeline)?

Yes. Some are completely OK, some have the same troubles. The more older, the less often I found the issue. But I've checked only at random.

seth wrote:

Regardless of the ffmpeg regression, you could try to re-encode it, even using https://wiki.archlinux.org/title/FFmpeg … Sync_(QSV) for hardware ENcoding

Yes. I did this.

But I couldn't get QSV HW encoding to work.

Used VAAPI HW-Encoding style with:

ffmpeg -threads 8 -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -extra_hw_frames 10 \
-i Nicole\ Kidman\ -\ Eyes\ Wide\ Open.mkv \
-vf 'format=nv12|vaapi,hwupload' \
-c:v h264_vaapi -rc_mode 3 -profile:v main -level 4.1 \
-b:v 9000k -map 0:v -map 0:a -map 0:s -c:a copy -c:s copy v_hw.mkv

That re-encode worked flawlessly with ffmpeg 7.1 and updated mpv player.

seth wrote:

Sure the Acer system used (intel) HW decoding?
[vaapi] libva: /usr/lib/dri/iHD_drv_video.so init failed
pacman -Qs intel-media-driver
glxinfo -B

Yes. I'm sure. See:
http://0x0.st/Xkhu.txt

seth · 2024-11-15 20:28:55

With all more recent Intel CPU / GPU Combos this "forgiveness" with ffpmeg 7.1 seems still to be the case.

Because of

The wiki wrote:

HD Graphics series starting from Broadwell (2014) and newer (e.g. Intel Arc) are supported by intel-media-driver.
GMA 4500 (2008) up to Coffee Lake (2017) are supported by libva-intel-driver.

?

That re-encode worked flawlessly with ffmpeg 7.1 and updated mpv player.

Ie re-enconding fixed the video and prevented the issue?

Yes. I'm sure. See:

Seems you've intel-media-driver installed but end up using libva-intel-driver because the braswell SoC isn't expectably supported by intel-media-driver (so no surprise there, just pointless package installation)

So indeed only the older Ivy- (and probably Sandy-)bridge IGPs along libva-intel-driver and the most recent ffmpeg expose the corruption.
==> Is it the only system tested with (probably) mesa-amber instead of mesa?

Arch Linux

#1 2024-11-11 05:14:55

Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

#2 2024-11-11 08:21:04

Re: Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

#3 2024-11-11 09:17:24

Re: Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

#4 2024-11-11 09:26:35

Re: Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

#5 2024-11-11 14:05:29

Re: Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

#6 2024-11-11 14:29:40

Re: Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

#7 2024-11-11 18:14:20

Re: Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

#8 2024-11-11 18:26:39

Re: Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

#9 2024-11-11 20:24:40

Re: Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

#10 2024-11-15 19:40:42

Re: Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

#11 2024-11-15 20:28:55

Re: Video playback w/ greenish blocks after ffmpeg 7.1 / x265 4.0 upgrade

Board footer