[MPlayer-dev-eng] Re: A minor patch to the RTP streaming code

[Arpi]

Hi,

> > > -       // Map known video MIME types to the format code that this prog 
> > uses:
> > > +       // Map known video MIME types to the BITMAPINFOHEADER parameters
> > > +       // that this program uses.  (Note that not all types need all
> > > +       // of the parameters to be set.)
> >
> >you should fill every field of BITMAPINFOHEADER, but at least width, height,
> >set depth to 24, planes to 1, imagesize to 3*width*height
> 
> Trouble is, for RTP streams, we don't (in general) know what the width and 
> hight are going to be, until we start receiving data.  (That information is 
true for mpeg, but this is available in headers in case of .asf, .rm or .mov
of course i need it only for codecs requires header, like mjpeg
(actually mjpeg caries w/h in the stream too, but to decide
interlaced/fullframe mode you need the full w/h from teh header)

> present only in the stream itself.)  Ditto for "frames per second".  If 
yes, i also need fps _or_ exact timestamps

> "mplayer" requires that this information be filled in ahead of time, then 
> that's a design flaw.  In reality, aren't these fields needed only for 
> video codecs for which this information is not carried in-band?  (Are there 
> any such codecs?)
most codecs are such, exept the mpeg 1/2/4 and h263

> > >         if (strcmp(subsession->codecName(), "MPA") == 0 ||
> > >             strcmp(subsession->codecName(), "MPA-ROBUST") == 0 ||
> > >             strcmp(subsession->codecName(), "X-MP3-DRAFT-00") == 0) {
> > > -         sh_audio->format = 0x50;
> > > +         wf->wFormatTag = sh_audio->format = 0x50;
> > > +         wf->nSamplesPerSec = 0; // sample rate is deduced from the data
> >
> >0x50 is mpeg audio layer 1/2
> >0x55 is mp3 aka mpeg audio layer-3
> 
> Once again, until we start receiving data, we don't know whether it's layer 
> I, II, or III until we start receiving data.  Fortunately, though, format 

i thought that X-MP3-DRAFT-00 is mp3 and the others are layer 1/2

> 0x50 works OK for MPEG layer III (i.e., MP3), as well as layer I and layer 
> II.  So, using 0x50 for all MPEG audio streams seems to work OK.

yes, as teh default mpeg audio codec (mp3lib) can handle both. so you're
lucky. anyway i still suggest 0x55 then, at least codecs with mp3 support
mostly can handle layer 1/2 too, but it isn't always true inverse.

> > >         } else if (strcmp(subsession->codecName(), "PCMU") == 0) {
> > > -         sh_audio->format = 0x7;
> > > +         wf->wFormatTag = sh_audio->format = 0x7;
> > > +         wf->nChannels = 1;
> >
> >you should set blockalign to 1 and avgbytepersec to the right value,
> >otherwise a-v sync issues may come up
> 
> OK, I'll set "nBlockAlign" (I presume that's what you mean) to 1.  As for 
> "nAvgBytesPerSec", is the right value (for PCM u-law and a-law) 16000 (== 
> 8000 samples/sec * 2 bytes/sample)?
it's the input (compressed) bitrate in bytes, so for mono 8-bit alaw/ulaw
it would be equal to samplerate, imho

> Could you please go ahead and apply the patch anyway, as it's an 
no

> >and i'm still waiting an rtp:// fallback/emulation or enabling the old code
> 
> And I'm still waiting for someone to point me at a file of  DVB data that, 
> when streamed using "dvbstream", "mplayer" is able to successfully receive 
> and play (using the "rtp://" hack) :-)
can dvbstream do streaming from file too?


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu