timestamp issue

[Chuck Crisler]

I think that I found the problem. In base plugins, source module
gstbasertppayload.c, the function set_headers (sets ssrc, payload type, seq
nbr and timestamp) uses the rtptime rather than the timestamp to set the
timestamp. A subsequent log message indicates that the displays the rtp
time but labels a data.timestamp as the actual timestamp for the packet. it
seems that the rtptime doesn't change. Was this intentional or is this an
old bug?

Chuck


On Fri, Jun 7, 2013 at 3:37 PM, Chuck Crisler <ccrisler at mutualink.net>wrote:

> OK, not an issue. I found the "other" required macro. :-)
>
> So even though timestamps now appear OK in the log files, they are wrong
> in wireshark. Still investigating.
>
> Chuck
>
>
> On Fri, Jun 7, 2013 at 2:24 PM, Chuck Crisler <ccrisler at mutualink.net>wrote:
>
>> I am using GStreamer 0.10.30 and good plugins 0.10.25 and have a strange
>> timestamp issue. My pipeline has h264parse feeding buffers to rtph264pay. I
>> have modified both elements to display the buffer timestamp. In h264parse
>> it is just before the buffer is pushed, in rtph264pay it is immediately
>> upon receiving the buffer. Here are 2 lines from the log file.
>>
>> Jun  7 14:07:43 imsvcctl[3106]: 0:00:03.924666709 [335m 3106 [00m
>> 0x82e96b0 [36mDEBUG  [00m [00m           h264parse
>> gsth264parse.c:2385:gst_h264_parse_chain_forward:<H264Parse> [00m pushing
>> buffer 0xf6f031a0, size 2742, ts 0:00:00.600000000
>> Jun  7 14:07:43 imsvcctl[3106]: 0:00:03.924686125 [335m 3106 [00m
>> 0x82e96b0 [36mDEBUG  [00m [00m          rtph264pay
>> gstrtph264pay.c:948:gst_rtp_h264_pay_handle_buffer:<RTPPayloader> [00m got
>> 2742 bytes, 0x00  0x00 0x0a 0xb2 TS: 600000000:00:4145690968.1293306562
>>
>> The h264parse element generates a timestamp and sets it on the buffer.
>> The rtph264pay element reads the timestamp from the buffer immediately upon
>> receiving the buffer. So it seems that something in between is changing the
>> timestamp.
>>
>> The good plugins 0.10.26 did have a RTP timestamp bug fix (#630256), but
>> that doesn't seem like the same issue. Also, the fix was in the depay
>> element, which this particular pipeline doesn't even use.
>>
>> This pipeline is sending h264/RTP to an IPad, which is not decoding the
>> stream and I think that the invalid and unchanging timestamps may be the
>> problem. I have this same code running in other places and sending H264/RTP
>> to a script that sets up a GStreamer RTP Rx pipeline that works.
>>
>> Does anyone have any comments or suggestions of where I should look next?
>>
>> Thank you,
>> Chuck Crisler
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130607/15b411c1/attachment.html>