Lag when pause/resume

[xtal256]

Version information:

MythTV Version : v34.0+fixes.202505182337.9a083bbe5c~ubuntu24.04.1
MythTV Branch : fixes/34
Network Protocol : 91
Library API : 34.20220913-1
QT Version : 5.15.13
Options compiled in:
linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_firewire using_frontend using_hdhomerun using_satip using_vbox using_ceton using_joystick_menu using_libcec using_libcrypto using_gnutls using_libdns_sd using_libxml2 using_lirc using_mheg using_opengl using_egl using_qtwebkit using_qtscript using_qtdbus using_taglib using_v4l2 using_v4l2prime using_x11 using_system_libbluray using_system_libudfread using_systemd_notify using_systemd_journal using_drm using_bindings_perl using_bindings_python using_bindings_php using_freetype2 using_mythtranscode using_opengl using_egl using_drm using_vaapi using_nvdec using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2 using_libmp3lame

Enable Music Choice is unchecked

Some other settings that might be useful,
Enable Realtime Priority Threads: true
Current Video Playback Profile: NVDEC Normal

My ~/.asoundrc file is exactly as you said in your earlier comment (my device id is also 3)

aplay -L

My problem happens when watching live TV (i.e pausing and resuming it) and watching videos (e.g. mp4 files). I have not yet made any recordings but I'd assume the problem also happens there.
I tested mpv on the same mp4 files.
I tried the different audio tracks of that video you mentioned (it was just audio commentary) but it had the same lag. I also tried the Adjust Audio Sync setting but it didn't help either.

I also found the Playback Data menu option which shows some debug info on the screen, but nothing looked odd. While playing, Storage to Buffer was ">1Gbps" and Buffer to Decoder was anywhere between 500kbps and 3Mbps. Available Buffer was between 97 and 99% of 4Mb. A/V Sync was usually 0ms while playing, and only went to between -1 and 7ms when pausing / resuming.

[dnalorernst]

@xtal256:
In your first post you wrote:

My hardware:
ODROID H4+, Intel N97 CPU, Intel UHD Graphics

In the last post you wrote:

Some other settings that might be useful,
Enable Realtime Priority Threads: true
Current Video Playback Profile: NVDEC Normal

You should switch the "Video Playback Profile" from NVDEC to VAAPI, otherwise the CPU is used to decode the video.

[xtal256]

Thanks, I was actually wondering about that.

Short of trying every video profile option, I don't really know which is best.
I guess the "NV" stands for NVidia, but I'm certainly no expert on video decoding.

[dnalorernst]

I am pretty sure that the lag you see is caused by the wrong display driver.
Please install vainfo if not already done by

Code: Select all

$ sudo apt-get install vainfo 

run it in the terminal and check the first lines, they should be similar to these

Code: Select all

$ vainfo
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.20 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 24.1.0 ()
....

If vainfo reports an error or if vainfo does not load the Intel iHD driver,
install the Intel iHD driver by

Code: Select all

$ sudo apt-get install intel-media-va-driver-non-free 

and reboot.
Afterwards, run vainfo again

[xtal256]

Changing to VAAPI seemed to help a bit, but there is still lag.

This is the output of vainfo:

Code: Select all

libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.20 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 24.1.0 ()
vainfo: Supported profile and entrypoints
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileNone                   : VAEntrypointStats
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSliceLP
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSliceLP
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointEncSliceLP
      VAProfileVP9Profile1            : VAEntrypointVLD
      VAProfileVP9Profile1            : VAEntrypointEncSliceLP
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointEncSliceLP
      VAProfileVP9Profile3            : VAEntrypointVLD
      VAProfileVP9Profile3            : VAEntrypointEncSliceLP
      VAProfileHEVCMain12             : VAEntrypointVLD
      VAProfileHEVCMain422_10         : VAEntrypointVLD
      VAProfileHEVCMain422_12         : VAEntrypointVLD
      VAProfileHEVCMain444            : VAEntrypointVLD
      VAProfileHEVCMain444            : VAEntrypointEncSliceLP
      VAProfileHEVCMain444_10         : VAEntrypointVLD
      VAProfileHEVCMain444_10         : VAEntrypointEncSliceLP
      VAProfileHEVCMain444_12         : VAEntrypointVLD
      VAProfileHEVCSccMain            : VAEntrypointVLD
      VAProfileHEVCSccMain            : VAEntrypointEncSliceLP
      VAProfileHEVCSccMain10          : VAEntrypointVLD
      VAProfileHEVCSccMain10          : VAEntrypointEncSliceLP
      VAProfileHEVCSccMain444         : VAEntrypointVLD
      VAProfileHEVCSccMain444         : VAEntrypointEncSliceLP
      VAProfileAV1Profile0            : VAEntrypointVLD
      VAProfileHEVCSccMain444_10      : VAEntrypointVLD
      VAProfileHEVCSccMain444_10      : VAEntrypointEncSliceLP

