gst_bin_recalculate_latency() doesnt work (Latency calculation fails)
Describe your issue
Since Gst 1.22, I get a warning message repeatedly "Can't determine running time for this packet without knowing configured latency" message from rtpsession element. This should happen if using gst_bin_recalculate_latency() on the pipeline element every time a LATENCY message goes on the bus. Attached two fils: logs level 6 + pipeline graph
Expected Behavior
Latency calculation should work, no Can't determine running time for this packet without knowing configured latency" message
Observed Behavior
Ï still get the message. More over, I do gst_bin_recalculate_latency() on the pipeline when elements signal "LATENCY" on the bus, EXCEPT sink (fakesink, udpsink) elements. For some reason if I do this to sink elements as well, the pipeline stops. Still in my pipeline it the rtpsession is created after any sink element, so I don't think it's an issue.
Setup
- **Operating System: Ubuntu 22.04
- Device: Virtual Machine
- **GStreamer Version: 1.22
- **Command line: Dynamic pipeline (python bindings) The pipeline attached on picture (pipeline_debug.jpg) made by Gstreamer
Steps to reproduce the bug
- Create dynamic pipeline as in picture pipeline_debug udpsrc ! mpegtsparse ! tsdemux ! tee ! parsebin ! tee name=output ! queue2 ! fakesink output. ! h264timestamper ! rtph264pay ! webrtcbin
- Listen to GST bus, to message Gst.MessageType.LATENCY Whenever it happens, do pipelineElement.recalculate_latency()
How reproducible is the bug?
Every time, also if I change the input element to rtspsrc.
Screenshots if relevant
Solutions you have tried
I silenced the log, but it doesnt really fix the issue. I tried to change the input elements, and as I mentioned I disabled recalculate_latency when fakesink or udpsink creates the LATENCY message, because it stops the whole pipeline. (Im watching the PTS by pad buffer probes of each packet in each pad in my pipeline, to know when something is wrong. And doing recalculate_latency causes the PTS to stop, meaning I stop getting buffers)
Related non-duplicate issues
This message ("Can't determine running time for this packet without knowing configured latency") didn't happen on GST 1.20, but from issue 1659 I understand its just because it was silenced before 1.22)