[MPlayer-dev-eng] Streaming ASF and Title/Author headers

[Bertrand Baudet]

On Sunday 20 July 2003 16:26, Adam wrote:
> On Sat, 19 Jul 2003, Bertrand Baudet wrote:
> > Which protocol are you using. Is it MMST or ASF/HTTP?
>
> its a MMST Stream.
>
> > What is the radio URL?
>
> That I really would rather not give out over the list, granted its a
> premium/paid service

Well, don't they have a free trial version?

> > You can't query the server for the track name.
> > It depends on the way the radio is streaming. Is it a live brodcast that
> > is also streamed over the internet? Or is it a playlist that is only
> > streamed on the net?
>
> its a Play list, I am not trying to Query, per-se, the
> server for the
> track name, as I understand how this is working, when the song comes on,
> it sends the track info that mplayer can read? (granted if I got it
> *RIGHT* when this header was sent, mplayer would probably grab it fine.

Well the way the ASF streaming works is by encapsulation:
You have one layer of encapsulation for the network streaming. Once you
remove this layer you have the same thing as an ASF file which is:
an ASF header, and ASF data packets. In the ASF header you have ASF stream
header that describe the streams(audio/video) and there codecs.
You can also have an optional ASF content description for the track info.
When the server send the song from its playlist it only add the network
encapsulation. It will always send the ASF header for each new song from
the playlist. The ASF parser needs it to correclty play the song.

> The requirements is that you use MSWin to play this (obviously) with media
> player, in this, its a activex call (as far as I can tell) that gets track
> name and title pulled off the stream, it only grabs it when a song starts,
> that is how I can safely assume everything I can, otherwise I am not sure
> how it works ;)

It depends a lot of the player side. For example, I know a company
that send the ASF content description correctly but only set an hash key
in it. Then the player, on the track transition signal, grab the associated
information of the hash key from the web server and display it.
So it really depends on the client side implemetation. 
(The client probably uses the WMSDK)

> > In the firt case, I don't remember seeing a way of updating the tittle.
> > For the last case, they can setup on the server side to stream as a live
> > stream from a playlist, or to stream tittle by tittle. Streaming tittle
> > by tittle will send the ASF header for each tittle. Which is not the case
> >  for the live stream. The trouble by sending tittle by tittle is that you
> > need to reset the ASF parser with the new info from the header. The new
> > tittle can be encoded with another codec, so you will have to close the
> > previously used one and reopen the new one.
>
> well, this may be a dumb question, but cant be programmed  to "grep" this
> data out of the stream every time its passed and decode it into a variable
> that can be printf'ed? you shoulent *have* to restart the codec just to
> get new header info, at least how I am looking at this situation.

No, no, it's not like this. The server is sending complete ASF files. So it's
like if you were concateneting the files.
The ASF parser need the header to play the stream and if there is a new 
ASF header that is send you have to process it.
And when I said you need to close the previously used codec it's because
you can have the first song using MP3 and then the next one using WMA.
You have to change codec to be able to playback. So you have to reset
the player with the proper setting. And I personnaly don't know how to 
do that.

The place that the content description is parsed is in asfheader.c line 373
from an up to date CVS MAIN version of mplayer.

Bertrand