R: R: R: Urgent please

I uploaded another shorter example where real player fail:

http://rapidshare.com/files/37893915/bug2.rar.html

The structure is something like:

	<body>
		<par>
			<img id="A" ... fill="freeze"/>
			<img id="B" ... fill="freeze"/>
			<img id="C" ... fill="freeze"/>
			<excl dur="indefinite">
				<par begin="0s;D2.activateEvent">
					<textstream id="T1" ...
rn:backgroundOpacity="0%" fill="freeze"/>
					<textstream id="T2" ...
rn:backgroundOpacity="0%" fill="freeze"/>
					<img id="D1" ... fill="freeze"/>
				</par>
				<par begin="D1.activateEvent">
					<textstream id="T3" ...
rn:backgroundOpacity="0%" fill="freeze"/>
					<img id="D2" ... fill="freeze"/>
				</par>
			</excl>
		</par>
 	 </body> 

The real network documentation
(http://service.real.com/help/library/guides/realone/ProductionGuide/HTML/re
alpgd.htm?page=htmfiles/cliptags.htm%23inlinetext) says:

fill="freeze":
<seq>  	Clip freezes after playback only for the duration of the subsequent
clip's begin value, such as begin="5s".
<par> 	Clip freezes until the entire <par> group concludes.
<excl> 	Clip freezes until another clip in the <excl> group plays.

So, in my case "<img id="D2" ... fill="freeze"/>" should disappear when its
"par" group end, that is when D2 is clicked. If you try the example i
uploaded, D1 (right arrow image button) disappear when it's clicked, while
D2 (that is shown after D1 click) doesn't disappear once it's clicked.
So, or i'm missing something, or real player is bugged.

Please let me know

-----Messaggio originale-----
Da: Sjoerd Mullender [mailto:sjoerd@acm.org] 
Inviato: luned́ 18 giugno 2007 8.44
A: ___
Cc: 'Jack Jansen'; 'SMIL List'
Oggetto: Re: R: R: Urgent please

___ wrote:
>> Please explain how a bug in one implementation of SMIL makes SMIL 
>> totally
> useless?
> 
> Yes sorry, that was frustration, it doesn't mean nothing.
> 
>> Have you tried other players, e.g. ambulant or GRiNS?
> 
> I tried ambulant but it has problems to show static gif or png images, 
> so even pages that works on realplayer doesn't work there :( Grins 
> player is not freeware or evaluation edition, so i couldn't had a 
> chance to try it
> 
>> The first version below is a copy of your version with all 
>> superfluous
> attributes removed. 
> 
> And it doesn't work. I arrived to this version since excl didn't work, 
> i know it's a bad way of code it...
> 
>>  The second is an equivalent version that uses excl
> 
> That's a sort of what i tried in first instance (your version is 
> clearer) but unfortunately it doesn't work.
> I uploaded the presentation on rapidshare, so if maybe you want to try 
> it, you could check if it's a realplayer bug (so i can notice them or 
> something like that) or it's me that is doing something wrong..
> http://rapidshare.com/files/37735652/bug.rar.html
> Index.smil works good since there are only some animation, while 
> storia.smil is the bugged one, clicking on second menu link and then 
> the first one, will show images of both links, instead of removing 
> them =\
> 
> Hope you have some time to test it and let me know if i should report 
> to RealPlayer (in some way) the bug.
> Thanks in advance

The attached seems to work.  What I did was simplify the code more.  I
removed all the z-index manipulation, but instead did the overlays in the
excl's.  Looks ok in the RealPlayer.


