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