instream API doesn't properly resume video after the instream clip is replayed second time

[GoogleCodeExporter]

Currently instream API of Flowplayer doesn't properly resume video after the 
instream clip finishes playing second time. Test case: 
http://post.lnk.lt/flow/lnk2.html

What steps will reproduce the problem?
1. Wait for the pre-roll to finish.
2. Mouseclick on the control bar at ~16 minutes. The mid-roll playback is 
enforced. Wait for it to finish.
3. Mouseclick back on the control bar at 14:50 and wait for the mid-roll to 
start normally at 15:00.
4. After mid-roll is played second time the original video clip doesn‘t 
resume anymore.

What is the expected output? What do you see instead?
The original clip should resume playing. We see the counter resuming however 
the video doesn't play. Well it actually plays, but is underneath the instream 
clip. You can clearly see this by switching to full screen mode. See 
http://post.lnk.lt/flow/fullscreen.png

What version of the product are you using? On what operating system?
Flowplayer 3.2.12 and OVA 1.1 Final (build 6) plugin.

Original issue reported on code.google.com by vil...@lnk.lt on 18 Jul 2012 at 1:38

[GoogleCodeExporter]

Can this problem be solved if we would bought Flowplayer Support? We already 
have a commercial version.

Original comment by vil...@lnk.lt on 23 Jul 2012 at 7:42

[GoogleCodeExporter]

Hi, please contact the ova developers in regards to your issue, you would have 
support with them

http://www.longtailvideo.com/support/open-video-ads/ova-for-flowplayer

Original comment by electrot...@gmail.com on 24 Jul 2012 at 5:15

[GoogleCodeExporter]

Actually I've done so at first, but they redirected me here. Here are some 
excerpts from the emails between me and OVA support:

Me to OVA support: "I‘m still not sure that it‘s related to
 Flowplayer API. At least the workaround should be possible because as you
 have mentioned the video starts to play and it IS there under the OVA
 overlay. Switching to full screen clearly shows that. Check the screenshot
 attached. It seems like OVA overlay just stays there after the ad is
 finished."

OVA support: "Ok, but OVA has *no* control of that. 

All OVA does is: _player.playInstream(clip)

where "_player" is Flowplayer. 

Flowplayer is responsible playback (starting, stopping and closing the
 instream clip). Clearly in this case, Flowplayer is not correctly closing
 down the instream clip.

Honestly, there is nothing I can do - this issue definitely has to be
 logged with Flowplayer."

I can try to get Paul from OVA to comment on this bug if you need more 
information.

Original comment by vil...@lnk.lt on 24 Jul 2012 at 9:01

[GoogleCodeExporter]

HI don't see a pre-roll or mid roll happen. Here is a working config for the 
basic functionality I am able to seek back and replay the mid roll many times. 

    flowplayer("player", "../build/flowplayer.swf",
    {

        onStart: function(clip) {
            console.log("onStart: " + clip.url);
        },

        onFinish: function(clip) {
            console.log("onFinish: " + clip.url);
        },

        onPause: function(clip) {
            console.log("onPause: " + clip.url);
        },

        onResume: function(clip) {
            console.log("onResume " + clip.url);
        },

        onSeek: function() {
            console.log("onSeek");
        },

        clip: {

            // baseUrl for both parent and instream clips
            baseUrl: 'http://stream.flowplayer.org',

            // duration for the parent clip
            //duration: 10,

            // instream playlist
            playlist: [

                // in the middle of the parent clip (ie. "mid-roll") starting at
                // 5 seconds
                {
                    url: 'honda_accord.flv', duration: 5, position: 2
                },
                {
                     url: 'http://pseudo01.hddn.com/vod/demo.flowplayervod/flowplayer-700.flv', duration: 5, position: 15
                }

            ]
    }
    });

Original comment by electrot...@gmail.com on 10 Aug 2012 at 11:40

[GoogleCodeExporter]

Sorry for the delay. Our ad provider disabled commercials by accident.

I have enabled the ads again, can you try to reproduce it now? I can confirm 
that this doesn't happen on HTTP streams but it does happen on RTMP stream 
*and* instream API.

Original comment by vil...@lnk.lt on 13 Aug 2012 at 1:02

[GoogleCodeExporter]

Still cannot replicate any issues using rtmp

clip: {

            // baseUrl for both parent and instream clips

            url: "mp4:big_buck_bunny_480p_h264.mp4",
            provider: "rtmp",
            // duration for the parent clip
            //duration: 10,

            // instream playlist
            playlist: [

                // in the middle of the parent clip (ie. "mid-roll") starting at
                // 5 seconds
                {

                    url: "mp4:Elephants_Dream_720-h264-st-aac.mp4", duration: 5, position: 2 
                },
                {

                    url: "mp4:big_buck_bunny_480p_h264.mp4", duration: 5, position: 15
                }

            ]
        },

I'll notify paul to see what is going on. 

Original comment by electrot...@gmail.com on 15 Aug 2012 at 3:55

[GoogleCodeExporter]

More information available, please see: 
http://flash.flowplayer.org/forum/7/104184

a) The bug only appears with "accelerated: true" and "wmode: direct" settings.

b) I have created somewhat reproducible example without OVA: 
http://post.lnk.lt/flow/flow.html

1. Start the video and wait for the mid-roll at 15 seconds.
2. Wait for the mid-roll to finish and main video resumes playing. Memorize 
last frame of the mid-roll (It's a guy standing with a briefcase).
3. Seek back to 10 second mark and wait for the mid-roll to start playing 
again. You can see that second time it starts playing from the *last* frame of 
the mid-roll from step 2 very briefly.

I think some kind of canvas or buffer is not cleared after mid-roll finishes. 
The same last frame is not visible without HW acceleration.

Original comment by vil...@lnk.lt on 24 Oct 2012 at 6:19