Failed to initialize a/v sync

[Jarno Suni]

When using VDPAU it the frontend can not play HD TV recordings. (DVB-T2, h.264)

(Graphics: 01:00.0 VGA compatible controller: NVIDIA Corporation G84GLM [Quadro FX 570M] (rev a1))

[Jarno Suni]

frontend output

[Jarno Suni]

I do not understand the cause of E Player(0): Video sync method can't support double framerate (refresh rate too low for 2x deint)

The refresh rate is 50Hz and TV content has 25 Hz frame rate and it is interlaced. If I change refresh rate to 60Hz, I see

2020-02-09 08:49:41.781754 I VidOutVDPAU: Enabled deinterlacing. 2020-02-09 08:49:41.781811 E VSYNC: DRMVideoSync: VBlank ioctl did not work, unimplemented in this driver? 2020-02-09 08:49:41.781857 E VSYNC: RTCVideoSync: Could not open /dev/rtc:

eno: Permission denied (13)

2020-02-09 08:49:41.789749 I Player(1): Video timing method: USleep with busy wait 2020-02-09 08:49:41.789774 I Player(1): Display Refresh Rate: 59.999 Video Frame Rate: 29.970 2020-02-09 08:49:41.789794 I Player(1): SetFrameInterval? ps:1 scan:1

[Jarno Suni]

Also:

VDPAU: Error at mythrender_vdpau.cpp:762 (#23, The system does not have enough resources to complete the requested operation at this time.) VidOutVDPAU: Failed to create decoder.

seems odd, there is 256 MB dedicated memory and not much else running.

[Mark Kendall]

Can you attach a full log with '-v playback'.

It's hard to tell without the extra detail, but I'm guessing the root cause here is similar to #13557; the video stream isn't detected properly.

[Jarno Suni]

there are 4 blocks in this log: first file and second file playback when web browser is running; then the second file and first file playback when the web browser is not running.

[Jarno Suni]

mediainfo output about the first file; see playback-log

[Mark Kendall]

Not sure where to go with this.

The frame rate detection is obviously a problem - I'd like to think this better/fixed in master/v31 as there have been improvements there.

Can you upload a brief clip from the first file?

Secondly, I can't see that there is much to be done with the memory issues. I'm guessing from your comments that there are other processes running - this is almost certainly going to cause issues with only 256MB of GPU ram - and probably won't necessarily be fixed by closing other processes, as there is no guarantee that the freed memory will become available to mythtv in the short term.

My gut feeling is that this would be better tested with master/v31 - as there has been so much change to this code (VDPAU support has been completely rewritten).

[Jarno Suni]

I seem to be unable to play any HD content; this is a regression. Maybe it is due to upgrade 2020-02-08 22:01:04 upgrade mythtv-frontend:amd64 2:30.0+fixes.202001141938.05910a4~ubuntu18.04.1 2:30.0+fixes.202002042145.3e9e835~ubuntu18.04.1

Or upgrading Xfce may have increased memory usage; I'll try to disable comopsiting and run the frontend only after I have closed other apps.

[Jarno Suni]

I disabled compositing in Window manager tweaks, and logged out and in to Xfce session. Then I could play HD content by mythfrontend.

[Jarno Suni]

This is the beginning of the file that mythtv thinks has framerate 29.970 Hz: ​https://drive.google.com/open?id=1wcxQggs_bNoHGgEWiaesGheEDgiDt769

[Jarno Suni]

BTW Why has VDPAU support been completely rewritten for v31?

[jpilk]

I have no problem playing your clip in current master with the nvidia 440.59 driver. I understand that support for your 340 series is getting to be problematic, although that may not be affecting you. As for your comment 9, this might help:

One of the main goals of the render branch was to give consistent, performant and accurate video display across different platforms. So there is now one 'display' pathway that always uses OpenGL/ES for rendering.

from ​http://lists.mythtv.org/pipermail/mythtv-dev/2020-February/078289.html

[Jarno Suni]

I can play it too. Just wondering where the odd the framerate comes from to the log.

[Jarno Suni]

BTW if I copied the clip to videos folder and played it using the videos function, it would play the full version anyway, not just the clipped part.

[Jarno Suni]

I had to use different filename so that the actual clip would be played. When playing the clip I do not see anything about the 29.970 framerate.

[Jarno Suni]

However, when I play the full file, there is

2020-02-12 15:51:28.851079 E  Player(2): Video sync method can't support double framerate (refresh rate too low for 2x deint)
2020-02-12 15:51:28.852343 I  VDP: GetFilteredDeint(vdpauadvanced) : vdpau -> 'vdpauadvanced'
2020-02-12 15:51:28.853529 I  VidOutVDPAU: Enabled deinterlacing.
2020-02-12 15:51:28.854538 I  Player(2): Video timing method: USleep with busy wait
2020-02-12 15:51:28.854561 I  Player(2): Display Refresh Rate: 50.000 Video Frame Rate: 29.970

Anyway, it can play the file, if there is enough video memory available.

[Jarno Suni]

Replying to jpilk:

I have no problem playing your clip in current master with the nvidia 440.59 driver. I understand that support for your 340 series is getting to be problematic, although that may not be affecting you. As for your comment 9, this might help:

One of the main goals of the render branch was to give consistent, performant and accurate video display across different platforms. So there is now one 'display' pathway that always uses OpenGL/ES for rendering. from ​http://lists.mythtv.org/pipermail/mythtv-dev/2020-February/078289.html

I can free some video memory, if I use Standard decoder instead of VDPAU. However, I have to choose vdpau rendering to get decent playback quality; opengl does not perform well at least by Mythfrontend version 30 with my hardware and nvidia 340.107 driver. (I did not test by all opengl variants, though.) So I think I had better not upgrade to 31, if it does not support VDPAU rendering. Furthermore, If I want to use this hardware, I may have to cut out kernel upgrades in near future, if they break compatibility with the driver.

[Mark Kendall]

Closing this ticket as I don't see at the moment what else can be done.

The framerate detection issue should be improved in 0.31 - although there are wider issues about livetv and initialisation of video parameters and codecs.

With respect to VDPAU, I suspect 0.31 may actually be slightly more memory efficient when using VDPAU. There is now a clear distinction between OpenGL (rendering) and VDPAU (decoding). VDPAU frames are mapped directly into OpenGL textures for display (to be clear - 0.31 does support VDPAU rendering - just in a different way). In 0.30 we still had OpenGL for the GUI, VDPAU for rendering and OSD and VDPAU for decoding - which, despite code to minimise memory consumption, would inevitably lead to some overlap.

What is not supported in 0.31 is using VDPAU to display video decoded with FFmpeg. But on the flipside, the OpenGL rendering should be better in 0.31 as a lot of work has gone into optimising performance.