none
Tee Node and Custom MFT RRS feed

  • Question

    • I have a topology as below, it works fine for all frames of video sequence:

      Source --> Video Decoder MFT --->Custom MFT ---> Video Encoder MFT ---> File Sink MFT

      If I insert a Tee node between "Custom MFT" & "Video Encoder MFT", to render the preview using EVR, then the application doesn't run for all frames of the input video. I mean it ends early, I see just 50% of frames in output file. Even I verified it by keeping process counter in "Custom MFT".

      I tried to figure out the cause using mftrace, but it didn't help much. Is there a possibility of frame skips by any node if custom MFT takes too long time?  Can topology behavior change if 2 sinks run at different speed? Does topology stop If one of the sinks finish early? Is there a chance of frames getting dropped at input side of "Custom MFT"?

      I experimented with 2 resolutions to check the behavior, this issue observed only when I try with UHD (3840x2160) resolution video. It works well for HD (1920x1080) resolution.

      I have done some more experiments by changing "Tee Node" properties MF_TOPONODE_PRIMARYOUTPUT and MF_TOPONODE_DISCARDABLE. But Nothing helped.

      Can someone give insights to figure out the cause for this behavior? Is there a property that I can set to avoid frame drops/skips in the entire topology? No node should drop any frames, it's OK to run with lesser speed.

    Thursday, December 17, 2015 3:58 PM

All replies

  • Hi

    I think the Output Stream to the Video Encoder from the Tee Node should be the primary output. As the documentation on MF_TOPONODE_PRIMARYOUTPUT states :

    "The pipeline waits for a request from the primary output before processing requests from the other Outputs."

    If you set the EVR as Primary Output then the Video Encoder gets not all of the frames as it cant keep up with the EVR's Frame Request Firings. Well if you use a Hardware Encoder then yes it could, but a Software Encoder ... no way could it keep up with the EVR's Rendering Frame Rate in 4K ( And as the EVR doc states : "The output frame rate is locked to the reference stream and cannot be changed during Playback" ).

    You have Recording and Playback together in the same Topology, and they behave completly different when it comes to the Presentation Time ( IMFPresentationClock ).

    In a Recording ( Encoding ) scenario there is no use of a Presentation Clock. There is no rate of consuming, it mainly depends on how fast the Encoder is.

    In a Playback ( Rendering ) scenario the Media Sink fires a sample request and then renders the received frame according to the presentation clock ( the time is automatically calculated from Frame Rate and normaly not to be changed by you. Though you can get access to it, even on the Sink Writer ).

    In your Topology :

    I guess the EVR is requesting frames and the Encoder cant keep up with it. That explains why on 1080 your result is ok. Because these days CPU's are capable of encoding 1080 with a speed of up to 40 Fps. I tested that a few years ago in a project, was mainly pending between 30 and 35 with a max of 40 ). You can forget about encoding 4K in real time without a Hardware Encoder. So if your Video is lets say a Blue Ray with 1080 resolution and 25 Fps the Software Encoder can encode it in real time ( it depends also to a small degree on the Encoder Settings ).

    Setting the Encoder as the Primary Output should be it. I dont know though if the EVR's frame requests are dropped then or if the Video Playback is delayed, but you can check that with MFTrace. I havnt used Topologies with Encoding and Rendering from a Tee Node yet, but what i wrote here should explain the problem.

    Regards,

    Francis







    Friday, January 8, 2016 8:44 PM