Vorbis dev - Nov 2000 - Re: I'd like to join the OVD project

On Mon, Nov 06, 2000 at 12:16:00PM -0700, Robert Scott Horning
wrote:
> "Sean R. Lynch" wrote:
> 
> > I was one of the original advocates of the project and I've
> > written a draft specification at
> > http://www.literati.org/~seanl/ovd.html that to my knowledge
> > is the only one in existence.  I'd like to work on some code
> > integrating the Fiasco video codec with Ogg and Vorbis, and
> > this seems like the right place to do it.
> 
> Sean,
> 
>     Thank you for your interest in OVD, and I'd like to spend a fair
> amount of time right now as we are heading into the Christmas holidays
> and it looks like I'm going to have a bit of a lull in my professional
> projects that I can actually spend some time working on OVD.  What we
> really need to get organized is the Source Forge web site
> (http://OVD.sourceforge.net)  If you have a source forge account, I'd
be
> willing to give you full administrator access to this site, so we can
> put some of these documents onto the account.  I'd like to get a little
> bit more activity going there, and at that point I think we could start
> getting the mailing list a little more active as well.
I'm definitely willing to work on the web site.  My username on sourceforge
is seanl.
> Here are my main points I want to get across as to WHY we want to do
> OVD:
[...] 
I agree with all these reasons, with the addition that most of the
work to accomodate different timing aspects (3:2 pulldown, speedups for
PAL) should be done by the decoder, with enough information given by the
encoder to handle these different systems.  The fact that DVDs are currently
PAL or NTSC specific is ridiculous, though it fits with region coding
(which I have no intention of allowing).

My other reason is exactly this:  I do not want another format for people
to release "controlled" content in.  If people release content in OVD
format, it should be with the intention that all fair use is OK and relying
only on regular copyright protections.

If you could look at http://www.literati.org/~seanl/ovd.html and let me
know how your ideas differ from what I have there, that would help a lot,
because I think that I've done a pretty good job with that page.
> I'm sure there are other aspects of OVD that could be fleshed out, but
> these are the principle items that are driving me to continue
> development of OVD.  I would like to encourage you to keep in touch, and
> let's see if we can get something put together.  I'd also like to
start
> development of a simple authoring system with a playback.
I'd like to see playback incorporated into OMS, and authoring included into
some existing system as well, possibly Broadcast 2000 if people are still
looking at that.
> In terms of format style, there are four basic general formats I'd like
> to consider for OVD:
> 
> A) MPEG data format style (with a unique byte code header that never
> shows up in data).  This is robust and proven.
This is fine.  I think Ogg is the bitstream format we should use.
> B) PNG data format style (contains basic headers to blocks of data, with
> testing block available.)  This isn't quite as robust for streaming
data
> where the integrity is suspect, and resyncing after a garbled frame can
> cause some problems.  There are some good features to this, however.
This (along with MNG) would make a good subpicture format as well.
Multiple layers of subpictures with transparency and animation should
accomodate a lot of things that have been done with DVD plus a bit more.
> C) XML data format style (plain text editable)  This has the added
> advantage that we can create content with a simple text editor (as
> opposed to a more complex hex-editor) and some debugging can be done
> simply by examining the file content.  Post-script is another example of
> something like this where the output is seldom actually looked at with a
> text editor, although it is possible.  The primary drawback to this
> format is that it isn't efficient with data storage, and has some
access
> requirement that may be unacceptable in a multi-media environment.
This is already incorporated into Ogg, and I think it would be good for
metadata.
> D) Object hierarchy style (A list of object in a hierarchy where details
> are listed with properties and child objects nested in the description)
> This is used in Visual Basic as well as Borland's Delphi compiler to
> store form information in the GUI description.  Both compilers also
> "tokenize" this information as a binary format, so the verbose
edit
> screens aren't necessarily stored in that fashion.  It should be
telling
> that Borland is going to a format more like XML, however, because of
> their recent move to Linux.
I believe this is something that has been mentioned for MPEG-7.  We should
definitely try to learn as much as we can from the MPEG group, taking stuff
where it makes sense and is free to take.
> I'm willing to investigate other data format styles, but these are ones
> that I'm familiar with and I've seen used to store multi-media data
> effectively.  My preference is to use the MPEG style format, but I'd
> like to get some more feed back before something like this is
> committed.  If you have a preference, I'd like to get something put
> together so we can display a couple simple rendered bitmap images with
> navigation buttons between "menu" pages by the end of the
American
> Thanksgiving Holiday (November 23rd-November 26th).  For static
> displays, I'd like to use the PNG data format (which is good
> compression, no patents, and code is already available) with additional
> information for menu navigation done in the OVD data format.  This is a
> big task, but I think it is possible to be done part-time by this
> deadline.  What do you think?
I'm not nearly as interested in navigation as I am in encoding the
video/audio itself.  However, I do think that it would make the most sense
to use something like javascript or scheme embedded in XML for this
purpose.  I think that we could easily work with the Ogg people to get
this done.


