Vlc 3.0.17.4 fails playing mpeg2 ts

Support Software & Applications
1

When I try to play an mpeg2 (dvb-s recording) ts file with vlc 3.0.17.4-7 on actual Manjaro stable (XFCE) I see different bad behaviour - on two very different computers - either video remains black, or picture evolves jumpy while remaining still for times, or only left part of picture showing, blocky, then colourful blocks, then grey towards right. One of the computers crashed two times after running the blocky video for several minutes… After that I stopped it always immediately if the video playback failed.

The same happpened when I booted 21.3.2 installation media either XFCE or KDE and tried the included vlc. No issues playing the same file on the same computer on W10 vlc 3.0.17.4 or even on vlc (32bit) for Windows on wine in the same Manjaro where it fails to play on the Linux-VLC.
Just tried debian live media, added vlc 3.0.17.4 via apt-get - no issue to play the same .ts.

If the video and audio stream are re-multiplexed to mpeg ps (.mpg) by ffmpeg -c copy, I can play the same video that just failed as .ts on the same vlc. I also tried to skip some part from the beginning and copy the video and audio only to a .ts - can’t play the .ts, but no issue playing the same video and audio multiplexed as .mpg.
Two weeks ago(?) before some updates I had no such issues with .ts files from the same receiver. Unfortunately I have no exact date when it was working last on which versions. Any ideas?

Thank you,
Dirk

2

Do you have any error when launching it from the terminal?

3

Yes, there are endlessly lines:

$ vlc 000.ts
VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)
[0000564bafe415d0] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
[mpeg2video @ 0x7f01c0006180] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f01c0006180] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f01c0006180] Invalid frame dimensions 0x0.
[00007f01ccc0b810] main decoder error: buffer deadlock prevented
[00007f01ccc19da0] main decoder error: buffer deadlock prevented
[mpeg2video @ 0x7f01c0006180] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f01c0006180] Invalid frame dimensions 0x0.
...

Could it be a demuxer issue? Strange, that it happens on Manjaro only.

The Windows version issues:

>vlc.exe 000.ts

 [00f05cc0] main libvlc: VLC wird mit dem Sta
ndard-Interface ausgeführt. Benutzen Sie 'cvlc', um VLC ohne Interface zu verwe
nden.
QWidget::paintEngine: Should no longer be called
[05fa1810] direct3d9 vout display error: SetThumbNailClip failed: 0x80004001
...
[0603e6a8] dxva2 generic error: IDirectXVideoDecoderService_GetDecoderDeviceGuid
s failed
[0603e6a8] dxva2 generic error: FindVideoServiceConversion failed
[...] direct3d9 ...
...

I may try the debian live once more on the same file…

Regards,
Dirk

4

If you can play the file through another player, it may indeed be an issue from vlc. Otherwise, it may be an issue with the file.

If you confirm it comes from vlc, you should forward your issue upstream.

6

There’s the point, I can confirm that the issue is only with vlc 13.0.17.4 on Manjaro (I tried the KDE installation media meanwhile - exactly the same output on the console with the same file, that seamlessly plays on vlc 13.0.17.4 - installed live while running from the debian live installation media - all with the same .ts file on the same media.) So it’s either something missing or failing in the Manjaro distro that vlc should use, or the issue is with the Manjaro vlc package. I tried also to boot a different (LTS) kernel - no change.

Here’s the output from the Debian console that started vlc:

$ vlc 000.ts
VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)
[000055f88d87b5b0] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
[00007feca8001650] gl gl: Initialized libplacebo v2.72.0 (API v72)
libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
[00007fec5cc4ebf0] avcodec decoder: Using Intel i965 driver for Intel(R) Bay Trail - 2.4.1 for hardware decoding

And here from the Manjaro KDE live system vlc (identic to that from XFCE):

$ vlc 000.ts
VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)
[000055abd8e04660] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[00007f905cc13f20] main decoder error: buffer deadlock prevented
[00007f905cc27ac0] main decoder error: buffer deadlock prevented
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
[mpeg2video @ 0x7f905000a140] Invalid frame dimensions 0x0.
...

I cannot think that it should depend on upstream vlc.

“Upstream” was a good hint, though: There’s a bug filed already for the archlinux vlc package - for .ts decoding the vlc package lacks referring a dependency on “aribb24” - installing this package resolves the main issue playing .ts files.

Second on my desktop I had to disable HW acceleration - vlc loaded automatically

avcodec decoder: Using Intel i965 driver for Intel(R) Bay Trail - 2.4.1 for hardware decoding

(console output), but on my system the video gets stuck with this, I have

