[mythtv] [mythtv-commits] Ticket #6974: last few seconds of video are not played

Mark Spieth mark at digivation.com.au
Sun Jan 6 04:04:08 UTC 2013


On 1/6/2013 2:43 PM, Jim Stichnoth wrote:
> Thanks, Mark.  I'll take a deeper look at #3, and maybe come back to
> #1 later.  I don't have a practical way to test MHEG.
>
> As for the other part of the ticket, I attached a revised version of
> your patch to the ticket.  In many cases, it works exactly right,
> playing all the way to what appears to be precisely the last frame
> that can be seen in the cutlist editor, and it does so with or without
> the end-of-recording delete prompt.  However, in other cases, it may
> still stop up to almost 1 second before the end of the recording.  In
> that case, lots of messages appear in the log: "Video is 30 frames
> behind audio (too slow), dropping frame to catch up."  This is
> reminiscent of the original play-to-end.patch which also did some
> audio blocking.  Is the audio portion still relevant in today's code?
>
> Jim
Yes your revised patch looks good and consistent. I left the bool 
interfaces there for ease of implementation.

However I dont think you need it with your implementation because the 
player doesnt stop until framesPlayed (from 
videooutput->GetFramesPlayed()) indicates completion.
This should be consistent with ValidVideoFrames being 0 and thus the 
check should not be necessary.
If this is not true, then it should be (IMO). It should be a pointless test.

Im just building for testing ATM.

Any other issues I believe will be that pause is not active before 
playing is set to false.
Or perhaps some other issue with GetFramesPlayed not being updated 
correctly in some corner cases.

As for audio/video issues, the main issue is that the stream audio and 
video timestamps may vary (in the DVB ones Ive examined anyway) by even 
1 second. so there is more audio buffered when the video packets appear 
in the stream or vice versa.
That means in this end of stream case we have eitehr no audio left to 
play or we have lots of audio to play and no more video frames. This can 
cause the slowdown seen when AVsync has to catch up one way or the 
other. This is also seen after a seek.
My faststart patch handles early unusable audio by dropping it. Havent 
figured out a decent way to handle the early video bit yet.
Perhaps a flag to disable AVSync when performing EOF processing. Not 
sure about this though.


Mark



More information about the mythtv-dev mailing list