locked
Seeking is slow RRS feed

  • Question

  • My goal is to replace WME with MF with repect to extracting a video clip (10 seconds) from a large video (typically near 2 hours long). At first, I was suggested to use Transcode technique, but there were two problems. First being slow, since Transcode decode the video and then re-encode the video. Second being compatibility, since Transcode works only under Windows 7. Then I switched to use a topology that connects directly from the source to sink. But this topology leads to a deadlock issue, if the first sample passed to the sink is not a key frame. Then I was suggested to place a simple MFT in between that drops all the samples until a key frame is found.

    Now I have a seeking problem. It takes very long to seek through the video. 
    Extracting from 10s to 20s takes no time.
    Extracting from 30m to 30m20s takes 8s.
    Extracting from 60m to 60m20 takes 16s.
    It seems like it's linear to how far into the video we are extracting.

    =============================================
    newly added:

    In order not to misleading, I removed my code for the MFT. I did some timing analysis, most of the time was used before my MFT is called.

    I tested the Transcoding technique, which also seeks very slow.
    I tested the MFPlay sample, which does NOT have seeking problem.
    Monday, August 17, 2009 1:39 PM

Answers

  • Problem solved,
    I removed
    CHECK_HR( hr = pNode->SetUINT64( MF_TOPONODE_MEDIASTART, hnsStart ) );

    instead, I added
    varStart.vt = VT_I8;
    varStart.hVal.QuadPart = hnsStart;
    CHECK_HR( hr = pSession->Start( NULL, &varStart ) );


    Sadly I think MF_TOPONODE_MEDIASTART is totally useless...and people should use PROVARIANT and specify the start time.
    • Marked as answer by DreamFly_ Tuesday, August 18, 2009 6:46 PM
    • Unmarked as answer by DreamFly_ Tuesday, August 18, 2009 8:32 PM
    • Marked as answer by DreamFly_ Tuesday, August 18, 2009 8:32 PM
    Tuesday, August 18, 2009 6:46 PM