MPEG-2 and MPEG-4 videos are green in Totem

I’ve got some old videos that won’t play properly in Totem, but do play in ffplay and gst-play. The video opens, the audio plays, but the screen is pure green. Not “colour decoding went wrong and it’s tinted green” but just a single shade of green.

If I open a newer h.264 file then it plays fine in Totem.

As well as playing correctly in ffplay and gst-play, the video also plays partly okay in Showtime - the video shows and plays but there’s a lot of horizontal corruption.

$ file Videos/family/mov067.mpg
Videos/family/mov067.mpg: MPEG sequence, v2, program multiplex
$ ffprobe Videos/family/mov067.mpg
Input #0, mpeg, from 'Videos/family/mov067.mpg':
  Duration: 00:00:28.03, start: 0.199456, bitrate: 6613 kb/s
  Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, smpte170m, top first), 720x480 [SAR 32:27 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, start 0.266189
    Side data:
      CPB properties: bitrate max/min/avg: 8400000/0/0 buffer size: 1835008 vbv_delay: N/A
  Stream #0:1[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 384 kb/s, start 0.199456
$ file Videos/family/video-2011-12-06-10-07-42.mp4
Videos/family/video-2011-12-06-10-07-42.mp4: ISO Media, MP4 Base Media v1 [ISO 14496-12:2003]
$ ffprobe Videos/family/video-2011-12-06-10-07-42.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Videos/family/video-2011-12-06-10-07-42.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 0
    compatible_brands: isom3gp4
    creation_time   : 2011-12-06T10:11:54.000000Z
  Duration: 00:04:11.41, start: 0.000000, bitrate: 1634 kb/s
  Stream #0:0[0x1](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 62 kb/s (default)
    Metadata:
      creation_time   : 2011-12-06T10:11:54.000000Z
      handler_name    : SoundHandle
  Stream #0:1[0x2](eng): Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 1568 kb/s, 23.96 fps, 1k tbr, 90k tbn, start 0.004000 (default)
    Metadata:
      creation_time   : 2011-12-06T10:11:54.000000Z
      handler_name    : VideoHandle
      encoder         :          

Distro: Tumbleweed (updated yesterday)
ffmpeg: ffmpeg-8-8.1.1-2.1.x86_64
gstreamer: gstreamer-1.28.3-1.1.x86_64
Desktop: gnome-shell-50.1-44.1.x86_64 (Wayland)
Graphics: NVidia GeForce RTX 4070 Ti with nvidia-common-G06-580.159.03-56.1.x86_64
Environment: GDK_GL=gles set to avoid Totem#616 and GSK_RENDERER=glto avoid Showtime#276

@IBBoard Hi, The GSK option should not be needed as GTK4 is updated. What does the output from ffmpeg -hide_banner -decoders | grep mpeg2video show?

FWIW, I install the flatpak version of handbrake and use that for conversion…

$ ffmpeg -hide_banner -decoders | grep mpeg2video
 V.S.BD mpeg2video           MPEG-2 video
 V.S.BD mpegvideo            MPEG-1 video (codec mpeg2video)
 V..... mpeg2_v4l2m2m        V4L2 mem2mem MPEG2 decoder wrapper (codec mpeg2video)
 V....D mpeg2_qsv            MPEG2VIDEO video (Intel Quick Sync Video acceleration) (codec mpeg2video)
 V..... mpeg2_cuvid          Nvidia CUVID MPEG2VIDEO decoder (codec mpeg2video)

Which makes sense, because ffmpeg can play the video. Just not Totem.

The GSK option should not be needed as GTK4 is updated.

It looks like it should be fixed (tag list shows 4.22.2 and I’m running 4.22.4) but I still get vkAllocateMemory(): A device memory allocation has failed. and a segfault if I run GSK_RENDERER= showtime Videos/family/video-2011-12-06-10-07-42.mp4

FWIW, I install the flatpak version of handbrake and use that for conversion…

I’d rather not transcode the files. They’re already old and low quality without adding re-encoding on top!

I would suggest using showtime going forward. It’s likely a Mesa issue, but should have been fixed in 26.1.0 “After updating GStreamer, all videos in Showtime are green/purple)”
https://docs.mesa3d.org/relnotes/26.1.0.html

