I'm generating an H264 RTP stream from ffmpeg and playing it back in Chrome WebRTC, however I'm observing some strange playback behavior where only keyframes are rendered. Sample video attached.
I'm using
https://github.com/pion/webrtc/tree/master/examples/rtp-to-webrtc to pipe the RTP packets to WebRTC and this example works fine for VP8 and low-resolution H264, however when I increase the resolution to H264 1080p30 it runs into problems. ffmpeg/libx264 confirms that I'm producing Constrained Baseline at level 4.0. I've tried also signalling the profile-level-id accordingly in the SDP however it doesn't seem to have an impact despite reflecting the change in webrtc-internals.
I did some further debugging and it looks like setting sliced-threads=1 causes an issue which gets set when I decompose -tune zerolatency. In particular, this doesn't work:
ffmpeg -re -f lavfi -i testsrc=size=1920x1080:rate=30 -pix_fmt yuv420p -c:v libx264 -g 10 -preset ultrafast -x264opts bframes=0:force-cfr=1:mbtree=0:sync-lookahead=0:sliced-threads=1:rc-lookahead=0 -f rtp 'rtp://
127.0.0.1:5004?pkt_size=1200'
But this works:
ffmpeg -re -f lavfi -i testsrc=size=1920x1080:rate=30 -pix_fmt yuv420p -c:v libx264 -g 10 -preset ultrafast -x264opts bframes=0:force-cfr=1:mbtree=0:sync-lookahead=0:rc-lookahead=0 -f rtp 'rtp://
127.0.0.1:5004?pkt_size=1200'
This is unfortunately where my knowledge ends, does anyone know why sliced-threads=1 might result in playback issues with WebRTC at higher levels? As one would expect, playback works fine when played with ffplay.
Thanks in advance!