VP9 with SVC: video hangs

[Andrew S]

Hi all. I'm testing VP9+SVC support with chrome (launched with flag: --force-fieldtrials=WebRTC-SupportVP9SVC/EnabledByFlag_2SL3TL).
It works for some short time, then video freezes on receiver side, chrome keeps requesting keyframes once per 3 seconds, and FPS drops to 1 frame per 3 second.
Problem reproduces, for example, using medooze SFU test page: https://sfu.medooze.com/svc/ as well as with our application.
No need to change set of received layers to reproduce the problem. No problem is visible on sender side, all packets are forwarded by SFU to receives, so stream is broken on receiver side.
Tested with chrome stable (59) and chrome beta (60).
Is it a known issue, and is it going to be fixed?

[Lorenzo Miniero]

I've noticed the same, even though only occasionally, when integrating VP9 SVC in Janus: https://github.com/meetecho/janus-gateway/pull/925

What I noticed is that, when that happens, falling back to spatial layer 0 and then back seems to often "fix" it, which makes me think something brings the decoder to an inconsistent state from which it can recover only with some kind of "context change" (but that's just speculation deriving from observation). Keyframes didn't seem to help recover, instead, as even in a room that forces a keyframe every 10s it was still happening. On a general note, the decoder seems indeed a bit fragile with respect to what must happen to keep it happy, especially considering losses could occur and so it's not things that the SFU alone can take care of.

Lorenzo

[Sergio Garcia Murillo]

May be this related to the VP8 picture ID rewriting required when doing temporal selection on simulcast/VP8?

In the jitter buffer code it is checked if the received frame is a continuous frame from previous one, which is done by checking the picture ID:

bool VCMDecodingState::ContinuousPictureId(int picture_id) const {
  int next_picture_id = picture_id_ + 1;
  if (picture_id < picture_id_) {
    // Wrap
    if (picture_id_ >= 0x80) {
      // 15 bits used for picture id
      return ((next_picture_id & 0x7FFF) == picture_id);
    } else {
      // 7 bits used for picture id
      return ((next_picture_id & 0x7F) == picture_id);
    }
  }
  // No wrap
  return (next_picture_id == picture_id);
}

If the frame is not continuous it is put in the incomplete_frames queue, and it will cause a freeze until the time out triggers (as there is no way to recover from it via nack/rtx)

      if (continuous) {
        decodable_frames_.InsertFrame(frame);
        FindAndInsertContinuousFrames(*frame);
      } else {
        incomplete_frames_.InsertFrame(frame);
        // If NACKs are enabled, keyframes are triggered by |GetNackList|.
        if (nack_mode_ == kNoNack &&
            NonContinuousOrIncompleteDuration() >
                90 * kMaxDiscontinuousFramesTime) {
          return kFlushIndicator;
        }

IMHO this is a wrong behavior, as it should just be checking if the previous frame was completed, and the next one has a pictureID bigger than the last one.

I have just open an issue, please start it! https://bugs.chromium.org/p/webrtc/issues/detail?id=7897

Best regards
Sergio

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2a936213-89bf-46b0-8f8b-bc7c94722ceb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Philip Eliasson]

Hi Andrew!

I looked into it and created this bug to track the issue: crbug.com/webrtc/7920

/Philip

[Sergio Garcia Murillo]

Hi Philip,

I think that the code in jitter_buffer would also need to be fixed as well to not check for picture id discontinuities:

https://bugs.chromium.org/p/webrtc/issues/detail?id=7897

Best regards
Sergio

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2b230081-cd56-4b14-918c-59449fa035f1%40googlegroups.com.