Opened 12 years ago
Closed 3 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 Changed 4 years ago by
Owner: | changed from JYA to Mark Kendall |
---|---|
Status: | new → assigned |
comment:2 Changed 4 years ago by
Milestone: | unknown → 32.0 |
---|---|
Status: | assigned → accepted |
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:5 Changed 3 years ago by
Resolution: | → Abandoned |
---|---|
Status: | accepted → closed |
Migrated remaining potential issue to https://github.com/MythTV/mythtv/issues/226
Mark, didn't you just fix something like this?