H.264 can not be decoded when there are multiple video streams
Reported by
brightc...@gmail.com,
Sep 28 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38 Example URL: Steps to reproduce the problem: 1. make chrome to receive multi H264/VP8/VP9 video streams with difference ssrcs 2. 3. What is the expected behavior? All H264 and vp8/vp9 should be decoded. What went wrong? VP8/VP9 can be decoded, H264 (Contrained, Payload=100) decode failed 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: <Copy from: 'about:version'> Channel: n/a OS Version: OS X 10.12.6 Flash Version: Contents of chrome://gpu: When there is one H264 video stream, It can be decoded.
,
Sep 28 2017
can you provide the link to the videos?
,
Sep 30 2017
Sorry, I can not provide the videos link. We are using chrome webRTC to develop a SFU video conferencing. The multistreams can work well when all the endpoints using VP8/VP9. The H264 stream can only be decoded when it is the first stream.
,
Sep 30 2017
Thank you for providing more feedback. Adding requester "ligimole@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 5 2017
,
Oct 6 2017
,
Oct 8 2017
The bug is also existed in native webRTC for Android and IOS.
,
Oct 12 2017
I found that the H264 RTP packet can be received, but did not trigger the decoding.
,
Oct 16 2017
We don't support sending H.264 simulcast, but receiving multiple streams should work OK. Re. comment#8: Can you provide a text log that shows this? https://webrtc.org/native-code/logging/
,
Oct 16 2017
@brandtr@chromium.org, The following is windows chrome version 62 log when try to decode H.264. I have let H264 source stream generate keyframe every 3s. The same H264 stream can be decoded by my SIP agent. [3624:3544:1016/210444.499:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210444.899:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210445.099:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210445.299:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210445.499:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210445.899:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210446.099:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210446.299:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210446.499:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210446.699:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210446.899:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210447.099:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210447.299:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210447.499:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210447.899:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210448.099:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210448.299:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210448.499:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210448.899:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210449.099:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210449.299:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210449.499:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210449.702:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210449.902:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210450.102:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210450.302:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe. [3624:3544:1016/210450.502:WARNING:video_receive_stream.cc(438)] No decodable frame in 200 ms, requesting keyframe.
,
Oct 16 2017
Thank you for providing more feedback. Adding requester "brandtr@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 17 2017
Thanks. Can you upload the full log as an attachment?
,
Oct 18 2017
I debug the native webRTC and found that H264 keyframes can not be recognized especially when the frame contain more than one packets.
,
Oct 18 2017
Adding Needs-Feedback label back for full log as per C#13.
,
Oct 18 2017
Thank you for providing more feedback. Adding requester "ajha@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 18 2017
@brandtr@chromium.org, The attached is chrome_debug.log for the following test: 1. Two sessions under chrome v62 of windows 64bit 2. Each send one H264 stream to our platfrom and received two streams: one is encoded by our platfrom(VP8) and the other is origin H264 stream from another session 3. H264 can not be decoded each other.I debug the native webRTC and found that H264 keyframes can not be recognized especially when the frame contain more than one packets 4. But, when reencoded to H264 by our platform, both of two streams can be decoded each other.
,
Oct 22 2017
Hello All, I print something in the rtp_fromat_h264.c and found when the fragmented payload was parsed by ParseFuaNalu, but the fist fragment bit (kSBit) not set (payload_data[1]). But I can verify this bit set was set in in NextAggregatePacket(fu_header). Any hints why payload data was modifed?
,
Oct 22 2017
Hello All, I found that the first FU-A fragement's ksbit is cleared but the krbit is setting. I "resolved" the decoding problem also check the KRBIT for first fragment. It works in my android and IOS app now. But, I do not know why this bit (KSBIT) is changed in receiving end.
,
Nov 15 2017
brightcove, we need an rtp dump/pcap (unencrypted) to be able to investigate an rtp payload format issue. Can you provide us with that?
,
Dec 12 2017
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by brightc...@gmail.com
, Sep 28 2017