Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 2 years ago

Closed 2 years ago

#10173 closed Bug Report - General (Fixed)

Double framerate deinterlacer incorrectly invalidated

Reported by: krose@… Owned by: markk
Priority: minor Milestone: 0.25
Component: MythTV - Video Playback Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

This subset of --verbose playback illustrates the problem:

2011-11-20 19:18:30.893637 I  Trying to match best refresh rate 29.970Hz
2011-11-20 19:18:30.893712 I  Trying 1920x1080 60.000 Hz
2011-11-20 19:18:31.184949 I  SwitchToVideo: Video size 1920 x 1080: 
    Switched to displaying resolution 1920 x 1080, 160mm x 90mm
2011-11-20 19:18:31.257548 I  VDPAU: Created VDPAU render device 1920x1080
2011-11-20 19:18:32.141666 I  VDP: GetFilteredDeint() : vdpau -> 'vdpaubasicdoublerate'
2011-11-20 19:18:32.199135 I  VidOutVDPAU: Enabled deinterlacing.
2011-11-20 19:18:32.199860 I  Player(0): detectInterlace(Detect Scan, Interlaced Scan, 29.97, 1080) ->Interlaced Scan
2011-11-20 19:18:32.199891 E  Player(0): Video sync method can't support double framerate (refresh rate too low for 2x deint)
2011-11-20 19:18:32.250178 I  VDP: GetFilteredDeint(vdpaubasic) : vdpau -> 'vdpaubasic'
2011-11-20 19:18:32.298770 I  VidOutVDPAU: Enabled deinterlacing.

Why is the 2x temporal deinterlacer being invalidated for 29.97 fps content on a 60 Hz display? (I can't imagine I actually need a 59.94 Hz modeline, but even if I did, the log line "refresh rate too low for 2x deint" would be misleading.) Judging from the strobishness of the resulting video, it appears the 1x temporal deinterlacer just throws out one of the two fields, which is not really an acceptable state of affairs.

One thing that may complicate affairs is that I have "Separate video modes for GUI and playback" on, with 24, 50, and 60 Hz modelines properly achieved by the relevant videos. I wonder if the deinterlacer check is comparing the video against the wrong refresh rate?

Attachments (0)

Change History (7)

comment:1 Changed 2 years ago by krose@…

After doing some more digging, this problem appears to be limited to live TV. When I watch a live TV recording after the fact, I get the proper deinterlacing behavior:

2011-11-21 13:45:05.570575 I [14632/14632] CoreContext tv_play.cpp:336 (StartTV) - TV: Entering main playback loop.
2011-11-21 13:45:05.624509 I [14632/14632] CoreContext mythplayer.cpp:791 (SetScanType) - Player(0): Validating double framerate: frame_interval=33367 videosync->getRefreshInterval()=16667
2011-11-21 13:45:05.657728 I [14632/14632] CoreContext mythrender_vdpau.cpp:558 (CheckOutputSurfaces) - VDPAU: Added 2 output surfaces (total 4, max 4)

Note that 33367/2 is close enough to 16667. But when I watched the same program live, I got this weirdness:

2011-11-21 13:50:11.695572 I [14632/14632] CoreContext mythrender_vdpau.cpp:373 (Create) - VDPAU: Created VDPAU render device 1920x1080
2011-11-21 13:50:12.711364 N [14632/14632] CoreContext mythplayer.cpp:541 (CheckExtraAudioDecode) - Player(2): Forcing decode extra audio option on (Video method requires it).
2011-11-21 13:50:12.711525 I [14632/14632] CoreContext mythplayer.cpp:791 (SetScanType) - Player(2): Validating double framerate: frame_interval=33367 videosync->getRefreshInterval()=41717
2011-11-21 13:50:12.711549 E [14632/14632] CoreContext mythplayer.cpp:796 (SetScanType) - Player(2): Video sync method can't support double framerate (refresh rate too low for 2x deint)

The framerate computed for the video is correct, but where is 41717 coming from in the vsync code? If anyone more familiar with that code has any idea, I would greatly appreciate it; otherwise, I will try to dig into the code after Thankgiving when I should have more time.

comment:2 Changed 2 years ago by krose@…

After pondering this for a while, I have a strong suspicion as to what's happening here. 41717 is about 2.5 * 16667. Guess what is also 2.5 something else? 60 = 24 * 2.5. What I suspect is happening is that in live TV the vsync refresh interval is being calculated with my display in its default mode, which is 24 Hz, rather than being calculated based on the target mode, which would be 60 Hz for this video.

comment:3 Changed 2 years ago by krose@…

More info, as I continue to answer my own questions:

#0  MythPlayer::SetVideoParams (this=0x7fd911069b30, width=720, height=576, fps=25, scan=kScan_Ignore) at mythplayer.cpp:819
#1  0x00007fd9587a22c9 in MythPlayer::OpenDummy (this=0x7fd911069b30) at mythplayer.cpp:873
#2  0x00007fd9587a23c6 in MythPlayer::OpenFile (this=0x7fd911069b30, retries=4, allow_libmpeg2=true) at mythplayer.cpp:912
#3  0x00007fd95879cf3c in MythPlayer::StartPlaying (this=0x7fd911069b30) at mythplayer.cpp:2596
#4  0x00007fd9587c43a4 in PlayerContext::StartPlaying (this=0x25706d0, maxWait=-1) at playercontext.cpp:455
#5  0x00007fd9587c4be6 in PlayerContext::CreatePlayer (this=0x25706d0, tv=0xac44, widget=0x22ccd80, desiredState=kState_WatchingLiveTV, embed=false, 
    embedbounds=..., muted=false) at playercontext.cpp:442
