m1k1o / neko

A self hosted virtual browser that runs in docker and uses WebRTC.
https://neko.m1k1o.net/
Apache License 2.0
5.96k stars 449 forks source link

VLC play stucked #283

Closed xushier closed 1 year ago

xushier commented 1 year ago

My device、env & configs:

cpu: i9-9900 gpu: intel uhd 630 network: UP:1000Mbps docker:

docker run
  -d
  --name='Neko-Vlc'
  --net='bridge'
  --privileged=true
  -e 'NEKO_PASSWORD'='xxx'
  -e 'NEKO_PASSWORD_ADMIN'='xxx@'
  -e 'NEKO_NAT1TO1'=''
  -e 'NEKO_ICELITE'='true'
  -e 'NEKO_VP8'='true'
  -e 'NEKO_VP9'='false'
  -e 'NEKO_H264'='false'
  -e 'NEKO_VIDEO_BITRATE'='2500'
  -e 'NEKO_MAX_FPS'='25'
  -e 'NEKO_AUDIO_BITRATE'='128'
  -e 'NEKO_FILE_TRANSFER_ENABLED'='true'
  -e 'NEKO_HWENC'='vaapi'
  -e 'NEKO_CONTROL_PROTECTION'='true'
  -e 'NEKO_FILE_TRANSFER_PATH'='/home/neko/Downloads'
  -e 'NEKO_IPFETCH'='https://checkip.amazonaws.com'
  -e 'NEKO_PROXY'='true'
  -e 'NEKO_BIND'=':8080'
  -e 'NEKO_LOCKS'='file_transfer control'
  -e 'NEKO_IMPLICIT_CONTROL'='false'
  -e 'NEKO_EPR'='52000-52100'
  -e 'NEKO_SCREEN'='1600x900@60'
  -p '6531:8080/tcp'
  -p '52000-52100:52000-52100/udp'
  -v '/mnt/user':'/mnt':'rw'
  -v '/mnt/user/appdata/Neko-Vlc':'/home/neko/Downloads':'rw'
  --device='/dev/dri/'
  --shm-size="6gb"
  --cap-add=SYS_ADMIN 'ghcr.io/m1k1o/neko/intel-vlc:latest

I've tried playing 1080p , x264 and x265 encoded movies and the file sizes are both around 5gb. When playing, the cpu and gpu occupancy are both about 20%, and the performance and network are both redundant.

I think this configuration playback should not freeze. But in fact even if I am the only one watching in the room, and the resolution is turned down, it will still play like powerpoint.

If i don't use vaapi, it will still freeze, but it is slightly better than using vaapi, and the CPU usage will be higher, about 30%.

I want to use vaapi to encode, and the playback will not freeze. How can I configure it?

m1k1o commented 1 year ago

I cannot reproduce it. CPU only using Intel(R) Xeon(R) CPU E5-2678 v3 @ 2.50GHz it yields very good results.

Could you check in media statistics: image

If you see any lost frames during decoding? image

xushier commented 1 year ago

image image No lost.

xushier commented 1 year ago

So, No lost means that the encoding of n.eko is working normally, is the decoding speed not keeping up?

But the graphics card uhd630 has been assigned to n.eko and the call is correct, and the video is also being decoded with vaapi. This work should be more than enough for uhd630, and it should not be stuck.

m1k1o commented 1 year ago

It means that VLC can decode video normally. You could see WebRTC internals in google chrome chrome://webrtc-internals to see if you get any lost packets.

You could try switching to H264 if that makes difference.

xushier commented 1 year ago

Thanks for your answer.

If there is no problem with encoding and decoding, it should be a network problem. My ipv6 network bandwidth is large enough, but the ipv4 bandwidth is only 60Mbps, which may be caused by the slow speed of the ipv4 network.

Anyway, using the ipv6 network alone does not cause playback lag.

Finally, I changed the network mode of the container from bridge to host, and now the ipv4 network also looks normal.