While updating my notes I noticed we are using version 3 to generate something that does not contain the main_flags. (Yes somewhere I have patches to support BROADCAST_MODE and I'm thinking about introducing an unseekable PIPE_MODE dropping syncpoints completely) I suggest to hold either bump to 4 for the version exposing the main_flags and use version 5 for futher changes or lump together main_flags and frame specific data support. lu
On 05/04/2013 01:02 PM, Luca Barbato wrote:
While updating my notes I noticed we are using version 3 to generate something that does not contain the main_flags.
(Yes somewhere I have patches to support BROADCAST_MODE and I'm thinking about introducing an unseekable PIPE_MODE dropping syncpoints completely)
Since the broadcast mode had never been used in the wild I'd change the definition of the additional timestamp so it is the actual wallclock epoch. This way provides a mean to know the overall latency and not just knowing the packet skew/jitter. lu
On Sat, May 04, 2013 at 10:48:43PM +0200, Luca Barbato wrote:
On 05/04/2013 01:02 PM, Luca Barbato wrote:
While updating my notes I noticed we are using version 3 to generate something that does not contain the main_flags.
(Yes somewhere I have patches to support BROADCAST_MODE and I'm thinking about introducing an unseekable PIPE_MODE dropping syncpoints completely)
Since the broadcast mode had never been used in the wild I'd change the definition of the additional timestamp so it is the actual wallclock epoch. This way provides a mean to know the overall latency and not just knowing the packet skew/jitter.
interresting idea. I would suggest the following: * leave the transmit_ts as it is * add a field to the main header that contains the wallclock transmit time corresponding to the transmit_ts == 0 This should avoid the need to bump the version, improving compatibility as old demuxers will be able to read it (they would reject VERSION>3) Its more space efficient than storing a full wallclock timestamp as the 0 based timestamps would be smaller in value and take up fewer bytes Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus
On 05/15/2013 01:21 PM, Michael Niedermayer wrote:
interresting idea.
I would suggest the following: * leave the transmit_ts as it is * add a field to the main header that contains the wallclock transmit time corresponding to the transmit_ts == 0
This should avoid the need to bump the version, improving compatibility as old demuxers will be able to read it (they would reject VERSION>3)
Its more space efficient than storing a full wallclock timestamp as the 0 based timestamps would be smaller in value and take up fewer bytes
Surely feasible, since it is a real-time information can stay on the global header w/out problems. lu
On Wed, May 15, 2013 at 01:32:37PM +0200, Luca Barbato wrote:
On 05/15/2013 01:21 PM, Michael Niedermayer wrote:
interresting idea.
I would suggest the following: * leave the transmit_ts as it is * add a field to the main header that contains the wallclock transmit time corresponding to the transmit_ts == 0
This should avoid the need to bump the version, improving compatibility as old demuxers will be able to read it (they would reject VERSION>3)
Its more space efficient than storing a full wallclock timestamp as the 0 based timestamps would be smaller in value and take up fewer bytes
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 Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
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? lu
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
On 05/15/2013 05:00 PM, Michael Niedermayer wrote:
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.
My current implementation uses the stream timebase (actually the first/last) to represent the starttime and the timebase already in use for the timedelta in the syncpoint.
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.
We can store this as the last timebase and use it for starttime and timedelta. In the end the timestamp representation in nut is flexible enough we can just specific it as "valid timestamp within the file" and let implementor pick what's best for them. lu
Hi On Sat, May 04, 2013 at 01:02:24PM +0200, Luca Barbato wrote:
While updating my notes I noticed we are using version 3 to generate something that does not contain the main_flags.
indeed
(Yes somewhere I have patches to support BROADCAST_MODE and I'm thinking about introducing an unseekable PIPE_MODE dropping syncpoints completely)
I suggest to hold either bump to 4 for the version exposing the main_flags and use version 5 for futher changes or lump together main_flags and frame specific data support.
I dont think a version bump is needed The spec says the flags should be there and with version 3 which is what we use currently also nothing bad happens (with our demuxer) if we write the flags and nut was designed to allow addition of new fields without version bumps PS: sorry for my late reply i had missed the new mails on nut-devel PS2: ill send a patch in a moment to add the missing main_flags field to nutenc.c Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
On 05/15/2013 12:51 PM, Michael Niedermayer wrote:
(Yes somewhere I have patches to support BROADCAST_MODE and I'm thinking about introducing an unseekable PIPE_MODE dropping syncpoints completely)
I suggest to hold either bump to 4 for the version exposing the main_flags and use version 5 for futher changes or lump together main_flags and frame specific data support.
I dont think a version bump is needed The spec says the flags should be there and with version 3 which is what we use currently also nothing bad happens (with our demuxer) if we write the flags and nut was designed to allow addition of new fields without version bumps
The broadcast mode, as described is less than useful so I'd take the chance to update it.
PS: sorry for my late reply i had missed the new mails on nut-devel
No problem.
PS2: ill send a patch in a moment to add the missing main_flags field to nutenc.c
I drafted pipe and (new) broadcast mode in my git meanwhile, today I was planning to experiment a bit with side-data and see if the tag+enum is cumbersome as I'm afraid or not. lu
participants (2)
-
Luca Barbato -
Michael Niedermayer