[mythtv] sound during fast forward/rewind on pvr350 when using it for tv-out

Joseph A. Caputo jcaputo1 at comcast.net
Fri Mar 19 10:24:35 EST 2004


On Friday 19 March 2004 03:49, Simon Kenyon wrote:
> On Thursday 18 March 2004 17:45, Joseph A. Caputo wrote:
> > On Thursday 18 March 2004 11:57, Simon Kenyon wrote:
> > > David Engel wrote:
> > > >On Thu, Mar 18, 2004 at 01:49:44PM +0000, Simon Kenyon wrote:
> > > >>with ivtv-fb. when i fast forward to rewind then it plays brief
> > > >>sequences of video as it goes. unfortunately, it also plays
> > > >> brief snatches of audio as well, which IMHO is annoying. this
> > > >> does not
> > > >
> > > >It's a known problem.  I don't know when it will get fixed since
> > > > it requires a significant change to the way Myth does ff/rew.
> > >
> > > oh well. i'll have to live with it so
> > > thanks for the quick answer
> >
> > You could use the 'trick play' feature instead of bona-fide ff/rew.
> >
> > Pro/cons:
> >
> > + gives 'smooth' rather than 'jumpy' ff/rew
> >
> > - requires more CPU, as it actually decodes every frame, as opposed
> > to skipping them like ff/rew does
> > - max. speed is lower than ff/rew
> >
> > That said, I think ff/rew should be able to be re-worked so that it
> > doesn't play sound.  Trick play obviously does it.
> >
> > This has been an item on my list for a long time.  I wrote the
> > initial implementation of the current ff/rew behavior, and at the
> > time there was no clean way to mute the sound during ff/rew without
> > modifying NuppelVideoPlayer, which Isaac didn't want me to do at
> > the time.  Later the 'mute' functionality was added, and I thought
> > I might be able to utilize that, but it would have been a kludge,
> > and since the mute function doesn't maintain state, there was no
> > elegant way to determine if the sound should remain muted or not
> > when exiting ff/rew.  Then the trick play features were added, and
> > I seem to recall ended up touching NuppelVideoPlayer to do
> > things... I guess the author was able to make a better argument
> > than I did at the time.
> >
> > Maybe I'll revisit this, but actually it's not a priority right
> > now; I think I'm going to remap my ff/rew keys to do trick play. 
> > Anyone else is welcome to take a stab at it...
> >
> > -JAC
> > _______________________________________________
> to paraphrase:
>
> you're saying that because mute doesn't maintain state it cannot be
> used to
>
> mute (if necessary)
> ff/rew
> unmute (if necessary)
>
> in the code.
> could mute not maintain state, or does that complicate all sorts of
> code paths?
>
> regards
> --
> simon
> ps i'm speaking from a theoretical/design viewpoint. not
> asking/demanding anything! just having a speculative conversation :-)


Well, *anything* is possible in code :-)

However, you're essentially correct.  The way 'mute' currently works, 
it's the "if necessary" part that can't be (easily) determined... 
actually, the problem (going on very rusty memory here) is that the 
mute functions *always* toggle the mute state, but we don't want the 
state to be toggled if we're merely muting for ff/rew (as opposed to a 
bona fide mute/unmute action).

The other thing is that, IMHO, using the 'mute' feature is not "The 
Right Way(tm)" to do things... I think that ff/rew should handle sound 
suppression the same way that the trick play features do -- that is, 
NVP should be aware of the fact that we're in a special playback mode 
and not output audio, or whatever it does.

-JAC


More information about the mythtv-dev mailing list