MIRACAST DATARATE and frame drop question RRS feed

  • Question

  • 1. Does anyone knows why win8.1 miracast do re-send frame behavior ?


    The total number of Wi-Fi frames that succeeded after a single retry since the previous time step.

    typedefstruct { UINT64 EncoderBitRate; UINT64 CurrentMaxTxDataRate; UINT64 TransmittedFrameCount; UINT64 FailedFrameCount; UINT64 RetriedFrameCount; UINT64 MultipleRetryFrameCount; } MIRACAST_DATARATE_STATS;

    2. And why win8.1 miracast do frame dropped behavior , processed before or after MIRACAST_CHUNK_TYPE_ENCODE_COMPLETE ?

    Dropped frame, chunk type MIRACAST_CHUNK_TYPE_FRAME_DROPPED:

    If at any time the driver decides that it won't complete the processing of the frame/part and send it to the sink, then it should report the dropped frame. In this context a frame is only considered dropped if the driver actually started processing it by logging MIRACAST_CHUNK_TYPE_FRAME_START. If a driver calculates that it's going to skip this frame without any processing, it can log MIRACAST_CHUNK_TYPE_FRAME_DROPPEDwithout logging MIRACAST_CHUNK_TYPE_FRAME_START.

    Monday, March 3, 2014 2:15 AM


  • Here are some answers :

    1) The frame retry mentioned here are Wi-Fi data frames not H.264 frames.  The WiFi 802.11 protocol has Wi-Fi packet re-transmit provision and that is what is being reported here.

    2) MIRACAST_CHUNK_TYPE_FRAME_DROPPED frame can be reported before or after MIRACAST_CHUNK_TYPE_ENCODE_COMPLETE.  After encode complete the driver still needs to mux the video with the audio before transmission, there are likely to be queues in that processing so if for example the network send is taking too long for the previous frame the driver could device to drop this frame and encode a new IFrame.

    Roger Coote

    Windows Team

    Thursday, March 13, 2014 5:22 PM