I’m running Mesa-26.1.0-2.1.x86_64, so it’s seemingly not fixed or not that issue. I’m not seeing green/purple in Showtime. I’m seeing striping. I’ve played with decoding image formats before and it looks a bit like what happens when you get the stride wrong and so your “row” of pixels isn’t mapping to a row in the display. But it moves around too quickly to be sure.

So my options are currently “fix the green video in Totem” or “open another thread to fix the same videos breaking in different ways in Showtime”.

@IBBoard No, it’s likely a Mesa bug report is probably required…

Could see if it’s Vulkan releated…

I use in a /etc/environment file on my Tumbleweed/Nvidia (Quadro RTX 4000) setup;

## CURRENT ##
## Reduce Mutter debugging output
MUTTER_DEBUG_FORCE_KMS_MODE=simple
## FFMPEG encode/decode options
ANV_VIDEO_DECODE="1"
ANV_DEBUG="video-decode,video-encode"
## END CURRENT ##

You can also look at using the flatpak version temporarily as a test with the stable and then master version to see if it duplicates.

I don’t think it is Vulkan. At least not in Totem.

I’ve tried some of the GDK_DISABLE values and even a list of all of the values with Totem and still get a green video.

For Showtime, if I run GDK_DISABLE=vulkan,gl showtime … or GDK_DISABLE=vulkan,egl showtime … then I avoid the crash, I see Gsk-WARNING: Failed to realize renderer 'GskGLRenderer' for surface 'GdkWaylandToplevel' in the output and the video renders correctly. If I could set that just for Showtime then that could be workable, but I don’t want to disable Vulkan and GL globally!

So are the libnvidia-egl-* libraries installed from the repo-non-free? I have;

zypper se -si egl

S  | Name                        | Type    | Version     | Arch   | Repository
---+-----------------------------+---------+-------------+--------+--------------
i  | gegl-0_4                    | package | 0.4.70-1.4  | x86_64 | repo-oss
i  | libgegl-0_4-0               | package | 0.4.70-1.4  | x86_64 | repo-oss
i  | libnvidia-egl-gbm1          | package | 1.1.3-11.2  | x86_64 | repo-non-free
i  | libnvidia-egl-wayland1      | package | 1.1.22-57.4 | x86_64 | repo-non-free
i  | libnvidia-egl-x111          | package | 1.0.5-26.2  | x86_64 | repo-non-free
i  | libwayland-egl1             | package | 1.25.0-1.2  | x86_64 | repo-oss
i+ | Mesa-demo-egl               | package | 9.0.0-7.3   | x86_64 | repo-oss
i  | Mesa-libEGL1                | package | 26.1.0-2.1  | x86_64 | repo-oss
i  | typelib-1_0-Gegl-0_4        | package | 0.4.70-1.4  | x86_64 | repo-oss
i  | typelib-1_0-GeocodeGlib-2_0 | package | 3.26.4-2.2  | x86_64 | repo-oss

Yeah, libnvidia-egl-* appears to be installed:

