[mythtv] Mplayer and certain .nuv files

Sam N. Max (snx) snx at rogers.com
Thu Aug 7 01:30:58 EDT 2003

----- Original Message ----- 
From: "Martin Moeller" <martin at martinm-76.dk>
To: "Development of mythtv" <mythtv-dev at mythtv.org>
Sent: Wednesday, August 06, 2003 6:27 PM
Subject: [mythtv] Mplayer and certain .nuv files

> Hi there.
> Lately I have had MPlayer going bonkers on certain .nuv files but not on
> others. I'm not yet sure what is the reason. Some of the files are from
> before the teletext work I did, but not that many (since most have
> already been deleted). Many of the files that MPlayer breaks on contains
> teletext streams, but according the the patch these should be ignored
> and if so, that is not the problem. The problem usually occurs about 28
> seconds in. It varies whether it breaks is decode_audio or video_frame,
> sometimes all I get is massive disk activity and something like this:

I'm not sure what's causing it to just die in the middle, as I've been
having that problem as well and couldn't track down the issue.  However,
there is a problem with the seek code in that it does properly handle text
frames in the video stream.  This happens in the libdemux code.  On mine I
quickly fixed it so it would work, by adding the following after the "else
if ( rgjpeg....frametype == 'A')" block of the demux_seek_nuv function:

    else if ( rtjpeg_frameheader.frametype == 'T' )
        curr_pos = stream_tell ( demuxer->stream );
        stream_seek ( demuxer->stream, curr_pos +
rtjpeg_frameheader.packetlength );

Probably should just move the code that seeks outside the if statements
since it applies to all frametypes (well, except for one that I know of that
doesn't occur while playing the video).  Also the mplayer seek code could
use an update to make use of the seek table, as any slightly long seek
currently requires going through a lot of the video (also sucks to seek at
all over any slowish type connection like wireless).

- Eron

More information about the mythtv-dev mailing list