The top lines are identical to what you posted.

[dnalorernst]

I guess you played a lot with the video and audio settings on the frontend.
These are my settings (an indentation means entering a sub menue with the "right key (->)":

Code: Select all

Frontend:
Setup --> Video --> Playback 
    --> Advanced Playback Settings --> Audio read ahead: 100 ms
    --> Advanced Playback Settings --> Current Video Profile: VAAPI Normal
        --> VAAPI acceleration & OpenGL Hardware
            --> Decoder: VAAPI acceleration
            --> Max CPUs : 4               ### you need to change this to the actual CPU count !!
            --> Video Renderer: OpenGL Hardware
            --> Video Scaler: Default (bilinear)
            --> Deinterlacer Quality (single rate): High Quality
            --> Prefer OpenGL deinterlacers: checked
            --> Prefer driver deinterlaces: checked
            --> Deinterlacer quality (double rate): High Quality
            --> Prefer OpenGL deinterlacers: checked
        --> Standard & OpenGL YV12
            --> Decoder: Standard
            --> Max CPUs: 4                ### you need to change this to the actual CPU count!!
            --> Video renderer: OpenGL YV12
            --> Video scaler: Default (bilinear)
            --> Deinterlacer quality (single rate): Medium quality
            --> Prefer OpenGL deinterlacers: checked
            --> Prefer driver deinterlcers: unchecked
            --> Deinterlacer quality (double rate): Medium quality
            --> Prefer OpenGL deinterlacers: checked
            --> Prefer driver deinterlacers: unchecked
                                                                                               
                                                                                               
Setup --> Audio
    --> Audio output device: ALSA:hdmi:Card=PCH,Dev=0           ### this is trial and error !!   
    --> Digital Audio Capabilities 
        --> Dolby Digital: unchecked
        --> DTS: unchecked
        --> E-AC-3: unchecked        ### albeit it plays e-ac-3 !!
        --> TrueHD: uncheked
        --> DTS-HD: uncheked
    --> Speaker configuration: Stereo
    --> Upconvert stereo to 5.1 surround: uncheked
    --> Upmix Quality: Best                         ### Note: In case 'Upconvert' setting cheked !!
    --> Use internal volume controls: uncheked
    --> Advanced Audio Settings
        --> Seperate digital output device: unchecked

My TV is old and a cheapo one, thus it has not a lot of capabilities.
From my memory, I only changed the "Max CPUs" setting and had a lot of trials
to get the "ALSA:hdmi:Card=PCH,Dev=X" device working.

When playing a movie, in the frontend logs, do you see a message like

Code: Select all

[W] Try to manually increase audio buffer with: echo blah, blah | sudo tee blah, blah

then follow this advice, restart the frontend and play the movie again.

I am curious about the movie that causes that lag itself:
Please run in a terminal

Code: Select all

mythffprobe /path/to/the/movie/file

and post the output

[xtal256]

I checked my settings and they are the same as yours. My Max CPU count was set to 2 and I increased it to 4 (the Odroid has 4 CPUs) but it made no difference.

I don't see that "manually increase audio buffer" line in the log file. Here is the most recent log file: mythfrontend.log.

As for which movie causes lag, it's all movies and tv shows including live TV. But here is one example from mythffprobe:

Code: Select all

mythffprobe /data/videos/movies/Americana.mp4
ffprobe version 5.1 Copyright (c) 2007-2022 the FFmpeg developers
  built with gcc 13 (Ubuntu 13.3.0-6ubuntu2~24.04)
  configuration: --arch=x86 --sysinclude=/usr/include --cc='ccache gcc' --cxx='ccache g++' --ld=gcc --cpu=generic --target_os=linux --pkg_config=pkg-config --prefix=/usr --libdir=/usr/lib --as=gcc --objcc=gcc --dep_cc=gcc --host_cc=gcc --host_ld=gcc --ar=ar --nm='nm -g' --ranlib='ranlib -D' --disable-cross-compile --enable-libmp3lame --enable-libx264 --disable-libx265 --enable-libvpx --disable-libxvid --enable-vdpau --enable-libxml2 --enable-libass --disable-dxva2 --enable-libbluray --disable-libfontconfig --disable-libfreetype --disable-libiec61883 --disable-crystalhd --disable-sdl2 --disable-ffplay --enable-vaapi --enable-libdrm --enable-libaom --enable-libdav1d --enable-gnutls --extra-cflags=' -w' --extra-ldflags= --extra-libs= --enable-stripping --strip='echo skipping strip' --disable-manpages --disable-podpages --disable-doc --disable-nvenc --enable-shared --disable-static --enable-gpl --enable-pic --disable-demuxer=mpegtsraw --disable-indev=dshow
  libavutil      57. 28.100 / 57. 28.100
  libavcodec     59. 37.100 / 59. 37.100
  libavformat    59. 27.100 / 59. 27.100
  libavdevice    59.  7.100 / 59.  7.100
  libavfilter     8. 44.100 /  8. 44.100
  libswscale      6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc    56.  6.100 / 56.  6.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x566ef47ccb00] Referenced QT chapter track not found
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/data/videos/movies/Americana.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf60.4.101
  Duration: 01:47:21.41, start: 0.000000, bitrate: 1283 kb/s
  Chapters:
    Chapter #0:0: start 0.000000, end 6055.000000
      Metadata:
        title           :
    Chapter #0:1: start 6055.000000, end 6441.408000
      Metadata:
        title           :
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1280x534 [SAR 801:800 DAR 12:5], 1149 kb/s, 23.98 fps, 23.98 tbr, 24k tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
      encoder         : Lavc60.9.100 libx264
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]

