Opened 13 years ago

Closed 13 years ago

#7967 closed defect (fixed)

OS X and 'need to change video renderer' problem

Reported by: jet.jetpac@… Owned by: markk
Priority: major Milestone: 0.23
Component: MythTV - Video Playback Version: 0.22-fixes
Severity: medium Keywords: osx frontend video renderer
Cc: Ticket locked: no


I am having problems when playing a show recorded from dvb-t. The television broadcasts in 720x576. The recording begins at 16:9 (commercials) and then switches to 4:3. In that moment, the myth frontend freezes for a while (5-20s) and then returns to menu with message 'need to change video renderer'.

I have tried to tweak settings - resolutions, renderes (VPDAU, CPU+ CPU++ etc), no luck. I am pretty stuck now.

The backed runs on ubuntu-9.10, mythtv version 0.22.0+fixes23230-0ubuntu0+mythbuntu3 Fronted is on OS X 10.5.8, fronted version 0-22-fixes-20100124_Rev.23230 (thanks to

I have tried the same playback on ubuntu (9.10) based frontend and this works without a problem.

The log from the OSX frontend is attached.

Attachments (2)

log.txt (7.5 KB) - added by jet.jetpac@… 13 years ago.
Log from the OSX Fronted.
osx_renderswitch.log (22.3 KB) - added by markk 13 years ago.
Attaching full log from mythtv-users

Download all attachments as: .zip

Change History (9)

Changed 13 years ago by jet.jetpac@…

Attachment: log.txt added

Log from the OSX Fronted.

comment:1 Changed 13 years ago by stephen.hocking@…

I have also seen this - it is symptom of the broadcaster changing the resolution of the video stream as well (in my case it was changing from 576i to 1080i). In Settings->TV playback->Playback profiles (about page 3/10) you will see playback profiles for various resolutions. In my case I have three set up - if rez <= 720 576 & > 0 0 -> ffmpeg & quartz and if rez <= 1280 720 & > 0 0 - > ffmpeg & quartz and if rez > 1280 720 -> ffmpeg & quartz I had to set them up this way, as some of the 1080i streams were being broadcast as an anamorphic 1440x1080, rather than the 1920x1080i that one might naively expect. That is what the > 1280 720 is set up to catch. Setup the de-interlacers as appropriate (the 1280 720 stream is progressive, so wont need one. Once I had done this, it all worked.

comment:2 Changed 13 years ago by markk

Component: Ports - OSXMythTV - Video Playback
Owner: changed from Nigel to markk
Priority: criticalmajor
Status: newaccepted

Changed 13 years ago by markk

Attachment: osx_renderswitch.log added

Attaching full log from mythtv-users

comment:3 Changed 13 years ago by markk


As noted elsewhere, the way to work around this problem is to create a new display profile with one entry that uses ffmpeg and quartz-blit as the renderer. That should ensure that no unnecessary renderer changes are triggered.

The underlying issue needs a proper fix though.

comment:4 Changed 13 years ago by jet.jetpac@…

Thanks for the workaround! It finally works, you have made my day!

comment:5 Changed 13 years ago by markk

Milestone: unknown0.23

comment:6 Changed 13 years ago by anonymous

See r23398

comment:7 Changed 13 years ago by markk

Resolution: fixed
Status: acceptedclosed

(In [23420]) Platform dependant VideoDisplayProfile? options.

We now build the list of supported decoders, renderers and associated options from the decoder and video output classes at run time. Any unsupported options are ignored when building the profile list from the database entries.

The net result is that the user is only presented with options that have been compiled in and the playback code will not try to initialise renderers that are unavailable. As before, final selection and validation of decoder/renderer support is completed as needed (e.g. XvMC support for MPEG2..)

Closes #7967, Refs #7972.

Note: See TracTickets for help on using tickets.