[vlc-devel] Re: Design Query

[Gautam Morey]

Thank you very much Sigmund. You have really taken time out and
replied to my queries.
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.

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!!

> 
> > 
> > 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 !

> 
> 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.

> 
> -- 
> 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