locked
MPEG-4 Media Sink Produces Incorrect Length of File RRS feed

  • Question

  • I have a transcoding topology to capture from a Firewire-connected VCR to an H.264 MPEG-4 file. The basic flow is as follows: DV Video Capture Source -> DV Decoder -> H.264 Encoder -> MPEG-4 Sink. (I create the MPEG-4 media sink using MFCreateMPEG4MediaSink). After I build the topology, and connect its nodes to each other, I load it using the topoloader, and queue it to a media session. I start the media session, and the transcoding starts, the output file grows accordingly. After about 30 seconds I stop the media session, finalize the MPEG-4 media sink using the IMFFinalizableMediaSink interface, then shut it down using the Shutdown method. My resulting file plays in WMP, VLC, etc., but its reported time is wrong (I assume the moov atom contains the wrong length somehow). Instead of something close to 30 seconds, the players report the file is about 27 minutes long.

    What am I doing wrong here? Other than that the file is OK. I must mention that I do not set the presentation clock on the media sink, could this be the problem? If so, where do I obtain the presentation clock?

    Thanks in advance.

    Thursday, February 13, 2014 6:34 PM

All replies

  • Hello.

    I don't really know what's the problem, but perhaps, because of the live source, there is no presentation time. And perhaps the Mp4 Sink expect time and duration on the sample to create the duration correctly.

    I will try this. Use the Source Reader to get decoded sample. Set manually the time and duration on the sample (SetSampleTime and SetSampleDuration, also check MFSampleExtension_CleanPoint). Then send samples to a Mp4 Sink Writer.

    Source Reader and Sink Writer

    • Edited by Miaou77 Thursday, February 13, 2014 7:57 PM
    Thursday, February 13, 2014 7:50 PM
  • Hi Miaou77!

    Thanks for replying, I must mention it, but the file plays just fine, at normal, correct speed. I therefore believe that the information for individual samples is OK. OTOH, you bring up a point that maybe the sample times have a significant constant component that derails the MPEG-4 sink. If nothing works, I'll try your method of examining individual samples, unfortunately, I opted for not using media writers/readers, and instead using the media session, so it'll be a significant rework of my code.

    My other theory is that since the sink does not register itself to a presentation clock, the clock start/stop methods are not called, and some vital information, such as time difference between the start and the stop of the presentation, is not passed to the sink, resulting in wrong overall file duration metadata. For my scenario, how (where?) do I obtain the presentation clock? From the DV capture media source? Sorry, I am a beginner to MF, and my knowledge is spotty.

    Thursday, February 13, 2014 8:07 PM
  • Hello.

    If the file does not have dts-pts, it can be play correctly, because source and decoder can set the sample time and sample duration according to the fps for example.

    I don't really know mpeg4 format but for the Mpeg2 format, the best way to calculate the duration of the file is to get the first dts, then the last dts and finally : duration = LastDts - firstDts.

    I suspect the problem to be here, but difficult to say without test. According to this link : Tutorial Sink Writer , the sample time and sample duration are set manually, beginning to zero for the duration and increase along the fps.

    Because a live source does not have presentation time, i suspect this to be the problem. But you have to check. If the tutorial uses sample duration and sample time, perhaps it's because the Mpeg4 encoder needs it.

    Media Sink Encoder are normally MEDIASINK_RATELESS. They ignore the clock because they don't really needs it. Check this on the Media Sink : GetCharacteristics . You can read this too : SetPresentationClock . I don't think this is the problem, but i can be wrong. Also check this about presentation clock : Presentation Clock . They say "Media sinks use the presentation time to schedule when to render samples". An encoder does not need this when he is MEDIASINK_RATELESS. An encoder render samples as quickly as possible.





    • Edited by Miaou77 Friday, February 14, 2014 8:29 PM
    Friday, February 14, 2014 8:08 PM
  • Hi!

    I am aware that archive sinks don't need the presentation clock per se, but the AVI sink example from A. Pollinger's book does show that the sink implements the clock start/stop methods.

    A question - why do you say the live source does not have the presentation time? What does it mean?

    Tuesday, February 18, 2014 6:13 PM
  • Hello.

    Yes a clock is use to start/pause/stop/rate.

    A file begin at time zero and have a duration. The source can find this in the file. The file also usually say at wich time the frame has to be presented (think about unordered frame).

    A capture is not a file, it does not really have a duration. The duration is the time you capture it, and a source can't know how many times you will play the stream. So when i say there is no presentation time frome the source, i say that missing informations to the source. So it's possible the source does not set sample time and sample duration correctly regarding this. I did not check, but the Microsoft sample to encode mpeg4 seems to need a correct sample time and sample duration. I think the source does not set it correctly (not sure, just an idea) and finally the duration is incorrect in the file.

    I i have time, i will try to capture and encode a stream to see what happens.

    • Edited by Miaou77 Tuesday, February 18, 2014 8:54 PM
    Tuesday, February 18, 2014 8:48 PM