[FFmpeg-devel] [PATCH] Sync the NTP timestamps for RTP streams

[Michael Niedermayer]

On Thu, Mar 11, 2010 at 11:51:08AM +0200, Martin Storsj? wrote:
> (Changed subject, since this discussion mainly was on this topic...)
> 
> On Thu, 11 Mar 2010, Michael Niedermayer wrote:
> 
> > On Wed, Mar 10, 2010 at 10:35:09PM +0200, Martin Storsj? wrote:
> > > On Tue, 9 Mar 2010, Michael Niedermayer wrote:
> > > 
> > > > I assume you know how AVOptions are used to set things in AVFormatContext
> > > > the idea is to do the same with AVFormatContext->priv_data
> > > 
> > > Ah, I see. That generally feels like a good idea. However, here's the list 
> > > of open questions in this approach, as far as I can tell from the code:
> > > 
> > > Should one be able to do av_set_string3() directly on an AVFormatContext, 
> > > with the name of a private context option, and this should either succeed 
> > > or fail depending on which (de)muxer it actually is? In that case, 
> > > av_find_opt would need to be extended to look for options other than just 
> > > the list found in the AVClass.
> > 
> > this would be nice but not essential in an initial implementation
> > Maybe a offset in the AVClass struct could point to priv_data
> > or NULL for structs not having a priv_data with its own AVClass
> > 
> > 
> > > 
> > > Or if we're supposed to do the av_set_string3() on 
> > > AVFormatContext->priv_data instead, we would have to make sure all 
> > > instances of priv_data actually has an AVClass.
> > > 
> > > In ffmpeg.c/cmdutils.c, the options are temporarily stored in an 
> > > AVFormatContext before they're later applied to the actual muxer using 
> > > set_context_opts. In this scenario, setting a muxer-specific setting 
> > > wouldn't work since the temporary AVFormatContext wouldn't have the 
> > > private data for that particular muxer.
> > 
> > hmm, that may need a little redesign then
> > i never liked that storing of things in that temporary contexts
> > 
> > either way codec specific options would make alot of people happy
> > i think, personally i never understood it but it seems people really
> > dont like adding their stuff to a ever growing context
> 
> If adding another field to the context is ok with you, the attached 
> series would be another way of solving it.
> 
> Instead of storing NTP time (which isn't all that common outside of RTP), 
> the field stores unix time (in microseconds). Also, I chose to store this 
> in AVStream instead of in AVFormatContext, since it could be used to store 
> extra info for the RTP streams when using the RTSP demuxer.
> 
> Is this acceptable, and does it seem generally usable for other things 
> than this one in particular, so that it could be accepted in the general 
> context?
> 
> // Martin
>  avformat.h |    8 ++++++++
>  1 file changed, 8 insertions(+)
> d43f659c8bfdbc7b0fbfad8256d7d3856e2e77d7  0001-Add-a-field-to-AVStream-for-specifying-a-real-world-.patch
> From 61fd799efc279662d0e7718db7366fc642d5c472 Mon Sep 17 00:00:00 2001
> From: Martin Storsjo <martin at martin.st>
> Date: Thu, 11 Mar 2010 11:11:43 +0200
> Subject: [PATCH 1/4] Add a field to AVStream for specifying a real world start time for the stream
> 
> ---
>  libavformat/avformat.h |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 10371a4..7c74951 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -526,6 +526,14 @@ typedef struct AVStream {
>       * Number of frames that have been demuxed during av_find_stream_info()
>       */
>      int codec_info_nb_frames;
> +
> +    /**
> +     * Start time of the stream in real world time, in microseconds
> +     * since the unix epoch.
> +     * - encoding: Set by user.
> +     * - decoding: Unused.
> +     */
> +    int64_t start_time_realtime;

this is not completely clear, we have
time of transmission of first packet
time of decoding of first packet
time of presentation of first packet
time corresponding to timestamp=0 instead of first packet

and i think you should write out what the unix epoch is

that said, i didnt follow the thread very much, could you explain in a few
lines why this is needed?


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100311/1fdcef73/attachment.pgp>