CR-Client: handle WM-RTSP HXSource failover

Inside DoURLOpenFromSource, I suggest to get the original
URL from the
source(call HXSource::GetURL) instead of using
HXPlayer::m_pszURL. 

m_pszURL points to the most recent track opened by the
HXPlayer, it's not
guaranteed that m_pszURL would be the same URL as the
source's. Especially
when the WM-RTSP failover is async. operation, a new track
can be opened by
the HXPlayer prior to the current source receives its RTSP
OPTIONS response.

The rest looks good.

-->Henry

> -----Original Message-----
> From: client-dev-bounceshelixcommunity.org 
> [mailto:client-dev-bounceshelixcommunity.org] On
Behalf Of Eric Hyche
> Sent: Monday, December 04, 2006 10:33 PM Ping
> To: client-devlists.helixcommunity.org; 
> common-devlists.helixcommunity.org; 
> datatype-devlists.helixcommunity.org; 
> protocol-devlists.helixcommunity.org
> Subject: [Client-dev] CR-Client: handle WM-RTSP
HXSource failover
> 
> 
> Description
> --------------------------------------------
> The WM-RTSP protocol is implemented as a fileformat
plugin, 
> and thus an HXFileSource. We added the ability for a 
> fileformat to claim a protocol by adding the 
> SchemeExtensionPair plugin handler property.
> 
> So currently in HXPlayer::CreateSourceInfo() before we
decide 
> which type of source (HXFileSource or HXNetSource) to
create, 
> we ask the plugin handler whether any file format
plugin can 
> claim the scheme:extension in the URL we are given. For
RTSP 
> URLs we currently say that both the scheme and
extension must 
> matched by a fileformat before we decide to make an 
> HXFileSource to handle this.
> 
> So for rtsp with recognizable WM extensions such as
.asf, 
> .wma, .wmv, etc. we currently have no problem. However,
in 
> lots of URLs we cannot recover a file extension. For
those 
> URLs, we were creating an HXNetSource (which is the
Helix 
> RTSP stack) and trying to playback the URL with that
source. 
> Since the two RTSP stacks are currently incompatible,
then 
> this fails for these kind of URLs.
> 
> The purpose of this change is to make sure that these
type of 
> URLs make it to the WM-RTSP fileformat.
> 
> First, we have to make sure that the Helix RTSP stack
returns 
> some sort of clearly recognizable error when it
encounters a 
> Windows Media Server. We do this by checking the
"Server:"
> header in the initial OPTIONS response and if it is a
Windows 
> Media Server, we return a new HX_RESULT named 
> HXR_INCOMPATIBLE_RTSP_SERVER.
> 
> Next this error will filter up to
HXPlayer::ReportError(). 
> Here, we look for it, and if we find this error, then
we add 
> the SourceInfo pointer to a list and set a flag saying
that 
> the HXNetSource failed for this URL. At the next 
> HXPlayer::ProcessIdle(), we call 
> DoURLOpenFromSource(pSourceInfo, URL_OPPOSITE_HXSOURCE)
on 
> this SourceInfo with the URL_OPPOSITE_HXSOURCE enum
saying 
> that we are trying to switch HXSource's.
> 
> This causes us to try the URL again, but this time with
a 
> flag saying that we have already tried an HXNetSource
and 
> failed. So this time in HXPlayer::CreateSourceInfo(),
we will 
> not try the HXNetSource but will instead create an
HXFileSource.
> This is very similar to the code used to try alternate
URLs, 
> redirects, and SDP URLs - in fact,
DoURLOpenFromSource() is 
> used by all of these cases.
> 
> Files Modified
> --------------------------------------------
> M client/core/hxplay.cpp
> M client/core/srcinfo.cpp
> M client/core/srcinfo.h
> M client/core/pub/hxplay.h
> M common/include/hxresult.h
> M datatype/wm/fileformat/asf_file_format_xplatform.cpp
> M protocol/rtsp/rtspclnt.cpp
> M protocol/rtsp/pub/rtspclnt.h
> 
> Branches
> --------------------------------------------
> HEAD only
> 
> Testing
> --------------------------------------------
> I changed the extension on a .wmv file sitting on a WM
server 
> to .foobar and tried playing the URL. It successfully
played 
> after this change.
> 
> 
> 
> =============================================
> Eric Hyche (ehychereal.com)
> Technical Lead
> RealNetworks, Inc. 
> 


_______________________________________________
Common-dev mailing list
Common-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/comm
on-dev