libvpx in webrtc

[Kevin Glass]

Hi all,

Could someone tell me which version of libvpx is being used in the chrome canary build at the moment? It appears to be v1.0.0 (based only on the defines it uses). Unfortunately that won't build on my OSX box here. 

I've been trying to interoperate VP8 video from canary with mediastreamer's vp8 support (which is based on v1.1.0) but I just keep getting the:

Bitstream not supported by this decoder

Any thoughts or help appreciated,

Cheers,

Kev

[Stefan Holmer]

Hi,

From what I can see Chromium upgraded to v1.1.0 three weeks ago:

http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libvpx/source/libvpx/

/Stefan

[Kevin Glass]

Thanks for that Stefan.

I've been digging more into the issue and it seems that the VP8 I'm receiving from the browser has the extension bit set and the mediastreamer use of the codec doesn't use that - does anyone know if there's a flag that is passed to vpx to support it?

Cheers,

Kev

[John Koleszar]

Seems more likely that you're not passing the decoder the correct start of the vp8 data. Can you give me a hex dump of the first 16 bytes or so of the first frame?

[Kevin Glass]

This is a snippet of the start of the payload from the RTP packet that I decode from the WebRTC SRTP, seems to fit as VP8 with the extension bit set.

0000  - 90 80 93 e4 b1 1e 00 08 10 7c 00 1e dc 6e 1c e6

0010  - 82 ad 41 32 cc 9c 6a c0 c0 c0 c0 c1 85 82 a7 65

0020  - f2 99 01 54 c0 48 bd ff f7 de 5e 62 aa d7 93 05

I'm not 100% convinced that's what actually getting into the decoder, I'm currently trying to get that data out now. 

Could you help me to understand if the above payload for VP8 make sense and I'll try and get the data thats going into the decoder itself shortly.

Cheers,

Kev

[John Koleszar]

Ah, I see what you're doing. You can't pass the RTP data into libvpx. You need to depacketize it and pass only the vp8 payload to the decoder.

[Kevin Glass]

Thanks for helping, I've got mediastreamer2 doing the de-packetizing but I'm wondering if their code isn't quite right. If I take a stream that they've encoded and try and decode that - all is well. Only when I try to decode the stream from WebRTC do I get the error.

I'll find out exactly whats being passed in for decoding.

Cheers,

Kev

[Kevin Glass]

Here's some debug track from the packets being decoded, first the RTP stack receives two packets. The first isn't marked (cseq=19770, timestamp=1515417266) and the next marked.

ortp-message-PACKET: not marked - 19770 - 1515417266
ortp-message-PACKET: marked - 19772 - 1515424106

The first frame of data is passed into the decoder and has a length of 935:

ortp-message-Decode length= 935

The first 16 bytes of the frame passed in:

ortp-message-byte 0 = 3e
ortp-message-byte 1 = 44
ortp-message-byte 2 = 54
ortp-message-byte 3 = 53
ortp-message-byte 4 = 44
ortp-message-byte 5 = 4b
ortp-message-byte 6 = 4e
ortp-message-byte 7 = 61
ortp-message-byte 8 = 6d
ortp-message-byte 9 = 65
ortp-message-byte 10 = 3c
ortp-message-byte 11 = 2f
ortp-message-byte 12 = 6b
ortp-message-byte 13 = 65
ortp-message-byte 14 = 79
ortp-message-byte 15 = 3e

And the message provided out of the codec:

ortp-warning-vpx_codec_decode failed : 5 Bitstream not supported by this decoder ((null))

I think the de-packetizing is the issue here, but I'm struggling to comprehend what it *should* be doing. If RTP packets have been lost or re-ordered does it make sense to just bin up until the next marked packet - i.e. the next frame?

Apologies if this slightly off topic - trying to get webrtc to talk to mediastreamer.

Cheers,

Kev

[Kevin Glass]

Tracked down the the actual data thats being pushed through:

ortp-message-Decode length= 221

DECODING: 90,80,bc,4a,31,12,00,0a,10,5c,00,1e,eb,be,9b,05,

ortp-warning-vpx_codec_decode failed : 5 Bitstream not supported by this decoder ((null))

Any ideas what's wrong with that packet?

Cheers,

Kev

[John Koleszar]

I can't tell you what's going wrong with the depacketization, only that neither one of the dumps you show represents a VP8 keyframe. Have you tried bouncing the data you're seeing against the VP8 RTP payload spec? The 90 80 pair looks like it could be the start of the "VP8 Payload Descriptor" from section 4.2 for a keyframe, but this still isn't data that should be passed to the decoder, and the rest of the data doesn't look right for what the codec's expecting.

