Do GStreamer handle loss of key frames (H264)?

[Nicolas Dufresne]

Le ven. 28 sept. 2018 13 h 58, Marcos Kintschner <marcos.ktn at gmail.com> a
écrit :

> 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
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180928/f7977f10/attachment.html>