[vlc-devel] Smooth Streaming manifest, track IDs

[Martin Storsjö]

Hi Frederic,

On Wed, 15 Feb 2012, Frederic YHUEL wrote:

> Why does the (client) manifest *not* contain the track IDs?
>
> I guess that what Microsoft had in mind, when they wrote the specs, is
> that the client can associate an arbitrary ID to each track. Since the
> client does know from which track belongs each chunk, all should go
> well.

I guess the reason is that it normally isn't required - each fragment only 
contains data from one single track anyway. (And within one smooth 
streaming presentation, the tracks might either reside in separate ismv 
files and thus have overlapping track ids, or they might all be within the 
same and have unique ids.)

> But the way VLC is done makes things tricky. Retrieving the "real"
> track IDs is compulsory, if we use avformat demux, and is very helpful
> otherwise (I'm working on VLC's MP4 demux).

Why do you need knowing the real track id if using the avformat demuxer? 
If you use one separate demuxer for each fragment, there shouldn't be any 
ambiguity, but does that have other drawbacks?

> Do you think my guess is correct? Or maybe there is a simple way to
> retrieve the track IDs after all? The only way I have in mind, is to
> pre-fetch the first (lowest quality) chunk of each track, and to parse
> the tfhd atom to finally get the track ID.

Also, a small note about prefetching (which might be informative but 
probably not helpful): I guess you know that you can request 
QualityLevels(...)/FragmentInfo(...) instead of Fragments. This gives you 
only the moof atom, not the mdat part. This is used by the silverlight 
player to fetch info about upcoming fragments (that are advertised within 
the tfrf uuid tags) in live streams, without downloading the full 
fragments.

This is possible, since even if the client manifest explicitly contains
declarations like

Url="QualityLevels({bitrate})/Fragments(video={start time})",

the spec actually mandates this to be almost literally this string, 
there's not much variability. In particular, the "Fragments" string must 
be exactly that, since apparently the silverlight players can swap it out 
against FragmentInfo. The spec also mentions a few other similar things 
that can be requested.

I'm not sure if all smooth streaming content providers actually answer to 
requests for FragmentInfo though, it might have been omitted in some 
implementations of static content I think, since the official silverlight 
player only requests it for live streams.

// Martin