I can't decide a proper way for this... One possibility is this: Info packet 1: ChapterId=1, TrackTime=3min Info packet 2: ChapterId=1, TrackTime=4min Info packet 3: ChapterId=2, TrackTime=3min ... But it seems over complicated. I'd like the ability to do this somehow: Single info packet: Chapters=3min,4min,3min,... (in case it wasn't obvious, all the "3min" stuff I meant as a vlc rational) But this can only be done either with parsable strings, or an array of vlc's. Parsable string is bad, and the current info setup does not allow for an array of vlc's... unless you embed it within a 'vb', which is even worse. Maybe Michael had a point in sorting info fields by "age"... I'd like to not follow the curse of mkv and end up with a container just as complicated. :/ This might be a solution: Single info packet: TrackLength=3min TrackLength=4min TrackLength=3min ... And the order they appear in the info packet is the order of the chapters... It's nice, but it gives significance to the order of the items in the info packet which I am not sure is a good idea. Using "TrackLength1", "TrackLength2", ... Is not good cause it's the same idea as parsable strings... Another note: I'd like to disallow info streams in non live streams.. For any purpose, info packets and chapters can be used. (It should at least be a "SHOULD"...) - ods15
Oded Shimon wrote:
I can't decide a proper way for this... One possibility is this:
Info packet 1: ChapterId=1, TrackTime=3min Info packet 2: ChapterId=1, TrackTime=4min Info packet 3: ChapterId=2, TrackTime=3min ...
But it seems over complicated. I'd like the ability to do this somehow:
hmm Info packet 1: ChapterId=1, TrackTime=3min, Title="foo", ShortSynopsys="blah",... other fields and friends.. I think this will be the usage of it.
This might be a solution: Single info packet: TrackLength=3min TrackLength=4min TrackLength=3min ...
And the order they appear in the info packet is the order of the chapters... It's nice, but it gives significance to the order of the items in the info packet which I am not sure is a good idea.
Why not?
Another note: I'd like to disallow info streams in non live streams.. For any purpose, info packets and chapters can be used. (It should at least be a "SHOULD"...)
use COULD. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero
On Sat, Feb 18, 2006 at 10:38:37AM +0100, Luca Barbato wrote:
Oded Shimon wrote:
I can't decide a proper way for this... One possibility is this:
Info packet 1: ChapterId=1, TrackTime=3min Info packet 2: ChapterId=1, TrackTime=4min Info packet 3: ChapterId=2, TrackTime=3min ...
But it seems over complicated. I'd like the ability to do this somehow:
hmm
Info packet 1: ChapterId=1, TrackTime=3min, Title="foo", ShortSynopsys="blah",... other fields and friends..
I think this will be the usage of it.
Yes, I had considered this and had already decided that there will be such an option, 'chapterid' describes which chapter the entire info packet describes. BUT, I'd like the _layout_ of the chapters to be decided globally in a single packet, otherwise the player will have to do a whole "mapping" thing to decide where chapters begin and end. Putting the start and length in each chapter-specific packet is worse, because it introduces redundancy. Might be nice for gaps though.
This might be a solution: Single info packet: TrackLength=3min TrackLength=4min TrackLength=3min ...
And the order they appear in the info packet is the order of the chapters... It's nice, but it gives significance to the order of the items in the info packet which I am not sure is a good idea.
Why not?
I don't know... It just seems odd.
Another note: I'd like to disallow info streams in non live streams.. For any purpose, info packets and chapters can be used. (It should at least be a "SHOULD"...)
use COULD.
No, SHOULD. "Info streams SHOULD NOT be used in non-live streams." COULD only means ability. They can be used anywhere, but they should only be used in this situation. BTW, the only keywords defined in NUT spec are SHOULD and MUST. :) - ods15
Hi On Sat, Feb 18, 2006 at 11:58:53AM +0200, Oded Shimon wrote:
On Sat, Feb 18, 2006 at 10:38:37AM +0100, Luca Barbato wrote:
Oded Shimon wrote:
I can't decide a proper way for this... One possibility is this:
Info packet 1: ChapterId=1, TrackTime=3min Info packet 2: ChapterId=1, TrackTime=4min Info packet 3: ChapterId=2, TrackTime=3min ...
But it seems over complicated. I'd like the ability to do this somehow:
hmm
Info packet 1: ChapterId=1, TrackTime=3min, Title="foo", ShortSynopsys="blah",... other fields and friends..
I think this will be the usage of it.
Yes, I had considered this and had already decided that there will be such an option, 'chapterid' describes which chapter the entire info packet describes. BUT, I'd like the _layout_ of the chapters to be decided globally in a single packet, otherwise the player will have to do a whole "mapping" thing to decide where chapters begin and end. Putting the start and length in each chapter-specific packet is worse, because it introduces redundancy. Might be nice for gaps though.
putting all the chapter start/end info in a single packet makes the whole very fragile, if that packet is lost all chapte info is lost so iam against it [...]
Another note: I'd like to disallow info streams in non live streams.. For any purpose, info packets and chapters can be used. (It should at least be a "SHOULD"...)
use COULD.
No, SHOULD. "Info streams SHOULD NOT be used in non-live streams." COULD only means ability. They can be used anywhere, but they should only be used in this situation. BTW, the only keywords defined in NUT spec are SHOULD and MUST. :)
iam strongly against that, either we need info streams or non global info packets, i dont care which but i wont accept the "neither case" [...] -- Michael
On Sat, Feb 18, 2006 at 12:21:38PM +0100, Michael Niedermayer wrote:
Hi
On Sat, Feb 18, 2006 at 11:58:53AM +0200, Oded Shimon wrote:
On Sat, Feb 18, 2006 at 10:38:37AM +0100, Luca Barbato wrote:
Oded Shimon wrote:
I can't decide a proper way for this... One possibility is this:
Info packet 1: ChapterId=1, TrackTime=3min Info packet 2: ChapterId=1, TrackTime=4min Info packet 3: ChapterId=2, TrackTime=3min ...
But it seems over complicated. I'd like the ability to do this somehow:
hmm
Info packet 1: ChapterId=1, TrackTime=3min, Title="foo", ShortSynopsys="blah",... other fields and friends..
I think this will be the usage of it.
Yes, I had considered this and had already decided that there will be such an option, 'chapterid' describes which chapter the entire info packet describes. BUT, I'd like the _layout_ of the chapters to be decided globally in a single packet, otherwise the player will have to do a whole "mapping" thing to decide where chapters begin and end. Putting the start and length in each chapter-specific packet is worse, because it introduces redundancy. Might be nice for gaps though.
putting all the chapter start/end info in a single packet makes the whole very fragile, if that packet is lost all chapte info is lost so iam against it
But I am against the complication of a player "putting together" a bunch of seperate info packets to figure out which chapter it is in right now... I think the only tolerable way to do it in seperate info packets is: no chapterid ChapterStart, TrackTime, and description-info. Makes it tricky for a player to do '-chapter 5' though... (It has to sort the chapterstart.. Maybe force that chapter info packets must come in sequential order?)
Another note: I'd like to disallow info streams in non live streams.. For any purpose, info packets and chapters can be used. (It should at least be a "SHOULD"...)
use COULD.
No, SHOULD. "Info streams SHOULD NOT be used in non-live streams." COULD only means ability. They can be used anywhere, but they should only be used in this situation. BTW, the only keywords defined in NUT spec are SHOULD and MUST. :)
iam strongly against that, either we need info streams or non global info packets, i dont care which but i wont accept the "neither case"
Well, there are two problems here: 1. A player wants to know all chapter info when loading the file, so the user can do 'mplayer -chapter 5', and it can show chapter info while playing. 2. A live stream wants to give song info when switching songs. If we put chapter info spread out in an info stream, there's no way to load all chapter info when opening the file except linear searching the entire file. What solution do you suggest to these 2 problems? - ods15
Hi On Sat, Feb 18, 2006 at 01:32:13PM +0200, Oded Shimon wrote:
On Sat, Feb 18, 2006 at 12:21:38PM +0100, Michael Niedermayer wrote: [...]
Another note: I'd like to disallow info streams in non live streams.. For any purpose, info packets and chapters can be used. (It should at least be a "SHOULD"...)
use COULD.
No, SHOULD. "Info streams SHOULD NOT be used in non-live streams." COULD only means ability. They can be used anywhere, but they should only be used in this situation. BTW, the only keywords defined in NUT spec are SHOULD and MUST. :)
iam strongly against that, either we need info streams or non global info packets, i dont care which but i wont accept the "neither case"
Well, there are two problems here: 1. A player wants to know all chapter info when loading the file, so the user can do 'mplayer -chapter 5', and it can show chapter info while playing. 2. A live stream wants to give song info when switching songs.
If we put chapter info spread out in an info stream, there's no way to load all chapter info when opening the file except linear searching the entire file. What solution do you suggest to these 2 problems?
info != chapter info can be stored at 2 places 1. global & constant & repeated after every main/stream headers 2. local in an info stream info SHOULD be stored in global packets instead of info streams if possible and the amount of data is not large noone wants 50mb of info packets at the file start nomatter what they contain [...] -- Michael
On Sat, Feb 18, 2006 at 12:50:49PM +0100, Michael Niedermayer wrote:
Hi
On Sat, Feb 18, 2006 at 01:32:13PM +0200, Oded Shimon wrote:
On Sat, Feb 18, 2006 at 12:21:38PM +0100, Michael Niedermayer wrote: [...]
Another note: I'd like to disallow info streams in non live streams.. For any purpose, info packets and chapters can be used. (It should at least be a "SHOULD"...)
use COULD.
No, SHOULD. "Info streams SHOULD NOT be used in non-live streams." COULD only means ability. They can be used anywhere, but they should only be used in this situation. BTW, the only keywords defined in NUT spec are SHOULD and MUST. :)
iam strongly against that, either we need info streams or non global info packets, i dont care which but i wont accept the "neither case"
Well, there are two problems here: 1. A player wants to know all chapter info when loading the file, so the user can do 'mplayer -chapter 5', and it can show chapter info while playing. 2. A live stream wants to give song info when switching songs.
If we put chapter info spread out in an info stream, there's no way to load all chapter info when opening the file except linear searching the entire file. What solution do you suggest to these 2 problems?
info != chapter
info can be stored at 2 places 1. global & constant & repeated after every main/stream headers 2. local in an info stream
info SHOULD be stored in global packets instead of info streams if possible and the amount of data is not large
noone wants 50mb of info packets at the file start nomatter what they contain
OK, I agree, this is actually same as I had in mind, I guess we just understood each other differently. I can't think of any scenarios where info streams are useful except for live streams, that's why I said the "SHOULD" there, but your rule is more accurate... - ods15
Michael Niedermayer wrote:
info can be stored at 2 places 1. global & constant & repeated after every main/stream headers
There I'd store just the chapter startpos
2. local in an info stream
There I'd store all the other optional stuff Why it looks like the same discussion about index? lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero
On Sat, Feb 18, 2006 at 02:31:58PM +0100, Luca Barbato wrote:
Michael Niedermayer wrote:
info can be stored at 2 places 1. global & constant & repeated after every main/stream headers
There I'd store just the chapter startpos
Over here I'd store just about all metadata possible, so the player can see/know everything without seeking all over the file. Imagine a player that shows you a chapter list with titles and you pick one.
2. local in an info stream
There I'd store all the other optional stuff
IMO, no. Info streams should just about only ever be used in live streams - in any other situation, they make you loose the metadata if you're seeking into the middle of such an area. (each info frame should be closely followed either by an EOR or by a repeated info frame, to prevent back_ptr being unusably large)
Why it looks like the same discussion about index?
lol, it isn't. The discussion there was overhead vs. seeking speed in very rare situations. The discussion here is merely correctness, where is the most correct place to put this metadata. Also, I don't think there's much of an argument here, it seems we are mostly in agreement. - ods15
On Sat, Feb 18, 2006 at 10:38:37AM +0100, Luca Barbato wrote:
This might be a solution: Single info packet: TrackLength=3min TrackLength=4min TrackLength=3min ...
And the order they appear in the info packet is the order of the chapters... It's nice, but it gives significance to the order of the items in the info packet which I am not sure is a good idea.
Why not?
Because this does not match normal demuxer semantics, which pair each key with a single value. Rich
On Sat, Feb 18, 2006 at 11:15:45AM +0200, Oded Shimon wrote:
I can't decide a proper way for this... One possibility is this:
Info packet 1: ChapterId=1, TrackTime=3min Info packet 2: ChapterId=1, TrackTime=4min Info packet 3: ChapterId=2, TrackTime=3min
OK, I propose using this, together with 'ChapterStart'. (also rename TrackTime to ChapterLength?) Of course all additional info to the chapter (artist, blah) will be added in the same info packet. - ods15
Hi On Sat, Feb 18, 2006 at 07:46:43PM +0200, Oded Shimon wrote:
On Sat, Feb 18, 2006 at 11:15:45AM +0200, Oded Shimon wrote:
I can't decide a proper way for this... One possibility is this:
Info packet 1: ChapterId=1, TrackTime=3min Info packet 2: ChapterId=1, TrackTime=4min Info packet 3: ChapterId=2, TrackTime=3min
OK, I propose using this, together with 'ChapterStart'. (also rename TrackTime to ChapterLength?)
ok, and iam also in favor of ChapterLength [...] -- Michael
participants (4)
-
Luca Barbato -
Michael Niedermayer -
Oded Shimon -
Rich Felker