$ inxi -CG
CPU:
  Info: quad core model: Intel Celeron J1900 bits: 64 type: MCP cache:
    L2: 2 MiB
  Speed (MHz): avg: 1368 min/max: 1333/2416 cores: 1: 1333 2: 1474 3: 1333
    4: 1333
Graphics:
  Device-1: Intel Atom Processor Z36xxx/Z37xxx Series Graphics & Display
    driver: i915 v: kernel
  Display: x11 server: X.Org v: 21.1.4 driver: X: loaded: modesetting
    gpu: i915 resolution: 1920x1080~60Hz
  Message: Unable to show GL data. Required tool glxinfo missing.

Now I can play my .ts files again with aribb24 installed and HW acceleration disabled.
Yet the vlc package issue needs to be resolved.

1 Like
7

Well, actually we inherit the package from Arch. So if they have issues open about that, they’ll probably the ones fixing the package…

8

Indeed. Please link things like that in the future so others don’t have to go searching.

FS#68856 - [vlc] optdepends/depends for playback of .ts files

9

If the bug is only reported to affect .ts filetype, try changing the filetype from .ts to .mpeg

TS File (What It Is & How to Open One)
Another option for opening the TS file is to rename it to something that your existing media player will support, like .MPEG. Most multimedia players already support .MPEG files, and since TS files are MPEG files, the same program should also play your TS file.

10

No, just renaming .ts to .mpg or .mpeg does not work as a replacement for a Transport Stream de-multiplexer (in difference to mpeg Packet Stream .mpg). I just briefly uninstalled aribb24 and renamed a .ts to .mpg - voilá: scrambled/broken video and audio.

11

Renaming to .mpeg works occasionally for me. It can save some time checking mediainfo or running ffmpeg conversions for everything in a large batch of files

There are 35 open issue reports about this demuxer
Demuxers:TS - Issues · VideoLAN / VLC · GitLab
If Arch maintainers can’t resolve this it might be a while before VLC deal with it

12

If you tell ffmpeg to copy to .mpeg it does more than just copy the streams - it de-multiplexes the .ts (transport stream) and multiplexes to .mpg / .mpeg (packet stream). ffmpeg naming -f mpeg (vs. -f mpegts for .ts).
I came to this right now upon a fresh installation where the vlc package omitted the aribb24 .ts demuxer so that I couldn’t use vlc any more to check my crops of my recorded .ts,
Before this on my older manjaro installation that I used the aribb24 package ist present and I didn’t experience such outage.
After the fresh installation I had the idea to switch back to .mpg. But - except ffmpeg (options -ss -t / -i concat:) I’m using avidemux very much - it can deal even with h.265 .ts (1080p50) which my computer is too slow to play on vlc - but now I found avidemux completely failing on .mpg which it had no problem in earlier versions with. So I went a little desparate with my two main tools drifting apart.

Now after I manually installed arobb24 and - after some testing I set vlc deinterlacing to discard - my vlc plays .ts smoothly again and avidemux still likes .ts - my despair went a little away.
After a few years of customizing Knoppix every few weeks with fresh Thunderbird and Firefox I came to the thought that a rolling release could save me a lot of time - when my frient brought a Vista-era notebook and I found Manjaro the first release to run on it out-of-the box, I moved to Manjaro also. But watching now how “old” systems and formats support gets dropped, I have to think of ‘freezing’ one system (and backup/restore for the case of broken storage) that won’t ever see any internet, and running another constantly updated for internet-related things. Which is, of course, kind of crazy to keep up with.

13

Comments on VLC forum suggest that package aribb24 was dropped from being installed by default when VLC v3.0.4 was released in 2018
VLC 4.0.3 DVB Video Playback broken - The VideoLAN Forums
why is vlc getting the file format wrong ? - The VideoLAN Forums

14

As advised in the forum posts you referred I checked via “vlc -l” and found that in Manjaro I have this line only with aribb24 installed:

$ vlc -l | grep -i '^ *ts'
VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)
  ts                     MPEG Transport Stream-Demuxer

On my wine vlc installation a ts demuxer is included in the Windows-vlc-installation:

$ env WINEPREFIX="/home/<user>/.vwine" wine "C:\\windows\\system32\\cmd.exe"
...
C:\Program Files\VideoLAN\VLC>.\vlc.exe -l > module.txt
...
$ cat module.txt | grep -i '^ *ts'
  ts                     MPEG Transport Stream-Demuxer

It does not give the name of the library used, though.

15

and

could be a general buffering issue, mpeg2 files are huge. And it could have been caused by an update overwriting default values. Have you tried resetting/maxing out VLC’s caching settings, as shown here in 'Method 1" How to Fix VLC Lagging/Stuttering/Buffering Issues