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

[Ross Finlayson]

> > -       // 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 
present only in the stream itself.)  Ditto for "frames per second".  If 
"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?)


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


> >         } 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)?

Could you please go ahead and apply the patch anyway, as it's an 
improvement on the old code.  (PCM audio streams work now where they didn't 
before.)


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

I'm pretty sure that the new LIVE.COM code can to receive/play such a 
stream OK, but until I get an example to play with, I won't know for sure.

         Ross.