Re: VMR Mixing Mode and Seeking Problem
- From: Cyborg <sirhaden@xxxxxxxxxxx>
- Date: Tue, 11 May 2010 07:02:07 -0700 (PDT)
On Apr 16, 3:59 pm, Cyborg <sirha...@xxxxxxxxxxx> wrote:
On Apr 14, 6:11 am, Geraint Davies <gerai...@xxxxxxxxxx> wrote:
This sounds like a bug I tracked down in the VMR about a year ago. The
flush operation is not correctly handled for secondary streams. I
don't remember the exact details of the bug, but I know it related to
secondary streams that I call SetActiveStreamState on.
I had a decoder that was feeding alpha bitmaps that were not always
available. I started out with active state = false, and in the
decoder's Deliver function, I set active state = true before the first
delivery.
To work around the flush bug, I overrode DeliverBeginFlush in my
decoder's output pin, and called SetStreamActiveState(false) *before*
passing BeginFlush downstream to the VMR.
G
On Mon, 12 Apr 2010 10:20:50 -0700 (PDT), Cyborg
<sirha...@xxxxxxxxxxx> wrote:
I've got a custom demux filter that has 2 video output pins. Both of
the video output pins are connected to decoder filters and then to a
single VMR in Windowless Mixing mode. When the graph transitions from
stopped to running in the Pause method of the filter, the input pin of
the VMR connected to the 2nd video stream has
SetStreamActiveState(FALSE) called on it to disable the 2nd video
stream. This is done because the second video stream may not start
for some time into playback. When the second stream is detected,
SetStreamActiveState(TRUE) is called on the associated VMR input pin
and playback proceeds.
The problem occurs during seeking. The main video stream is the one
for which seeking occurs and the 2nd video stream is simply a slave.
This results in the main video stream being seeked to an IFrame while
the 2nd video stream is often seeked to a non-IFrame. During seeking,
the DeliverBeginFlush and DeliverEndFlush methods are called on the
video output pins which are associated with an active VMR input pin.
When both video streams are playing and a seek occurs, the 2nd video
stream's output pins have the DeliverBeginFlush call succeed but the
DeliverEndFlush method hangs.
I'm not sure if it is the 2nd video stream's downstream decoder that
is causing the DeliverEndFlush call to hang, or if it's the VMR. Any
ideas how to what may be causing DeliverEndFlush to hang?
Thanks Greatly,
Michael- Hide quoted text -
- Show quoted text -
I've been trying many things from setting the pin to inactive in the
DeliverBeginFlush call as you suggested to messing with the
IFilterChain interface and more. The best results do seem to occur
when the VMR's 2nd input pin is set to inactive and then the Begin and
End Flush calls are made, but every now and then I still get a lock
up.
The lock ups seem to occur during BeginFlush, EndFlush or even when
trying to pause the pull pin thread. I'm starting to think that there
is an issue with the decoder (as 2 instances are being used). By
pausing the debugger and examining the threads and call stacks it does
appear that there is always a freeze in one of the decoders, either
waiting to deliver a sample to the renderer or trying to complete a
begin or end flush operation.
Very frustrating indeed...
Thanks- Hide quoted text -
- Show quoted text -
Getting back on the issue, it appears that even when there are 2 video
streams going into a single VMR9 instance the problem continues to
exist. Removing all calls to SetActiveStreamState(FALSE) and simply
performing seeking around in the file, eventually ends up with the
second video stream's video decoder getting deadlocked in a call to
GetBuffer on the VMR's allocator. The deadlock occurs even after the
flushing occurs, which seems to have no effect on the deadlock.
I've tried using the SetActiveStreamState approach mentioned above and
even included a disconnect of the second video stream's decoder output
pin from VMR, along with a decommit of the allocator during the
DeliverBeginFlush. In the DeliverEndFlush, the pins are reconnected
and the allocator is recommitted before making the call to
SetActiveStreamState(TRUE). What I'm seeing in this scenario is the
call to ConnectDirect to reconnect the second stream's video decoder
and the VMR will succeed for a variable number of times and then it
will fail with VFW_E_BUFFERS_OUTSTANDING.
Could this be a bug in the VMR? Does the VMR share a single allocator
between all of its pins? It's odd that decommitting the allocator
does not ensure all buffers are not released and that the call to
flush (even while not calling SetActiveStreamState or performing any
special functionality during the flush calls) does not result in the
GetBuffer method being freed from its deadlock.
I've started writing a custom transform filter to go between the
second video stream's decoder and the VMR to attempt to control the
flushing, allocator deadlocking, etc., but I'm unsure if this is the
best approach. I've examined the GMFBridge's
BridgeAllocator::GetBuffer method thinking that a similar approach
within a transform filter may help, but it may be a dead end as the
VMR may insist on using its own allocator and the deadlocking problem
may still exist.
I prefer not to write my own renderer, and I certainly wish MS had
released the code to the VMR so more intense debugging could be
performed. I've been eyeing the MultiVMR9 sample project trying to
determine if it may be help get past the issue.
Any suggestions or thoughts on the issue are greatly appreciated...
.
- Prev by Date: Video can be rendered from Averlogic source, but nothing else
- Next by Date: RE: Video can be rendered from Averlogic source, but nothing else
- Previous by thread: Video can be rendered from Averlogic source, but nothing else
- Next by thread: h264 streaming over RTP/RTCP
- Index(es):
Relevant Pages
|
