[FFmpeg-devel] [NUT-devel] NUT version bump
Michael Niedermayer
michaelni at gmx.at
Wed May 15 17:00:21 CEST 2013
On Wed, May 15, 2013 at 04:32:55PM +0200, Luca Barbato wrote:
> On 05/15/2013 02:04 PM, Michael Niedermayer wrote:
> >> Surely feasible, since it is a real-time information can stay on the
> >> global header w/out problems.
> >
> > The wallclock time corresponding to the transmit_ts of 0 does not
> > change throughout the stream. Its just the origin / zero point from
> > where you count time
> >
> > Its like the day you are born does not change and can be written in
> > your birth certificate. While your age changes in relation
> > to your "birth date" (realtime) over your life.
> >
> > That is instead of
> > packet 123 transmit time = 2013 01 02 03:04:05.00
> > packet 124 transmit time = 2013 01 02 03:04:05.02
> > packet 125 transmit time = 2013 01 02 03:04:05.03
> >
> > one can use:
> > main_header reference_wallclock = 2013 01 02 00:00:00.00
> > ...
> > packet 123 transmit time = 03:04:05.00
> > packet 124 transmit time = 03:04:05.02
> > packet 125 transmit time = 03:04:05.03
> >
> > Its the same information, just requires fewer bytes to transmit/store
> > and the stream can continue realtime for millions of years with the
> > same main header if someone really wanted
> >
> > Though i suspect the stream would be restarted several times a year
> > with new video resolutions, audio sample rates, audio & video codecs
> > and other change
> >
> > I hope that clarifies what i was suggesting
>
> It was already clear and I do agree with that, the start time can be
> part of the global header and then we can just record the timedelta.
>
> I was wondering between storing it per-stream but seems not necessary,
> any opinion on the timebase to be used?
I would suggest to let the muxer choose the used timebase. Either as
its done now or by some other method. This way it can be changed later
and changed per file.
For the muxer implementation, i think the simplest would be to use
microseconds as av_gettime() returns for now, but i think any timebase
thats more precisse than milliseconds should be fine.
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130515/8916e123/attachment.asc>
More information about the ffmpeg-devel
mailing list