Custom H264 video encoder

[Chao Liu]

Hi,

I am trying to use hardware h264 encoder in webrtc to send video to browser.

The output of h264 encoder could be played in Chrome.

However, WebRTC couldn't decode the video stream.

I got sth. like this from webrtc-internals page:

bytesReceived 10464

codecImplementationName unknown

mediaType video

packetsLost 0

packetsReceived 35

ssrc 2379292875

transportId Channel-video-1

googCaptureStartNtpTimeMs 0

googCodecName

googCurrentDelayMs 0

googDecodeMs 0

googFirsSent 0

googFrameHeightReceived -1

googFrameRateDecoded 0

googFrameRateOutput 0

googFrameRateReceived 0

googFrameWidthReceived -1

googJitterBufferMs 0

googMaxDecodeMs 0

googMinPlayoutDelayMs 0

googNacksSent 0

googPlisSent 2

googRenderDelayMs 10

googTargetDelayMs 10

googTrackId 6fecbb767df61f47cd4f

I am not sure whether there is sth. wrong with my encoder. The same code works for VP8 though.

Could sb. tell me how to find why Chrome fails to decode the stream?

[Chao Liu]

After accumulated some data, it actually works. I could see it changes googCodecName to H264 after that.

Looks like webrtc don't know the codec of my stream at the beginning. It somehow detects it's H264 after a while.

What might have caused this behavior?

The SDP looks like this:

o=- 7743168055577671137 2 IN IP4 127.0.0.1

s=-

t=0 0

a=group:BUNDLE video data

a=msid-semantic: WMS 5da9fc4beb670272e58b

m=video 9 UDP/TLS/RTP/SAVPF 107

c=IN IP4 0.0.0.0

a=rtcp:9 IN IP4 0.0.0.0

a=ice-ufrag:PB/L

a=ice-pwd:cdizQqlFP8H2MZJr10VbUmoH

a=fingerprint:sha-256 00:F8:AB:7B:E9:30:B5:D9:A0:48:CB:1F:4E:5C:BB:93:8F:7C:0D:A4:35:7F:E8:76:4A:E1:67:2D:4A:63:86:6D

a=setup:actpass

a=mid:video

a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=extmap:4 urn:3gpp:video-orientation

a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay

a=sendonly

a=rtcp-mux

a=rtcp-rsize

a=rtpmap:107 H264/90000

a=rtcp-fb:107 ccm fir

a=rtcp-fb:107 nack

a=rtcp-fb:107 nack pli

a=rtcp-fb:107 goog-remb

a=rtcp-fb:107 transport-cc

a=fmtp:107 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

a=ssrc:860755576 cname:KOaEOJ0ikg7ySU4T

a=ssrc:860755576 msid:5da9fc4beb670272e58b 5da9fc4beb670272e58b

a=ssrc:860755576 mslabel:5da9fc4beb670272e58b

a=ssrc:860755576 label:5da9fc4beb670272e58b

m=application 9 DTLS/SCTP 5000

c=IN IP4 0.0.0.0

a=ice-ufrag:PB/L

a=ice-pwd:cdizQqlFP8H2MZJr10VbUmoH

a=fingerprint:sha-256 00:F8:AB:7B:E9:30:B5:D9:A0:48:CB:1F:4E:5C:BB:93:8F:7C:0D:A4:35:7F:E8:76:4A:E1:67:2D:4A:63:86:6D

a=setup:actpass

a=mid:data

a=sctpmap:5000 webrtc-datachannel 1024

[Chao Liu]

OK. I found the problem. JitterBuffer buffers the frames until it thinks it finds a complete frame.

My question is what's the difference between VP8 and H264? My code works for VP8 but not H264. There must be some difference JitterBuffer handles H264 frames compared to VP8.

Here is the log:

INFORMATION 17216 11752 12:00:28-934 c:\b\build\slave\win\build\src\third_party\webrtc\modules\video_coding\jitter_buffer.cc       1276 Received first complete key frame

INFORMATION 17216  7420 12:00:28-945 c:\b\build\slave\win\build\src\third_party\webrtc\modules\video_coding\video_receiver.cc         290 Received first complete decodable video frame

INFORMATION 17216  7420 12:00:28-945 c:\b\build\slave\win\build\src\third_party\webrtc\modules\video_coding\codec_database.cc 530 Initializing decoder with payload type '107'.

[Christoffer Jansson]

+Stefan Holmer +Henrik Boström do you know?

--

---
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/7cfc07f3-0ae0-4722-bb29-dfb1e13ec956%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

/Chris

[Chao Liu]

Thanks. I figured it out some time later after I posted here. (Sorry for forgetting to update this thread..)

The hardware encoder use 3 or 2 "0" and a "1" as separator. 

RtpFragmentize from webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc uses "{0, 0, 0, 1}". This is true for libopenh264. I should not reuse the same code.

[Niklas Enbom]

Right, this is a bug on the WebRTC side to not accept both, see https://bugs.chromium.org/p/webrtc/issues/detail?id=6278 

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e06d5ff7-d1a6-46da-ae8e-69a848f58337%40googlegroups.com.