[theora-dev] Support for layers and alpha channel?

[Dennis SCP]

Ralph Giles heeft op woensdag, 24 maa 2004 om 18:06 (Europe/Amsterdam) 
het volgende geschreven:
>
>> Underneath It All
>> Remember the No Doubt video where the singer straddles and orgasms and
>> blinks of screen (to that happy place:-) to quickly return back on
>> screen? Perhaps it would easier for the codec if she would be on a
>> layer that simply jumps behind the background layer. Perhaps even more
>> so if the motion in that layer can be frozen in time and continue when
>> it is brought back to the front.
>
> While this sort of thing would help compression in this particular 
> case, such sequences are rare
> and it's not worth adding special case support for them. What you're 
> describing is a non-linear
> transition between two streams. From a technical point of view, this 
> belongs at a level above the
> Ogg transport stream, which only supports linear media, in something 
> like a SMIL file
> (http://www.w3.org/AudioVideo/). If we supported 'blinks' to an 
> alternate stream, why not the much
> more common fade and dissolve? Then wipes, weaves, of course jump 
> cuts, and so on? In an efficient
> design these things are of a package.

Why not support the furniture wipes as seen in Home Improvement? :-)
Just like you don't need to ask if a color video codec supports water 
or fire effects, you don't need to ask what types of transitions are 
possible between a movie with alpha channel and its background (video). 
Both answers are any effect that is in the movie.

An alpha channel is created (automatically) in editing software like 
Apple Final Cut Pro, and more complex in Apple Shake.

As for a video codec:
1 Once you have synchronized video layers support
2 You get alpha channel support for free (because that is done by the 
player)
3 Once you have alpha channel support you have unlimited transition 
variety (because that is an inherent trait of alpha channel video)

An alpha channel is nothing more then a grey scale picture or frame 
which is used by the player as a transparency layer. White means 
transparent, black means solid and at 8 bit you have 256 steps to fool 
the eye into thinking that it is fluent.

You don't say in a video stream 'hard swipe transition left to right', 
no the alpha channel does that: the greyscale movie shows white filling 
the screen from left to right, revealing what is underneath (another 
movie, or scene, or the black background of the player, or the 
background of a desktop or a website). A completely white alpha channel 
means the movie is 100% transparent, you can stop streaming it. 
Actually you don't even have to clean up the mess, the video just can't 
be seen. It also means that if you use a 8 by 8 pixel coding, you don't 
care or code any information when any 8 by 8 pixel square has a white 
alpha channel.

You can also save some bandwidth because you don't have to stream or 
code what is 100% transparant and invisible.

Therefore it is important to have the codec support complete 
synchronisation between (at least) two video streams / frames; color 
video and its greyscale alpha video. You don't want a bright background 
color piercing through because the synchronisation is a frame off or 
the alpha video has white artifacts from encoding.

So I was wondering if this group is:
- working on and testing synchronous playback
- optimizing a grayscale movie encoding
- testing both in a alpha channel aware player

And if so is seeing any speed/space advantage in the examples I gave 
(which I agree some maybe implemented in the higher end of the complete 
multimedia package)

Greetings,
Dennis SCP
PS: the singer in the example would not move to the background (which 
maybe how I confused everybody) but would become 100% transparent 
because of the alpha channel video that would be part of the layer 
featuring the videorecording of the singer. Ther would be no actual 
transitions be made by the player, just playing multiple synced video 
streams.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.