#6  0x00007fd958733075 in TV::StartPlayer (this=0x256e580, mctx=0x25706d0, ctx=0x25706d0, desiredState=kState_WatchingLiveTV) at tv_play.cpp:5001
#7  0x00007fd95875fec3 in TV::HandleStateChange (this=0x256e580, mctx=0x25706d0, ctx=0x25706d0) at tv_play.cpp:2079
#8  0x00007fd9587624a4 in TV::LiveTV (this=0x256e580, showDialogs=true) at tv_play.cpp:1468
#9  0x00007fd95876b231 in TV::StartTV (tvrec=0x0, flags=<optimized out>) at tv_play.cpp:306
#10 0x000000000043bec5 in startTVNormal () at main.cpp:559

This explains where it's coming up with the wrong frames per second. SetVideoParams? gets called again with the *correct* video parameters after the channel is tuned and data starts coming in, but this is too late for the deinterlacer check.

I'm going to work around this temporarily by hard coding more appropriate parameters for my locale into OpenDummy?, but really it feels like the player really should not be created, or should be left in some limbo state, until video data comes in; or, even better, it should reconfigure itself and potentially change video modes dynamically as the incoming MPEG changes.

comment:4 Changed 2 years ago by krose@…

FWIW, hard-coding the call to SetVideoParams? in OpenDummy? to:

SetVideoParams(1920, 1080, 29.97, kScan_Interlaced);

works perfectly on my setup on both recordings and TV, for all channels. This is obviously not a solution, but it may help others out until a real solution is developed.

comment:5 Changed 2 years ago by markk

ref #8336

comment:6 Changed 2 years ago by Github

VideoSync?: Update the refresh interval after a video stream change.

An input change, as seen in live tv, may change the refresh rate which
then requires an update to the rate stored in the VideoSync? object. If
not, under certain circumstances the deinterlacer selection will fail
(and probably a range of other, more subtle issues).

Ref #10173
Ref #8336

Branch: master
Changeset: d4bbe75e42d0d85f8384c8126fea560af50721c7

comment:7 Changed 2 years ago by markk

  • Milestone set to 0.25
  • Resolution set to Fixed
  • Status changed from new to closed

As far as I can tell, this is fixed.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.