$ zypper se -si egl
S  | Name                                     | Type    | Version     | Arch   | Repository
---+------------------------------------------+---------+-------------+--------+--------------
i+ | gegl                                     | package | 0.4.70-1.4  | x86_64 | repo-oss
i+ | gegl-0_4                                 | package | 0.4.70-1.4  | x86_64 | repo-oss
i+ | gegl-0_4-lang                            | package | 0.4.70-1.4  | noarch | repo-oss
i+ | gegl-devel                               | package | 0.4.70-1.4  | x86_64 | repo-oss
i+ | libgegl-0_4-0                            | package | 0.4.70-1.4  | x86_64 | repo-oss
i+ | libmypaint-gegl0                         | package | 1.6.1-2.10  | x86_64 | repo-oss
i+ | libnvidia-egl-gbm1                       | package | 1.1.3-11.2  | x86_64 | repo-non-free
i+ | libnvidia-egl-gbm1-32bit                 | package | 1.1.3-11.1  | x86_64 | repo-non-free
i+ | libnvidia-egl-wayland1                   | package | 1.1.22-57.4 | x86_64 | repo-non-free
i+ | libnvidia-egl-wayland1-32bit             | package | 1.1.22-57.2 | x86_64 | repo-non-free
i+ | libnvidia-egl-x111                       | package | 1.0.5-26.2  | x86_64 | repo-non-free
i+ | libnvidia-egl-x111-32bit                 | package | 1.0.5-26.1  | x86_64 | repo-non-free
i  | libQt6WaylandEglCompositorHwIntegration6 | package | 6.11.0-1.2  | x86_64 | repo-oss
i+ | libwayland-egl1                          | package | 1.25.0-1.2  | x86_64 | repo-oss
i  | libwayland-egl1-32bit                    | package | 1.25.0-1.2  | x86_64 | repo-oss
i+ | Mesa-libEGL1                             | package | 26.1.0-2.1  | x86_64 | repo-oss
i+ | typelib-1_0-Gegl-0_4                     | package | 0.4.70-1.4  | x86_64 | repo-oss

But disabling it is what fixes the corruption in Showtime.

Did you try the flatpak versions? So if you don’t disable vulkan, does this work?

You could always copy the desktop file over to ~/.local/share/applications an modify the Exec= to include the flags?

Might need to wait for the G08 driver to drop and see if it’s present…

No, I’ve not had a chance to try the Flatpak yet. I’ll need to reinstall the Flatpak framework as well to try it. I’ll report back when I’ve tested it.

In case anyone else tries editing the Exec= command to fix something like this… it won’t work because Showtime is DBus enabled (DBusActivatable=true) and so it ignores the exec line.

The options are to change that to false as well (and lose whatever benefits DBus activation gives) or to set a global environment variable value.

Trying not to get too off-topic (since I was trying to fix Totem), but where would it be best to report the Showtime issue? Given that it only appears in Showtime and not ffmpeg/gst-play, is it a Showtime issue? Or is it a GStreamer issue and Showtime just uses different pipelines? Or is it a driver issue?

I’d say Showtime, but lets see what @iznogood thinks.

Lets figure out what codec is in use when its borked.

First, install gstreamer-utils if not already installed.

Run this command

gst-inspect-1.0 | grep h264 

(also please paste the output of zypper se -is gstreamer)

Since you have a nvidia card, and I presume use the binary driver (not nouveau) I bet nvh264dec is the culprit.

Once we have a list over h264 plugins you have available

GST_PLUGIN_FEATURE_RANK=avdec_h264:MAX showtime borked.mp4

Replace avdec_h264 with nvh264dec and openh264dec and possibly others depending what is available in your install.

showtime can also be replaced with totem/clapper/gst-play-1.0 etc (as long as it is a gst based player).

@iznogood I can check those things, but H264 is perfectly fine. The “video is completely green” problem is only MPEG2 and MPEG4 videos. And only in Totem, not gst-play or Showtime (the final posts were about a separate Showtime issue, because it was an app to compare against)

