[mythtv] [mythtv-commits] Ticket #4222: Update MythMusic to continue playing in the background after exiting it.

[Ashley Bostock]

On 01/01/2008, Stuart Morgan <stuart at tase.co.uk> wrote:
>
> On Tuesday 01 January 2008 13:52:43 Ashley Bostock wrote:
> > mplayer, xine, etc... will play most files you throw at them and
> > ffwd/rewind without issue.  For the Internal player you have to make
> sure
> > you have pre-built a seek table for each file otherwise it doesn't
> > ffwd/rewind at all, or is very jumpy, and/or you get sound still playing
> > while it does so. I think most people are put off straight away when
> that
> > doesn't work and just switch to using an external player.  Once that
> part
> > gets automated I think more people will use it.  On a side note, any
> idea
> > why myth needs the seek table to be built when mplayer, xine, etc...
> don't
> > have any problems at all?  Only time I've been prompted by mplayer or
> xine
> > to rebuld one (assuming that's the same thing) is if I have a slightly
> > broken avi file. Aren't these stored in the file already?
> >
> > Ash
>
> The seeking without a seektable is a little broken in trunk, it needs
> fixing
> but it's off the radar of most devs because recordings will generally have
> seektables. It shouldn't be hard to do though and if someone opens a
> ticket
> it will probably get fixed for 0.21.
>
> To explain the reason for building seektables I'm just going to
> copy/edit/paste what I said in IRC last night to this same question:
>
> By building a seektable mythtv can do frame accurate skipping and smoother
> ffw/rew etc. Notice that mplayer/xine don't really offer ffw/rew.
>
> In order to skip etc you need to move the read pointer ahead in the file.
> So
> you need to know what point in the file is equal to the time unit used.
> e.g.
> 1 minute might be 36,163 bytes ahead in the file.
>
> Mplayer/xine etc just make guesses based on average bitrate, so although
> you
> are asking them to skip 1 minute forward in the video, they might actually
> do
> anything from 45 seconds to 1 minutes 15 seconds.
>
> When you build a seektable in mythtv, we go through the file at high speed
> and
> record the location of every keyframe, so when you skip 1 minute you move
> exactly one minute in the video. We are not performing calculations to
> work
> out the correct byte/jump amount and can skip much faster, thus allowing
> FFW/REW as well as accuracy down to the exact frame of video.
> --
> Stuart Morgan
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

Thanks for the explanation, that does make sense.

Other reasons I don't use the Internal player is that many of the video
podcasts I watch do not play correctly or even at all.

Few examples I just tried (with svn 15223 tested lastest episode from each
feed)...
http://www.hak5.org/rss/xvid.xml  - Plays video but no sound.
http://revision3.com/systm/feed/quicktime-large - Get a black screen as if
its about to play, then just goes back to the video info screen.
http://revision3.com/tekzilla/feed/quicktime-high-definition - Crashes
mythfrontend completely.
http://revision3.com/pixelperfect/feed/quicktime-high-definition - Get a
black screen as if its about to play, then just goes back to the video info
screen.
http://revision3.com/diggnation/feed/quicktime-high-definition - Crashes
mythfrontend completely.

All these work fine using mplayer and with those that are high def h.264 I
can use the -lavdopts fast:threads=2 option so that it shares the load
across my 2 cores, can the Internal player do that?

I haven't built any seektables for these videos, but I think I'm right in
saying that shouldn't affect straight playback - just limitation on
ffwd/rewind.

Ash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20080101/5e79ce0c/attachment-0001.htm