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