<div dir="ltr"><div>Upon further investigate I found that the code I added in h264parse to accumulate data in the adapter is causing the buffer pool SEI to be processed twice for each I Frame. The time calculated is different for the 2 iterations. I guess that may be causing the problem.<br> <br></div>Chuck<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 25, 2014 at 3:44 PM, Chuck Crisler <span dir="ltr"><<a href="mailto:ccrisler@mutualink.net" target="_blank">ccrisler@mutualink.net</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Sebastian, Thank You for your suggestion. However, it doesn't work. Remember, I am using 0.10.30 and bad plugins 0.10.20. Also, my pipeline is rather weird. It is basically udpsrc->mp2tdemux->h264parse->rtph264pay->udpsink (with some queues, etc. included). The mp2tdemux filter pushes random buffers. The size of those buffers ranges from 2 or 3 bytes up to 8,000 bytes or more. Those buffers do not correspond to AUs or NALs or frames or anything else that I can discern. Note: I don't know much about the MP2T spec. Early on I discovered that the rtph264pay filter was having problems with the buffers it was receiving, so I used the h264parse filter and modified it to collect data in the adapter until it identified the end of a NAL and then push that. RTPH264pay has an assert that the nal_queue->len must be 0 on entry, which implies to me that it really won't buffer data and expects entire frames, which is why I modified h264parse. (Please critique my actions if I have screwed up some aspect of h264parse due to my focusing on my specific problem set.)<br> <br></div>So I have modified h264parse to hold SEI NALs until the next video NAL and use the timestamp from that NAL. It pushes the SEI immediately before pushing the video buffer. That works and the SEI timestamp matches the video timestamp as verified in wireshark. That was very simple.<br> <br></div>The problem that I now have (and have probably had for some time) is that the timestamp on IFrames jumps by 59 frames (177000 ticks) from the previous PFrame. The next PFrame after the IFrame has a timestamp 3000 after the PFrame before the IFrame. The timestamp sequence seems like the IFrame didn't exist. This *ONLY* happens with this one video source that is inserting SEI NALS. It is using buffer pool and picture timing SEI NALS. The buffer pool SEIs are grouped with the IFrames, so I suspect that is causing the timestamp error.<br> <br></div>I am slogging through this timestamp stuff which is pretty obtuse, especially with these SEIs. I believe that there is a bug here but probably fixed in the 1.0 series (aren't they all?). If anyone could please shed any insight on how these SEIs are supposed to contribute to timestamps I would really appreciate it.<span class="HOEnZb"><font color="#888888"><br> <br></font></span></div><span class="HOEnZb"><font color="#888888">Chuck<br></font></span></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Sat, Jan 25, 2014 at 5:44 AM, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div><div>On Fr, 2014-01-24 at 11:00 -0500, Chuck Crisler wrote:<br> > I am using GStreamer 0.10.30 (sigh). I have an input source that is an RTSP<br> > server that is using SEI messages. The stream is multiplexed into MP2T and<br> > then converted back to RTP. The problem is that the SPS/PPS/SEI messages on<br> > the output side have timestamps equal to the previous frame while on the<br> > input side the timestamps equal the next frame. When the output RTP is sent<br> > to VLC on Windows, it doesn't display well. It pauses, then plays several<br> > seconds very quickly, then pauses.<br> ><br> > 2 Questions.<br> ><br> > 1. Is it likely that the SEI timestamp change is responsible for this issue?<br> > 2. Should I try to shift the SEI timestamps to the next frame in rtph264pay?<br> ><br> > I don't have much experience with SEI messages. The RTP that I have worked<br> > with in the past didn't use them.<br> <br> </div></div>You might want to try if this is still like that with 1.0. In theory<br> (after h264parse if it outputs with alignment=AU) you will get<br> everything from the end of the previous frame until the end of the<br> current frame in a single buffer and thus with the timestamp.<br> <br> That means that any SPS/PPS/SEI that comes in front of a frame will be<br> bundled together with that frame in the same buffer with the same<br> timestamp.<br> <br> Everything else would seem like a bug. Not sure how it works in<br> alignment=NAL mode.<br> <span><font color="#888888"><br> --<br> Sebastian Dröge, Centricular Ltd - <a href="http://www.centricular.com" target="_blank">http://www.centricular.com</a><br> Expertise, Straight from the Source<br> </font></span><br></div></div><div class="im">_______________________________________________<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="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br> <br></div></blockquote></div><br></div> </blockquote></div><br></div>