> 
> -----Messaggio originale-----
> Da: Sjoerd Mullender [mailto:sjoerd@acm.org]
> Inviato: domenica 17 giugno 2007 14.03
> A: ___
> Cc: 'Jack Jansen'; 'SMIL List'
> Oggetto: Re: R: Urgent please
> 
> On 06/17/2007 01:04 PM, ___ wrote:
>> Well, if realplayer can't handle it, then SMIL is totally useless. I 
>> mean,
> 
> Please explain how a bug in one implementation of SMIL makes SMIL 
> totally useless?
> Have you tried other players, e.g. ambulant or GRiNS?
> 
>> if it handle just the base things like transitions of slides, then i 
>> could use powerpoint for a presentation. The nice thing of SMIL 
>> should be the interactivity. After 2 weeks i couldn't handle 
>> succesfully to load on same page objects according to what is 
>> selected from menu. Use href to link to external .smil files is 
>> terrible and senseless, but seems the only thing that works.
>> I would expect to use <excl> group and fix things: no! It just 
>> doesn't work, i understood that only the begin event should be 
>> described for each excl child and excl will handle to exclusively 
>> load the child group. Obviously that doesn't work, and objects from 
>> other excl children are still visible for no reason (no, i didn't use 
>> the fill="hold"). I tried several tutorial with excl, but only those 
>> that load just an image per child works.. If i start from those and 
>> add groups as excl child, then all mess up, sooner or late.
>> Is there any template that works on realplayer or any other player 
>> where SMIL has sense and interactive presentation works?
>> Please answer, since i'm quite frustrated
> 
> I'm not really getting a warm, fuzzy feeling from trying to help you.
> 
> There are a few things you could try to get those textstreams to end 
> when you click on the button, but first I would try to *simplify* the 
> code by removing begin/end attribute values that are already implied 
> by the timing model.  The first version below is a copy of your 
> version with all superfluous attributes removed.  The second is an 
> equivalent version that uses excl.  The second version would be the 
> preferred way of doing it.  I think they should both do what you seem 
> to want, but I cannot guarantee that the RealPlayer does this 
> correctly.  If it doesn't, then it's a bug in the RealPlayer, not in SMIL.
Don't confuse the two.
> 
> <body>
>   <par dur="indefinite">
>     <par id="A_par" begin="bt_A.activateEvent" end="bt_B.activateEvent">
>       ......
>     </par>
>     <par id="B_par" begin="bt_B.activateEvent" end="bt_A.activateEvent">
>       <par id="B_par_text1" begin="0s;arrow_b.activateEvent"
> end="arrow_f.activateEvent">
> 	<textstream id="B_text1" src="..." rn:backgroundOpacity="0%"
> transIn="fade_1" region="text_B_a" fill="freeze"/>
> 	<textstream id="B_text2" src="..." rn:backgroundOpacity="0%"
> transIn="fade_1" region="text_B_b" fill="freeze"/>
>       </par>
>       <par id="B_par_text2" begin="arrow_f.activateEvent"
> end="arrow_b.activateEvent">
> 	.......
>       </par>
>     </par>
>   </par>
> </body>
> 
> <body>
>   <excl dur="indefinite">
>     <par id="A_par" begin="bt_A.activateEvent">
>       ......
>     </par>
>     <excl id="B_par" begin="bt_B.activateEvent">
>       <par id="B_par_text1" begin="0s;arrow_b.activateEvent">
> 	<textstream id="B_text1" src="..." rn:backgroundOpacity="0%"
> transIn="fade_1" region="text_B_a" fill="freeze"/>
> 	<textstream id="B_text2" src="..." rn:backgroundOpacity="0%"
> transIn="fade_1" region="text_B_b" fill="freeze"/>
>       </par>
>       <par id="B_par_text2" begin="arrow_f.activateEvent">
> 	.......
>       </par>
>     </par>
>   </par>
> </body>
> 
> 
>> -----Messaggio originale-----
>> Da: Sjoerd Mullender [mailto:sjoerd@acm.org]
>> Inviato: domenica 17 giugno 2007 12.40
>> A: Jack Jansen
>> Cc: ___; 'SMIL List'
>> Oggetto: Re: Urgent please
>>
>> On 06/17/2007 12:47 AM, Jack Jansen wrote:
>> --
>> Sjoerd Mullender
>>> It is a bit difficult to read your code, but the problem may be that 
>>> your mixing up scheduled end and event-based end.
>>>
>>> if bt_A.activateEvent is fired then two things happend immediately:
>>> 1. B_par ends
>>> 2. B_text2 ends
>>>
>>> You're expecting that the end of B_par raises B_par.end which in 
>>> turn leads to B_text2 ending. This seems like a reasonable 
>>> expectation, but I'm not 100% sure it is correct. "B_par.end" is 
>>> different from
>>> "B_par.endEvent": the first one is scheduled and the second one is 
>>> event-based.
>>>
>>> The exact distinction between those two mechanisms can be found in 
>>> the SMIL standard (in the timing section), but the hand-waving 
>>> explanation is that scheduled timing is pre-computed into the 
>>> timegraph (similar to seq children starting when their predecessor 
>>> ends, etc) whereas event-based timing happens on the fly (the 
>>> timegraph is computed as if end="indefinite", I think).
>>>
>>> I'm not sure whether the standard specifies what should happen in 
>>> this case (a scheduled timing relationship depending on an 
>>> event-based timing relationship), maybe Sjoerd or someone else who 
>>> understands this better than me can explain?
>> When an element ends because of an event, the end condition is 
>> reevaluated and repropagated.
>>
>>> But what I am sure of is that with a construct like this you're 
>>> descending into the deep damp cellars of the SMIL timing model, so 
>>> you're quite likely to stumble upon a bug. My suggestion would be to 
>>> change the "B_par.end" into "B_par.endEvent", thereby making 
>>> everything event-based, and hoping that that fixes the problem.
>>>
>>> On  16-Jun-2007, at 23:56 , ___ wrote:
>>>
>>>> This situation is extremely easy to understand, please give me a 
>>>> reply please. I'm using real player.
>>>>
>>>>   <body>
>>>>     <par dur="indefinite">
>>>> <par id="A_par" begin="bt_A.activateEvent" 
>>>> end="bt_B.activateEvent"> ......
>>>> </par>
>>>> <par id="B_par" begin="bt_B.activateEvent" 
>>>> end="bt_A.activateEvent"> <par id="B_par_text1"
begin="0s;arrow_b.activateEvent"
>>>> end="B_par.end;arrow_f.activateEvent">
>>>> <textstream id="B_text1" src="..."
>>>> rn:backgroundOpacity="0%" transIn="fade_1" region="text_B_a"
>>>> end="B_par_text1.end;bt_A.activateEvent" fill="freeze"/> 
>>>> <textstream id="B_text2" src="..."
>>>> rn:backgroundOpacity="0%" transIn="fade_1" region="text_B_b"
>>>> end="B_par_text1.end;B_par.end" fill="freeze"/> </par> <par 
>>>> id="B_par_text2" begin="arrow_f.activateEvent"
>>>> end="B_par.end;arrow_b.activateEvent">
>>>> .......
>>>> </par>
>>>> </par>
>>>>     </par>
>>>>   </body>
>>>> </smil>
>>>>
>>>> Why when B_text1 and B_text2 are visible, and i click on bt_A, only
>>>> B_text1
>>>> disappear?
>>>> The difference between B_text1 and B_text2 is that the end differ 
>>>> in this
>>>> way:
>>>>
>>>> B_text1 --> B_par_text1.end;bt_A.activateEvent
>>>> B_text2 --> B_par_text1.end;B_par.end
>>>>
>>>> BUT, since B_par group has the end attribute set to: 
>>>> bt_A.activateEvent, shouldn't B_par.end and bt_A.activateEvent act 
>>>> the
>> SAME way?
>>
>> It seems to me you've uncovered a bug in the RealPlayer.  When you 
>> click on bt_A, since B_par has an end="bt_A.activateEvent", it ends.
>> It doesn't matter what's inside, but all that is inside should end 
>> then as well, so this definitely includes B_text1 and B_text2.  There 
>> is no two ways about it, and it doesn't matter what their end 
>> attributes
> say, they should end.
>> --
>> Sjoerd Mullender
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition. 
>> Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 
>> 16/06/2007 12.50
>>  
>>
>> No virus found in this outgoing message.
>> Checked by AVG Free Edition. 
>> Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 
>> 16/06/2007 12.50
>>  
>>
>>
> 
> 
> --
> Sjoerd Mullender
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 
> 16/06/2007 12.50
>  
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition. 
> Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 
> 16/06/2007 12.50
>  
> 


--
Sjoerd Mullender

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 16/06/2007
12.50
 
  

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 17/06/2007
8.23

Received on Monday, 18 June 2007 09:59:37 UTC