[Matroska-devel] Invitation to discuss about USF in MKV

[Christian HJ Wiesner]

Hi,

we decided to try to hold a brainstorming meeting to define how to store 
USF in MKV in the best possible way, the IRC meeting is taking place 
tomorrow on irc.corecodec.com #matroska-dev at saturday 21st May, 5 PM .

Requested Participants :

Mosu
Alexnoe
Unmei
Kaiousama
Haali

but everybody else is gladly invited to join and contribute. If any of 
the people listed above cant join then, please come up with an 
alternative date/time. To get an idea about what we will have to 
discuss, read here :



	

	ChrisHJW_ 	lo MosuAtWork

	ChrisHJW_ 	long time no see

	
	

	ChrisHJW_ 	unmei , MosuAtWork : 
http://corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=1259&start=15 
<http://corecodec.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=1259&start=15> 
<----- kaiousama knows how to make girls happy :D

	ChrisHJW_ 	Italians :)


	

	ChrisHJW_ 	lol

	ChrisHJW_ 	MosuAtWork : tell me when you are ready and have the time 
for a brainstorming with kaiousama and unmei about how to mux USF into 
MKV in best way, i will gladly try to organize an IRC meeting then

	ChrisHJW_ 	alexnoe said its not as easy as muxing SSA if we want to do 
it right

	ChrisHJW_ 	as USF will allow colour palette changes in a single stream

	ChrisHJW_ 	i understand that if we take the SSA route, we needed a 
codec state element, as colour palette is defined in the track header ??

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	this weekend should be 
fine, but not sunday evening, i'll be watching the sith ;)

	alexnoe <irc://127.0.0.1/alexnoe,isnick> 	:)

	ChrisHJW_ 	MosuAtWork : great :)

	robUx4 <irc://127.0.0.1/robux4,isnick> 	is going to watch it tonight

	ChrisHJW_ 	I'll send an email to -general , cc. to kaiousama and unmei, 
to meet saturday afternnon ?

	ChrisHJW_ 	robUx4 : you wonna join ?

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	well CodecState has 
been added for such changes mid-stream. we just have to revive it

	robUx4 <irc://127.0.0.1/robux4,isnick> 	nop

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	and start using it

	robUx4 <irc://127.0.0.1/robux4,isnick> 	I'm leaving to LA on tuesday so 
I'm quite busy here

	alexnoe <irc://127.0.0.1/alexnoe,isnick> 	codec state is b0rked

<irc://127.0.0.1/alexnoe,isnick>
	

	ChrisHJW_ 	MosuAtWork : i agree, a spec conformant way to do this would 
be to use codec state

	ChrisHJW_ 	robUx4 : k

	robUx4 <irc://127.0.0.1/robux4,isnick> 	codec state is meant for the 
container to know about things needed for seeking

	robUx4 <irc://127.0.0.1/robux4,isnick> 	but from what I understood it 
may not be needed for USF

	ChrisHJW_ 	robUx4 : right, for colour palette only the container 
wouldnt need to know and we could define this in the USF stream, but 
what about allowing resolution changes also ?

	robUx4 <irc://127.0.0.1/robux4,isnick> 	matroska does not support 
resolution change

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	it's not resolution change

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	it's out-of-band 
configuration change

	ChrisHJW_ 	robUx4 : in any case, if we leave colour palette in the USF 
stream, should we also add it to the track header then ( the 'initial' 
palette ), or leave it away completely ?

	robUx4 <irc://127.0.0.1/robux4,isnick> 	kaiousama and unmei can tell 
better

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	robUx4: at the moment 
the description of codecstate seems to be just fine

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	for this purpose

	ChrisHJW_ 	MosuAtWork : can we handle codec state on DirectShow ?

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	no clue

	robUx4 <irc://127.0.0.1/robux4,isnick> 	ok

	ChrisHJW_ 	maybe Haali could tell

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	Haali will have to 
comment on that

	ChrisHJW_ 	alexnoe : why is codec state b0rked ?


	

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	Haali will have to 
comment on that

	ChrisHJW_ 	alexnoe : why is codec state b0rked ?

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	but the container 
should be more or less indedependant of the OS APIs ;)

	robUx4 <irc://127.0.0.1/robux4,isnick> 	so we need to handle the codec 
state in the cue as originally planned

	alexnoe <irc://127.0.0.1/alexnoe,isnick> 	ChrisHJW_ because it makes 
remuxing b0rked

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	robUx4: it HAS to! 
otherwise the decoder won't have the current information after seeking

	robUx4 <irc://127.0.0.1/robux4,isnick> 	alexnoe, nop

	MosuAtWork <irc://127.0.0.1/mosuatwork,isnick> 	alexnoe: why should it?

	robUx4 <irc://127.0.0.1/robux4,isnick> 	yup, that's my idea

	ChrisHJW_ 	alexnoe : USF cant be used in any other container than MKV 
yet, so why should we care ?

	alexnoe <irc://127.0.0.1/alexnoe,isnick> 	it would allow to join 
incompatible streams into one segment, making it necessary to create new 
codecstates...

	robUx4 <irc://127.0.0.1/robux4,isnick> 	alexnoe, it's not much 
different than block addition

	alexnoe <irc://127.0.0.1/alexnoe,isnick> 	:(

	robUx4 <irc://127.0.0.1/robux4,isnick> 	only the meaning is different

	robUx4 <irc://127.0.0.1/robux4,isnick> 	and the occurence

	ChrisHJW_ 	Hmmm .... somehow i wonder if using codec state would mean 
we have reinitialize the stream on DShow ?

	ChrisHJW_ 	codec state is read and used by the parser, right ?

	ChrisHJW_ 	only alternative i see is to create another API sitting on 
top of DShow, with USF decoder and MKV parser communicating directly

	ChrisHJW_ 	like what Toff did with Gabest's splitter, to read out track 
header

	robUx4 <irc://127.0.0.1/robux4,isnick> 	you pass the codec state each 
time with the codec data

	robUx4 <irc://127.0.0.1/robux4,isnick> 	or only when needed, as an 
optional field in a structure (maybe EBML like)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20050520/f37c36d6/attachment.html>