$ gst-inspect-1.0 | grep h264 
closedcaption:  h264ccextractor: H.264 Closed Caption Extractor
closedcaption:  h264ccinserter: H.264 Closed Caption Inserter
codec2json:  h2642json: H2642json
codectimestamper:  h264timestamper: H.264 timestamper
nvcodec:  nvautogpuh264enc: NVENC H.264 Video Encoder Auto GPU select Mode
nvcodec:  nvh264dec: NVDEC H.264 Decoder
nvcodec:  nvh264enc: NVENC H.264 Video Encoder CUDA Mode
openh264:  openh264dec: OpenH264 video decoder
openh264:  openh264enc: OpenH264 video encoder
rtp:  rtph264depay: RTP H264 depayloader
rtp:  rtph264pay: RTP H264 payloader
typefindfunctions: video/x-h264: h264, x264, 264
uvch264:  uvch264deviceprovider (GstDeviceProviderFactory)
uvch264:  uvch264mjpgdemux: UVC H264 MJPG Demuxer
uvch264:  uvch264src: UVC H264 Source
videoparsersbad:  h264parse: H.264 parser
vulkan:  vulkanh264dec: Vulkan H.264 decoder on NVIDIA GeForce RTX 4070 Ti
vulkan:  vulkanh264enc: Vulkan H.264 encoder on NVIDIA GeForce RTX 4070 Ti

Testing GST_PLUGIN_FEATURE_RANK values, the culprit is actually specifically not the NVidia codec. nvmpeg2videodec and nvmpeg4videodec are the only ones that actually work! avdec_mpeg2video, avdec_mpeg4, avdec_msmpeg4, avdec_msmpeg4v1 and avdec_msmpeg4v2 all still give a green screen.

So something is apparently wrong with the other codecs, but GStreamer (via Totem) is choosing to use them in preference to the NVidia one. Could it be because of the GLES problem in https://gitlab.gnome.org/GNOME/totem/-/issues/616?

Please run mediainfo problem.file

I assumed it was a h.264 encoded file. Lets have the full view of what/how the files in question are encoded.

So the hardware codecs works, but software ones fails, not what I expected at all.
This smells like a upstream bug, and can indeed be the one listed.
Does running totem via xwayland fix it?

I just installed Opensuse Tumbleweed. And I have the same problem with my GTX 1650 graphics card.If I run GDK_BACKEND=x11 totem video.mp4 the video is seen without problems. But on the first system boot with the drivers nouveau the video were seen

@iznogood: I had to install the mediainfo package. Here’s the details for an MPEG2 file:

General
Complete name                            : Videos/family/mov002.mpg
Format                                   : MPEG-PS
File size                                : 52.3 MiB
Duration                                 : 1 min 4 s
Overall bit rate mode                    : Variable
Overall bit rate                         : 6 790 kb/s
Frame rate                               : 29.970 FPS

Video
ID                                       : 224 (0xE0)
Format                                   : MPEG Video
Format version                           : Version 2
Format profile                           : Main@Main
Format settings                          : CustomMatrix / BVOP
Format settings, BVOP                    : Yes
Format settings, Matrix                  : Custom
Format settings, GOP                     : M=3, N=15
Format settings, picture structure       : Frame
Duration                                 : 1 min 4 s
Bit rate mode                            : Variable
Bit rate                                 : 6 271 kb/s
Maximum bit rate                         : 8 400 kb/s
Width                                    : 720 pixels
Height                                   : 480 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 29.970 (30000/1001) FPS
Standard                                 : NTSC
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Interlaced
Scan order                               : Top Field First
Compression mode                         : Lossy
Bits/(Pixel*Frame)                       : 0.605
Time code of first frame                 : 00:00:00:00
Time code source                         : Group of pictures header
GOP, Open/Closed                         : Closed
Stream size                              : 48.3 MiB (92%)
Color primaries                          : BT.601 NTSC
Transfer characteristics                 : BT.601
Matrix coefficients                      : BT.601

