<div dir="ltr">Hello,<div><br></div><div>With reference to this <a href="https://stackoverflow.com/questions/68066985/how-to-write-specific-time-interval-oaf-gstsamples-rtp-over-udp-h264-packets">post</a>  <a href="https://stackoverflow.com/questions/68066985/how-to-write-specific-time-interval-oaf-gstsamples-rtp-over-udp-h264-packets">https://stackoverflow.com/questions/68066985/how-to-write-specific-time-interval-oaf-gstsamples-rtp-over-udp-h264-packets</a> which records videos from a queue of h264 GstSamples based on user request. I wish to adapt and optimize that to write jpeg images based on user request as well.</div><div><br></div><div>So a sample pipeline to start with is as follows:</div><div><span style="color:rgb(208,204,198);font-family:ui-monospace,"Cascadia Mono","Segoe UI Mono","Liberation Mono",Menlo,Monaco,Consolas,monospace;font-size:13px;white-space:pre-wrap;background-color:rgb(38,42,43)">gst-launch-1.0 appsrc ! h264parse ! avdec_h264 ! jpegenc ! filesink location=image.jpeg</span><br></div><div><br></div><div>Next we add a pad probe callback on <span style="background-color:rgb(30,33,34);color:rgb(199,194,187);font-family:ui-monospace,"Cascadia Mono","Segoe UI Mono","Liberation Mono",Menlo,Monaco,Consolas,monospace;font-size:13px;white-space:pre-wrap">avdec_h264's </span>src pad and check whether this is the requested frame (by matching the timestamp in the GstMeta). If this is the frame we allow it to pass otherwise we drop it.</div><div><br></div><div>Problem with this is when we want to write a single image, we end up feeding a larger interval of GstSamples such that the <span style="color:rgb(199,194,187);font-family:ui-monospace,"Cascadia Mono","Segoe UI Mono","Liberation Mono",Menlo,Monaco,Consolas,monospace;font-size:13px;white-space:pre-wrap;background-color:rgb(30,33,34)">h264parse</span> will work and figure out the codec data and/or NAL parts. So in most cases, we definitely parse and decode more frames than necessary yielding a slow performance. Is it possible to optimize this?</div><div><br></div><div>P.S. Images are requested via an RPC at a later time after the stream has been processed. So persistent decoding of the stream is not an option due to the size of raw frames.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Best Regards,<br>Eslam Ahmed</div></div></div></div></div>