On 05/05/2015 11:56 PM, Info || Non-Lethal Applications wrote:
Thomas,
thanks for your quick response.
On 05 May 2015, at 23:25, Thomas Volkert <[email protected]> wrote:
Am 05.05.2015 um 22:43 schrieb Info || Non-Lethal Applications:
Hi guys,
I’m sending an H.264 stream from the Mac to an iOS device using OpenH264 and
RTP and it works great.
I was wondering if there’s a chance to add private data to the packets so I
could add some info in order to know the exact delay of the stream?
I thought about adding a timestamp of the source machine to every packet.
If you are using RTCP packets within the RTP based stream, you could extract
the NTP timestamps from RTCP packets of the source and (if the clock at sender
side is correct) conclude the transmission delay.
That sounds like a good approach. Can you give me a hint on how this is done?
I was just trying to find information about RTCP support in FFmpeg and didn’t
find much.
For example, you could write a simple RTP parser which also supports
RTCP. In this case the A/V decoding would remain inside FFmpeg:
see RTP::RtpParse at line 1639 in
https://github.com/Homer-Conferencing/Homer-Conferencing/blob/master/HomerMultimedia/src/RTP.cpp
I was just trying to find information about RTCP support in FFmpeg and didn’t
find much.
There is support for RTCP in FFmpeg, but the NTP timestamps are not
accessible outside of FFmpeg.
see rtcp_parse_packet() at line 143 in
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/rtpdec.c
(a possible hack for this could be: get access to RTPDemuxContext and
use "last_rtcp_ntp_time" and "statistics.transit" to determine delays)
Best regards,
Thomas.
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
