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

Issue metadata

Status: Archived
Owner:
Closed: Aug 2017
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

Issue description

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 2017

Status: Archived (was: Assigned)
[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