Hi Currently info packets are list of streams list of name/type/value triplets i would suggest that we change this to first name/type/value is the "name/id" of what is described remander is a list of descriptions and require that any 2 info packets with the same name/id be identical one case where the current variant is unclear is ChapterId=5 StartTime=1min StopTime=2min does this mean Chapter 5 is from 1min to 2min or that the info packet describes the time from 1min to 2min of chapter 5? for my suggestion it would be Chapter 5 --- StartTime=1min StopTime=2min vs. TimeSpan 123 --- Chapter=5 StartTime=1min StopTime=2min the following is the simplest way to store things i could come up with: count v for(i=0; i<count; i++){ x v name vb if(x==0){ type vb value vb }else if(x==1){ type= "UTF-8" value vb }else{ type= "rational" value.num s value.den= x-1 } } -- Michael
On Sun, Feb 19, 2006 at 10:28:39AM +0100, Michael Niedermayer wrote:
Hi
Currently info packets are list of streams list of name/type/value triplets
i would suggest that we change this to first name/type/value is the "name/id" of what is described remander is a list of descriptions and require that any 2 info packets with the same name/id be identical
one case where the current variant is unclear is ChapterId=5 StartTime=1min StopTime=2min
does this mean Chapter 5 is from 1min to 2min or that the info packet describes the time from 1min to 2min of chapter 5?
I don't think you can break down info packets to smaller than chapers... Also, it's 'ChapterLength', not 'StopTime'... I'm considering something different - each info packet is prepended with stream id/mask and chapter id/mask, and they identify the entire info packet. If we do the chapter mask thing, we might want to bring back the "decompress element" you had... Chapters really would need an overflow protection, and building a custom v reader is slightly annoying, as they come in reverse order... (msb bits first) Also, if we do do this, I'm wondering if to allow a stream which has already been described by an info packet to be described again, only this time the mask is different. like: info packet 1: streams 1,2,3: title-whatever info packet 2: stream 1: disposition-whatever info packet 3: stream 2: ... Same with chapters.
for my suggestion it would be Chapter 5 --- StartTime=1min StopTime=2min
vs. TimeSpan 123 --- Chapter=5 StartTime=1min StopTime=2min
I don't like the idea of info packets describing regions smaller than chapters, seems complex and unuseful.. describing several chapters at once though could be useful, using chapter mask...
the following is the simplest way to store things i could come up with:
count v for(i=0; i<count; i++){ x v name vb if(x==0){ type vb value vb }else if(x==1){ type= "UTF-8" value vb }else{ type= "rational" value.num s value.den= x-1 } }
I like this (the compression)... I'm assuming you still want the stream mask in the begginning?.. - ods15
Hi On Sun, Feb 19, 2006 at 02:09:09PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 10:28:39AM +0100, Michael Niedermayer wrote:
Hi
Currently info packets are list of streams list of name/type/value triplets
i would suggest that we change this to first name/type/value is the "name/id" of what is described remander is a list of descriptions and require that any 2 info packets with the same name/id be identical
one case where the current variant is unclear is ChapterId=5 StartTime=1min StopTime=2min
does this mean Chapter 5 is from 1min to 2min or that the info packet describes the time from 1min to 2min of chapter 5?
I don't think you can break down info packets to smaller than chapers... Also, it's 'ChapterLength', not 'StopTime'...
I'm considering something different - each info packet is prepended with stream id/mask and chapter id/mask, and they identify the entire info packet. If we do the chapter mask thing, we might want to bring back the "decompress element" you had... Chapters really would need an overflow protection, and building a custom v reader is slightly annoying, as they come in reverse order... (msb bits first)
do what you want, i will write my own ext-info packet extension, as this is not worth the fight, info packets had one propose and that was to be generic, and you and rich try to make it impossible to store generic info with these packets, you wont succeed, people dont need a standarized system to store what they want to store, only thing you achive is that it will be non standard or they will use another container [...]
the following is the simplest way to store things i could come up with:
count v for(i=0; i<count; i++){ x v name vb if(x==0){ type vb value vb }else if(x==1){ type= "UTF-8" value vb }else{ type= "rational" value.num s value.den= x-1 } }
I like this (the compression)... I'm assuming you still want the stream mask in the begginning?..
no [...] -- Michael
On Sun, Feb 19, 2006 at 01:23:30PM +0100, Michael Niedermayer wrote:
Hi
On Sun, Feb 19, 2006 at 02:09:09PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 10:28:39AM +0100, Michael Niedermayer wrote:
Hi
Currently info packets are list of streams list of name/type/value triplets
i would suggest that we change this to first name/type/value is the "name/id" of what is described remander is a list of descriptions and require that any 2 info packets with the same name/id be identical
one case where the current variant is unclear is ChapterId=5 StartTime=1min StopTime=2min
does this mean Chapter 5 is from 1min to 2min or that the info packet describes the time from 1min to 2min of chapter 5?
I don't think you can break down info packets to smaller than chapers... Also, it's 'ChapterLength', not 'StopTime'...
I'm considering something different - each info packet is prepended with stream id/mask and chapter id/mask, and they identify the entire info packet. If we do the chapter mask thing, we might want to bring back the "decompress element" you had... Chapters really would need an overflow protection, and building a custom v reader is slightly annoying, as they come in reverse order... (msb bits first)
do what you want, i will write my own ext-info packet extension, as this is not worth the fight, info packets had one propose and that was to be generic, and you and rich try to make it impossible to store generic info with these packets, you wont succeed, people dont need a standarized system to store what they want to store, only thing you achive is that it will be non standard or they will use another container
Umm... I had no intention of flaming or fighting :/ I want a relatively standarnized way of handling chapters/streams in info packets in nut so not any asshat can make up his own stuff and no player will know what to do with it... Yes info packets should be generic, but not to the point that players won't know how to handle them and make use of them... :/ So, going back to your idea of "first triplet is the id of the info packet". You use it is like this? packet: title=bla, artist=.. (global packet) packet: streamid=1, disposition=.. ("streamid" is a field like any other?) packet: chapterid=1, start=0, length=3min, title=... packet: chapterid=2, start=3min, length=3min, ... ... If I understand this correctly, there's no way to describe further in detail than a chapter, or a stream, or describe several streams/chapter together. (like, you can't describe a certain chapter for a certain stream. not that i see a usefulness in this though) Am I understanding right? (i'm not objecting to any of this, just quering) (BTW, on the one hand you're saying "let's be generic and do anything", and on the other hand you're asking to disallow utf-8 in names and just allow [a-z]...) - ods15
Hi On Sun, Feb 19, 2006 at 03:01:25PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 01:23:30PM +0100, Michael Niedermayer wrote:
Hi
On Sun, Feb 19, 2006 at 02:09:09PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 10:28:39AM +0100, Michael Niedermayer wrote:
Hi
Currently info packets are list of streams list of name/type/value triplets
i would suggest that we change this to first name/type/value is the "name/id" of what is described remander is a list of descriptions and require that any 2 info packets with the same name/id be identical
one case where the current variant is unclear is ChapterId=5 StartTime=1min StopTime=2min
does this mean Chapter 5 is from 1min to 2min or that the info packet describes the time from 1min to 2min of chapter 5?
I don't think you can break down info packets to smaller than chapers... Also, it's 'ChapterLength', not 'StopTime'...
I'm considering something different - each info packet is prepended with stream id/mask and chapter id/mask, and they identify the entire info packet. If we do the chapter mask thing, we might want to bring back the "decompress element" you had... Chapters really would need an overflow protection, and building a custom v reader is slightly annoying, as they come in reverse order... (msb bits first)
do what you want, i will write my own ext-info packet extension, as this is not worth the fight, info packets had one propose and that was to be generic, and you and rich try to make it impossible to store generic info with these packets, you wont succeed, people dont need a standarized system to store what they want to store, only thing you achive is that it will be non standard or they will use another container
Umm... I had no intention of flaming or fighting :/
I want a relatively standarnized way of handling chapters/streams in info packets in nut so not any asshat can make up his own stuff and no player will know what to do with it... Yes info packets should be generic, but not to the point that players won't know how to handle them and make use of them... :/
So, going back to your idea of "first triplet is the id of the info packet". You use it is like this?
packet: title=bla, artist=.. (global packet) packet: streamid=1, disposition=.. ("streamid" is a field like any other?) packet: chapterid=1, start=0, length=3min, title=... packet: chapterid=2, start=3min, length=3min, ... ...
If I understand this correctly, there's no way to describe further in detail than a chapter, or a stream, or describe several streams/chapter together. (like, you can't describe a certain chapter for a certain stream. not that i see a usefulness in this though)
well, my idea was supposed to allow this too, but iam no longer sure if its clean or a good idea how i wanted to support that, probably you wont like it packet: global, title=blah, artist= ... packet: stream=2, disposition=commentary, language=eng packet: part=0, stream=0, stream=1, disposition= packet: chapter=0, start=0, length=5, title="introduction" packet: chapter=1, start=5, length=10,title="battle" packet: part=1, chapter=0, chapter=1, director="arpi" packet: part=2, part=1, chapter=2, location="russia" packet: part=3, start=0, length=1, stream=1, artist=foobar maybe a system we both would like is to add a list of streams and start/stop times at the top of every info packet, so that the packet applies to (streamX + StreamY + ... + StreamZ) at the time intervals (startX..endX + startY..EndY + ... + startZ..EndZ) and require that every 2 info packes with the same streams and intervalls be identical that would avoid the chapter limitation your system introduces and it doesnt make info packets depend on each other which means simpler parsing and more error robustness [...] -- Michael
On Sun, Feb 19, 2006 at 03:42:11PM +0100, Michael Niedermayer wrote:
On Sun, Feb 19, 2006 at 03:01:25PM +0200, Oded Shimon wrote:
Umm... I had no intention of flaming or fighting :/
I want a relatively standarnized way of handling chapters/streams in info packets in nut so not any asshat can make up his own stuff and no player will know what to do with it... Yes info packets should be generic, but not to the point that players won't know how to handle them and make use of them... :/
So, going back to your idea of "first triplet is the id of the info packet". You use it is like this?
packet: title=bla, artist=.. (global packet) packet: streamid=1, disposition=.. ("streamid" is a field like any other?) packet: chapterid=1, start=0, length=3min, title=... packet: chapterid=2, start=3min, length=3min, ... ...
If I understand this correctly, there's no way to describe further in detail than a chapter, or a stream, or describe several streams/chapter together. (like, you can't describe a certain chapter for a certain stream. not that i see a usefulness in this though)
well, my idea was supposed to allow this too, but iam no longer sure if its clean or a good idea how i wanted to support that, probably you wont like it
packet: global, title=blah, artist= ... packet: stream=2, disposition=commentary, language=eng packet: part=0, stream=0, stream=1, disposition= packet: chapter=0, start=0, length=5, title="introduction" packet: chapter=1, start=5, length=10,title="battle" packet: part=1, chapter=0, chapter=1, director="arpi" packet: part=2, part=1, chapter=2, location="russia" packet: part=3, start=0, length=1, stream=1, artist=foobar
Yeah you guessed right... I don't like it, too high complexity :/
maybe a system we both would like is to add a list of streams and start/stop times at the top of every info packet, so that the packet applies to (streamX + StreamY + ... + StreamZ) at the time intervals (startX..endX + startY..EndY + ... + startZ..EndZ)
and require that every 2 info packes with the same streams and intervalls be identical
that would avoid the chapter limitation your system introduces and it doesnt make info packets depend on each other which means simpler parsing and more error robustness
Do we really need the ability to specify regions smaller/seperate from chapters? I fail to see the usefulness of this... Even mkv doesn't have such an ability, and they are the bloated tag-info experts... Maybe we can make a 'chapterid=-1' or whatever that means it's not any chapter, it's some subregion. it has the disadvantage of having to allow several packets with the same "chapterid".. BTW, I vote to back to dropping the masks and going back to ability of a single stream and/or single chapterid per info packet.. The very rare space save is not worth the complexity.. (you have multiple packets describing the same stream or whatever) Even a simple implementation detail, how do you store the bitmask, you either limit yourself to 64 bits or use yet another dynamic array for the info packet... - ods15
On Sun, Feb 19, 2006 at 06:47:13PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 03:42:11PM +0100, Michael Niedermayer wrote:
maybe a system we both would like is to add a list of streams and start/stop times at the top of every info packet, so that the packet applies to (streamX + StreamY + ... + StreamZ) at the time intervals (startX..endX + startY..EndY + ... + startZ..EndZ)
and require that every 2 info packes with the same streams and intervalls be identical
that would avoid the chapter limitation your system introduces and it doesnt make info packets depend on each other which means simpler parsing and more error robustness
Do we really need the ability to specify regions smaller/seperate from chapters? I fail to see the usefulness of this... Even mkv doesn't have such an ability, and they are the bloated tag-info experts... Maybe we can make a 'chapterid=-1' or whatever that means it's not any chapter, it's some subregion. it has the disadvantage of having to allow several packets with the same "chapterid"..
Alternative, chapterid=-1,-2,... each subregion has a new id. (the only reason negative values are special, they can overlap real chapters with positive id's..) This only works if we agree to dump the bitmask... I preffer simplicity over compactness for the info packets... - ods15
Hi On Sun, Feb 19, 2006 at 07:04:02PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 06:47:13PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 03:42:11PM +0100, Michael Niedermayer wrote:
maybe a system we both would like is to add a list of streams and start/stop times at the top of every info packet, so that the packet applies to (streamX + StreamY + ... + StreamZ) at the time intervals (startX..endX + startY..EndY + ... + startZ..EndZ)
and require that every 2 info packes with the same streams and intervalls be identical
that would avoid the chapter limitation your system introduces and it doesnt make info packets depend on each other which means simpler parsing and more error robustness
Do we really need the ability to specify regions smaller/seperate from chapters? I fail to see the usefulness of this... Even mkv doesn't have such an ability, and they are the bloated tag-info experts... Maybe we can make a 'chapterid=-1' or whatever that means it's not any chapter, it's some subregion. it has the disadvantage of having to allow several packets with the same "chapterid"..
Alternative, chapterid=-1,-2,... each subregion has a new id. (the only reason negative values are special, they can overlap real chapters with positive id's..)
This only works if we agree to dump the bitmask...
I preffer simplicity over compactness for the info packets...
i wont object against a single stream id and single start/stop time per info packet as long as the overhead is not unreasonable i am against your overlapping restrictions and negative chapter ids packet: streamid=-1(all), startTime=0, len=sth_big, Title=foobar packet: streamid=-1(all), startTime=0, len=123, Type="chapter", Title="Introduction" packet: streamid=1, startTime=0, len=sth_big, Lang=mixed, PrimaryLang=eng packet: streamid=1, startTime=100, len=50, Lang=ger [...] -- Michael
On Sun, Feb 19, 2006 at 07:15:17PM +0100, Michael Niedermayer wrote:
On Sun, Feb 19, 2006 at 07:04:02PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 06:47:13PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 03:42:11PM +0100, Michael Niedermayer wrote:
maybe a system we both would like is to add a list of streams and start/stop times at the top of every info packet, so that the packet applies to (streamX + StreamY + ... + StreamZ) at the time intervals (startX..endX + startY..EndY + ... + startZ..EndZ)
and require that every 2 info packes with the same streams and intervalls be identical
that would avoid the chapter limitation your system introduces and it doesnt make info packets depend on each other which means simpler parsing and more error robustness
Do we really need the ability to specify regions smaller/seperate from chapters? I fail to see the usefulness of this... Even mkv doesn't have such an ability, and they are the bloated tag-info experts... Maybe we can make a 'chapterid=-1' or whatever that means it's not any chapter, it's some subregion. it has the disadvantage of having to allow several packets with the same "chapterid"..
Alternative, chapterid=-1,-2,... each subregion has a new id. (the only reason negative values are special, they can overlap real chapters with positive id's..)
This only works if we agree to dump the bitmask...
I preffer simplicity over compactness for the info packets...
i wont object against a single stream id and single start/stop time per info packet as long as the overhead is not unreasonable
i am against your overlapping restrictions and negative chapter ids
packet: streamid=-1(all), startTime=0, len=sth_big, Title=foobar packet: streamid=-1(all), startTime=0, len=123, Type="chapter", Title="Introduction" packet: streamid=1, startTime=0, len=sth_big, Lang=mixed, PrimaryLang=eng packet: streamid=1, startTime=100, len=50, Lang=ger
Hmm, you can do all this with the negative chapter ids, so what's the problem? The negative chapter id's have absoloutely no overlapping rules, they can overlap the positive chapters and each other.. - ods15
Hi On Sun, Feb 19, 2006 at 08:48:55PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 07:15:17PM +0100, Michael Niedermayer wrote:
On Sun, Feb 19, 2006 at 07:04:02PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 06:47:13PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 03:42:11PM +0100, Michael Niedermayer wrote:
maybe a system we both would like is to add a list of streams and start/stop times at the top of every info packet, so that the packet applies to (streamX + StreamY + ... + StreamZ) at the time intervals (startX..endX + startY..EndY + ... + startZ..EndZ)
and require that every 2 info packes with the same streams and intervalls be identical
that would avoid the chapter limitation your system introduces and it doesnt make info packets depend on each other which means simpler parsing and more error robustness
Do we really need the ability to specify regions smaller/seperate from chapters? I fail to see the usefulness of this... Even mkv doesn't have such an ability, and they are the bloated tag-info experts... Maybe we can make a 'chapterid=-1' or whatever that means it's not any chapter, it's some subregion. it has the disadvantage of having to allow several packets with the same "chapterid"..
Alternative, chapterid=-1,-2,... each subregion has a new id. (the only reason negative values are special, they can overlap real chapters with positive id's..)
This only works if we agree to dump the bitmask...
I preffer simplicity over compactness for the info packets...
i wont object against a single stream id and single start/stop time per info packet as long as the overhead is not unreasonable
i am against your overlapping restrictions and negative chapter ids
packet: streamid=-1(all), startTime=0, len=sth_big, Title=foobar packet: streamid=-1(all), startTime=0, len=123, Type="chapter", Title="Introduction" packet: streamid=1, startTime=0, len=sth_big, Lang=mixed, PrimaryLang=eng packet: streamid=1, startTime=100, len=50, Lang=ger
Hmm, you can do all this with the negative chapter ids, so what's the problem?
negative chapter ids are an ugly hack and from where do we know the start/stop times of the chapters, iam strongly against putting all chapter start/stop times in a single packet [...] -- Michael
On Sun, Feb 19, 2006 at 10:04:21PM +0100, Michael Niedermayer wrote:
I preffer simplicity over compactness for the info packets...
i wont object against a single stream id and single start/stop time per info packet as long as the overhead is not unreasonable
i am against your overlapping restrictions and negative chapter ids
packet: streamid=-1(all), startTime=0, len=sth_big, Title=foobar packet: streamid=-1(all), startTime=0, len=123, Type="chapter", Title="Introduction" packet: streamid=1, startTime=0, len=sth_big, Lang=mixed, PrimaryLang=eng packet: streamid=1, startTime=100, len=50, Lang=ger
Hmm, you can do all this with the negative chapter ids, so what's the problem?
negative chapter ids are an ugly hack
and from where do we know the start/stop times of the chapters, iam strongly against putting all chapter start/stop times in a single packet
It would be nice if we could design this in such a way that the same in-band info stream frames for streaming content could be directly remuxed to info packets for easy chapter access in on-disk files (and vice versa). Rich
On Sun, Feb 19, 2006 at 10:04:21PM +0100, Michael Niedermayer wrote:
Hi
On Sun, Feb 19, 2006 at 08:48:55PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 07:15:17PM +0100, Michael Niedermayer wrote:
On Sun, Feb 19, 2006 at 07:04:02PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 06:47:13PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 03:42:11PM +0100, Michael Niedermayer wrote:
maybe a system we both would like is to add a list of streams and start/stop times at the top of every info packet, so that the packet applies to (streamX + StreamY + ... + StreamZ) at the time intervals (startX..endX + startY..EndY + ... + startZ..EndZ)
and require that every 2 info packes with the same streams and intervalls be identical
that would avoid the chapter limitation your system introduces and it doesnt make info packets depend on each other which means simpler parsing and more error robustness
Do we really need the ability to specify regions smaller/seperate from chapters? I fail to see the usefulness of this... Even mkv doesn't have such an ability, and they are the bloated tag-info experts... Maybe we can make a 'chapterid=-1' or whatever that means it's not any chapter, it's some subregion. it has the disadvantage of having to allow several packets with the same "chapterid"..
Alternative, chapterid=-1,-2,... each subregion has a new id. (the only reason negative values are special, they can overlap real chapters with positive id's..)
This only works if we agree to dump the bitmask...
I preffer simplicity over compactness for the info packets...
i wont object against a single stream id and single start/stop time per info packet as long as the overhead is not unreasonable
i am against your overlapping restrictions and negative chapter ids
packet: streamid=-1(all), startTime=0, len=sth_big, Title=foobar packet: streamid=-1(all), startTime=0, len=123, Type="chapter", Title="Introduction" packet: streamid=1, startTime=0, len=sth_big, Lang=mixed, PrimaryLang=eng packet: streamid=1, startTime=100, len=50, Lang=ger
Hmm, you can do all this with the negative chapter ids, so what's the problem?
negative chapter ids are an ugly hack
I somewhat agree... It reflects me failing to see the usefulness of specifying subareas... It also confuses the player, it has several info packets applying to the same region...
and from where do we know the start/stop times of the chapters, iam strongly against putting all chapter start/stop times in a single packet
I already gave up this, I said so in the other thread... The idea I have in mind right now is: packet: streamid=-1, chapterid=1, start=0, len=50, title=bla packet: streamid=-1, chapterid=2, start=50, len=30, title=whatever packet: streamid=-1, chapterid=-1, start=30, len=40, title=... It's not very different from your idea of identifying packets by stream and start/stop time... I suppose we can do that... Can you give a spec for how to code it? - ods15
Hi On Mon, Feb 20, 2006 at 06:22:34AM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 10:04:21PM +0100, Michael Niedermayer wrote:
Hi
On Sun, Feb 19, 2006 at 08:48:55PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 07:15:17PM +0100, Michael Niedermayer wrote:
On Sun, Feb 19, 2006 at 07:04:02PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 06:47:13PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 03:42:11PM +0100, Michael Niedermayer wrote: > maybe a system we both would like is to add a list of streams and start/stop > times at the top of every info packet, so that the packet applies to > (streamX + StreamY + ... + StreamZ) at the time intervals > (startX..endX + startY..EndY + ... + startZ..EndZ) > > and require that every 2 info packes with the same streams and intervalls be > identical > > that would avoid the chapter limitation your system introduces and it doesnt > make info packets depend on each other which means simpler parsing and > more error robustness
Do we really need the ability to specify regions smaller/seperate from chapters? I fail to see the usefulness of this... Even mkv doesn't have such an ability, and they are the bloated tag-info experts... Maybe we can make a 'chapterid=-1' or whatever that means it's not any chapter, it's some subregion. it has the disadvantage of having to allow several packets with the same "chapterid"..
Alternative, chapterid=-1,-2,... each subregion has a new id. (the only reason negative values are special, they can overlap real chapters with positive id's..)
This only works if we agree to dump the bitmask...
I preffer simplicity over compactness for the info packets...
i wont object against a single stream id and single start/stop time per info packet as long as the overhead is not unreasonable
i am against your overlapping restrictions and negative chapter ids
packet: streamid=-1(all), startTime=0, len=sth_big, Title=foobar packet: streamid=-1(all), startTime=0, len=123, Type="chapter", Title="Introduction" packet: streamid=1, startTime=0, len=sth_big, Lang=mixed, PrimaryLang=eng packet: streamid=1, startTime=100, len=50, Lang=ger
Hmm, you can do all this with the negative chapter ids, so what's the problem?
negative chapter ids are an ugly hack
I somewhat agree... It reflects me failing to see the usefulness of specifying subareas... It also confuses the player, it has several info packets applying to the same region...
and from where do we know the start/stop times of the chapters, iam strongly against putting all chapter start/stop times in a single packet
I already gave up this, I said so in the other thread...
The idea I have in mind right now is:
packet: streamid=-1, chapterid=1, start=0, len=50, title=bla packet: streamid=-1, chapterid=2, start=50, len=30, title=whatever packet: streamid=-1, chapterid=-1, start=30, len=40, title=...
It's not very different from your idea of identifying packets by stream and start/stop time... I suppose we can do that... Can you give a spec for how to code it?
stream_plus_1 v start v len v chapterid s count v for(i=0; i<count; i++{ name vb value s if(value==-1){ type= "UTF-8" value vb }else if(value==-2){ type vb value vb }else if(value<-2){ value.den= -value-2 value.num s } } stream_plus_1 if zero then the packet applies to all streams start/len are in the timebase of stream_plus_1 - 1 or msecs if stream_plus_1=0 [...] -- Michael
On Mon, Feb 20, 2006 at 11:55:23AM +0100, Michael Niedermayer wrote:
On Mon, Feb 20, 2006 at 06:22:34AM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 10:04:21PM +0100, Michael Niedermayer wrote:
and from where do we know the start/stop times of the chapters, iam strongly against putting all chapter start/stop times in a single packet
I already gave up this, I said so in the other thread...
The idea I have in mind right now is:
packet: streamid=-1, chapterid=1, start=0, len=50, title=bla packet: streamid=-1, chapterid=2, start=50, len=30, title=whatever packet: streamid=-1, chapterid=-1, start=30, len=40, title=...
It's not very different from your idea of identifying packets by stream and start/stop time... I suppose we can do that... Can you give a spec for how to code it?
stream_plus_1 v start v len v chapterid s count v for(i=0; i<count; i++{ name vb value s if(value==-1){ type= "UTF-8" value vb }else if(value==-2){ type vb value vb }else if(value<-2){
type="rational"
value.den= -value-2 value.num s }
else { type="integer" } right? And if you want an actual negative value, I suppose you use -3 and then the negative number...
}
stream_plus_1 if zero then the packet applies to all streams
start/len are in the timebase of stream_plus_1 - 1 or msecs if stream_plus_1=0
some questions... 1. you made chapterid signed, so you DO want the negative chapterid thing? 2. timebase msecs is "bleh" :/ 3. what are start,len, and chapterid, if the packet applies globally? It might be silly, but the idea of using the negative chapters was to NOT have the start and len in the "info header" but in the actual info, cause for ex. they make no sense if you are talking about a global packet. ok, how about this idea... stream_plus_1 v chapterid s if (chapterid) { start v len v } count v ... Is this OK? - ods15
2006/2/20, Oded Shimon <ods15@ods15.dyndns.org>:
On Mon, Feb 20, 2006 at 11:55:23AM +0100, Michael Niedermayer wrote:
On Mon, Feb 20, 2006 at 06:22:34AM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 10:04:21PM +0100, Michael Niedermayer wrote:
and from where do we know the start/stop times of the chapters, iam strongly against putting all chapter start/stop times in a single packet
I already gave up this, I said so in the other thread...
The idea I have in mind right now is:
packet: streamid=-1, chapterid=1, start=0, len=50, title=bla packet: streamid=-1, chapterid=2, start=50, len=30, title=whatever packet: streamid=-1, chapterid=-1, start=30, len=40, title=...
It's not very different from your idea of identifying packets by stream and start/stop time... I suppose we can do that... Can you give a spec for how to code it?
stream_plus_1 v start v len v chapterid s count v for(i=0; i<count; i++{ name vb value s if(value==-1){ type= "UTF-8" value vb }else if(value==-2){ type vb value vb }else if(value<-2){
type="rational"
value.den= -value-2 value.num s }
else { type="integer" }
right? And if you want an actual negative value, I suppose you use -3 and then the negative number...
}
stream_plus_1 if zero then the packet applies to all streams
start/len are in the timebase of stream_plus_1 - 1 or msecs if stream_plus_1=0
some questions...
1. you made chapterid signed, so you DO want the negative chapterid thing? 2. timebase msecs is "bleh" :/ 3. what are start,len, and chapterid, if the packet applies globally?
It might be silly, but the idea of using the negative chapters was to NOT have the start and len in the "info header" but in the actual info, cause for ex. they make no sense if you are talking about a global packet.
ok, how about this idea...
stream_plus_1 v chapterid s if (chapterid) { start v len v } count v ...
Is this OK?
Don't get me wrong, but do we need chapter_len/end? AFAIK chapters are just seek points where you go to watch specific part, and when it ends the playback just go on. The chapter_start must be the time units of the stream.
On Mon, Feb 20, 2006 at 02:34:07PM +0200, Ivan Kalvachev wrote:
2006/2/20, Oded Shimon <ods15@ods15.dyndns.org>:
ok, how about this idea...
stream_plus_1 v chapterid s if (chapterid) { start v len v } count v ...
Is this OK?
Don't get me wrong, but do we need chapter_len/end? AFAIK chapters are just seek points where you go to watch specific part, and when it ends the playback just go on.
Well, yeah, they could be implictly stopped by the next chapter start, it removes redundancy... I dunno. It doesn't work with michaels subregion stuff though Maybe add another if inside the if, 'chapterid < 0' ...
The chapter_start must be the time units of the stream.
Semantic... I'm leaning toward using coded_pts style like syncpoints - ods15
Hi On Mon, Feb 20, 2006 at 01:23:16PM +0200, Oded Shimon wrote:
On Mon, Feb 20, 2006 at 11:55:23AM +0100, Michael Niedermayer wrote:
On Mon, Feb 20, 2006 at 06:22:34AM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 10:04:21PM +0100, Michael Niedermayer wrote:
and from where do we know the start/stop times of the chapters, iam strongly against putting all chapter start/stop times in a single packet
I already gave up this, I said so in the other thread...
The idea I have in mind right now is:
packet: streamid=-1, chapterid=1, start=0, len=50, title=bla packet: streamid=-1, chapterid=2, start=50, len=30, title=whatever packet: streamid=-1, chapterid=-1, start=30, len=40, title=...
It's not very different from your idea of identifying packets by stream and start/stop time... I suppose we can do that... Can you give a spec for how to code it?
stream_plus_1 v start v len v chapterid s count v for(i=0; i<count; i++{ name vb value s if(value==-1){ type= "UTF-8" value vb }else if(value==-2){ type vb value vb }else if(value<-2){
type="rational"
value.den= -value-2 value.num s }
else { type="integer" }
right? And if you want an actual negative value, I suppose you use -3 and then the negative number...
yes, its a little bit "compressed" but negative values are like rationals very rare, at least for the stuff we want to store currently ...
}
stream_plus_1 if zero then the packet applies to all streams
start/len are in the timebase of stream_plus_1 - 1 or msecs if stream_plus_1=0
some questions...
1. you made chapterid signed, so you DO want the negative chapterid thing?
no but its not a problem, lavf will just ignore chapterId completely and encode only negative ones
2. timebase msecs is "bleh" :/
yes, but it was that way already, my proposal makes it msecs only if the packet is not for a specific stream which is better then it was ...
3. what are start,len, and chapterid, if the packet applies globally?
start=0, chapterid=0, len=length in msec of video or 0 if not known? [...] -- Michael
On Mon, Feb 20, 2006 at 08:10:42PM +0100, Michael Niedermayer wrote:
2. timebase msecs is "bleh" :/
yes, but it was that way already, my proposal makes it msecs only if the packet is not for a specific stream which is better then it was ...
IMO just make the time type rational (pair of vlcs). Even then someone can decide to use msec for it and stores and extra 2 bytes for the denominator of 1000, but they're free to use correct exact values too. Rich
Hi On Mon, Feb 20, 2006 at 02:54:59PM -0500, Rich Felker wrote:
On Mon, Feb 20, 2006 at 08:10:42PM +0100, Michael Niedermayer wrote:
2. timebase msecs is "bleh" :/
yes, but it was that way already, my proposal makes it msecs only if the packet is not for a specific stream which is better then it was ...
IMO just make the time type rational (pair of vlcs). Even then someone can decide to use msec for it and stores and extra 2 bytes for the denominator of 1000, but they're free to use correct exact values too.
iam against this, people will store every info packet in msecs then even if they are for a specific stream i rather suggest to use a system similar to what we do in syncpoints [...] -- Michael
On Tue, Feb 21, 2006 at 12:22:49AM +0100, Michael Niedermayer wrote:
Hi
On Mon, Feb 20, 2006 at 02:54:59PM -0500, Rich Felker wrote:
On Mon, Feb 20, 2006 at 08:10:42PM +0100, Michael Niedermayer wrote:
2. timebase msecs is "bleh" :/
yes, but it was that way already, my proposal makes it msecs only if the packet is not for a specific stream which is better then it was ...
IMO just make the time type rational (pair of vlcs). Even then someone can decide to use msec for it and stores and extra 2 bytes for the denominator of 1000, but they're free to use correct exact values too.
iam against this, people will store every info packet in msecs then even if they are for a specific stream
i rather suggest to use a system similar to what we do in syncpoints
ok. rich
On Sun, Feb 19, 2006 at 06:47:13PM +0200, Oded Shimon wrote:
maybe a system we both would like is to add a list of streams and start/stop times at the top of every info packet, so that the packet applies to (streamX + StreamY + ... + StreamZ) at the time intervals (startX..endX + startY..EndY + ... + startZ..EndZ)
and require that every 2 info packes with the same streams and intervalls be identical
that would avoid the chapter limitation your system introduces and it doesnt make info packets depend on each other which means simpler parsing and more error robustness
Do we really need the ability to specify regions smaller/seperate from chapters? I fail to see the usefulness of this... Even mkv doesn't have such an ability, and they are the bloated tag-info experts... Maybe we can make a 'chapterid=-1' or whatever that means it's not any chapter, it's some subregion. it has the disadvantage of having to allow several packets with the same "chapterid"..
BTW, I vote to back to dropping the masks and going back to ability of a single stream and/or single chapterid per info packet.. The very rare space
I tend to agree with this, unless there's a compelling reason to do otherwise. What I originally envisioned was this: some metadata applies to the file as a unit (such as title, author, ...) while other metadata applies only to a single stream (language, disposition, ...). Then if you want chapters, you also have metadata that applies to only a fixed time range of the file as a unit, or (if you want very detailed information in odd cases) metadata that only applies to a fixed time range of one particular stream. Anyway, I never saw file-global metadata as being equivalent to "all streams". For instance, if I have an anime fansub, I would still consider the production company, director, etc. tags to apply to the file as a whole, and only tag the subtitle tracks with special info by the sub group (or even alternatively make an X-Subtitler global tag). Thus, I don't see any need when adding an extra stream to a nut file to exclude the global info tags from applying to it.
save is not worth the complexity.. (you have multiple packets describing the same stream or whatever) Even a simple implementation detail, how do you store the bitmask, you either limit yourself to 64 bits or use yet another dynamic array for the info packet...
No you don't!! This was already discussed. 'v' is called v for a reason; it has arbitrarily many bits! An implementation that won't read more than 64 for a field that's not limited to 64bit is a broken implementation. Anyway, I have no particular position for or against Michael's particular implementation ideas on info. However, here are a few things I would prefer... - Let's not use the same key more than once with different values in the same context (same stream/chapter/timeinterval). I fear this will be confusing to players. - If possible, I'd prefer that the demuxer not need to handle any of the semantics of info tags. But maybe this is a stupid requirement on my part. Maybe I'll try throwing some ideas out later for discussion. In the mean time, no worries, it's not my intent to flame or shoot down anyone's approach to info. Rich
On Sun, Feb 19, 2006 at 01:39:51PM -0500, Rich Felker wrote:
On Sun, Feb 19, 2006 at 06:47:13PM +0200, Oded Shimon wrote:
maybe a system we both would like is to add a list of streams and start/stop times at the top of every info packet, so that the packet applies to (streamX + StreamY + ... + StreamZ) at the time intervals (startX..endX + startY..EndY + ... + startZ..EndZ)
and require that every 2 info packes with the same streams and intervalls be identical
that would avoid the chapter limitation your system introduces and it doesnt make info packets depend on each other which means simpler parsing and more error robustness
Do we really need the ability to specify regions smaller/seperate from chapters? I fail to see the usefulness of this... Even mkv doesn't have such an ability, and they are the bloated tag-info experts... Maybe we can make a 'chapterid=-1' or whatever that means it's not any chapter, it's some subregion. it has the disadvantage of having to allow several packets with the same "chapterid"..
BTW, I vote to back to dropping the masks and going back to ability of a single stream and/or single chapterid per info packet.. The very rare space
I tend to agree with this, unless there's a compelling reason to do otherwise. What I originally envisioned was this: some metadata applies to the file as a unit (such as title, author, ...) while other metadata applies only to a single stream (language, disposition, ...).
Then if you want chapters, you also have metadata that applies to only a fixed time range of the file as a unit, or (if you want very detailed information in odd cases) metadata that only applies to a fixed time range of one particular stream.
I can't think of a usefulness for this btw... but it should be allowed
Anyway, I never saw file-global metadata as being equivalent to "all streams". For instance, if I have an anime fansub, I would still consider the production company, director, etc. tags to apply to the file as a whole, and only tag the subtitle tracks with special info by the sub group (or even alternatively make an X-Subtitler global tag). Thus, I don't see any need when adding an extra stream to a nut file to exclude the global info tags from applying to it.
Same here... global info is info usually about the "main content"...
save is not worth the complexity.. (you have multiple packets describing the same stream or whatever) Even a simple implementation detail, how do you store the bitmask, you either limit yourself to 64 bits or use yet another dynamic array for the info packet...
No you don't!! This was already discussed. 'v' is called v for a reason; it has arbitrarily many bits! An implementation that won't read more than 64 for a field that's not limited to 64bit is a broken implementation.
I meant store the bitmask in ram, it's just a silly implementation detail, but i want to avoid yet another malloc for info struct...
Anyway, I have no particular position for or against Michael's particular implementation ideas on info. However, here are a few things I would prefer...
- Let's not use the same key more than once with different values in the same context (same stream/chapter/timeinterval). I fear this will be confusing to players.
You mean, if I have 'director' set to the entire file, i can't use 'director' again as a subinfo for some stream?.. sounds ok with me...
- If possible, I'd prefer that the demuxer not need to handle any of the semantics of info tags. But maybe this is a stupid requirement on my part.
Maybe I'll try throwing some ideas out later for discussion. In the mean time, no worries, it's not my intent to flame or shoot down anyone's approach to info.
BTW, I'm considering keeping compatiblity with mkv tags, so transcoding is easy... Just the names of the fields, they use all caps and underscores (TITLE, CHAPTER_ID, whatever) - ods15
On Sun, Feb 19, 2006 at 08:45:01PM +0200, Oded Shimon wrote:
On Sun, Feb 19, 2006 at 01:39:51PM -0500, Rich Felker wrote:
Anyway, I have no particular position for or against Michael's particular implementation ideas on info. However, here are a few things I would prefer...
- Let's not use the same key more than once with different values in the same context (same stream/chapter/timeinterval). I fear this will be confusing to players.
You mean, if I have 'director' set to the entire file, i can't use 'director' again as a subinfo for some stream?.. sounds ok with me...
Actually, hold on, i'm against this. "Title" for ex., takes on a different meaning when you use it with chapters. Also, you can have an audio cd where all but one tracks are the same artist, so you use artist in the global info and a sepcific artist in one chapter.... - ods15
On Sun, Feb 19, 2006 at 08:45:01PM +0200, Oded Shimon wrote:
Anyway, I have no particular position for or against Michael's particular implementation ideas on info. However, here are a few things I would prefer...
- Let's not use the same key more than once with different values in the same context (same stream/chapter/timeinterval). I fear this will be confusing to players.
You mean, if I have 'director' set to the entire file, i can't use 'director' again as a subinfo for some stream?.. sounds ok with me...
No, i mean you can't put both Stream=1 and Stream=2 in the same packet.
- If possible, I'd prefer that the demuxer not need to handle any of the semantics of info tags. But maybe this is a stupid requirement on my part.
Maybe I'll try throwing some ideas out later for discussion. In the mean time, no worries, it's not my intent to flame or shoot down anyone's approach to info.
BTW, I'm considering keeping compatiblity with mkv tags, so transcoding is easy... Just the names of the fields, they use all caps and underscores (TITLE, CHAPTER_ID, whatever)
I doubt anyone will remux between nut and mkv.. and all other formats require different names anyway (or don't use names at all). IMO the all-caps is yet another ugly WINDOWS-ism of mkv... Rich
On Sun, Feb 19, 2006 at 02:13:10PM -0500, Rich Felker wrote:
On Sun, Feb 19, 2006 at 08:45:01PM +0200, Oded Shimon wrote:
Anyway, I have no particular position for or against Michael's particular implementation ideas on info. However, here are a few things I would prefer...
- Let's not use the same key more than once with different values in the same context (same stream/chapter/timeinterval). I fear this will be confusing to players.
You mean, if I have 'director' set to the entire file, i can't use 'director' again as a subinfo for some stream?.. sounds ok with me...
No, i mean you can't put both Stream=1 and Stream=2 in the same packet.
This is already impossible because stream and chapter will be id in the begginning of the packet, and all packets which have these 2 values the same must be binary identical...
- If possible, I'd prefer that the demuxer not need to handle any of the semantics of info tags. But maybe this is a stupid requirement on my part.
Maybe I'll try throwing some ideas out later for discussion. In the mean time, no worries, it's not my intent to flame or shoot down anyone's approach to info.
BTW, I'm considering keeping compatiblity with mkv tags, so transcoding is easy... Just the names of the fields, they use all caps and underscores (TITLE, CHAPTER_ID, whatever)
I doubt anyone will remux between nut and mkv.. and all other formats require different names anyway (or don't use names at all). IMO the all-caps is yet another ugly WINDOWS-ism of mkv...
if nothing else, it has the advantage of players not needing another mapping table to go from info in containers into their own constructs.. - ods15
participants (4)
-
Ivan Kalvachev -
Michael Niedermayer -
Oded Shimon -
Rich Felker