locked
Has Anyone Done a Seek (Start) from within your Media Source? RRS feed

  • Question

  • My medium goes (say, a file) has frames whose timestamps go

    1,2,3,4,5,67,68,69,...

    When I see 67 (assume these are relative timestamps) I know there's a long wait ahead.  I want to move the presentation clock ahead to be 67 (not 6).  I thought I'd do an IMFMediaSource::Start to 67, but if I make that from within my media source, I get an E_FAIL (or E_ABORT if I do this right after start, before the first time is valid).

    From the UI I can do the seek using IMFPMediaPlayer::SetPosition() and that much works (no gap, other than the time it takes me to manually do it).

    Has anyone done an IMFMediaSource::Start from within their media source?  Or how can I move the presentation clock (that's all I need to do)?  IMFPMediaPlayer is on top.


    Monday, August 27, 2012 11:11 AM

Answers

  • Update 4-Sep.  Today, it works.  Using the same source stream (and the same timestamp source), no delay.  I expected similar problems after doing seeks, but nothig amiss, so I went back to the old timestamp with gaps.  Still worked.  It was not a reboot-fixed-it thing since it was a problem for many days.  Maybe it was something fixed elsewhere.  I may never know.

     - - -

    The sample (each AV) is marked as a discontinuity exactly at the sample that first is.  However, that does nothing useful since it waits until the time elapses (5,6,...67,68), which can be a very long time.  I expected what you say, "...time source ... [moves the clock when the discontinuity state of the sample is seen]" to happen, but it does not do that.

    Anyway, I control the source so adding yet another timestamp to frames, linear and continuous, took care of the problem.

    Point:  While this is foreign and new-ish, the docs are severely slowing me down.  This one cost two days, not counting tangents.  If it had worked like you said, and like I understood the docs to imply (setting the discontinuity flag on the sample(s)), well, those are two days I'll never get back (or, who do I see about that?).  Who knows, maybe it does work as you say, but it didn't for me.

    Point same: Docs need more detail.  Used to be before msdn went online, the docs (API use) had much more detail.  Now it's almost always just a wham!, bam! thank you mam^Hn!

    I'll mark mine as the answer, not that it is much of one, but it looks better that way.



    Saturday, September 1, 2012 1:08 PM

All replies

  • Doing a Start internally in a media source will only lead to problems.  The client of the media source (media session, source reader, etc) is expecting the media source to be at a certain position and in a certain state, and unprompted state changes will result in the state being desynchronized with the client.  If there is a discontinuity in timestamps, set the MFSampleExtension_Discontinuity attribute on the first sample after the gap.  Then the time source (typically the audio renderer) is responsible for jumping the clock to compensate for the discontinuity.

    Friday, August 31, 2012 9:19 PM
  • Update 4-Sep.  Today, it works.  Using the same source stream (and the same timestamp source), no delay.  I expected similar problems after doing seeks, but nothig amiss, so I went back to the old timestamp with gaps.  Still worked.  It was not a reboot-fixed-it thing since it was a problem for many days.  Maybe it was something fixed elsewhere.  I may never know.

     - - -

    The sample (each AV) is marked as a discontinuity exactly at the sample that first is.  However, that does nothing useful since it waits until the time elapses (5,6,...67,68), which can be a very long time.  I expected what you say, "...time source ... [moves the clock when the discontinuity state of the sample is seen]" to happen, but it does not do that.

    Anyway, I control the source so adding yet another timestamp to frames, linear and continuous, took care of the problem.

    Point:  While this is foreign and new-ish, the docs are severely slowing me down.  This one cost two days, not counting tangents.  If it had worked like you said, and like I understood the docs to imply (setting the discontinuity flag on the sample(s)), well, those are two days I'll never get back (or, who do I see about that?).  Who knows, maybe it does work as you say, but it didn't for me.

    Point same: Docs need more detail.  Used to be before msdn went online, the docs (API use) had much more detail.  Now it's almost always just a wham!, bam! thank you mam^Hn!

    I'll mark mine as the answer, not that it is much of one, but it looks better that way.



    Saturday, September 1, 2012 1:08 PM