Opened 14 years ago

Closed 6 years ago

#10602 closed Bug Report - General (Abandoned)

Playback profiles do not fall back to follow-up entries should the first fail

Reported by: JYA Owned by: Mark Kendall
Priority: minor Milestone: 32.0
Component: MythTV - Video Playback Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

The video playback profile editor let you enter different entries according to specific video size criteria.

The choice of a playback profile works only according to those criteria. If one is automatically selected, only to later fail ; for say when the video codec isn't supported, it doesn't try another video profile.

For example, say you have a VAAPI profile, that as first entry uses VAAPI for all decoding and vaapi for deinterlacing, and a 2nd entry that uses ffmpeg for decoding and opengl for deinterlacer.

if the VAAPI/GPU doesn't support a particular codec, it only reverts to ffmpeg decoding. It should try the next entry in the playback profile. If not, as deinterlacers aren't available any longer, the video being played isn't deinterlaced and it looks awful.

Should playback profiles properly worked, a side effect would be to have for example a general "Hardware Accelerated" profile. It would first try VDPAU, then VAAPI, then CrystalHD etc... it would greatly simplify user experience

Change History (5)

comment:1 by Stuart Auchterlonie, 6 years ago

Owner: changed from JYA to Mark Kendall
Status: newassigned

Mark, didn't you just fix something like this?

comment:2 by Mark Kendall, 6 years ago

Milestone: unknown32.0
Status: assignedaccepted

The issue of deinterlacers no longer working after falling back to software decode should be fixed with the changes to the deinterlacer setup.

Falling back to an entirely different profile is something I'm aware of. It is currently complicated by the need to coordinate between the decoder and videooutput classes i.e. if hardware decoding fails, the code could fallback (fallthrough) to the next profile but it is not clear how that would be interpreted for rendering - and might produce unexpected results.

Realistically there are few situations where an alternate hardware decoder is a useful option (VDPAU to NVDEC perhaps being one exception) - although falling through to a clearly defined software decoding profile is preferable (as this will allow e.g. deinterlacing preferences to be set properly).

comment:3 by Mark Kendall <mark.kendall@…>, 6 years ago

In fb01cb3f4/mythtv:

Error: Processor CommitTicketReference failed
GIT backend not available

comment:4 by Mark Kendall <mark.kendall@…>, 6 years ago

In 240038b689/mythtv:

Error: Processor CommitTicketReference failed
GIT backend not available

comment:5 by Mark Kendall, 6 years ago

Resolution: Abandoned
Status: acceptedclosed

Migrated remaining potential issue to https://github.com/MythTV/mythtv/issues/226

Note: See TracTickets for help on using tickets.