Ok, thanks. Relying on the h264 bitstream would probably be tedious, as
I'm experimenting with different mtu sizes for rtp.
But rtph264pay has min-ptime and max-ptime properties which according to
the documentation can cap the duration per packet. Therefore the
payloader should at some point have the duration, if only to check if
it's within the limits set by these two properties. I was thinking about
modifying the payloader to add this duration to the buffer, just for a
couple of experiments.
The rtpbasepayload class has a function gst_rtp_base_payload_is_filled()
with the duration as a parameter in which these limits are checked. I
just can't seem to find any reference to it where it would be used by
the actual rtph264pay.
Am I missing something or are these two properties simply ignored?
Best Regards
Christoph
Am 10.01.20 um 02:58 schrieb Nicolas Dufresne:
> Le vendredi 10 janvier 2020 à 00:42 +0100, christoph eifert a écrit :
>> Hi,
>> is there a way to force a rtp payloader (specifically rtph264pay) to put duration timestamps on all buffers?
>> I'm currently only getting the pts timestamp on buffers from rtph264pay. Is that standard or is it dependant on
>> the pipline prior to the payloading element?
> Duration isn't exposed by RTP packets. The h264 bitstream may contain
> timeing SEI with information like framerate, but don't think the parser
> will add a duration for that. You'd need a filter or a pad probe to do
> that.
>
>>
>> Best Regards
>>
>> Christoph
>> _______________________________________________
>> gstreamer-devel mailing list
>>
[hidden email]
>>
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel> _______________________________________________
> gstreamer-devel mailing list
>
[hidden email]
>
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