[blm-ubunet]

At the risk of NOT being helpful & getting off topic..
The pause/unpause behaviour in mythtv video playback is not helpful & always looked clunky.
When you pause, video playback continues (AFAP) until all decoded/buffered frames are spent.
When you unpause, playback detects big AV sync & has to judder/stutter back to correct video frame to decode/buffer resume..
This would be more noticeable on a slow PC. Bad enough with VDPAU & GTX GPU.

A side effect of Mythtv video playback/overlay method (in v31) is that pause is continuously decoding a video frame & for interlaced material "pause" displays a deinterlaced frame from 2 identical half resolution fields.

I have a simple patch for an older version (pre v31) of Mythtv that makes an attempt to minimize the (un)pause glitch & have been attempting to get it into a github fork.

Do you compile Mythtv from source?

[xtal256]

I do not compile from source, but I might try if there is a possibility that I can tweak some settings that can't otherwise be changed in a normal build.

I'm also curious if using MythTV as a live TV backend would affect video playback in Kodi, as I experience similar clunky stuttering playback there too, even when watching videos straight from the SSD (i.e. not TV).

[blm-ubunet]

I had a closer look at later MythTV playback code, it has been completely changed/rewritten (from circa v31).
So forget about my patch..
Also compiled master (on a different PC with llvm & CPU decode) & tested playback pause/unpause.
Does not seem to have the pause/unpause behaviour of old pre v31..

If Kodi playback or recorded video is similar to Mythtv then I would think issue is in PC.
Watching LiveTV (in mythtv) too close to realtime does tend to cause playback issues.

I would have thought VA-API was best option (VDPAU did work on AMD) but need to monitor OSD: <M> Playback / Playback Data.

[xtal256]

