Do GStreamer handle loss of key frames (H264)?
nicolas at ndufresne.ca
Fri Sep 28 23:25:04 UTC 2018
Le ven. 28 sept. 2018 13 h 58, Marcos Kintschner <marcos.ktn at gmail.com> a
> Do you have any advice from where should I start looking it? I think we
> could add an option (disabled by default) to check for picture loss in
> rtph264depay or h264parse to make it "implementation agnostic", so one
> could use it for avdec_h264 or other decoders.
RTP packet loss should catch all losses, parsing that much the stream in
h264parse is quite some overhead.
What I had in mind is that rtph264depay could simply send the keyframe
event on discont unless we have a valid header sequence ([AUD], pps, sps,
[sei], IDR slice). It could also drop the data before pps/sps like
h264parse is doing.
> Em qua, 26 de set de 2018 às 01:19, Marcos Kintschner <
> marcos.ktn at gmail.com> escreveu:
>> I'm trying to understand if and how GStreamer handle a lost IDR frame.
>> I know there is an event called GstForceKeyUnit that is sent by
>> rtph264depay when this element receives data before setting SPS/PPS and
>> that this event is then processed by rtpsession that generates a RTCP/PLI
>> message. But it seems that rtph264depay doens't send the event when it
>> receives a P-Slice before a IDR-Slice, for example. Do I have to handle it
>> manually by adding probes and checking if the IDR has arrived or not?
>> Marcos Kintschner.
> Marcos Kintschner.
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel