Video playback issues

[JimSoft]

Hi all,

I've been using mythtv since v0.21. Got an issue with my combined BE/FE video playback, I'm in the UK recording from FreeView/FreeSat PCI cards.

I have just upgraded to Ubuntu 22.04 & MythTV 0.32 on a system with an Nvidia 9500GT (Driver 340.108).

I can get HD video to playback fine (H.264 vdpau-dec) but strangely SD video (MPEG-2 vdpau-dec) stutters badly and only gets about 7fps. The SD files play back with ffplay and VLC but not in mythtv even when I check "Use FFMPEG's original TS demuxer".

I'm at my wits end with this one. Any clues of something to try or look at?

Thanks, Graham.

[mtvf2894]

Interestingly I am having issues with VAAPI (AMD) hardware accelerated playback since updating to 22.04 and v32 which worked "ok" in 20.10 and v31.

I used a NVIDIA card in the historic past (but before the major changes in MythTV in this area) have you tried just straight VDPAU not the one with decode in your playback settings?

I have just updated my thread with more details and queried if a possible ffmpeg sync in the upcoming v33 release may help with this problem? (it might if it works in ffplay etc).

Fingers crossed.

[JimSoft]

Hi,

When I try the full VDPAU setting I get the "Decoder timed out waiting for free video buffers" when playing back HD recordings. Strangely the playback of SD recordings is 7fps and jerky with either setting.

Graham.

[blm-ubunet]

Recent (last couple of years) changes to Mythtv mean that all the settings for Video playback have slightly different definitions.
That developer is not around at moment sadly.
The HQ scaler & denoise & sharpening features of VDPAU have also been lost from MythTV.

I seem to recall that the old ION/8400/9400 video cards were not always being probed correctly for their true capability. But that should be better now & not worse.
With old ION/9400/9500 I think VDPAU slim is possibly a good starting point & also adjust deinterlacer down from HQ setting..
VDPAU slim might be meant of ION with less & slow RAM.

I suspect the old VDPAU MPEG2 decode on 8400/9400 might not as efficient as it is not performed completely in dedicated hardware block.

Unless you need analogue video output (or no PCIe), then all the later cards have much better PQ & lower power consumption.

[mtvf2894]

I have updated my related thread with some information viewtopic.php?f=36&t=5021
As mentioned not 100% sure whether it will help.

[JimSoft]

Thanks for the comments. Does this mean I have to wait for 0.33 to get the latest FFMPEG?

A bit of a thorny subject but I remember a few years ago when VDPAU was first introduced it made my low end CPU/GPU system capable of playing UK broadcast HD and SD material with very low CPU usage consistently. Sadly this has slowly regressed to a point where the same system is now unusable when recording and playing the same formats.

[blm-ubunet]

0.32 has brought in a lot of changes to video playback.
That FFMPEG TS demuxer is to do with not detecting streams properly & timing out on playback.

I do not think it relates to playback (once started) of recorded files except when seeking (keyframes etc) in a file.
With all updates you should stop backend & allow the schema upgrade by running mythtv-setup.

Then with 0.32 playback changes, I believe have to go into frontend video playback settings & change your VDPAU to slim or medium.
All those settings have changed.

Start frontend from terminal & have a look at logging messages. Start with -v playback:debug

I'm still using same Core2Duo from 12+ yrs ago but with much later video card. Playback formats have always been H264 what you refer to as "HD" altho it isn't really. Still plays fine but I think later Mythtv versions have more playback hiccups with high levels of database access.

Your old video card forces you to use legacy drivers (lucky Nvidia support is fantastic).
I also do not think any of the later desktop environments/managers do video playback any favours.

[mtvf2894]

Thanks for the comments. Does this mean I have to wait for 0.33 to get the latest FFMPEG?

Yes possibly even later and then I am purely guessing this may help with hardware accelerated playback issues.

The plan is to release v33 in time for the Ubuntu 22.10 release which means to make the feature freeze (August 25th) we have about 5 weeks to at least get the pre release out. It's doable but with the imminent ffmpeg resync I expect many regressions so I have my doubts. It's easier to herd cats than get MythTV developers to co-operate getting a release ready and I no longer have the energy to push things along so if it happens fine if not we will just have to try again in April

There were major changes for hardware accelerated playback in v31 and it still worked reasonably fine for me but once I went to v32 this is when the major problems started (it may be related to 22.04 though). If v32 also brought in even more changes to hardware accelerated playback this further complicates things and may point to a MythTV rather than FFMPEG resync / OS driver problem.

The Use Old FFMPEG TS demuxer option does not help my problems and the problem does not seem to be limited to ".ts" files.

[JimSoft]

I'm still using same Core2Duo from 12+ yrs ago but with much later video card.

Which video card are you using?

[blm-ubunet]

Using GTX1050ti which is overkill really. But the fans never spin up driving a 4K screen.

Would have bought a GTx1030 but it was not released then.
I think the GTX1630 is the best offering from Nvidia.

