Unexpected framerate using webrtcbin and h264

Application Development
1

Hello,

In a pipeline constructed in Python using webrtcbin, rtpvp8depay, avdec_h264, videoconvert and autovideosink, I am receiving an unexpected framerate. In my test case I have a webcam on another system (on my LAN) that is uploading a stream of 1280x720 at 20+ fps and encoded as h264. In other parts of our software system and in a browser on the test receiving system I can view the video and I can firmly state the received framerate is 20+ fps. However in my gstreamer pipeline on the same test receive system, the framerate is listed at 12 fps and it visually appears as such. I have tried inserting caps filters between the decoder element and the videoconvert, as well as between the videoconvert and the autovideosink and both give me issues with negotiation and hence do not link. I have reviewed the specifications for all of the listed elements and Iā€™m unable to find a property that can help me.

The caps string provided to the webrtcbin RECVONLY transceiver is:

application/x-rtp,media=video,encoding-name=H264,payload=96,clock-rate=90000,packetization-mode=(string)1,profile-level-id=(string)42e01f,width=(int)480,height=(int)540

In the actual project the video is later cropped in the pipeline to 480x540 hence the mismatch.

Can anyone provide some insight into my issue, please?

In my actual project there are many more elements at play, but I have narrowed it down to this smaller pipeline to simplify the issue to present here.

Thank you.

unexpected_framerate_with_webrtcbin_to_avdec_h264
unexpected_framerate_with_webrtcbin_to_avdec_h2642556Ɨ350 64 KB

2

Hello,
why not adding framerate=(fraction)30/1 or something to your caps?
On the receiver parts you can always sink into a fpsdisplaysink (not a great plugin but good for testing) to measure the actuale rate.

3

Hi leonardosalvatore,

Thanks for responding.

I should have mentioned that I tried that in my original post but for good measure, I tried it again this morning and it has no effect on the behavior. The graph still shows the framerate is 12/1 in all spots illustrated in the photo of the original post.

For sake of confirmation, the gstreamer log shows this line snippet:

webrtcbin gstwebrtcbin.c:3532:sdp_media_from_transceiver:<wsrc>e[00m Caps application/x-rtp, media=(string)video, encoding-name=(string)H264, payload=(int)96, clock-rate=(int)90000, framerate=(fraction)30/1, packetization-mode=(string)1, profile-level-id=(string)42e01f, width=(int)480, height=(int)540, rtcp-fb-nack-pli=(boolean)true, rtcp-fb-ccm-fir=(boolean)true, rtcp-fb-transport-cc=(boolean)true

Also with the fpsdisplaysink element (thanks for introducing it), it clearly shows 12 fps. See attached.

framerate_12_with_fpsdisplaysink

Thank you.

4

Update on progress.

Discovered the videorate element thanks to this thread.

After inserting a videorate and capsfilter into the pipeline, the fpsdisplaysink is reporting the expected rate.

Success came with this:

webrtcbin ! rtph264depay ! avdec_h264 ! videorate ! video/x-raw,framerate=30/1 ! videocrop ! ...

versus this:

webrtcbin ! rtph264depay ! avdec_h264 ! videocrop ! ...

Thank you.

1 Like