locked
[MS-RDPEUSB] webcam Image flicker RRS feed

  • Question

  • Dear All,


    When I use Webcam through the URB redirection, I will see the image screen flicker.
    I don't know what cause image flicker, Can anyone give me some advice?


    image link:
    http://imgur.com/qmuRr
    http://imgur.com/fh5DN



    Thanks in Advance.

    Regards,

    Alfred
    Monday, August 1, 2011 10:57 AM

Answers

  • Follow-up to forum:

     

    The issue was involved HD content.  There was an issue regarding handling TS_URB_ISOCH_TRANSFER_RESULT in the correct FIFO order.  On a high latency network, enabling bulk compression also helped resolved this.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Friday, December 2, 2011 9:50 PM

All replies

  • Hi Alfred,

    Thank you for your question.  A colleague will follow up with you soon to investigate.

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM


    Monday, August 1, 2011 12:17 PM
  • Hi Alfred.

     

    I can help you with this.  Webcams use isochronous end points.  As such, in [MS-RDPEUSB] you can take advantage of setting the NoAck bit in the TS_URB_HEADER (2.2.9.1.1):

     

    “NoAck (1 bit):  A 1-bit field. If this bit is nonzero the client should not send a URB_COMPLETION message for this TRANSFER_OUT_REQUEST. This bit can be nonzero only if the NoAckIsochWriteJitterBufferSizeInMs field in USB_DEVICE_CAPABILITIES is nonzero and URB Function is set to URB_FUNCTION_ISOCH_TRANSFER. If the RequestId field is set to TRANSFER_IN_REQUEST, this field MUST be set to zero.”

     

    You will also have to set NoAckIsochWriteJitterBufferSizeInMs in USB_DEVICE_CAPABILITIES (2.2.11):

     

    “NoAckIsochWriteJitterBufferSizeInMs (4 bytes):  A 32-bit unsigned integer. If the value is nonzero, the client supports TS_URB_ISOCH_TRANSFER messages that do not expect URB_COMPLETION messages; otherwise, if the value is zero, the client does not support TS_URB_ISOCH_TRANSFER messages. If the value is not zero, the value represents the amount of outstanding isochronous data the client expects from the server. If this value is nonzero, it MUST be greater than or equal to 10 and less than or equal to 512.”

     

    That controls the size of the server-side jitter buffer.  We recommend 80ms.  The higher this value, the more latency is tolerated and the more memory is used.

     

    Please let me know if this resolves your issue
    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Wednesday, August 3, 2011 8:49 PM
  • Hi Bryan,

    Thanks for your reply

    The field "NoAckIsochWriteJitterBufferSizeInMs" in my process had been set to 0x100 in the previous, and I try to set the field to 0x200, this issue is still not resolved...
    In TS_URB_ISOCH_TRANSFER_RESULT packet, I suspect this issue is caused by StratFrame number, because my frame number is a fake, that get the current time(millisecond) to fill the StartFrame field.
    But I'm not sure the start frame is the root cause or not, is it possible to make the image flicker?



    Regards,

    Alfred



    Thursday, August 4, 2011 5:46 AM
  • Did you also set the NoAck TS_URB_HEADER for each Isoch URB, too?  We use 0x50 (80) for NoAckIsochWriteJitterBufferSizeInMs.

     

     


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Thursday, August 4, 2011 2:28 PM
  • In TS_URB_HEADER, I only receive the NoAck in TRANSFER_OUT_REQUEST, and I will not send the URB_COMPLETION packet to server, if the NoAck field is not zero.

    But webcam Image transfer is TRANSFER_IN_REQUEST, and the NoAck field is always zero.

    Should I have to set the NoAck in URB_COMPLETION packet?  but it is not defined in spec MS-RDPEUSB.

     

    Regards,

    Alfred

    Friday, August 5, 2011 1:13 AM
  • You are correct regarding NoAck applying to writes v reads.

     

    Can you send me mail to “dochelp (at) microsoft (dot) com”?  In that mail, can you identify the make/model of the Webcam?


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Friday, August 5, 2011 10:38 PM
  • Follow-up to forum:

     

    The issue was involved HD content.  There was an issue regarding handling TS_URB_ISOCH_TRANSFER_RESULT in the correct FIFO order.  On a high latency network, enabling bulk compression also helped resolved this.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Friday, December 2, 2011 9:50 PM