Re: Extension to Skeleton for multi-track media

Silvia Pfeiffer wrote:
>> Why do you have to create an order? I cannot think of any programming task
>> that requires such an ordering.
> 
> An index is the easiest way to address a track lacking any other
> information. The serial number cannot be used for addressing, since it
> should not be exposed, will not work across chained streams, and
> nobody wants to deal with such long, meaningless numbers anyway.

I don't see any need for a defined ordering on the tracks.  A correctly
written script should not depend on the ordering at all, so there's no
need to specify it.

Also, BOS ordering won't work across chained streams, as the number of
tracks and their order may be different in different streams.  Heck, the
whole nature of the content can be completely different in different
streams.  Conversely, opaque identifiers like serial numbers _will_ work,
because each serial number clearly refers to a single track from a single
stream.

As for identifying objects by long, meaningless numbers ... that's what a
pointer is.  All objects in C and C++ are identified by these long,
meaningless numbers.  You can just treat them as opaque tokens, and
everything works fine.

>> Sure.  I guess I'm just nitpicking as to whether the location is a very
>> useful hint.  Are there other systems that provide such hints?
> 
> That is a good point. I did a bit of searching. I found MPEG hints at
> the possibility of using their parallel tracks for pip applications,
> but
> haven't specified it in the container. Thus, for example in HD DVDs,
> there were formats specified to allow such, e.g.
> http://blogs.msdn.com/ptorr/archive/2006/09/11/750124.aspx . They
> don't put that information into the media file, but into associated
> xml files. Seems to also exist in Bluray, but is known as "secondary
> video".

Yep, although that XML file doesn't seem to specify the display location,
which is what I was questioning.  Actually, I guess I'm warming up to the
idea, especially if the location hint is optional (i.e. "Display-hint: pip")

> OTOH, we could just call the video track for display as PiP a
> "video/secondary" or "video/alternate" and leave it to the player to
> decide to display it as PiP. Then this hint is  not necessary.

That's true, if you don't want the location hint.  I don't know what to do
about this anymore.

>>Can you point me a to media player other than a web browser that
>> can play statically-masked video?
> 
> QuickTime: http://docs.info.apple.com/article.html?artnum=42623&coll=cp

Huh.  That's very interesting, and certainly fits the bill.  I'm still of
the position that it's not a feature we can or should duplicate.  I'd
prefer to solve this problem by implementing a complete alpha channel
solution for video.

> Flash: http://www.adobe.com/designcenter/tutorials/fla8at_maskvideo/ -
> though it works a bit different with Flash

Yeah, the Flash case is more like the CSS approach.

>> Adding an alpha channel
>> to Theora would be possible, but the resulting tracks wouldn't play at all
>> in any current player; it would essentially be a different codec,
>> requiring new encoders and decoders.
> 
> ... unless Theora was to be extended with bits at the end that
> current players would ignore (if such was possible).

That would be nice.  I doubt it's possible, but I can't completely rule it
out.

_______________________________________________
theora-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/theora-dev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkuplVoACgkQUJT6e6HFtqQHFACfQGUP6eW7uqR3GJv2v6BnAKE2
gl0Ani4RlZWomlItRyOVTYIHb8/UOsca
=jeD0
-----END PGP SIGNATURE-----