<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Nicolas,</div><div dir="ltr"><br></div><div>Thank you for quick reply.</div><div><br></div><div>> Consider adding an rtpjitterbuffer on the receiver, in future GST version, you'll be able to use rtpsrc/rtpsink (or the rist variant) in order to get a full feature RTP stream without complex pipeline construction.<div dir="auto"><br></div><div>The actual pipeline which I use in the program has "rtpjitterbuffer", I shared a simple test pipeline.</div><div><br></div><div dir="auto">>For jpeg, consider configuring max-bitrate property on udpsink. As frames are spread out on a lot more packet, it tend to become bursty and may saturate the link or exhaust the udpsrc socket buffer-size.</div></div><div><b></b><i></i><u></u><strike></strike><br></div><div>Point noted, will make the changes.</div><br></div><div dir="ltr">>That is the method I would have used. It should work with any RTP packet, so you likely have or hit a bug.</div><div dir="ltr">Here, I am attaching the source code for option 3 I tried.<br><br></div><div dir="ltr">"send_h264.c" and "recv_h264.c", work successfully and the frame number is appended to RTP buffer. Prints in both the probes output the correct value.</div><div dir="ltr"><br></div><div dir="ltr">However, the probe function (pay_src_probe) in "send_jpeg.c" never gets called.<br>When I change the probe type from "GST_PAD_PROBE_TYPE_BUFFER" to "GST_PAD_PROBE_TYPE_BUFFER_LIST", then it gets called, and the frame numbers appended are wrong. i.e. for each frame around 100 times this function gets called and program slows down like a sloth.</div><div dir="ltr"><br></div><div dir="ltr">I checked the source code for "rtph264pay" and rtpjpegpay" element, both of them are creating buffer lists which I guess is to push multiple RTP packets at one go, to the next element in pipeline.<br>But strangely H264 works fine and JPEG fails.</div><div dir="ltr"><br></div><div dir="ltr">Please check if my code has some bug.</div><div dir="ltr"><br></div><div>And do you have any suggestions on KLV metadata approach?</div><div dir="ltr"><br></div><div dir="ltr">Thanks,</div><div dir="ltr">Priyanka</div><div dir="ltr"><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Thu, Sep 26, 2019 at 7:11 PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca">nicolas@ndufresne.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="auto"><div><br><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">Le jeu. 26 sept. 2019 05 h 25, priyanka kataria <<a href="mailto:priyanka.kataria86@gmail.com" target="_blank">priyanka.kataria86@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div dir="ltr"><div>Hello,</div><div><br></div><div>I have an interesting problem:<br>Need to transfer some kind of metadata (say frame number) with each frame over UDP. Receiver on the other hand, extracts he frame numebr from each frame and maintains it for some other work.</div><div><br></div><div>Sample sender and receiver pipelines:<br>Sender: gst-launch-1.0 -v filesrc location=file.h264  ! h264parse ! rtph264pay ! udpsink port=5001</div><div>Receiver: gst-launch-1.0 -v udpsrc port=5001 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264" ! rtph264depay ! decodebin ! autovideosink</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Consider adding an rtpjitterbuffer on the receiver, in future GST version, you'll be able to use rtpsrc/rtpsink (or the rist variant) in order to get a full feature RTP stream without complex pipeline construction.</div><div dir="auto"><br></div><div dir="auto">For jpeg, consider configuring max-bitrate property on udpsink. As frames are spread out on a lot more packet, it tend to become bursty and may saturate the link or exhaust the udpsrc socket buffer-size.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div dir="ltr"><div><br></div><div>Things I have already tried (I am still a beginner, so some of the below things may look stupid):<br>1. In Sender pipeline, attaching a probe on "h264parse" element and assigning incremental values to "GST_BUFFER_OFFSET". <br>But the set offset value is not reflected in the next element in the same pipeline only.</div><div><br></div><div>2. In Sender pipeline, attaching a probe on "h264parse" element and assigning incremental values to "GST_BUFFER_PTS". <br>The set PTS value is reflected in the next elements in the same pipeline, but gets lost across UDP.<br>I checked this by attaching a probe on "rtph264depay" element (src pad).</div><div><br></div><div>3. Using "gst_rtp_buffer_add_extension_twobytes_header()".<br>This method works for H264 files, but fails with MJPEG files, and my solution needs to be generic.<br>Here, I can provide more details with code if required.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That is the method I would have used. It should work with any RTP packet, so you likely have or hit a bug.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div dir="ltr"><div><br></div><div>4. Last thing I am trying is to mux KLV metadata into stream and send it across UDP.<br>I refer the following link: <a href="https://www.aeronetworks.ca/2018/05/mpeg-2-transport-streams.html" target="_blank" rel="noreferrer">https://www.aeronetworks.ca/2018/05/mpeg-2-transport-streams.html</a>.<br>This doesn't work though as written in the article but gave me an overview on how to use the pipeline.</div><div>Now I want to create my custom my KLV metadata file which contains only frame numbers and try to mux it.<br><br></div><div>Please help me in creating such file.</div><div><br></div><div>Also please share if there are any other working approaches I should try to append metadata in each frame buffer.</div><div><br></div><div>Thanks,</div><div>Priyanka</div></div></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank" rel="noreferrer noreferrer">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div></div></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank" rel="noreferrer">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div></div></div></div></div>