One thing you can look for when you're looking at these dumps is the sequence 9d 01 2a, which are bytes 3-5 of a VP8 keyframe. Byte 0 will have the LSB clear, probably the whole lower nibble. This is the "VP8 Payload Header" from section 4.3.

[Kevin Glass]

Thanks for the suggestions John. I've worked my way through a little further. Following your advice and the spec I've got a bit further. The first packet now looks good, I get the first packet and few fragments.

PACKET: sbit= 1 marked=false -     5061 - 3061282943
RECV: b0,bd,00,9d,01,2a,80,02,e0,01,0d,c7,08,85,8
PACKET: sbit= 0 marked=false -     5062 - 3061282943
RECV: f0,2b,e4,49,e8,6f,e4,1b,f9,5d,37,e3,87,40,ba,08,fb,dd
PACKET: sbit= 0 marked= true -     5063 - 3061282943
RECV: e9,bb,25,b5,08,c7,30,ea,2d,62,a2,19,48,05,b3,
DECODING: b0,bd,00,9d,01,2a,80,02,e0,01,0d,c7,08,85,85,88,85,84,88

I can see the marker bytes you suggested 9d,01,2a and passing this to the decoder doesn't seem to fail (at least nothing is reported). However, I expected to see whereever the sbit was set in the payload descriptor that I'd see that same payload header identifier. However, the next packet I get looks like this:

PACKET: sbit= 1 marked= true -     5064 - 3061290503
RECV: d1,1c,00,37,11,a8,00,18,8c,ca,a6,3f,ff,19,87,0a,f0,4
DECODING: d1,1c,00,37,11,a8,00,18,8c,ca,a6,3f,ff,19,87,0a,

So sbit=1, marked for the end of the frame but no payload header identifier. On the other hand the decoder still doesn't complain about this and packets continue to be process thought no frames are decoded.

Finally the decoder bails out on an assertion:

Assertion failed: (pbi->num_fragments < MAX_PARTITIONS), function vp8dx_receive_compressed_data, file vp8/decoder/onyxd_if.c, line 314.

I've been back to the spec but I can't see why I wouldn't be getting those header identifiers now. Not sure what the assertion is about either, have I missed a configuration option?

Thanks so much for the suggestions so far, it's got me a bit closer (I hope :)).

Cheers,

Kev

[Kevin Glass]

Thanks all for your help. I have it working now. It was a packetisation issue.

Cheers,

kev

[Mamadou]

For Linphone and VP8 error, you can check {1} which explain how to fix
the issue.

{1} http://linux.autostatic.com/installing-webrtc2sip-on-ubuntu-1204

On Mar 6, 10:42 am, Crazy Joe <grayfox61...@gmail.com> wrote:
> Hi Kevin,
>
> I am glad of that you solve the problem.
>
> I am doing some testing on WebRTC, I have already installed the WebRTC2Sip
> Server and it is running well with most codec.
> But only codec "VP8" , When I use Linphone to test With WebRTC Client using
> video codec "VP8", my Linhpone Client Logged the Error Message "5 Bitstream
> not supported by this decoder" same with u
>
> I have checked my first RTP packet with  sequence 9d 01 2a ...... , so I
> think the payload header which may be right.
> But I dont have any idea to solve the problem, I have checked all the
> package about install webrtc2sip is already installed with vp8 support.
>
> Would you tell me any tips about how you resolve the problem, thanks.
>
> Kevin Glass於 2012年7月4日星期三UTC+8下午11時16分25秒寫道：

>
>
>
>
>
>
>
>
>
> > Thanks all for your help. I have it working now. It was a packetisation
> > issue.
>
> > Cheers,
>
> > kev
>

> >> > On Tue, Jul 3, 2012 at 2:12 PM, Kevin Glass <ke...@cokeandcode.com<javascript:>>

> >> wrote:
>
> >> >> Tracked down the the actual data thats being pushed through:
>
> >> >> ortp-message-Decode length= 221
>
> >> >> DECODING: 90,80,bc,4a,31,12,00,0a,10,5c,00,1e,eb,be,9b,05,
>
> >> >> ortp-warning-vpx_codec_decode failed : 5 Bitstream not supported by
> >> this decoder ((null))
>
> >> >> Any ideas what's wrong with that packet?
>
> >> >> Cheers,
>
> >> >> Kev
>

