VP9 broken


#1

Hi guys,

Is VP9 still supported by jitsi?

I’ve posted messages and issues about VP9 not working after refactoring code of libjitsi (january 17).
I am willing to help to debug, but i have no idea how and where to start.

Thanks


#2

ping @gpolitis @Boris_Grozev @bbaldino


#3

Hi guys,

I’ve managed to figure out the problème: key pictures for VP9 were not detected. So the rtp packets were dropped systematically. Here is a simple patch vp9_fix.patch.txt (3.4 KB).

The key image detection is based on this https://tools.ietf.org/html/draft-ietf-payload-vp9-06#page-6. Especially this phrase

A key picture is a picture whose base spatial layer
frame is a key frame, and which thus completely resets the encoder
state. This packet will have its P bit equal to zero, SID or D
bit (described below) equal to zero, and B bit (described below)
equal to 1.

However desktop sharing isn’t working with VP9 as in Chrome it uses VP9 SVC. I am definitely getting my hands dirty to debug that too. I’am looking for some help on this part.

BTW all rtp video packets are processed by a java object called SimulcastController. Even for VP9. I would say that part of code still remains very VP8 specific and may need some refactoring.

Could this go for a PR?

Regards


#4

Hi Arthur, yes please do open a PR and I can help with VP9 screen sharing in case you finally decide to dig into it a bit further. Thanks very much for looking into it!


#5

Hi,

As you may have noticed i’ve proposed a PR that fixes VP9 with recent version of libjitsi.
I was facing issues with SVC so had problems with screen sharing.

With latest jitsi components (+PR) and by disabling VP8_PICID_REWRITING it seems to work.

Hope someone can test and confirm this.


#6

Hi Arthur, Is VP9 working with multi-user(No of users > 2) conference and desktop share for you right now? I tried the patch in this thread no luck yet. Thanks.


#7

Hi,

If i understand well, you’re facing VP9 issues with current master of JVB/libjitsi ?
For me its not working when 2 or more participants are connected because i disable P2P.

