> 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-dev helixcommunity.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
--
------------------------------------------------------------
--
Drs. Jechiam Gural
Noterik B.V.
Prins Hendrikkade 120
1011 AM, Amsterdam
The Netherlands
Tel. +31-(0)20-5929966
Fax. +31-(0)20-5929969
Direct+31-(0)20-5929980
http://www.noterik.com
http://www.streamedit.com
**********************************************************
Noterik has a position available for a Java / PHP developer.
**********************************************************
------------------------------------------------------------
--
_______________________________________________
Player-dev mailing list
Player-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/play
er-dev
|