From insomnia@core.binghamton.edu Tue, 7 Dec 1999 20:32:51 -0500 (EST)
Date: Tue, 7 Dec 1999 20:32:51 -0500 (EST)
From: Stea Greene insomnia@core.binghamton.edu
Subject: [Livid-dev] LiVid status and future.
About a year ago, I got involved in the loosely organized
development of ATI drivers, and found that despite my interest in the
low-level aspects of the project, what was really needed was someone to
basically coordinate the project full-time. Once I decided to do that, I
believe GATOS turned out quite well (I made some mistakes, but that's what
we call a learning experience).
I'm thinking that might be the exact situation I'm encountering
here. We seem to have a lot of things going on at once, and no firm idea
of where we want to go. Personally I see GATOS, LSDVD and LiVid merging -
at which point I'd like to keep doing what I am doing for the whole
project as opposed to GATOS alone. There seems to be more than enough
knowledge and ability in this group.
This is in no way meant as any offense to anyone here who is
trying to do this already. Generally the biggest problem with
coordinating a project this large is the fact that the coordinator really
can't get into the details, and if he/she does, less time is spent on
coordination and things fall apart.
Note: I'm not suggesting that I RUN the project, just coordinate
it. I'd keep track of who is doing what, forward questions and bug
reports to whoever needs them (or maintain the bug tracker...), handle
documentation, tell people who want to help what they can do, etc.... I
wouldn't decide where the project is going, I'd just help everyone figure
it out and put things down in writing as we come to decisions.
Is this what is needed? Anyone have any comments/flames?
--Insomnia (Stea Greene)
From pvolcko@concentric.net Tue, 7 Dec 1999 20:56:41 -0500 (EST)
Date: Tue, 7 Dec 1999 20:56:41 -0500 (EST)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] LiVid status and future.
> About a year ago, I got involved in the loosely organized
> development of ATI drivers, and found that despite my interest in the
> low-level aspects of the project, what was really needed was someone to
> basically coordinate the project full-time. Once I decided to do that, I
> believe GATOS turned out quite well (I made some mistakes, but that's what
> we call a learning experience).
> I'm thinking that might be the exact situation I'm encountering
> here. We seem to have a lot of things going on at once, and no firm idea
> of where we want to go. Personally I see GATOS, LSDVD and LiVid merging -
> at which point I'd like to keep doing what I am doing for the whole
> project as opposed to GATOS alone. There seems to be more than enough
> knowledge and ability in this group.
>
> This is in no way meant as any offense to anyone here who is
> trying to do this already. Generally the biggest problem with
> coordinating a project this large is the fact that the coordinator really
> can't get into the details, and if he/she does, less time is spent on
> coordination and things fall apart.
>
> Note: I'm not suggesting that I RUN the project, just coordinate
> it. I'd keep track of who is doing what, forward questions and bug
> reports to whoever needs them (or maintain the bug tracker...), handle
> documentation, tell people who want to help what they can do, etc.... I
> wouldn't decide where the project is going, I'd just help everyone figure
> it out and put things down in writing as we come to decisions.
>
> Is this what is needed? Anyone have any comments/flames?
>
> --Insomnia (Stea Greene)
I'm not so sure I see the projects merging so much as I see them providing
different parts to the larger puzzle.
Livid will probably end up providing CSS, Matrox drivers, and a open sourced
navigation implementation, as well as mpeg-2 and ac-3 decoding in
software. That is a lot of stuff and I'm not so sure it can all really be
considered part of livid, but we'll look at it as such for now.
I'm not familiar with GATOS, have to read up, any links to important
information would be appreciated. (or even an email detailing the goals)
LSDVD started out wanting to release everything open source, but quickly found
out we couldn't without legal hassles (mainly because most to the members have
seen the specs and thus have tarnished our ability to help in the livid
pursuits to any great degree). Then we looked into incorporating and trying
to release something under a business situation. No dice so far on that. So
now we are going to concentrate more on the framework stuff and integrating
all the parts together. We're also going to be working on a Nav
implementation that will probably never be seen except in demos or
something. We've also been planning on doing a mpeg-2 decoder for a while,
but depending on the quality of the next crop to come out from Nathan laredo
(sorry if I misspelled that) and Aaron, we may forgo that.
So I don't really see things merging so much as just working together (as
seperate entities) to meet a common goal (hopefully that of the framework).
There will be need for some top level guidance as this is a largish
undertaking.
I'll leave it there and see what gets said from here. :)
Flame on!
Paul Volcko
LSDVD
From aholtzma@ess4.engr.UVic.CA Tue, 7 Dec 1999 18:09:12 -0800
Date: Tue, 7 Dec 1999 18:09:12 -0800
From: Aaron Holtzman aholtzma@ess4.engr.UVic.CA
Subject: [Livid-dev] LiVid status and future.
It would seem that Stea Greene (insomnia@core.binghamton.edu) said:
*snip*
> Note: I'm not suggesting that I RUN the project, just coordinate
> it. I'd keep track of who is doing what, forward questions and bug
> reports to whoever needs them (or maintain the bug tracker...), handle
> documentation, tell people who want to help what they can do, etc.... I
> wouldn't decide where the project is going, I'd just help everyone figure
> it out and put things down in writing as we come to decisions.
>
> Is this what is needed? Anyone have any comments/flames?
No one is going to complain if you volunteer to do a bunch of tedious
work :) The question is what is the "goal" of the livid-dev mailing
list? I think the goal for most is a functional DVD player, whether
it be hardware or software. The road there is a long one though, and
we just pulled onto the on ramp.
I think it's dangerous to wander down the path of the uber-media
player. Quite a few people have tried, and quite a few have been
bogged down in "stuff". We don't need anymore distractions. If
there are people interested in doing such a thing, the ethereal
dvd_player app should be modular enough to pick out the parts you
want and run with them.
The lack of perceived goal or organization is also due to the
fact that a lot of the architectural discussions tend to happen
off list. There are also a lot of things still left up in the air,
because I think we lack the skills to make the right decision
until we've played around with working code a bit. What's the
point of defining an API until you fully understand the issues?
Anyways, here are the deliverables needed to integrate a fully
functional dvd player application:
1. software MPEG-2 video codec
2. software AC3 audio codec
3. subpicture decoding module
4. ifo parsing module
5. css module
6. demux/buffer module
6. navigation module
Now whether these boxes are best hooked up via threads, callbacks,
sockets, or duct tape is irrelevant right now because we
don't even have the parts yet. Most of the parts are only about
%20-%30 done with the exception of #2.
Alright, it's action item time :) What we need is a list of
TODOs for each module on the webpage. That way interested hackers
can find out what needs doing without having to read three months
of list archives.
Alright, I'll shut up now.
cheers,
aaron
From insomnia@core.binghamton.edu Tue, 7 Dec 1999 22:08:09 -0500 (EST)
Date: Tue, 7 Dec 1999 22:08:09 -0500 (EST)
From: Stea Greene insomnia@core.binghamton.edu
Subject: [Livid-dev] LiVid status and future.
On Tue, 7 Dec 1999 pvolcko@concentric.net wrote:
> I'm not so sure I see the projects merging so much as I see them providing
> different parts to the larger puzzle.
>
Exactly, this is what I meant by merging.
> Livid will probably end up providing CSS, Matrox drivers, and a open sourced
> navigation implementation, as well as mpeg-2 and ac-3 decoding in
> software. That is a lot of stuff and I'm not so sure it can all really be
> considered part of livid, but we'll look at it as such for now.
>
I think we should first decide how to modularize it, than split up
the work to whoever wants it and go from there.
> I'm not familiar with GATOS, have to read up, any links to important
> information would be appreciated. (or even an email detailing the goals)
>
http://www.core.binghamton.edu/~insomnia/gatos
It's GPL'ed ATI-TV for unix.
> LSDVD started out wanting to release everything open source, but
> quickly found out we couldn't without legal hassles (mainly because
> most to the members have seen the specs and thus have tarnished our
> ability to help in the livid pursuits to any great degree). Then we
> looked into incorporating and trying to release something under a
> business situation. No dice so far on that. So now we are going to
> concentrate more on the framework stuff and integrating all the parts
> together. We're also going to be working on a Nav implementation that
> will probably never be seen except in demos or something. We've also
> been planning on doing a mpeg-2 decoder for a while, but depending on
> the quality of the next crop to come out from Nathan laredo (sorry if
> I misspelled that) and Aaron, we may forgo that.
>
Well, I think with the tools LiVid has on CVS now (do any of them
have such legal issues?) we can still pull off a free solution, except for
a few proprietary codecs. It'd be really cool if we could utilize xanim
modules....
> So I don't really see things merging so much as just working together (as
> seperate entities) to meet a common goal (hopefully that of the framework).
> There will be need for some top level guidance as this is a largish
> undertaking.
>
Exactly. I think the main thing I'd be doing is keeping track of
the design of the framework.
> I'll leave it there and see what gets said from here. :)
>
I'm interested as well, let's hear it!
--Insomnia (Stea Greene)
From insomnia@core.binghamton.edu Tue, 7 Dec 1999 22:14:13 -0500 (EST)
Date: Tue, 7 Dec 1999 22:14:13 -0500 (EST)
From: Stea Greene insomnia@core.binghamton.edu
Subject: [Livid-dev] LiVid status and future.
On Tue, 7 Dec 1999, Aaron Holtzman wrote:
> No one is going to complain if you volunteer to do a bunch of tedious
> work :)
>
That's what I figured.
> The question is what is the "goal" of the livid-dev mailing list?
>
Yes, it is.
> I think the goal for most is a functional DVD player, whether it be
> hardware or software. The road there is a long one though, and we just
> pulled onto the on ramp.
>
True. I think that this goal will be only slightly hampered by a
certain standard modularization, while other groups with other goals can
use what we end up with to help with their goals.
> I think it's dangerous to wander down the path of the uber-media
> player. Quite a few people have tried, and quite a few have been
> bogged down in "stuff". We don't need anymore distractions.
>
These distractions would all be my job to take care of. Those
interested in DVD need only concern themselves with the relevant parts,
except when working on interfacing issues.
> If there are people interested in doing such a thing, the ethereal
> dvd_player app should be modular enough to pick out the parts you want
> and run with them.
>
I agree.
> The lack of perceived goal or organization is also due to the fact
> that a lot of the architectural discussions tend to happen off list.
> There are also a lot of things still left up in the air, because I
> think we lack the skills to make the right decision until we've played
> around with working code a bit. What's the point of defining an API
> until you fully understand the issues?
>
True. One thing I learned from GATOS is that we have to be
willing to screw with the API until we really know all about what we are
doing, THEN you work on standardizing it. BUT! It is important to keep
things modular and simple on the way in, even if it slightly hampers
performance of the temporary products.
> Anyways, here are the deliverables needed to integrate a fully
> functional dvd player application:
>
> 1. software MPEG-2 video codec
> 2. software AC3 audio codec
> 3. subpicture decoding module
> 4. ifo parsing module
> 5. css module
> 6. demux/buffer module
> 6. navigation module
>
> Now whether these boxes are best hooked up via threads, callbacks,
> sockets, or duct tape is irrelevant right now because we
> don't even have the parts yet. Most of the parts are only about
> %20-%30 done with the exception of #2.
>
Cool. What I am saying is we should define how we want them to
work together, THEN we can individually work on each part and we won't
have to worry about the other pieces.
> Alright, it's action item time :) What we need is a list of
> TODOs for each module on the webpage. That way interested hackers
> can find out what needs doing without having to read three months
> of list archives.
>
That's (one of the things) I want to collect and keep track of.
--Insomnia (Stea Greene)
From aholtzma@ess4.engr.UVic.CA Tue, 7 Dec 1999 19:26:38 -0800
Date: Tue, 7 Dec 1999 19:26:38 -0800
From: Aaron Holtzman aholtzma@ess4.engr.UVic.CA
Subject: [Livid-dev] LiVid status and future.
It would seem that Stea Greene (insomnia@core.binghamton.edu) said:
> These distractions would all be my job to take care of. Those
> interested in DVD need only concern themselves with the relevant parts,
> except when working on interfacing issues.
I think you underestimate how much effort it is to design the
uber media player, and how orthogonal it is to producing a dvd player.
> Cool. What I am saying is we should define how we want them to
> work together, THEN we can individually work on each part and we won't
> have to worry about the other pieces.
But my point is we don't know how we want the pieces to work together
precisely. We know in general terms, but until we can put them
in a bag and shake them, we're guessing.
> That's (one of the things) I want to collect and keep track of.
Cool. You can start with the TODO list in the mpeg2dec README :)
cheers,
aaron
From scarabaeus@convergence.de Wed, 08 Dec 1999 12:52:04 +0100
Date: Wed, 08 Dec 1999 12:52:04 +0100
From: Christian Wolff scarabaeus@convergence.de
Subject: [Livid-dev] LiVid status and future.
Aaron Holtzman wrote:
> I think it's dangerous to wander down the path of the uber-media
> player. Quite a few people have tried, and quite a few have been
> bogged down in "stuff". We don't need anymore distractions. If
> there are people interested in doing such a thing, the ethereal
> dvd_player app should be modular enough to pick out the parts you
> want and run with them.
Agree. We should build an architecture, that allows the playback of
DVD's and other MPEG streams, but not much more.
> Anyways, here are the deliverables needed to integrate a fully
> functional dvd player application:
> =
> 1. software MPEG-2 video codec
> 2. software AC3 audio codec
> 3. subpicture decoding module
> 4. ifo parsing module
> 5. css module
> 6. demux/buffer module
> 6. navigation module
OK, here's my attempt:
+--------------------------------+
| Media access to Disc or Files | (translates files to
+--------------------------------+ blocks, if neccessary)
|
+--------------------------------+ +--------------+
| Navigator and IFO parser |<----| User action |
| (and demux for BB,BF: PCI/DSI) | | and GUI |
+--------------------------------+ +--------------+
| | |
+---------------+ +-----------+ |
| Stream demux | | CSS auth. | |
+---------------+ +-----------+ |
| | | | | | Decoder control
+---------------+ | |
| CSS decode |<------+ |
+---------------+ V
| | | |E0 +--------------------+ +---------+
| | | +-->| MPEG video decoder |-->| Display |
| | | +--------------------+ | +---------+
| | | BD +--------------------+ |
| | +-------| SPU decoder |-+
| | C0-C7 +--------------------+
| | D0-D7 +--------------------+ +-------+
| +-----------| MPEG audio decoder |-->| Sound |
| +--------------------+ | +-------+
| BD +--------------------+ |
+---------------| AC3/LPCM decoder |-+
+--------------------+
Voil=E1! The 2 digit hex numbers are the startcodes of the resp. streams.=
> Now whether these boxes are best hooked up via threads, callbacks,
> sockets, or duct tape is irrelevant right now because we
> don't even have the parts yet. Most of the parts are only about
> %20-%30 done with the exception of #2.
Yep! We have a bunch of definitions (API's and Standards), but we need
to agree to an overall framework. Only then we can keep the parts
interchangable, like using a software instead of hardware MPEG decoder.
I already did a great deal on some parts of this framework (usual URL, ht=
tp://linuxtv.org/dvd/).
> Alright, it's action item time :) What we need is a list of
> TODOs for each module on the webpage. That way interested hackers
> can find out what needs doing without having to read three months
> of list archives.
Not to forget the interfaces between the modules.
So, can we all agree on one concept here?
-- =
Christian Wolff *196807101035 53=B08'2" N 8=B013'20" E
http://www.scarabaeus.org/ mailto:scarabaeus@scarabaeus.org
check out http://betalounge.com/ http://www.convergence.de
+49-30-4473 6926, Norwegerstr. 5.1, D-10439 Berlin, Germany
PGP Fingerprint:B871 358C 3F10 A5ED C41C B1DB B9F9 3C44/2048
From adq@tardis.ed.ac.uk Wed, 8 Dec 1999 13:40:25 GMT
Date: Wed, 8 Dec 1999 13:40:25 GMT
From: Andrew De Quincey adq@tardis.ed.ac.uk
Subject: Re[2]: [Livid-dev] LiVid status and future.
[snip]
CW> +--------------------------------+
CW> | Media access to Disc or Files | (translates files to
CW> +--------------------------------+ blocks, if neccessary)
CW> |
CW> +--------------------------------+ +--------------+
CW> | Navigator and IFO parser |<----| User action |
CW> | (and demux for BB,BF: PCI/DSI) | | and GUI |
CW> +--------------------------------+ +--------------+
CW> | | |
CW> +---------------+ +-----------+ |
CW> | Stream demux | | CSS auth. | |
CW> +---------------+ +-----------+ |
CW> | | | | | | Decoder control
CW> +---------------+ | |
CW> | CSS decode |<------+ |
CW> +---------------+ V
CW> | | | |E0 +--------------------+ +---------+
CW> | | | +-->| MPEG video decoder |-->| Display |
CW> | | | +--------------------+ | +---------+
CW> | | | BD +--------------------+ |
CW> | | +-------| SPU decoder |-+
CW> | | C0-C7 +--------------------+
CW> | | D0-D7 +--------------------+ +-------+
CW> | +-----------| MPEG audio decoder |-->| Sound |
CW> | +--------------------+ | +-------+
CW> | BD +--------------------+ |
CW> +---------------| AC3/LPCM decoder |-+
CW> +--------------------+
Just to make sure, I take it the Navigator and IFO parser's interface
would be flexible enough to allow it to be plugged on to different
MPEG decoding systems (e.g. hardware cards which do all the VOB
demux/CSS for you)
Remember that different cards/software players would need some
card-specific initalisation, and also need some small GUI interfaces
for configuring specific parameters... You could have an architecture
which allowed these device specific modules to be loaded dynamically
quite easily, so people don't have to hack about with the core sources
to everything just to support a new card.
Another thing is that a card might not do AC-3 decoding onboard, but
could output AC-3 through an SP-DIF, or even have an analogue output
for AC-3 which has been decoded and downmixed to 2-channel stereo
by the CPU. All the lower level modules would have to be very flexible
to allow this sort of thing.
Again, with CSS, you might get some cards which only decode certain
streams, but which can do CSS onboard for those streams as well.. It
would be a waste to do the CSS in software for these, when they can do
it themselves.
--
adq
From scarabaeus@convergence.de Wed, 08 Dec 1999 18:16:34 +0100
Date: Wed, 08 Dec 1999 18:16:34 +0100
From: Christian Wolff scarabaeus@convergence.de
Subject: [Livid-dev] Overall Framework
This is a multi-part message in MIME format.
--------------715FF1EC58CB743EC4751F5B
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
So, here i start with a little outline of the current work from
convergence's side.
Andrew De Quincey wrote:
> Just to make sure, I take it the Navigator and IFO parser's interface
> would be flexible enough to allow it to be plugged on to different
> MPEG decoding systems (e.g. hardware cards which do all the VOB
> demux/CSS for you)
sure.
> Remember that different cards/software players would need some
> card-specific initalisation, and also need some small GUI interfaces
> for configuring specific parameters... You could have an architecture
> which allowed these device specific modules to be loaded dynamically
> quite easily, so people don't have to hack about with the core sources
> to everything just to support a new card.
Tricky. That's stuff, that doesn't belong in the DVDNavigator API. It
should rather be 2 separate API's from the GUI to the decoders and the
display/audio, right? Even though i doubt we need extra control to the
decoders, so only the GUI-to-display-control is relevant. I included it
in the diagram now.
The GUI-to-audio-control will basically be level control, right?
The GUI-to-display-control depends on the kind of display, either window
position and size for X-Windows, or brightness, contrast etc. for a
CVBS-output. Anything else?
> Another thing is that a card might not do AC-3 decoding onboard, but
> could output AC-3 through an SP-DIF, or even have an analogue output
> for AC-3 which has been decoded and downmixed to 2-channel stereo
> by the CPU. All the lower level modules would have to be very flexible
> to allow this sort of thing.
Yes, my DecoderAPI lacks capability query support, still. I'll include
that as soon as possible.
> Again, with CSS, you might get some cards which only decode certain
> streams, but which can do CSS onboard for those streams as well.. It
> would be a waste to do the CSS in software for these, when they can do
> it themselves.
Yes, i took that into account here. For hardware CSS, everything below
the Navigator/GUI would be in the card and not separately available.
That's how it works with the LSI 64021 chip i'm developing on. I have no
information on the new sigma chipset, yet. It should be on a similar leve=
l.
+--------------------------------+
| Media access to Disc or Files | (translates files to
+--------------------------------+ blocks, if necessary)
|
+--------------------------------+ +--------------+
| DVD Navigator and IFO parser |<----| User action |
| (and demux for BB,BF: PCI/DSI) | | and GUI |
+--------------------------------+ +--------------+
| | | | |
+---------------+ +-----------+ | | |
| Stream demux | | CSS auth. | +---------+ | display
+---------------+ +-----------+ | | and sound
| | | | | | Decoder | control
+---------------+ | | control |
| CSS decode |<------+ | |
+---------------+ V V
| | | |E0 +--------------------+ +---------+
| | | +-->| MPEG video decoder |-->| Display |
| | | +--------------------+ | +---------+
| | | BD +--------------------+ |
| | +-------| SPU decoder |-+
| | C0-C7 +--------------------+
| | D0-D7 +--------------------+ +-------+
| +-----------| MPEG audio decoder |-->| Sound |
| +--------------------+ | +-------+
| BD +--------------------+ |
+---------------| AC3/LPCM decoder |-+
+--------------------+
OK, status on the modules from my side so far:
The media access module i've already published. =
http://linuxtv.org/dvd/#software
It allows the access to a DVD without mounting it into the file system
(this allows CSS, too), or access to a UDF-mounted DVD, or to a full
VIDEO_TS directory copied onto another file system.
The DVD-Navigator is basically finished, but i can't say anything about
a release date, yet. Company internals... Anyhow, we will NOT be able to
release source code due to the NDA of the DVD Forum. We will have to
release it as a linkable object file. Sigh.
The GUI is something where a lot of work can be done by excited
programmers. ;-) It is basically a "skin" for the DVD Navigator. My
version i use for debugging is a rather dull text console interface,
since i'm editing my files in bb-edit and do everything on the unix box
in a shell from mac-os. I'm too embarrassed to publish that piece of
"work" of mine. The API used is the "LinuxDVDPlayerNavigatorAPI" (or
somethin' like that) as published here:
http://linuxtv.org/dvd/api/DVDPlayerAPI.h
Decoder/DeMux/CSS: All this is done in hardware by our convergence card.
I made a little wrapper, that basically calls the relevant ioctls of the
decoder card's device driver. (see
http://linuxtv.org/dvd/api/cvdvtypes.h) This is, i think, a good
interface for accessing the rest of the decoding process from the
DVD-Navigator. I have some minor clean-ups to do, and then i will relase
the source. Instead of the decoder card you can hook up software CSS and
other MPEG/AC3-decoders into that header file.
Attached is the preliminary header file of my decoder wrapper.
I don't have an overview of the current software decoder development,
maybe someone can enlighten us?
Christian.
-- =
Christian Wolff *196807101035 53=B08'2" N 8=B013'20" E
http://www.scarabaeus.org/ mailto:scarabaeus@scarabaeus.org
check out http://betalounge.com/ http://www.convergence.de
+49-30-4473 6926, Norwegerstr. 5.1, D-10439 Berlin, Germany
PGP Fingerprint:B871 358C 3F10 A5ED C41C B1DB B9F9 3C44/2048
dvd_decoder.h
From aholtzma@ess4.engr.UVic.CA Wed, 8 Dec 1999 11:04:15 -0800
Date: Wed, 8 Dec 1999 11:04:15 -0800
From: Aaron Holtzman aholtzma@ess4.engr.UVic.CA
Subject: [Livid-dev] Overall Framework
It would seem that Christian Wolff (scarabaeus@convergence.de) said:
> I don't have an overview of the current software decoder development,
> maybe someone can enlighten us?
>
ac3dec status
- pretty much feature complete.
- undergoing work to librarify it and conseqently add
codec interface.
mpeg2dec status
- I-frame pictures work alright-ish.
- needs motion compensation and field picture work.
- needs assembly optimization for idct and motion compensation
(could probably be brought over from nist after de-nasming)
- also undergoing work to librarify
The only codec interface that we have defined so far, is that
the application registers a callaback that sets pointers to
new data for the codec to process.
eg. callback for a application simply reading a file from disk.
uint_32 buf[2048/4];
void fill_buffer(uint_32 **start,uint_32 **end)
{
uint_32 words_read;
words_read = fread(buf,4,2048/4,in_file);
*start = buf;
*end= buf + words_read;
}
Obviously we'll need some kind of synchronization if we
have concurrent demux/decode threads.
I can see integrating both codecs into the dvd_play framework
in the next week or so. We can then play around with the
synchronzation interface.
cheers,
aaron
From pvolcko@concentric.net Wed, 8 Dec 1999 17:42:29 -0500 (EST)
Date: Wed, 8 Dec 1999 17:42:29 -0500 (EST)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Overall Framework
> The only codec interface that we have defined so far, is that
> the application registers a callaback that sets pointers to
> new data for the codec to process.
>
> eg. callback for a application simply reading a file from disk.
>
> uint_32 buf[2048/4];
> void fill_buffer(uint_32 **start,uint_32 **end)
> {
> uint_32 words_read;
>
> words_read = fread(buf,4,2048/4,in_file);
>
> *start = buf;
> *end= buf + words_read;
> }
>
> Obviously we'll need some kind of synchronization if we
> have concurrent demux/decode threads.
>
> I can see integrating both codecs into the dvd_play framework
> in the next week or so. We can then play around with the
> synchronzation interface.
I agree 100% that the buffers should be their own entities so to speak, that
monitor themselves and ask for filling data. But the other side of the buffer
is also important to define. For instance, how is the data going to be
reported as used by the consumer?
Needed functions:
- Register Supplier Feed Function
- Register Consumer Eat Function
- Initialize Buffer
- Resize Buffer
- Report Buffer Level
- Flush Buffer
- Kill Buffer
As far as syncing goes am I correct in thinking that that is handled at the
decoder level and not at the buffer level (or perhaps at the decoder
buffer, which is different than the buffers described above)? If so, what is
the way that syncing is handled generally? The way I see it there are two
real solutions:
1) Stop the decoder that is getting ahead of the other until both are at the
same frame, within a tolerance of X frames. No one decoder has priority over
the others.
2) Define the decoders to have priority levels, the top level decoder defines
the "frame" to be decoded by all others, thus forcing them to either stop and
wait (if they are ahead) or request a buffer flush until the next cell (if
they are behind). Again, within a definable frame threshhold.
How is syncing being done now? In NIST? Is it any good (I haven't had a
chance to test it yet).
Paul Volcko
LSDVD
From aholtzma@ess4.engr.UVic.CA Wed, 8 Dec 1999 15:01:07 -0800
Date: Wed, 8 Dec 1999 15:01:07 -0800
From: Aaron Holtzman aholtzma@ess4.engr.UVic.CA
Subject: [Livid-dev] Overall Framework
It would seem that pvolcko@concentric.net (pvolcko@concentric.net) said:
> I agree 100% that the buffers should be their own entities so to speak, that
> monitor themselves and ask for filling data. But the other side of the buffer
> is also important to define. For instance, how is the data going to be
> reported as used by the consumer?
Whoa there. We don't care what the codec does with the data. Maybe
I chose a confusing function name. It should have been
point_the_codec_at_some_new_data(...). Once the codec asks for more
data, it's done with the current data.
> Needed functions:
> - Register Supplier Feed Function
> - Register Consumer Eat Function
> - Initialize Buffer
> - Resize Buffer
> - Report Buffer Level
> - Flush Buffer
> - Kill Buffer
This is all part of the buffer implementation and how it's used
by the "core". This also looks slightly more complicated than our
needs.
> As far as syncing goes am I correct in thinking that that is handled at the
> decoder level and not at the buffer level (or perhaps at the decoder
> buffer, which is different than the buffers described above)? If so, what is
> the way that syncing is handled generally? The way I see it there are two
> real solutions:
Sync is handled by the "core" (being the demux/buffer module). Codecs
know nothing about sync, other than decoding the frame nearest the
one requested.
cheers,
aaron
From andreas@andreas.org 08 Dec 1999 17:13:29 -0500
Date: 08 Dec 1999 17:13:29 -0500
From: Andreas Bogk andreas@andreas.org
Subject: [Livid-dev] LiVid status and future.
Stea Greene < insomnia@core.binghamton.edu> writes:
> Well, I think with the tools LiVid has on CVS now (do any of them
> have such legal issues?) we can still pull off a free solution, except for
The whole project is riddled with legal issues, unfortunately. We can
only hope for the industry being interested in people buying more
DVDs, rather than throwing stones into our direction.
MPEG and AC3 decoder licensing fees are only one issue.
Andreas
--
"We should be willing to look at the source code we produce not as the
end product of a more interesting process, but as an artifact in its
own right. It should look good stuck up on the wall."
-- http://www.ftech.net/~honeyg/progstone/progstone.html