Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1510913007:
Send key frame if time difference between incoming frames exceeds a certain limit. (Closed)
|
Created:
5 years ago by åsapersson Modified:
4 years, 11 months ago CC:
webrtc-reviews_webrtc.org, tterriberry_mozilla.com Base URL:
https://chromium.googlesource.com/external/webrtc.git@master Target Ref:
refs/pending/heads/master Project:
webrtc Visibility:
Public. |
DescriptionSend key frame if time difference between incoming frames exceeds a certain limit.
BUG=
Committed: https://crrev.com/1d61a518acb8eb50f4845c855a1905b26f4c2378
Cr-Commit-Position: refs/heads/master@{#11315}
Patch Set 1 #Patch Set 2 : #
Total comments: 4
Patch Set 3 : added comment #Patch Set 4 : rebase #Messages
Total messages: 20 (11 generated)
Description was changed from ========== Request frame if time difference between incoming frames exceeds a certain limit. BUG= ========== to ========== Send key frame if time difference between incoming frames exceeds a certain limit. BUG= ==========
asapersson@webrtc.org changed reviewers: + stefan@webrtc.org
Patchset #2 (id:20001) has been deleted
asapersson@webrtc.org changed reviewers: + mflodman@webrtc.org
https://codereview.webrtc.org/1510913007/diff/40001/talk/app/webrtc/java/jni/... File talk/app/webrtc/java/jni/androidmediaencoder_jni.cc (right): https://codereview.webrtc.org/1510913007/diff/40001/talk/app/webrtc/java/jni/... talk/app/webrtc/java/jni/androidmediaencoder_jni.cc:550: if (frames_received_since_last_key_ > kMinKeyFrameInterval) { What if there are two camera switches close to each other? Then the first one will only generate a key frame, right? Shouldn't be a big problem since kMinKeyFrameInterval is 2 though. Why is it 2 though? Should we remember that the delay was large and generate a key frame a few frames later when frames_received_since_last_key is large enough? https://codereview.webrtc.org/1510913007/diff/40001/talk/app/webrtc/java/jni/... talk/app/webrtc/java/jni/androidmediaencoder_jni.cc:625: frame_types->front() != webrtc::kVideoFrameDelta || send_key_frame; Why isn't this == kVideoFrameKey? Now we will generate a key frame if it's webrtc::kVideoFrameEmpty, which seems a bit wrong.
Patchset #3 (id:60001) has been deleted
https://codereview.webrtc.org/1510913007/diff/40001/talk/app/webrtc/java/jni/... File talk/app/webrtc/java/jni/androidmediaencoder_jni.cc (right): https://codereview.webrtc.org/1510913007/diff/40001/talk/app/webrtc/java/jni/... talk/app/webrtc/java/jni/androidmediaencoder_jni.cc:550: if (frames_received_since_last_key_ > kMinKeyFrameInterval) { On 2016/01/18 20:02:36, stefan-webrtc (holmer) wrote: > What if there are two camera switches close to each other? Then the first one > will only generate a key frame, right? Shouldn't be a big problem since > kMinKeyFrameInterval is 2 though. Why is it 2 though? > > Should we remember that the delay was large and generate a key frame a few > frames later when frames_received_since_last_key is large enough? Yes will not work if there are two camera switches with only one frame in between (but thought it should likely not be a problem?). kMinKeyFrameInterval is set to a small value to prevent triggering a key frame for every frame for very low framerates (for example if frame diff > kFrameDiffThresholdMs). Added a comment. https://codereview.webrtc.org/1510913007/diff/40001/talk/app/webrtc/java/jni/... talk/app/webrtc/java/jni/androidmediaencoder_jni.cc:625: frame_types->front() != webrtc::kVideoFrameDelta || send_key_frame; On 2016/01/18 20:02:36, stefan-webrtc (holmer) wrote: > Why isn't this == kVideoFrameKey? Now we will generate a key frame if it's > webrtc::kVideoFrameEmpty, which seems a bit wrong. Right seems a bit wrong, not sure about the reason.
lgtm
Patchset #4 (id:100001) has been deleted
asapersson@webrtc.org changed reviewers: + magjed@webrtc.org
magjed can you please have a look?
lgtm
The CQ bit was checked by asapersson@webrtc.org
The patchset sent to the CQ was uploaded after l-g-t-m from stefan@webrtc.org Link to the patchset: https://codereview.webrtc.org/1510913007/#ps120001 (title: "rebase")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1510913007/120001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1510913007/120001
Message was sent while issue was closed.
Description was changed from ========== Send key frame if time difference between incoming frames exceeds a certain limit. BUG= ========== to ========== Send key frame if time difference between incoming frames exceeds a certain limit. BUG= ==========
Message was sent while issue was closed.
Committed patchset #4 (id:120001)
Message was sent while issue was closed.
Description was changed from ========== Send key frame if time difference between incoming frames exceeds a certain limit. BUG= ========== to ========== Send key frame if time difference between incoming frames exceeds a certain limit. BUG= Committed: https://crrev.com/1d61a518acb8eb50f4845c855a1905b26f4c2378 Cr-Commit-Position: refs/heads/master@{#11315} ==========
Message was sent while issue was closed.
Patchset 4 (id:??) landed as https://crrev.com/1d61a518acb8eb50f4845c855a1905b26f4c2378 Cr-Commit-Position: refs/heads/master@{#11315} |
