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

[Ross Finlayson]

A'rpi,

It sounds like we're getting closer...

> > Trouble is, for RTP streams, we don't (in general) know what the width and
> > height 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)

As a general rule, RTP streams that use a codec that has this information 
'in band' (e.g., MPEG and H.26*) don't carry any of this information 
(width, height, frame rate) 'out of band', so for those codecs it's not 
possible for me to fill in that information in the 
"BITMAPINFOHEADER".  (It's not that I don't *want* to fill in this 
information; it's that can't.)

For other codecs, such as motion-JPEG, the RTP payload format (protocol) 
usually includes an extra header - in each data packet - that contains the 
extra needed information (e.g., width & height of each frame).  So again, 
for such codecs I don't have all of the information needed to fill in the 
"BITMAPINFOHEADER" fields ahead of time.  (However, since the LIVE.COM code 
currently doesn't implement the motion-JPEG RTP payload format, I'll 
probably just remove the 'MJPG' branch of the "if" statement for now.)

Finally, some codec-specific information (that's the same for all frames) 
*is* carried out-of-band, in the SDP description.  Fortunately, this is 
information that I *do* have when I'm setting up the 
"BITMAPINFOHEADER".  For most codecs, though, the only such 'out-of-band' 
information is the sampling rate.

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

QuickTime Player (and other RTP receivers/players) provide an 'existence 
proof' that it's possible to play incoming H.263+ streams (for example), 
without requiring the user to specify in advance what the frame rate is 
going to be.  However, if the "mplayer" code currently requires that the 
user use the "-fps" option for such streams, then guess I'll live with that 
for now.  Down the road, though, we should see if we can figure out a 
better solution.

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

You're right - I think "X-MP3-DRAFT-00" is exclusively layer III, and 
"MPA-ROBUST" is almost always layer III.  "MPA", however, can use any layer.

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

If you're sure about this, then yes, I'll use format code 0x55 for all of 
these MIME types.

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

OK, "nAvgBytesPerSec = 8000" it is.

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

I don't think the "dvbstream" code, as it currently stands, can read from a 
file, but it looks like it'll be an easy hack for me to do this (for my own 
testing).

         Ross.