Hi Olivier,<div><br></div><div>Thx for your answer. That's clarify the difference in behavior.</div><div>So, regarding my question and that right now the H.264 payloader does not merge NAL units into a single RTP packet, it means that's important to care about the max-ptime parameter so that only one frame is included into a single RTP packet in case of live streaming, because as I was saying, if the MTU is big or the frame size small, it might lead to laggy and/or delayed output.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>Paul</div><div><br><br><div class="gmail_quote">2012/12/7 Olivier Crête <span dir="ltr"><<a href="mailto:olivier.crete@collabora.com" target="_blank">olivier.crete@collabora.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
The only reason the H.264 payloader doesn't merge NAL into a single packet is that no one had done the work to do it intelligently.<br>
<br>
Olivier<br>
<div><div class="h5"><br>
Paul d'AUBIGNY <<a href="mailto:visechelle@gmail.com">visechelle@gmail.com</a>> wrote:<br>
<br>
>Hi guys,<br>
><br>
>When comparing rtph264pay and rtpmp4vpay plugins, I noticed a<br>
>difference in<br>
>the way RTP packets are filled.<br>
>In the case of H264, one RTP packet seems to contain maximum one entire<br>
>NAL<br>
>unit (can be splitted if MTU too small). In the case of rtpmp4vpay, it<br>
>fills the RTP packet with eventually several VOP frames as soon as mtu<br>
>is<br>
>not exceeded or a non VOP frame is received.<br>
>Therefore, with rtph264pay one RTP packet = one frame maximum, with<br>
>rtpmp4vpay one RTP packet = GOP frames maximum.<br>
><br>
>Why this difference of behavior? I'm wondering this because in case of<br>
>mpeg<br>
>version 4, it can lead to delayed and/or laggy output if it gathers<br>
>several<br>
>frames in one RTP packet and of course in the case of live streaming.<br>
>Of<br>
>course, we can still play with the max-ptime property of the payloader<br>
>so<br>
>that it limits the maximum duration of the packet data, thus we can<br>
>limit<br>
>the number of frame per RTP packet. But by default the behaviors are<br>
>different.<br>
><br>
>To illustrate what I'm saying, here are 2 examples to see the delay and<br>
>laggy output in case of MPEG4 (in case of H264 both output streams<br>
>might be<br>
>delayed due to the encoding time but both output streams should be<br>
>synchronized):<br>
><br>
><br>
</div></div>> - Case of MPEG4:<br>
<div class="im">><br>
><br>
>gst-launch-1.0 udpsrc port=2222 ! application/x-rtp, media=video,<br>
>payload=96, clock-rate=90000, encoding-name=MP4V-ES ! decodebin !<br>
>xvimagesink sync=false<br>
><br>
>gst-launch-1.0 v4l2src ! video/x-raw, format=YUY2, width=640,<br>
>height=480,<br>
>interlace-mode=progressive, pixel-aspect-ratio=1/1, framerate=30/1 !<br>
>videoconvert ! videorate ! avenc_mpeg4 ! tee name=t t. ! queue !<br>
>rtpmp4vpay config-interval=1 mtu=65507 ! udpsink host=127.0.0.1<br>
>port=2222<br>
> t. ! queue ! decodebin ! autovideosink<br>
><br>
><br>
><br>
</div>> - Case of H264:<br>
<div class="im">><br>
><br>
>gst-launch-1.0 udpsrc port=2222 ! application/x-rtp, media=video,<br>
>payload=96, clock-rate=90000, encoding-name=H264 ! decodebin !<br>
>xvimagesink<br>
>sync=false<br>
><br>
>gst-launch-1.0 v4l2src ! video/x-raw, format=YUY2, width=640,<br>
>height=480,<br>
>interlace-mode=progressive, pixel-aspect-ratio=1/1, framerate=30/1 !<br>
>videoconvert ! videorate ! x264enc ! tee name=t t. ! queue !<br>
>rtph264pay<br>
>config-interval=1 mtu=65507 ! udpsink host=127.0.0.1 port=2222 t. !<br>
>queue<br>
>! decodebin ! autovideosink<br>
><br>
><br>
</div>>*Note*: For each case, play the two pipelines at the same time. I put a<br>
<div class="im">>high MTU to demonstrate what I'm saying but that could occur even with<br>
>the<br>
>default MTU if the frame size is small enough.<br>
><br>
><br>
>Cheers,<br>
><br>
><br>
>Paul HENRYS<br>
><br>
><br>
</div>>------------------------------------------------------------------------<br>
><br>
>_______________________________________________<br>
>gstreamer-devel mailing list<br>
><a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
><a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</font></span></blockquote></div><br></div>