When you say it does not seem to have the pause/unpause behaviour, are you saying there is zero perceptible lag? Or just too little for it to bother you?

I know it can't be my hardware, as mpv is able to perfectly pause and resume. It can also fast forward smoothly up to 50x speed, something neither Myth nor Kodi can do. Which leads me to believe that these programs are just inefficient.

[blm-ubunet]

Apples & oranges..
The pre v31 pause/unpause was very annoying/distracting.
My pause/unpause playback observation is with latest MythTV master & on a desktop PC with powerful CPU but software OpenGL (llvm).
There is a small pause/unpause lag & does still appear to race to render further decoded frames. But this appears much less distracting than old pre v31.
But my actual "TV" MythTV runs old pre v31 (hacked about) & has GTX1050TI & nvidia driver & old i5 CPU.
Testing latest MythTV on this PC would end up being a one way road (for me).

MPV is a very performant program. It could be utilizing your h/w in a different way to mythtv/kodi.. What does the terminal output report about media decoding?
~$ mpv --hwdec=auto video_filename

If your PC was not working well with mpv, would have suggested forcing intel i915 instead of later iHD.

Fairly sure VA-API requires a couple other settings:
- Must use OpenGL renderer.
- think you have to set the LIBVA_DRIVER_NAME
And potentially the two settings here: viewtopic.php?p=29099#p29099

[xtal256]

MPV is a very performant program.

Yes, that's good. Why can't all video playback programs be this good? I bought a decent enough modern computer with fast RAM and a fast SSD. If a video program isn't performant then that hardware is going to waste.

mpv --hwdec=auto shows the following:

Code: Select all

[ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: Referenced QT chapter track not found
 (+) Video  --vid=1 (*) (h264 1280x534 23.976fps)
 (+) Audio  --aid=1 (*) (aac 2ch 48000Hz)
Cannot load libcuda.so.1
Using hardware decoding (vaapi).
AO: [alsa] 48000Hz stereo 2ch s32
VO: [gpu] 1280x534 => 1281x534 vaapi [nv12]
AV: 00:07:42 / 01:47:21 (7%) x1.0- A-V:  0.000

Fairly sure VA-API requires a couple other settings:
- Must use OpenGL renderer.
- think you have to set the LIBVA_DRIVER_NAME
And potentially the two settings here: viewtopic.php?p=29099#p29099

I just switched the playback profile from "VAAPI Normal" to "OpenGL Normal", with Decoder set to "VAAPI Acceleration", but that made no difference.
I also set those two environment variables in the post you mentioned, but that also didn't help. From the logs I have posted earlier, I think VAAPI is being detected and used already.

[white_haired_uncle]

Yes, that's good. Why can't all video playback programs be this good? I bought a decent enough modern computer with fast RAM and a fast SSD. If a video program isn't performant then that hardware is going to waste.

https://github.com/MythTV/mythtv/pulls

[blm-ubunet]

In your first post.. BE logs shows mkv file with HEVC video codec which then falls back to ffmpeg decoding.
Can you try a basic H264 AAC or AC3 in mpeg PS or TS file & MythTV FE logging options for playback?

MPV has far less complex requirements than MythTV.
Also has 1000 to 100,000 times more users & therefore potential developers.
Video playback & PQ across Windows/Android/Linux is probably their primary focus.
The maintenance surface of MythTV is huge.
MythTV is feature complete & has a reducing user base due to rise in VOD & current broadcasting environment (sunsetting).

Your problem could be related to desktop settings wayland/X11, DE composited effects, refreshrate & indirection of full screen etc.
In my experience lots of DEs do not play nice with PQ in MythTV.
People (in past?) ran MythTV FE on RaspberryPI & atom powered devices but with simple DEs.

AIUI:
MythTV now uses OpenGL renderer for the default setup of VAAPI Normal. This appears to be an automatic handled internal setting & not configured manually.
All hardware video decoding in MythTV since v31 must use OpenGL renderer for output. This means there is no data copy back from GPU to main memory & then back to output surface memory in GPU.
For VAAPI to work, MythTV must detect or be told the "Decoder Device for VAAPI hardware decoding".