directshow frustrations

Georg Seidel <[email protected]>
Newsgroups gmane.comp.video.gephex.devel
Message-ID <[email protected]>
After finishing the directshow capture driver (which seems to work quite 
well),
I gave the directshow video file driver in the frbinmodule another try.

I thought that it would be quite similar to the capture driver, because
I use a similar filter graph with a ISampleGrabber object.
But this assumption turned out to be wrong.
The first difference was that I could not use the 
ISampleGrabber::setCallback method that I used in
the capture driver, because of synchronization issues in the callback 
function
(which I tried to solve with a CriticalSection, but without success, I 
just got
a deadlock).
The second difference was that I would not get any frames until I inserted
a INullRenderer object into the filter graph.

Instead of the callback I now use the ISampleGrabber::getCurrentBuffer() 
method.

OK, so now for the tricky part: seeking to the requested frame
(the frbinmodule allows random access to frames).

My first try was to seek to the frame (using the IMediaSeeking 
interface) and then return the
current buffer.  But I soon realized that I needed synchronization (i.e. 
I had to wait for the frame
to be decoded and only after that call getCurrentBuffer()).

So next I set the sample grabber to one shot mode, paused the filter 
graph, seeked to the new frame,
ran the filter graph again and waited for the EC_COMPLETE signal.
This worked, but very very slowly (it also had the problem of letting 
the filter graph in a running state,
even if no frames were requested for a long time, so I added a thread 
that checked if
there was no request for a given time and stopped the graph in that case).

The next thing I tried was to drop the single shot mode and to use the 
AM_SEEKING_Segment flag for IMediaSeeking::setPositions,
but this seems not to be supported by the video codecs I tried.

Then, I tried to set the start time _and_ the stop time to the requested 
frame in IMediaSeeking::setPositions, and to wait for
a EC_COMPLETE (again without the single shot mode). That seemed to work, 
but was equally slow.

After that I gave up. I could not think of any easy thing to try next, 
and I could think of some hard things that I didn't
want to try (like building a custom sample grabber class or trying to 
talk to the codec filter directly).  At the moment I just
don't want to spend another full day trying to make a very simple thing 
work.


I wrote this email to document my experiments with directshow (and with 
the vague hope that someone reading this list
might have some suggestions). The problem with all the stuff above is 
that it is not only slow for random access
(which I could understand because of the nature of most codecs), but 
also for sequential access.


Regards,

Georg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.