<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Well, the h264parse handles additional stuff other than adding that flag. It fill missing caps fields based on the incoming bitstream, accumulates NAL units until a full frame is received and, more importantly, may convert between different stream formats (byte-stream, AVC, for example) and alignments (au, nal, for example). My two cents are that I would leave the parser:<div class=""><br class=""></div><div class="">- The h264parse may help if you receive a not-so-well-behaved network stream that could make your decoder unhappy.</div><div class="">- The h264parse may help if you are planning on supporting several decoders.</div><div class="">- More importantly, the h264parse is smart enough to bypass itself in case no processing is needed.</div><div class=""><br class=""></div><div class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 31 May 2022, at 06:16, John McDermott <<a href="mailto:egglue@gmail.com" class="">egglue@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class="">
<div name="messageBodySection" class="">
<div dir="auto" class="">Hi Michael,<br class="">
<br class="">
I’ve noticed that rtph264depay also sets the flag: <a href="https://github.com/GStreamer/gst-plugins-good/blob/20bbeb5e37666c53c254c7b08470ad8a00d97630/gst/rtp/gstrtph264depay.c#L973" target="_blank" class="">https://github.com/GStreamer/gst-plugins-good/blob/20bbeb5e37666c53c254c7b08470ad8a00d97630/gst/rtp/gstrtph264depay.c#L973</a><br class="">
<br class="">
Would that mean setting the flag again in h264parse is redundant if rtph264depay is in the pipeline?<br class="">
<br class="">
Cheers,<br class="">
<br class="">
John</div>
</div>
<div name="messageReplySection" class="">On 31 May 2022, 5:48 AM +1000, Michael Gruner <<a href="mailto:michael.gruner@ridgerun.com" class="">michael.gruner@ridgerun.com</a>>, wrote:<br class="">
<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;" class="">The h264parse will set the DELTA_UNIT flag based on the NAL units.
<div class=""><br class=""></div>
<div class="">
<div class=""><a href="https://github.com/GStreamer/gst-plugins-bad/blob/ca8068c6d793d7aaa6f2e2cc6324fdedfe2f33fa/gst/videoparsers/gsth264parse.c#L2659" class="">https://github.com/GStreamer/gst-plugins-bad/blob/ca8068c6d793d7aaa6f2e2cc6324fdedfe2f33fa/gst/videoparsers/gsth264parse.c#L2659</a></div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 30 May 2022, at 12:52, John McDermott via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org" class="">gstreamer-devel@lists.freedesktop.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<div name="messageBodySection" class="">
<div dir="auto" class="">Hi<br class="">
<br class="">
Does anyone know if key frames can be found without decoding? In the context of the pipeline rtspsrc->rtph264depay->h264parse->appsink, which element sets the GST_BUFFER_FLAG_DELTA_UNIT flag? I read that a keyframe has a unique start code in the NAL unit. In that case, does that mean rtph264depay sets the flag?<br class="">
<br class="">
Thanks</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</blockquote>
</div>
</div>
</div></blockquote></div><br class=""></div></div></body></html>