Opened 13 years ago
Closed 13 years ago
#8859 closed defect (Won't Fix)
Video playback not falling back to XVideo when VDPAU fails
| Reported by: | danielk | Owned by: | markk |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.25 |
| Component: | MythTV - Video Playback | Version: | Master Head |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
There are some files VDPAU no longer handles because either we or the driver is enforcing resource constraint checks more more vigorously than it used to. That is not a bug. But on Linux we are supposed to be falling back to XVideo playback when all configured video playback mechanisms fail. Instead we pause for a while and then exit video playback with a message about an A/V Sync failure.
Attachments (1)
Change History (7)
Changed 13 years ago by
| Attachment: | vdpau-fall-back.txt added |
|---|
comment:1 Changed 13 years ago by
Nothing has changed in how we handle VDPAU playback and I doubt the driver has changed much either. The log clearly states that the driver believes it is out of memory. As far as I can tell, the Quadro NVS 140M has 256Mb of video memory which is essentially unsupported.
This situation is compounded by the fact that decoder creation doesn't happen until after playback has started. Hence if it fails at this stage, which it has in this case, we need to signal an error state and attempt to recreate all of the playback objects. It is this last stage that appears not to be working.
comment:2 Changed 13 years ago by
| Status: | new → assigned |
|---|
comment:3 Changed 13 years ago by
| Milestone: | unknown → 0.24 |
|---|
comment:4 Changed 13 years ago by
| Status: | assigned → accepted |
|---|
comment:5 Changed 13 years ago by
| Milestone: | 0.24 → 0.25 |
|---|
Pushing back to 0.25 as I can't see a simple fix for this at the moment.
comment:6 Changed 13 years ago by
| Resolution: | → Won't Fix |
|---|---|
| Status: | accepted → closed |
Closing as Won't Fix but only because there isn't a Have No Idea How to Fix option.
With the various changes to VDPAU buffer handling and UI image caching, the likelihood of a 256Mb card working is now improved (though I still wouldn't recommend it).
The underlying issue remains the same however. With VDPAU, the decoder object is not created until after all other video playback objects (ringbuffer, player, video output, buffers etc) and ffmpeg is looking to decode the first frame. If creating the decoder then fails at this point, there is no obvious and easy route back to a valid video output.
The error messaging could do with fixing though.
-v playback log