[vlc-devel] Re: Design Query

[Sigmund Augdal]

On Thu, Apr 21, 2005 at 07:26:24PM +0530, Gautam Morey wrote:
> Thank you very much Sigmund. You have really taken time out and
> replied to my queries.
No problem, it didn't take me very much time.

> Though in the nature that this mail might become a good design FAQ
> reference I have added my new questions where they'll refer to the
> correct context.
That is generally good practice on public mailing lists and discussion
forums, reguardless of FAQ-potential.

> 
> On 4/20/05, Sigmund Augdal <sigmunau at stud.ntnu.no> wrote:
> > On Wed, Apr 20, 2005 at 07:42:38PM +0530, Gautam Morey wrote:
> > > Hi ,
> > > 
> > > I was just going through VLC's design structure and had this nagging
> > question:
> > > 
> > > Why does one need to write a special demux for mpeg audio or video ,
> > > mp4 audio and video rather than having it under the demux for PS or TS
> > > . After all if mp3 is an MPEG standard and if you are reading from a
> > > file , doesn't the demuxer for a PS stream become a direct
> > > hierarchical choice ?
> > These special demuxers are for es streams. That is audio or video streams
> > with no system wrapper.
> > 
> > > 
> > > Also what happens then if I have mp3 in a TS stream ? Does it call the
> > > mpga demux ? If it does then after having realised that it's an mp3
> > > stream ,which ASFIK is a logic implemented in ps.c and ts.c why go
> > > through all the redundancy again of checking for stream headers (ie
> > > according to mpga.c ) ?
> > It does not. The codec data are fed directly from the PS or TS demux to the
> > decoder.
> > 
> Well then should'nt the function tasks just before they write data to
> the decoder fifio be identical to the demuxer in mpga.c ? After all
> the decoder is agnostic to where the data is coming from. The
> redundancy still exists doesn't it? Of course if you know madlib well
> ... it does the same parsing at its own level again!!
I do not know this special case in particular, but generally speaking, the
reduncancy is neglectable. How to get a good packet of codec data to feed to
the decoder may depend very much on the structure of the file format, or
whatever the demuxer is reading from. As an example consider mp3 streaming
in rtp. The demuxer (in a bit of a wide interpretation of that word)
receives a rtp packet, it checks the appropriate field in the header to
select which codec it is, sets up a es_format_t stuct for the stream, calles
some es_out_ functions to initialize the decoder, then skips the rest of the
rtp header and feeds all remaining data to the decoder. Other demuxers might
work similarly depending on how the corresponding file format is built up.
If the special case of mp3 in ps requires you to parse through the stream
looking for frame borders etc, then that might introduce some redundancy in
the code, but I doubt it is much. Vlc has packetizer module to handle that.
What madlib does internally is of little interrest to vlc (and I don't know
madlib at all, so I can't elaborate)
> 
> > 
> > > 
> > > Also another interesting thing... I removed the file extension off an
> > > ogg file and put a debug print in the mpga.c file . It so conforms
> > > that vlc calls the mpga demux first and at some level when it gets a
> > > return error decides to try out other available demuxes finally
> > > finding ogg!
> > > Could someone explain this to me please. How viable is doing the
> > > stream type confirmation on the input side itself rather than after a
> > > demux has been deployed .
> > In vlc a module is not "deployed" before the Open function returns success.
> > The stream type detection could have been done by the imput layer, but that
> > would have been much less flexible (you could for isntance not add a new
> > demuxer plugin to an existing vlc then), less elegant, and harder to
> > maintain. In vlc a module is selected by trying all modules with the same
> > capability, in order of their score. First one to return success is
> > selected. (It is possible to force a module, or to alter the order in which
> > they are tried, but this is the main idea).
> > 
> > > 
> > > It would also be of immense help if someone can direct me to VLC's
> > > demux level design and whether its output for all the decoder modules
> > > that follow is the same?
> > I do not understand this question, and I belive it is too general. Take a
> > peek at the existing demuxers, and ask again if there is something you
> > don't
> > understand.
> 
> There is a radical difference in the input / demuxing logic between
> the current and last released version of VLC. This difference at the
> documentation level exists only as a log mesage I found in the current
> release. I use both versions of vlc to study and the older version
> works just as fine so then what lead to the design revisit ? Regulars
> to the forum might want me to refer to archives but then there has
> been little luck due to incorrect subject headings making me miss out
> on the real thing !
Do you mean 0.8.1 and 0.8.0? You are think of the demux to demux2
transition? If so, the motivation for that was mainly to better support
cases where the previous architechure was too limiting, like for rtp
streaming with each codecs data being sent to a different port. 

> 
> > 
> > at the end: Mind telling us what you plan to work on?
> 
> hey nothing to worry on that front. I am not forking another player !!
> I just found google returning too many links to vlc to almost all of
> my queries related to streaming / ps / ts / demuxing during the course
> of a stream analyzer design !! So I thought it to be a good case study
> for anything to do with digital media. I plan to produce a document
> that covers the working of VLC atleast to the extent that I have
> studied it soon.
I was not worried, more curious. also, if you were working on implementing a
demuxer (which it sounded like to me),  then it would have been good to
know, so that no one else started working on the same task. I'm looking
forward to your document, it might become a good start for a area of vlc
documentation that is largly missing at the moment.

Sigmund
---
Sigmund Augdal
Edgar B. Schieldropsv 29-14
N-7033 Trondheim
Norway
tlf: 91809129

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html