SMIL / UDP versus TCP IP -- Embedded player issue

(I added to the subject of this email in hopes that
someone from the player team might notice and be able
to help.)

Yes, in our SMIL 1.0 implementation, you do have to
wrap the <seq> in a <par> to get one timeline. 
You
don't in our SMIL 2.0 implementation.

Here are a few more things to try while waiting for
advice from embedded-player experts as to why
behavior changes with a change from TCP to UDP only
in an embedded player.  I don't imaging these
things changing the outcome, but if they do it would
be very useful to know:

(1) Try making it a SMIL 2.0 presentation.  You
can do this by simply changing the <smil> tag to
the following:
  <smil xmlns="http://www.w3.
org/2001/SMIL20/Language">

(2) Try removing every clip-begin from the
presentation. There were problems related to
clip-begin back in our early SMIL days; a clip-begin
requires a seek into the stream and then
pre-buffering prior to playing it and there may be
some bug related to doing that that only manifests
itself under embedded player + UDP conditions.

    - Erik

Jechiam Gural wrote:
>
>> Let me make sure I have this right:
>> (1) you have a playlist of RM videos in a SMIL 2.0
file (or is it 
>> SMIL 1.0?) that:
>> (2) play one at a time (in sequence)
>> (3) in their own timelines
>> (4) via rtsp://
>> (5) and there are no other media elements (images,
text, ...etc.) in 
>> the presentation,
>> (6) and, when you force your player to use UDP, you
have problems 
>> *only* when playing the SMIL URL in an embedded
player.
>
>
> (1) SMIL 1.0, using <Par> en <Seq>, I will
check
> (2) yes
> (3) yes, using clip-begin and clip-end tags
> (4) yes
> (5) yes
> (6) yes
>
>>
>> Could you try it in Firefox as well as IE (or
other) browsers to see 
>> if the problem is the same in each?  I'm far from
an expert on the 
>> embedded player; it may be that your browser is
using older installed 
>> components (?).  You should really include 
>> player-devhelixcommunity.org list on this thread.
>
> I'll do this...
> I belief the test was in IE.....
>
>
>
>
>>
>> One thing you should try is to add
<seq>...</seq> around your 
>> playlist to force it to be an all-one-timeline
presentation.  In the 
>> following, VERSION1 plays 10minVid.rm for its
natural duration of 10 
>> minutes and has a 10-minute timeline slider, then
it starts a new 
>> 7-minute timeline to play 7minVid.rm.  VERSION2 has
a <seq> wrapped 
>> around everything which forces it all to play in a
single 17-minute 
>> timeline.  Buffering between clips should be
seamless in both cases, 
>> but you may find that VERSION1 has buffering issues
(in the embedded 
>> player) and that VERSION2 does not.  Let us know
what you find:
>>
>> <!-- VERSION1: -->
>> <smil xmlns="http://www.w3.
org/2001/SMIL20/Language">
>>  <body>
>>    <video
src="rtsp://someServer/10minVid.rm">
>>    <video
src="rtsp://someServer/7minVid.rm">
>>  </body>
>> </smil>
>>
>> <!-- VERSION2: -->
>> <smil xmlns="http://www.w3.
org/2001/SMIL20/Language">
>>  <body>
>>    <seq>
>>    <video
src="rtsp://someServer/10minVid.rm">
>>    <video
src="rtsp://someServer/7minVid.rm">
>>    </seq>
>>  </body>
>> </smil>
>
>
> I belief its SMIL 1.0
>
> using the <PAR> command, which makes it to one
"virtual" clip with a 
> new timeline...
>
> leading to
>
> <body>
> <par>
>   <seq>
>   <video
src="rtsp://someServer/10minVid.rm">
>   <video
src="rtsp://someServer/7minVid.rm">
>   </seq>
> </par>
> </body>
>
>
> I belief the <par> is also needed to enfore that
the preroll of each 
> sequence in the <seq> is prebufferd...
> Jus a Ram file with sequences will not lead to a
seamless playback of 
> clips as far as I know...
> I'm not an expert in this, but since UDP is based on
the fact that 
> packets can get lost and client server intercation is
minimised to a 
> minumum, I can imagine that in in SMIL presentations in
which 
> prebuffering of playlists need to occur UDP is less
reliable than TCP 
> / IP...
>
> On  the other hand the issue seems to be more tight to
the fact wether 
> the player is embedded or not...
>
>
>>
>>>
>>> Two questions:
>>>
>>> 1) is TCP/Ip indeed advised for
"complicated" SMIL presentations, 
>>> i.e. better than UDP
>>
>>
>> A playlist of videos (no parallel track, no
excl's, no media added on 
>> event, ...etc.) is not a very complicated SMIL
presentation.  Try 
>> using a RAM file instead and see if you get the
same results.  A RAM 
>> file is just this format where the URLs are played
in sequence:
>>
>> URL1
>> URL2
>> URL3
>> ...
>> URLn
>>
>>> 2) is emebding the RealOne player known to
"influence" SMIL playback 
>>> reliability... ?
>>
>>
>> Not that I know of; player-devhelixcommunity.org would be a good 
>> list for that question.
>>
>>    - Erik
>>
>>>
>>> Setting:
>>> Latest RealOne player
>>> OS: win XP
>>> Helix 11 server
>>>
>>> Regards,
>>>
>>> Gural
>>
>
> Regards,
>
> Gural
>
>
>

_______________________________________________
Player-dev mailing list
Player-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/play
er-dev

SMIL / UDP versus TCP IP -- Embedded player issue

Thread: SMIL / UDP versus TCP IP -- Embedded player issue