[vlc-devel] Re: Design Query

[Gautam Morey]

Sorry Sigmund for having disappeared. Had been on vacation.

Some more queries :
Mplayer reads 2KB of data from the input irrespective of the nature of
the source whereas vlc has a default of 64KB per read call. Even after
this both work absolutely fine (even on network streams). Can this be
explained? who'll lose out when it comes to worst-case conditions
related to 1) Memory constraints as in embedded systems
    2) Bandwidth problems

Also a block_read call inside any demux allocates new memory on every
call if the 64K buffer has insufficient data after adjusting residue.
wouldn't it be more efficient to just reallocate the existing buffer
to the new size?

Thanks ,
Gautam


On 4/21/05, Sigmund Augdal <sigmunau at stud.ntnu.no> wrote:
> 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
> 
>

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