By applying the patch (see PR in github https://github.com/jitsi/libjitsi/pull/432) to libjitsi and disabling PICID rewriting (jitsi.videobridge.ENABLE_VP8_PICID_REWRITING=false) in JVB side VP9 works.

Are you sure you are linking correctly with patched libjitsi?


#8

Well, I tried the vp9_fix.patch.txt . But no luck yet. I did not disable PICID rewriting for sure. I will give it another shot. Thanks


#9

No luck yet. Did you ever see any error like this? The warning message “Failed to set the VP8 TL0PICIDX” was printed from #1606 of org/jitsi/videobridge/cc/SimulcastController.java in jitsi-videobridge. The code called DePacketizer.VP8PayloadDescriptor.setTL0PICIDX, but the code returns false, it supposed to return true. Not sure if this part caused vp9 conference (>3 participants) not working.

JVB 2018-10-06 21:46:37.060 WARNING: [237] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.060 WARNING: [431] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.060 WARNING: [237] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.060 WARNING: [431] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.061 WARNING: [237] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.061 WARNING: [431] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.061 WARNING: [237] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.061 WARNING: [271] timeseries.org.jitsi.videobridge.cc.SimulcastController.log() {“conf_creation_time_ms”:1538833571962,“stream”:1183206257,“conf_name”:“cz”,“series”:“frame_corruption”,“seq_start”:18905,“time”:“1538833597.61000000”,“seq”:18909,“seq_limit”:18908}
JVB 2018-10-06 21:46:37.061 WARNING: [271] timeseries.org.jitsi.videobridge.cc.SimulcastController.log() {“conf_creation_time_ms”:1538833571962,“stream”:957019618,“conf_name”:“cz”,“series”:“frame_corruption”,“seq_start”:18905,“time”:“1538833597.61000000”,“seq”:18909,“seq_limit”:18908}
JVB 2018-10-06 21:46:37.061 WARNING: [431] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.069 INFO: [246] org.jitsi.impl.neomedia.rtp.FrameDesc.log() keyframe,stream=1183206257 ssrc=27844137,idx=0,ts=2089680470,independent=true,min_seen=29793,max_seen=29793,start=29793,end=-1
JVB 2018-10-06 21:46:37.069 WARNING: [431] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.069 WARNING: [431] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.069 WARNING: [431] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.074 WARNING: [262] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.
JVB 2018-10-06 21:46:37.075 WARNING: [262] org.jitsi.videobridge.cc.SimulcastController.log() Failed to set the VP8 TL0PICIDX.


#10

Can you try with explicitely setting ENABLE_VP8_PICID_REWRITING to false.

private static final boolean ENABLE_VP8_PICID_REWRITING = false

org/jitsi/videobridge/cc/SimulcastController.java l.92

I’ve these messages so disabled VP8_PICID_REWRITING

For quick tests disable p2p in jitsi-meet. Next use chrome://webrtc-internals to check if packets are being sent, received and which video codec is used.


#11

Thanks, I just tried the method you’ve told me:

  1. set ENABLE_VP8_PICID_REWRITING = false
  2. disabled p2p in jitsi-meet

Checked the chrome://webrtc-internals. And I saw it is transferring video data inside audio channel. I have no idea about this situation.


#12

I dont know if this is normal… What about ssrc_XXXXXXXX_recv ? for video? there should be more than one. See if packets are received.
If not, packets are being dropped by the jvb. Please double check the link with lib jitsi for example by changing maven version label to 1.0-VP9-test an compiling with -U


#13

I already changed the module version of libjitsi. And updated pom.xml of jicofo and jitsi-video-bridge. Let me update lib-jitsi-meet and jitsi-meet, and git it another shot.


#14

Well, updated front-end code. Still stocked, :frowning:

I checked received package, but no frame decoded. Any idea?


#15

What are your versions of libjitsi, jvb, and jicofo ? And chrome? I’ll give it a try


#16

Thanks. I am using master branch of libjitsi jvb and jicofo.

Chrome: Version 68.0.3440.84 (Official Build) (64-bit) Mac
libjitsi: master branch, commit hash 017195565dd237d5c83d3e81c44291446ffbb0af
jvb: master branch, commit hash 584e4663187be65464b0315db684eb016b6a2773
jicofo: master branch, commit hash 05b37ae994b2e3ebcab654cbcc8ce231628c6d9d


#17

Actually i got it working with:

Chrome : 69.0.3497.100 (Windows)
jicofo : 05b37ae994b2e3ebcab654cbcc8ce231628c6d9d
jvb: 584e4663187be65464b0315db684eb016b6a2773
libjitsi: 017195565dd237d5c83d3e81c44291446ffbb0af

Can you set the following jvb side:

org.jitsi.videobridge.ENABLE_SVC=true
org.jitsi.videobridge.ENABLE_VP9_SVC=true


#18

Thanks. I tried the config you mentioned. Unfortunately, Still ran into the same
issue. And I found the static variable ENABLE_VP9_SVC(org.jitsi.videobridge.xmpp.MediaStreamTrackFactory line #99) was never being used any where.

I also tried to upgrade my chrome to latest version. Still got the exact same issue so far.

I gave it another shot by using vp8(disable svc), and vp8 worked without big problem. So I guess the libjitsi was linked correctly anyway.


#19

Have you the possibility to test in Windows environment?

Can you wipe ~/.m2/repository/org/jitsi/libjitsi/ and try to build only jvb and see error that says libjitsi-[your-version-tag] is missing

Please show me the diff of your libjitsi and jvb.


#20

I do not have a Windows development environment right now.

Well I checked dependencies by using command “mvn dependency:tree”. And I am sure maven is using my version of libjitsi.

Here are the diff files:
jvb.diff.txt (1.2 KB)
libjitsi.diff.txt (3.9 KB)

Thanks