youtube output choppy, gstreamer WARNs Got backwards dts!

[vaguelyr]

Hi,

Describe the bug A clear and concise description of what the bug is.

Youtube output is choppy/stuttery. Audio is fine. gstreamer WARN 'Got backwards dts! ' happens on the video pipeline, in flvmux, continuously.

To Reproduce Steps to reproduce the behavior:

GST_DEBUG=3 DISPLAY=:0 bash obplayer_loop -d

Expected behavior A clear and concise description of what you expected to happen.

Youtube output is smooth. DTS shouldn't go backwards.

Desktop (please complete the following information):

Player is running on Ubuntu 20.04.3 LTS Observer running Debian GNU/Linux 11 (bullseye), installed with latest script

Additional context Add any other context about the problem here.

GST_DEBUG=3 DISPLAY=:0 bash obplayer_loop -d 1>out.txt 2>err.txt out.txt : https://pastebin.com/y5jw83g8 err.txt : https://pastebin.com/b5w2VQV3 out.txt err.txt

This is on a completely clean unmodified observer and obplayer. The obplayer is the branch from the Fix the Password Bug currently open pull request, since logging in is not possible otherwise.

Observer has scheduled videos with sound, obplayer is playing the videos and streaming into youtube. Output is choppy.

I want to make a generalized RTMP output but this existing issue derails that effort. If you could help me figure out where in the audio/video > flvmux > rtmpsink pipeline this issue is being caused, I could help fix it.

[alphabitnz]

I want to make a generalized RTMP output but this existing issue derails that effort. If you could help me figure out where in the audio/video > flvmux > rtmpsink pipeline this issue is being caused, I could help fix it.

Vincent and I are currently developing a generalized RTMP module, it's still in development/testing but I have it fairly functional currently.

The main file to look at is obplayer/streamer/youtube.py, from 'Gst.ElementFactory.make('intervideosrc')'

I would be interested to know what output and streaming resolution settings you're using, and what CPU you're running on as the current production encoder settings are a) not offloaded to GPU and b) not particularly lightweight. Both of those issues are in scope of our work on the new RTMP module.