-- 
Sean R. Lynch KG6CVV <seanl@literati.org>  
http://www.literati.org/~seanl/
Finger for public key.  540F 19F2 C416 847F 4832  B346 9AF3 E455 6E73 B691



<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 241 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20001106/0b38ee5a/part-0001.obj

> > Here are my main points I want to get across as to WHY we want to do
> > OVD:
> [...] 
Hm, seems this is getting farther along...
> > In terms of format style, there are four basic general formats I'd
like
> > to consider for OVD:
> > 
> > A) MPEG data format style (with a unique byte code header that never
> > shows up in data).  This is robust and proven.
> 
> This is fine.  I think Ogg is the bitstream format we should use.
> 
> > B) PNG data format style (contains basic headers to blocks of data,
with
> > testing block available.)  This isn't quite as robust for
streaming data
> > where the integrity is suspect, and resyncing after a garbled frame
can
> > cause some problems.  There are some good features to this, however.
> 
> This (along with MNG) would make a good subpicture format as well.
> Multiple layers of subpictures with transparency and animation should
> accomodate a lot of things that have been done with DVD plus a bit more.
> 
> > C) XML data format style (plain text editable)  This has the added
> > advantage that we can create content with a simple text editor (as
> > opposed to a more complex hex-editor) and some debugging can be done
> > simply by examining the file content.  Post-script is another example
of
> > something like this where the output is seldom actually looked at with
a
> > text editor, although it is possible.  The primary drawback to this
> > format is that it isn't efficient with data storage, and has some
access
> > requirement that may be unacceptable in a multi-media environment.
> 
> This is already incorporated into Ogg, and I think it would be good for
> metadata.
Incorporated in concept.  Ogg is intended for all these things, but we
only have the transport-layer code at the moment.  We are yet to code
the XML stream type to be built on top of Ogg transport or the
meta-transport header (that serves as a table of contents for the
transport stream structure).

These things are major and important aspects of what we want to do,
but it seemed wise to warn you that parts of it are still vapor.
> > D) Object hierarchy style (A list of object in a hierarchy where
details
> > are listed with properties and child objects nested in the
description)
> > This is used in Visual Basic as well as Borland's Delphi compiler
to
> > store form information in the GUI description.  Both compilers also
> > "tokenize" this information as a binary format, so the
verbose edit
> > screens aren't necessarily stored in that fashion.  It should be
telling
> > that Borland is going to a format more like XML, however, because of
> > their recent move to Linux.
> 
> I believe this is something that has been mentioned for MPEG-7.  We should
> definitely try to learn as much as we can from the MPEG group, taking stuff
> where it makes sense and is free to take.
...And Ogg intends to use heirarchical, structured relationships
between individual logical streams as well. We'll be speccing this (as
part of meta-transport) in the next month or so; a good time to
leverage that foot you have in the door :-)

Monty

--- >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
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.