> >> >> On 3 July 2012 16:14, Kevin Glass <ke...@cokeandcode.com <javascript:>>

> >> >>> On 3 July 2012 15:37, Kevin Glass <ke...@cokeandcode.com<javascript:>>

> >> wrote:
>
> >> >>> > Thanks for helping, I've got mediastreamer2 doing the
> >> de-packetizing but I'm wondering if their code isn't quite right. If I take
> >> a stream that they've encoded and try and decode that - all is well. Only
> >> when I try to decode the stream from WebRTC do I get the error.
>
> >> >>> > I'll find out exactly whats being passed in for decoding.
>
> >> >>> > Cheers,
>
> >> >>> > Kev
>

> >> >>> > On 3 July 2012 15:24, John Koleszar <jkol...@google.com<javascript:>>

> >> wrote:
>
> >> >>> >> Ah, I see what you're doing. You can't pass the RTP data into
> >> libvpx. You need to depacketize it and pass only the vp8 payload to the
> >> decoder.
>

> >> >>> >> On Jul 3, 2012 7:15 AM, "Kevin Glass" <ke...@cokeandcode.com<javascript:>>

> >> wrote:
>
> >> >>> >>> This is a snippet of the start of the payload from the RTP packet
> >> that I decode from the WebRTC SRTP, seems to fit as VP8 with the extension
> >> bit set.
>
> >> >>> >>> 0000  - 90 80 93 e4 b1 1e 00 08 10 7c 00 1e dc 6e 1c e6
> >> >>> >>> 0010  - 82 ad 41 32 cc 9c 6a c0 c0 c0 c0 c1 85 82 a7 65
> >> >>> >>> 0020  - f2 99 01 54 c0 48 bd ff f7 de 5e 62 aa d7 93 05
>
> >> >>> >>> I'm not 100% convinced that's what actually getting into the
> >> decoder, I'm currently trying to get that data out now.
>
> >> >>> >>> Could you help me to understand if the above payload for VP8 make
> >> sense and I'll try and get the data thats going into the decoder itself
> >> shortly.
>
> >> >>> >>> Cheers,
>
> >> >>> >>> Kev
>

> >> >>> >>> On 3 July 2012 14:54, John Koleszar <jkol...@google.com<javascript:>>

> >> wrote:
>
> >> >>> >>>> Seems more likely that you're not passing the decoder the
> >> correct start of the vp8 data. Can you give me a hex dump of the first 16
> >> bytes or so of the first frame?
>

> >> >>> >>>> On Jul 3, 2012 2:58 AM, "Kevin Glass" <ke...@cokeandcode.com<javascript:>>

> >> wrote:
>
> >> >>> >>>>> Thanks for that Stefan.
>
> >> >>> >>>>> I've been digging more into the issue and it seems that the VP8
> >> I'm receiving from the browser has the extension bit set and the
> >> mediastreamer use of the codec doesn't use that - does anyone know if
> >> there's a flag that is passed to vpx to support it?
>
> >> >>> >>>>> Cheers,
>
> >> >>> >>>>> Kev
>

> >> >>> >>>>> On 2 July 2012 20:50, Stefan Holmer <hol...@google.com<javascript:>>

> >> wrote:
>
> >> >>> >>>>>> Hi,
>
> >> >>> >>>>>> From what I can see Chromium upgraded to v1.1.0 three weeks
> >> ago:
>

> >>http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libvpx/s...

[Kevin Glass]

That doesn't seem to cover the issue I was seeing with the Linphone. The source for linphone VP8 media filter in vp8_unpacketize doesn't support the Picture ID element that WebRTC includes in the VP8 RTP payload header - adding support is as easy as checking the bit and then skipping the couple of bytes for the extension byte and the 8 bit picture ID I think.

Cheers,

Kev

--

---
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Mamadou]

the link I sent is about doing it at server side:
https://code.google.com/p/doubango/source/browse/branches/2.0/doubango/tinyDAV/src/codecs/vpx/tdav_codec_vp8.c#854
as "crazy joe" says he's using webrct2sip server

On Mar 6, 4:44 pm, Kevin Glass <ke...@cokeandcode.com> wrote:
> That doesn't seem to cover the issue I was seeing with the Linphone. The
> source for linphone VP8 media filter in vp8_unpacketize doesn't support the
> Picture ID element that WebRTC includes in the VP8 RTP payload header -
> adding support is as easy as checking the bit and then skipping the couple
> of bytes for the extension byte and the 8 bit picture ID I think.
>
> Cheers,
>
> Kev
>

> ...
>
> read more >>