Opened 7 weeks ago

Closed 5 weeks ago

#13580 closed Bug Report - General (Works for me)

Failed to initialize a/v sync

Reported by: Jarno Suni Owned by: mark-kendall
Priority: major Milestone: 31.0
Component: MythTV - Video Decoding Version: v30-fixes
Severity: high Keywords:
Cc: Ticket locked: no

Description

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))

Attachments (3)

frontend-output.txt (17.9 KB) - added by Jarno Suni 7 weeks ago.
frontend output
playback-log (76.8 KB) - added by Jarno Suni 7 weeks ago.
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.
mediainfo-first-file (5.5 KB) - added by Jarno Suni 7 weeks ago.
mediainfo output about the first file; see playback-log

Download all attachments as: .zip

Change History (19)

Changed 7 weeks ago by Jarno Suni

Attachment: frontend-output.txt added

frontend output

comment:1 Changed 7 weeks ago by 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

comment:2 Changed 7 weeks ago by 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.

comment:3 Changed 7 weeks ago by mark-kendall

Component: MythTV - GeneralMythTV - Video Decoding
Owner: set to mark-kendall
Priority: blockermajor
Status: newaccepted

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.

Changed 7 weeks ago by Jarno Suni

Attachment: playback-log added

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.

Changed 7 weeks ago by Jarno Suni

Attachment: mediainfo-first-file added

mediainfo output about the first file; see playback-log

comment:4 Changed 7 weeks ago by mark-kendall

Status: acceptedassigned

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).

comment:5 Changed 7 weeks ago by mark-kendall

Milestone: needs_triage31.0

comment:6 Changed 7 weeks ago by 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.

comment:7 Changed 7 weeks ago by 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.

comment:8 Changed 7 weeks ago by 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

comment:9 Changed 7 weeks ago by Jarno Suni

BTW Why has VDPAU support been completely rewritten for v31?

comment:10 Changed 7 weeks ago by 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

comment:11 Changed 7 weeks ago by Jarno Suni

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

comment:12 Changed 7 weeks ago by 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.

comment:13 Changed 7 weeks ago by 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.

comment:14 Changed 7 weeks ago by 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.

comment:15 in reply to:  10 Changed 6 weeks ago by 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.

comment:16 Changed 5 weeks ago by mark-kendall

Resolution: Works for me
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.