The mark of packet of vp8 codec is incorrect.
Reported by
xp...@grandstream.cn,
Sep 5 2017
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Example URL: Steps to reproduce the problem: 1. join a webrtc conference using vp8 codec (pt = 100) What is the expected behavior? the mark flag should be set on the end of the frame. What went wrong? sometimes the first frame's packet is incorrect: the first packet of the frame has the mark flag but the end of the packet of the frame has no mark flag. the issue happens on the first frame. we can not reproduce the problem 100%. we test the problem with a internal auto test tool. the demo we can not provide now but we can provide the packet we captured. Did this work before? N/A Is it a problem with Flash or HTML5? N/A Does this work in other browsers? N/A Chrome version: 60.0.3112.113 Channel: stable OS Version: 10.0 Flash Version: Contents of chrome://gpu:
,
Sep 6 2017
This issue seems to be out of TE-scope as it is related to some internal auto test tool and pcap. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team. Requesting any dev from Blink>WebRTC team to please have a look into the issue.
,
Sep 6 2017
,
Sep 6 2017
Danil/Nisse, can you guys take a look at this? I took a quick look at the pcap included and it does seem to be the case that the first packet of the recording has a marker bit (seq 20292, timestamp 1544878563), while the last of that frame does not (seq 20322, timestamp 1544878563).
,
Sep 6 2017
Looking at the pcap first packet is the last packet of the frame followed by 29 pure padding packets with same timestamp.
,
Sep 6 2017
Ah good catch. That should be fine then. If you prefer not having padding as part of the vp8 stream you can negotiate rtx, in which case padding is sent on that stream instead. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by dalecur...@chromium.org
, Sep 5 2017