I imagine playback issues that impact a developer might get addressed but are they using old ION/9400GT video cards?
Can NOT believe any FFmpeg changes will have any impact on old H264 & mpeg2 video parsing/demuxing..
H264 playback was fine over 10yrs ago on 9400GT etc.

If you run frontend with some playback debug logging you may see the problem..
mythfrontend -v playback:debug

It might be better to downgrade to 0.31 or 0.30.. but you'll need a database backup from an acceptable schema revision & will loss any recent recording history.

I haven't upgraded my main MythTV install for about 2 yrs because the PQ matters more to me than some bug fixes.

[JimSoft]

If you run frontend with some playback debug logging you may see the problem..
mythfrontend -v playback:debug

I have tried this with no apparent clues. Playing HD results in 25fps with approx 50ms jitter. SD results in about 7fps with video frames constanly being dropped due to being behind about 5000ms all the time. Can't see any relevant issues before playback starts.

I haven't upgraded my main MythTV install for about 2 yrs because the PQ matters more to me than some bug fixes.

This is where I've gone wrong, always assuming the latest version would improve my experience. I think I peaked at 0.25 or somewhere about there, I'm considering if it's worth the time and effort to put together an old installation and try it.

Wondering if Tvheadend is the way forward, I have just always hated Kodi even though it seems to give smooth playback on numerious low power frontends (Rpi to name one) which is obviously where mythtv keeps letting me down.

[blm-ubunet]

The clues to playback problem most likely are revealed at the very start of playback & should reveal the file probing & the decoder selected etc.

Peak Ubuntu was likely 14.04 before Gnome destroyed the efficiency.. I've almost always built from source so can pick & choose any point in time within reason.

[paulh]

If your system a MythTV only system then I would recommend using something lighter than official Ubuntu with Gnome like Xubuntu. You may still have to disable the compositor to get flicker free playback but it works well.

[mtvf2894]

The clues to playback problem most likely are revealed at the very start of playback & should reveal the file probing & the decoder selected etc.

I do not want to polute a thread for NVIDIA with my AMD/VAAPI issue too much but for what it is worth my thread has frontend logs (no additional logging set just standard settings) of a problem with hardware acceleration and yes 50 times is not an exaggeration

The weird thing for me is if I keep on trying playing back different recordings and between it falling back to CPU playback or crashing the frontend hardware acceleration will eventually start working.

It is like some combination will make it work. I have my suspicions what combination makes it work for me but I am not 100% yet.

The frontend logs are full of entries like the following repeated 50 times before CPU playback is used (probably why it takes longer to start the recording).

Code: Select all

mythfrontend.real: mythfrontend[2997]: I Decoder mythplayervideoui.cpp:143 (HandleDecoderCallback) PlayerVideo: Queuing callback for VAAPI context creation
mythfrontend.real: mythfrontend[2997]: I CoreContext mythplayervideoui.cpp:159 (ProcessCallbacks) PlayerVideo: Executing VAAPI context creation
mythfrontend.real: mythfrontend[2997]: I CoreContext opengl/mythvaapiinterop.cpp:140 (InitaliseDisplay) VAAPIInterop: Created VAAPI 1.14 display for GL-VAAPI-DRM (Mesa Gallium driver 22.0.1 for AMD RENOIR (LLVM 13.0.1, DRM 3.42, 5.15.0-41-generic))
mythfrontend.real: mythfrontend[2997]: E CoreContext decoders/mythvaapicontext.cpp:346 (InitialiseContext) VAAPIDec: Failed to initialise VAAPI frames context
mythfrontend.real: mythfrontend[2997]: E Decoder decoders/avformatdecoder.cpp:3474 (ProcessVideoPacket) AFD: video avcodec_send_packet error: Invalid argument (-22) gotpicture:0

[blm-ubunet]

I'm certainly not using Gnome3 desktop for MythTV.
My current MythTV box uses Mate.

The problem/difficulty with the later compositors is lack of functioning support for "Unredirected Full Screen" which worked just fine with Ubu10.04 Gnome2 to 18.04 Unity (Compiz). Or they do not work with Nvidia drivers for ideological reasons..

The irony of Desktop shambles that is linux.. Ubuntu's Unity was fantastic for performance & low overhead & desktop UI efficiency, it never had problems with incorrect un-redirected full screen compositor interference causing with tearing full screen video.

mtvf2894
Are you able to debug VAAPI from shell outside of MythTV?
There are some basic cmd line tools to test it: vainfo?

I recall VA-API has to get some screen handle context from GL/GLX interface & that EGL can stop this working.
There are cmd line options to stop Mythtv FE using EGL if that was the problem.
I seem to recall some VA-API context/interface configuration was required inside MythTV..

When you first start up the FE there are VA-API API messages.. & other messages indicating the decoder support possible..
I have VA-API backend for VDPAU installed but the FE startup messages report it fails to initialise the VA-API connection.