[mythtv] [mythtv-commits] Ticket #6974: last few seconds of video are not played
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?
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.
More information about the mythtv-dev