New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 7 users
Status: Archived
Owner:
Closed: Aug 4
Cc:
Components:
NextAction: ----
OS: ----
Pri: 2
Type: Enhancement

Blocking:
issue 1667



Sign in to add a comment
Wire up and test target_delay_ms in new Video Engine API
Project Member Reported by sprang@webrtc.org, Dec 9 2013 Back to list
Wire up config, then test that frames are buffered rather than discarded when frame rate exceeds real-time.

 
Project Member Comment 1 by sprang@webrtc.org, Dec 9 2013
Blocking: webrtc:1667
Comment 2 by vrk@webrtc.org, Oct 14 2014
Labels: Area-Video
Project Member Comment 3 by mflodman@webrtc.org, Oct 6 2015
Is this still valid?
Project Member Comment 4 by pbos@webrtc.org, Oct 6 2015
I think so, it's still part of the API. :)
Project Member Comment 5 by mflodman@webrtc.org, Oct 7 2015
Yes, I know it's still part of the API. The question was rather if there are tests covering this.
Project Member Comment 6 by pbos@webrtc.org, Oct 7 2015
Ack, wasn't aware of anyone touching this since last time. Looks to me like they're not even wired up properly for either send- or receive side:

pbos@deimos:~/webrtc/src (master)$ git grep target_delay_ms webrtc/video
webrtc/video/end_to_end_tests.cc:2296:            stats.target_delay_ms != 0 || stats.discarded_packets != 0;
webrtc/video/receive_statistics_proxy.cc:82:                                             int target_delay_ms,
webrtc/video/receive_statistics_proxy.cc:91:  stats_.target_delay_ms = target_delay_ms;
webrtc/video/receive_statistics_proxy.cc:96:  // Network delay (rtt/2) + target_delay_ms (jitter delay + decode time +
webrtc/video/receive_statistics_proxy.cc:98:  delay_counter_.Add(target_delay_ms + rtt_ms / 2);
webrtc/video/receive_statistics_proxy.h:51:                       int target_delay_ms,
webrtc/video/video_receive_stream.cc:56:  ss << ", target_delay_ms: " << target_delay_ms;
webrtc/video/video_send_stream.cc:95:  ss << ", target_delay_ms: " << target_delay_ms;

Project Member Comment 7 by mflodman@webrtc.org, Mar 1 2016
Triage ping.
Project Member Comment 8 by mflodman@webrtc.org, Dec 1 2016
Cc: sprang@webrtc.org
Owner: asapersson@webrtc.org
├ůsa,
Do we already have coverage for this_
Project Member Comment 9 by sprang@webrtc.org, Dec 2 2016
Just to be clear about what this is actually supposed to do.. I'm guessing this is referring to the setting in webrtc::VideoSendStream::Config?

    // Target delay in milliseconds. A positive value indicates this stream is
    // used for streaming instead of a real-time call.
    int target_delay_ms = 0;

That field doesn't appear to be referenced anywhere apart from the ToString method.

How does this relate to the new PlayoutDelay feature, that's configured on a frame level (in EncodedImage)?

  // When an application indicates non-zero values here, it is taken as an
  // indication that all future frames will be constrained with those limits
  // until the application indicates a change again.
  PlayoutDelay playout_delay_ = {-1, -1};




Project Member Comment 10 by mflodman@webrtc.org, Aug 4
Status: Archived
[Bulk edit] This issue was created more than a year ago and hasn't been modified the last six months -> archiving.

If this is still a valid issue that should be open, please reopen again.
Sign in to add a comment