Audio
ID                                       : 189 (0xBD)-128 (0x80)
Format                                   : AC-3
Format/Info                              : Audio Coding 3
Commercial name                          : Dolby Digital
Muxing mode                              : DVD-Video
Duration                                 : 1 min 4 s
Bit rate mode                            : Constant
Bit rate                                 : 384 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 31.250 FPS (1536 SPF)
Compression mode                         : Lossy
Stream size                              : 2.96 MiB (6%)
Service kind                             : Complete Main
Dialog Normalization                     : -31 dB
compr                                    : -11.02 dB
dialnorm_Average                         : -31 dB
dialnorm_Minimum                         : -31 dB
dialnorm_Maximum                         : -31 dB

Menu
Format                                   : DVD-Video

And for an MPEG4 file:

General
Complete name                            : Videos/family/video-2011-12-06-10-07-42.mp4
Format                                   : MPEG-4
Format profile                           : Base Media
Codec ID                                 : isom (isom/3gp4)
File size                                : 49.0 MiB
Duration                                 : 4 min 11 s
Overall bit rate mode                    : Constant
Overall bit rate                         : 1 635 kb/s
Frame rate                               : 23.976 FPS
Encoded date                             : 1945-12-05 10:11:54 UTC
Tagged date                              : 1945-12-05 10:11:54 UTC

Video
ID                                       : 2
Format                                   : MPEG-4 Visual
Format profile                           : Simple@L0
Format settings                          : BVOP
Format settings, BVOP                    : Yes
Format settings, QPel                    : No
Format settings, GMC                     : No warppoints
Format settings, Matrix                  : Default (H.263)
Codec ID                                 : mp4v-20
Duration                                 : 4 min 11 s
Bit rate mode                            : Constant
Bit rate                                 : 1 570 kb/s
Nominal bit rate                         : 256 kb/s
Width                                    : 640 pixels
Height                                   : 480 pixels
Display aspect ratio                     : 4:3
Frame rate mode                          : Variable
Frame rate                               : 23.976 (23976/1000) FPS
Minimum frame rate                       : 6.161 FPS
Maximum frame rate                       : 40.706 FPS
Color space                              : YUV
Bit depth                                : 8 bits
Scan type                                : Progressive
Compression mode                         : Lossy
Bits/(Pixel*Frame)                       : 0.213
Stream size                              : 47.0 MiB (96%)
Title                                    : VideoHandle
Writing library                          :                                 
Language                                 : English
Encoded date                             : 1945-12-05 10:11:54 UTC
Tagged date                              : 1945-12-05 10:11:54 UTC
mdhd_Duration                            : 251407

Audio
ID                                       : 1
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 4 min 11 s
Bit rate mode                            : Constant
Bit rate                                 : 62.6 kb/s
Nominal bit rate                         : 96.0 kb/s
Channel(s)                               : 1 channel
Channel layout                           : M
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 1.88 MiB (4%)
Title                                    : SoundHandle
Language                                 : English
Encoded date                             : 1945-12-05 10:11:54 UTC
Tagged date                              : 1945-12-05 10:11:54 UTC

@Cubo3D - thanks for testing the X11/XWayland(?) backend. I didn’t know how to do that. I can confirm the same behaviour here.

Interestingly, it also fixes the striping/corruption problem in Showtime. Maybe it is different manifestations of the same “software decoding in a GL/EGL/GLES/whatever-graphics-acceleration app instances” bug? Totem fails and goes green, whereas showtime attempts something with the corrupt return and shows striping.

OK so nothing exotic.
Does GDK_GL=gles totem problem.file also make it work?
If yes, then this is a issue needing solving somewhere between nvidia, mesa, gstreamer or gtk and or totem/showtime.
Though since forcing it to run via xwayland kinda already proves this.

Edit:
If GDK_GL=gles works you could do this as a workaround:

 mkdir ~/.config/environment.d
vim ~/.config/environment.d/gdk.conf
GDK_GL=gles inside gdk.conf ```

As per my first post, I’ve already got that environment variable set because if I don’t then I hit Totem#616 and Totem won’t run because it fails to initialise OpenGL support.

So no, GLES doesn’t fix it. I still get a green video. Disabling GL or EGL does fix it (but logs a warning)