> > On Wed, Mar 16, 2016 at 22:42:09 +0100, Daniel Oberhoff wrote: >> around that there are things like RTCP sender reports and such on the low >> level containing this info, > > Without reading the RTP specs, I could see exactly that from Wireshark > dumps.
Ok, yeah, sounds like work and a litle cumbersome for production use, but yeah. > >> and I have seen indication that it is somehow parsed by ffmpeg. > > Yes, ffmpeg's source code fits to those findings. > >> What is the easiest way to get to this information? Best >> wpuld be command line dump of the time of the first frame, but rendering it >> somewhere, or even hacking ffmpeg would be doable too. > > ffmpeg doesn't provide this value, it only uses it for calculating the > PTS (offset) in the demuxer. So you would actually have to edit the > source. > > Check for last_rtcp_ntp_time and especially first_rtcp_ntp_time, which > is initialized from the frist packet's last_rtcp_ntp_time initially. > > You could either print it out with av_log() for your personal purposes. > Or better, you could try to get that timestamp into the PTS, which > would call for a "-use_source_wallclock_as_timestamps" option to the > demuxer. That assumes this PTS is useful for you (it's easy to extract > from the first frame via ffprobe), but at least it would be flexible. that or a logging option would be cool. The ntp is really important for synchronization, and it would be cool if we would not have to patch our own ffmpeg. I would like to propose a patch to devel for this. I guess the av_log option would be the least intrusive for now. thx! _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user
