[mythtv-users] Internal player crashes during HDTV playback on specific recordings

[Darren Hart]

On Mon, Mar 2, 2009 at 9:26 AM, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> On 03/02/2009 11:24 AM, Darren Hart wrote:
>>
>> Well, judging from how other players handle it (mplayer and xbmc both
>> can play it without crashing, but there is some solid evidence of
>> stream corruption even then) I doubt the stream is 100% valid.  Still,
>> Myth should be able to cope and continue playing as the other players
>> do.  I'll look into cropping the video and posting on my site (I have
>> plenty of space).
>>
>> Thanks for the input.
>
> (Haven't read the whole thread, but...) Yes, Myth /should/ handle it better,
> but note that the decoding/playback code in 0.21-fixes is old and what's in
> trunk has been updated significantly since then.
> Unfortunately, as people find new and interesting ways of breaking the specs
> (or as stream corruption causes new and interesting problems not seen before
> the version you're using), it takes time to get code updated /and/ pushed
> out to users.  And, since the changes introduce a /lot/ of instability,
> those "new features" (ability to handle new types of corruption) don't get
> pushed down to the stable -fixes branch.

I didn't mean the above as a negative criticism, hope it didn't come
across that way.  I do understand the issues surrounding release
engineering.

> Your MPlayer (and I'd assume xbmc) uses much newer libraries, so it has more
> fixes.
>
> So, if you /must/ have a working setup now, either:
>  a) use some external player (such as MPlayer) to play back the recording
> (most preferred solution),

Is there a way I can do this at play time?  I really want to use the
internal player most of the time.  Is there anything like a "Play with
Mplayer" ?  I haven't seen it...

>  b) as Yeechang suggested, transcode the recording(s) to some other format,
> possibly with some external transcoder, making a recording that Myth can
> play (most CPU/power cost to you, as well as inducing a large delay between
> recording and watching shows), or
>  c) subscribe to -dev and -commits list, read all the messages on those
> lists (as well as a /lot/ of the archived messages that have gone to those
> lists since 0.21 was released a year ago), then update your system to use
> trunk (noting that you can not go back to -fixes after trunk), configure
> trunk properly (making sure that you follow up any issues on the -users
> list), and test the recording with trunk /and/ keep following/reading the
> -dev and -commits lists (most work for you).

Yeah, I may try this on a laptop or something just to see if it can
play the stream, but from what I've read it isn't a good idea to run
trunk on my primary myth installation unless I am prepared to spend a
lot of time working with the community on issues.  And while I'd enjoy
it, I can't make the time for it right now.

>
> And, please do not submit a ticket until you have tested playback in MythTV
> trunk or /at least/ in the current SVN version of ffmpeg (the player,
> unrelated to Myth--if you have questions about how to do this, please follow
> up with questions here).  If it works in either of those, we don't want the
> ticket and playback will likely be fine in 0.22 (when ready).

I'll look into this, will take me some time, but I'll reply here if I
need help and with the results of course.

If I've understood you correctly, you don't feel a fix for this issue
is a candidate for the .21-fixes series?

Thanks for the response,

-- 
Darren Hart