Moving to nut-devel list... On Mon, Feb 27, 2006 at 08:08:55PM +0100, Michael Niedermayer wrote:
yes, but that realtime data could very well become available afterwards lets say some realtime news of a earthquake, its magnitude, number of casualties and so on wont be known immedeatly furthermore estimates will change, and if you dont like that example, take any other realtime stream (some DJ with music videos whatever) where info is added in realtime some mistakes will creep in and it should be possible to correct them, in such a way that automatic remuxing updates all info thats not hard but with our strict rules its impossible. so with these restrictions i see no sense in info streams
OK, how about this: drop the requirement that they be binary-identical, and instead the last packet with the given chapter_id is the one that's valid. Keep the rest of the semantics for what range it applies to. This allows updating/correcting info in a live stream and will give the correct results if you convert it to an info packet for permenant storage (using the latest/most correct data). Also this allows you to specify length if it becomes known.
Also I don't like supporting this for arbitrary codecs. The reason is that you have to do one of two things in the demuxer, and both are wrong for certain cases. You must either:
1. Output the whole NUT packet as one unit. This is wrong for codecs that actually use frames.
2. Split the NUT packet into frames according to packet_size and output each individually. This is horribly wrong for PCM as it will make CPU usage insanely high.
IMO special-casing PCM/ADPCM as codecs where any block of data up to X samples long is a valid 'frame' is a cleaner solution, but I'm open to alternatives for sure.
what about allowing it only for <4kbyte && <4ksamples ?
It still doesn't solve the problem about how do demux. How about this instead: - Storing multiple frames together is allowed only if the concatenation of all frames is also a valid single frame for the format. This way the demuxer can always output the whole frame as a unit and doesn't have to decide whether that's safe or not. But, having the packet_size (should be called frame_size...?) in the header is still useful, since it would allow more fine-grained seeking in a special-purpose application like a media editor. We can also put a limit on number of samples. IMO there's no real need for a size limit, and if there is a size limit it should probably be relative to max_distance rather than absolute. If we really want to avoid absolutes, we could make the sample limit relative to max_pts_diff too... Rich
Hi On Mon, Feb 27, 2006 at 02:30:23PM -0500, Rich Felker wrote:
Moving to nut-devel list...
On Mon, Feb 27, 2006 at 08:08:55PM +0100, Michael Niedermayer wrote:
yes, but that realtime data could very well become available afterwards lets say some realtime news of a earthquake, its magnitude, number of casualties and so on wont be known immedeatly furthermore estimates will change, and if you dont like that example, take any other realtime stream (some DJ with music videos whatever) where info is added in realtime some mistakes will creep in and it should be possible to correct them, in such a way that automatic remuxing updates all info thats not hard but with our strict rules its impossible. so with these restrictions i see no sense in info streams
OK, how about this: drop the requirement that they be binary-identical, and instead the last packet with the given chapter_id is the one that's valid. Keep the rest of the semantics for what range it applies to. This allows updating/correcting info in a live stream and will give the correct results if you convert it to an info packet for permenant storage (using the latest/most correct data). Also this allows you to specify length if it becomes known.
ok [...] -- Michael
On Tue, Feb 28, 2006 at 02:10:11AM +0100, Michael Niedermayer wrote:
Hi
On Mon, Feb 27, 2006 at 02:30:23PM -0500, Rich Felker wrote:
Moving to nut-devel list...
On Mon, Feb 27, 2006 at 08:08:55PM +0100, Michael Niedermayer wrote:
yes, but that realtime data could very well become available afterwards lets say some realtime news of a earthquake, its magnitude, number of casualties and so on wont be known immedeatly furthermore estimates will change, and if you dont like that example, take any other realtime stream (some DJ with music videos whatever) where info is added in realtime some mistakes will creep in and it should be possible to correct them, in such a way that automatic remuxing updates all info thats not hard but with our strict rules its impossible. so with these restrictions i see no sense in info streams
OK, how about this: drop the requirement that they be binary-identical, and instead the last packet with the given chapter_id is the one that's valid. Keep the rest of the semantics for what range it applies to. This allows updating/correcting info in a live stream and will give the correct results if you convert it to an info packet for permenant storage (using the latest/most correct data). Also this allows you to specify length if it becomes known.
ok
- ods15
Hi On Tue, Feb 28, 2006 at 06:17:09AM +0200, Oded Shimon wrote: [...]
chapter_len Length of chapter in same timebase of chapter_start. + In info streams, if chapter_len is zero, chapter_len is the pts of + the first EOR or info frame with a different chapter_id in the same + info stream, minus chapter_start.
iam not happy with this rule [...]
+The pts of an info frame MUST be >=chapter_start and <=chapter_start+len +(Compared using compare_ts)
not acceptable, as it totally defeats the idea of updating info frames later
+ +Info frames with a different chapter_id (or EOR) MUST NOT appear between +chapter_start and chapter_start+len. For overlapping chapters several info +streams can be used.
not acceptable, same reason as above
+ +If an info stream contains an info frame for chapter X then it MUST contain +an info frame with pts==chapter_start. Due to this restriction, the only +legal timebase for chapter_start (and chapter_len) is the info stream +timebase.
not acceptable, as it makes remuxing from info streams to info packets impossible (yeah the timebases might not match ...)
+ +Info frames with the same chapter_id and stream_id MUST have the same +chapter_start and chapter_len if it is non zero. The last info frame with +the same chapter_id and stream_id is the most correct one, and SHOULD have +chapter_len filled.
iam weakly against this restriction, the last packet should be used otherwise errors in chapter_start/len cannot be fixed in realtime streams [...] i really start to loose interrest in fighting against these arbitrary restrictions, you shouldnt add a restriction without a REASON!!!! not add one based on philosophical ideas and then wait until some very serious consequences are found -- Michael
On Tue, Feb 28, 2006 at 08:15:13PM +0100, Michael Niedermayer wrote: [...]
i really start to loose interrest in fighting against these arbitrary restrictions, you shouldnt add a restriction without a REASON!!!! not add one based on philosophical ideas and then wait until some very serious consequences are found
My intent was generally to reduce complexity. The general idea I have in my head is a console player that dumps an info frame/packet to stdout upon recieval. This gets trickier when you have info frame repetition, and this was what I was generally working for. But bleh, I guess I sucked at it. And _please_, I am not fighting with anyone here, especially not you.. I'm trying my best to actually accomplish the wishes of everyone, this includes writing and committing patches which so far very few of you seem to do. This includes sending (bad) patches, recieving reviews, and fixing the patches. So please try not to flame me. :( About patch, I consider change to "Info frames MUST have chapter_id < 0". - ods15
On Tue, Feb 28, 2006 at 08:15:13PM +0100, Michael Niedermayer wrote:
Hi
On Tue, Feb 28, 2006 at 06:17:09AM +0200, Oded Shimon wrote: [...]
chapter_len Length of chapter in same timebase of chapter_start. + In info streams, if chapter_len is zero, chapter_len is the pts of + the first EOR or info frame with a different chapter_id in the same + info stream, minus chapter_start.
iam not happy with this rule
A later frame could still update it. These end semantics are needed for proper streaming; else you have to transmit an extra copy of the info once it's no longer relevant, which is wasteful and silly. Also, they improve reliability, not harm it. For example: if the length is known ONLY once the chapter ends, then implicit ending ensures that the length does not overflow forever if the final frame with the length is somehow lost; it's bounded by the start of the next chapter.
[...]
+The pts of an info frame MUST be >=chapter_start and <=chapter_start+len +(Compared using compare_ts)
not acceptable, as it totally defeats the idea of updating info frames later
= chapter_start is certainly correct imo. If you want to relax/eliminate the <=chapter_start+len requirement I won't object.
+Info frames with a different chapter_id (or EOR) MUST NOT appear between +chapter_start and chapter_start+len. For overlapping chapters several info +streams can be used.
not acceptable, same reason as above
As far as I can tell this is not related to the above.. Well, maybe the "MUST NOT appear" is related, but the non-overlapping span criterion is still valid.
+If an info stream contains an info frame for chapter X then it MUST contain +an info frame with pts==chapter_start. Due to this restriction, the only +legal timebase for chapter_start (and chapter_len) is the info stream +timebase.
not acceptable, as it makes remuxing from info streams to info packets impossible (yeah the timebases might not match ...)
Agree that something needs to be done about this.
+Info frames with the same chapter_id and stream_id MUST have the same +chapter_start and chapter_len if it is non zero. The last info frame with +the same chapter_id and stream_id is the most correct one, and SHOULD have +chapter_len filled.
iam weakly against this restriction, the last packet should be used otherwise errors in chapter_start/len cannot be fixed in realtime streams
I'm fairly neutral, but I'd like to do as much as we can to ensure that info streams behave according to how you expect a stream to behave, without imposing restrictions that prevent doing something legitimate.
i really start to loose interrest in fighting against these arbitrary restrictions, you shouldnt add a restriction without a REASON!!!! not add one based on philosophical ideas and then wait until some very serious consequences are found
Restrictions that are placed on the basis of 'philosophical ideas' do have a reason. The reason is that a demuxer should not have to accept every bit of random shit thrown at it by some windows idiot like is the case with AVI. The more assumptions you can make about the format and sanity of your data, and the more unexpected cases you can discard as invalid data, the simpler the implementation and the less chance of having unintended consequences. I am all for arbitrary philosophical restrictions as long as they don't impede the ability to represent legitimate, meaningful information that cannot otherwise be represented. But I also don't want to limit the usefulness of the format. Rich
participants (3)
-
Michael Niedermayer -
Oded Shimon -
Rich Felker