Re: Video renderer stops rendering at reaching the former stop pos
- From: Geraint Davies <geraintd@xxxxxxxxxx>
- Date: Thu, 24 May 2007 15:07:41 +0100
On Thu, 24 May 2007 02:15:01 -0700, Andreas Korn wrote:
"Geraint Davies" wrote:
On Wed, 23 May 2007 04:00:00 -0700, Andreas Korn wrote:
I want to use a playback filtergraph in a read-while-write scenario (usually
with mpeg1) and use for this purpose a custom source and splitter filter
which support opening of files still being written (source filter) and
setting of the stop position beyond the initial value (~ duration at time of
filtergraph creation). The application sets the stopposition every few
seconds to the current duration to follow the growing video.
So far this works fine, but when the graph reaches the stopposition at the
time of the last seek operation (IMediaSeeking::SetPositions with current
position set) the video renderer stops displaying anything (probably
discarding all the samples it receives for some reason). Audio playback works
fine. To get the video renderer to display again I can either do a seek from
the application or send (after the stopposition is set) a sample from the
splitter with flagged as discontinuity. Both ways interrupt playback and in
the later case there are even some samples dropped. Sending IPin::NewSegment
from the splitter output pins downstream does not have any effect.
The decoders used are the stock DirectShow MPEG1 video and audio decoders.
It does not make any difference which video renderer is used (tested with
Video Renderer and Video Mixing Renderer9).
I need a way to force the video renderer to acknoledge the new stop position
without doing a seek or some other way to deliver smooth playback.
Thanks, Andreas
I'm surprised that the NewSegment does not help -- although maybe a
NewSegment is not looked at except after a discont/flush etc. The reason
this applies to video and not audio is that video has situations where you
need to deliver frames that are not rendered (to give the decoder the
keyframes) and NewSegment is used to indicate which portions of the data
should be rendered.
If it is related to this, then the solution should be to not set a stop
time at all, and ensure that the NewSegment stop time is max-long-long.
G
A discont sample definitly does help, but leads to some drop frames (either
dropped by the decoder or renderer, I' m not sure).
Currently I am experimenting along the lines of a maxed stop position.
Unfortunatly the filter graph manager sets the current position to the stop
position when it receives an end of stream (as is the case when the splitter
detects samples with a timespamp not smaller than the duration). No I'm
trying to send the eos (in the splitter) only if the duration hasn't changed
in a while.
Andreas
It's the stop value in the NewSegment that counts here (I think) and that's
in your control in the splitter. it does not need to be the seek time stop
position - in fact many valid parsers set the newsegment stop as maxtime
even while correctly handling the stop time internally.
G
.
- Follow-Ups:
- Re: Video renderer stops rendering at reaching the former stop pos
- From: Andreas Korn
- Re: Video renderer stops rendering at reaching the former stop pos
- References:
- Re: Video renderer stops rendering at reaching the former stop positio
- From: Geraint Davies
- Re: Video renderer stops rendering at reaching the former stop positio
- Prev by Date: Re: IGraphBuilder::Connect concept
- Next by Date: Source Filter Problem
- Previous by thread: Re: Video renderer stops rendering at reaching the former stop positio
- Next by thread: Re: Video renderer stops rendering at reaching the former stop pos
- Index(es):
Relevant Pages
|
Loading