The mov file here is a quicktime-redirector file to an rtsp stream. Directly playing the stream works fine.

So, we should be sending a redirect message instead of a missing-decoder message.

It already detected that it is an rtsp stream and ignores it (line 3519 of qtdemux.c).

When we only have a single track with rtsp we can just post a redirect message, but what to do when there are multiple tracks and one of them is rtsp?

Implementing the single-track case should be done IMHO, for multi track files rtsp URIs should still be ignored. That should fix most cases I guess.

And if someone really needs it for multi-track files it becomes complex (maybe can be done by internally having rtspsrc's inside qtdemux)

One option is to have a signal/message/any other notification mechanism to tell the application that the stream is part of the media.

It seems the problem is different here. It is already posting a redirect message, but the new-location field is "" (empty). This .mov has the rtsp address inside dref atom, which is currently not handled by qtdemux.

Created attachment 145519 [details] [review]
Straightforward solution patch

This code to fetch the uri from inside the atoms is really painful, if anyone out there got an easier way/idea on how to do it, please tell and I'll implement it.

Aditionally qtdemux is now posting 2 redirect messages, the one introduced by the patch (the correct one with the correct URI) and another one containing an empty string.

Not really familiar with how this all fits together, but here are some random comments nevertheless:

 - could this be split out into a separate function? I think
   parse_trak() is already quite long

 - it looks like you're assuming that the URI string is
   NUL-terminated, which you shouldn't. Better 
   g_strndup() and then later g_free() the string to
   make absolutely sure it has a terminator.

 - might want to check that the URI is a valid uri
   and/or looks like what you're looking for (do
   we only want URIs that redirect to rtsp://... ?)

 - how does this work policy-wise with these URIs?
   Do they sometimes appear in perfectly valid
   and playable files as extra information on the
   side (in which case the app shouldn't act on the
   redirect message) or can we assume that if
   there is such a redirect that's it? I don't really
   know what we do now, but we probably should
   think about this. Currently totem acts immediately
   on a redirect message, IIRC.

 - if there are multiple URIs, should they be collected
   and posted in one single message? (like the other
   redirect code does)

 - does that 4-byte value that you skip make sense
   if interpreted as bitrate?

(In reply to comment #8)
> Not really familiar with how this all fits together, but here are some random
> comments nevertheless:
> 
>  - could this be split out into a separate function? I think
>    parse_trak() is already quite long
Agreed.

> 
>  - it looks like you're assuming that the URI string is
>    NUL-terminated, which you shouldn't. Better 
>    g_strndup() and then later g_free() the string to
>    make absolutely sure it has a terminator.
Alright.

> 
>  - might want to check that the URI is a valid uri
>    and/or looks like what you're looking for (do
>    we only want URIs that redirect to rtsp://... ?)
In this case, the trak type is 'rtsp', so I guess we can check if it starts with 'rtsp'

> 
>  - how does this work policy-wise with these URIs?
>    Do they sometimes appear in perfectly valid
>    and playable files as extra information on the
>    side (in which case the app shouldn't act on the
>    redirect message) or can we assume that if
>    there is such a redirect that's it? I don't really
>    know what we do now, but we probably should
>    think about this. Currently totem acts immediately
>    on a redirect message, IIRC.
This is on a trak, so there is nothing restricting it on
appearing with other 'normal' traks, or having multiple
rtsp traks together. I guess we should have a different message
to signal this. Something like an 'external-location' or 'external-content'.

> 
>  - if there are multiple URIs, should they be collected
>    and posted in one single message? (like the other
>    redirect code does)
Already answered.

> 
>  - does that 4-byte value that you skip make sense
>    if interpreted as bitrate?
Don't know, it is all zeroes in this sample.


I had never seen files like this before, but quicktime plays it fine. (Well, the rtsp seems to
be inaccessible/down right now, but it does a redirect).

Created attachment 145801 [details] [review]
Reviewed patch

Improved patch. It posts a redirect if the file contains only one trak, and if it is a rtsp trak.

Module: gst-plugins-good
Branch: master
Commit: 92a83e016aa0824549a8e913f8bfa8ee105b0a44
URL:    http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=92a83e016aa0824549a8e913f8bfa8ee105b0a44

Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk>
Date:   Thu Jan 14 17:11:13 2010 -0300

qtdemux: Handle another kind of redirect trak

Some traks might contain a redirect rtsp uri inside
hndl atom (which is a dref atom entry). This commit makes qtdemux
post a message when it finds one of these traks and there are
no other traks.

Fixes #597497

Comment on attachment 145801 [details] [review]
Reviewed patch

Did not apply anymore,  committed a reviewed/updated version