why is onMetaData called several times?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. onMetaData: function (clip) {
     console.log(clip.metaData);
   }

What is the expected output? What do you see instead?
Expected: onMetaData is a singular event
Instead:
http progressive download video: 2 times
rtmp video:                      3 times
http progressive audio           1 time

But audio does not get the duration right with an empty cache (will file 
separate bug).

I don't really understand why the metaData has to be queried several times - 
this looks more like it is unclear where the definite point to retrieve 
metaData is.

But if it is required to be called several times, it's a bad idea to expose it 
via the API: on which of the onMetaData events should I base my scripting?

Original issue reported on code.google.com by blacktrashproduct on 17 May 2012 at 10:44

[GoogleCodeExporter]

probably need a demo it's only fired if the flash event fires of a metadata 
event. Tested with

mp4:bbb-800
rtmp://s3b78u0kbtx79q.cloudfront.net/cfx/st

and its fine

http://pseudo01.hddn.com/vod/demo.flowplayervod/flowplayer-700.flv

also once.

Original comment by electrot...@gmail.com on 18 May 2012 at 2:22

[GoogleCodeExporter]

Really? Did you check in the console? Look here:

http://flowplayer.blacktrash.org/test/minimal-rtmp.html

has:

onMetaData: function () {
  var info = document.getElementById("info");
  info.innerHTML = info.innerHTML + "<p>onMetaData called</p>";
}

Result: 3 times.

Original comment by blacktrashproduct on 18 May 2012 at 10:47

[GoogleCodeExporter]

Yes using the suggested video tested above not your flv, it looks like your 
file is triggering metadata more than one. 

Original comment by dani...@electroteque.org on 21 May 2012 at 5:17

[GoogleCodeExporter]

I see while autobuffering, thats because it's seeking to 100ms to bring up a 
frame and resending metadata events, this happens within the first metadata 
call. , this event gets triggered outside of the area of the paused to frame 
function. 

Original comment by dani...@electroteque.org on 21 May 2012 at 5:30

[GoogleCodeExporter]

ok, removed autoBuffering: true - but the event is still triggered with every 
seek. Why? And even if the file had strange metadata, that should not influence 
how often onMetaData is fired - or should it?

The way I understand it, onMetaData is fired once between onBegin and onStart. 
After all, a clip's metadata does not change, does it?

progressive download does not call again on seek:
http://flowplayer.blacktrash.org/test/minimal.html

And why should autoBuffering: true trigger another metaData retrieval? We have 
it already don't we?

Original comment by blacktrashproduct on 21 May 2012 at 9:53

[GoogleCodeExporter]

There seems to be a bug with auto buffering it was seeking twice. will have a 
look at metadata being triggered on a seek, 

Original comment by dani...@electroteque.org on 23 May 2012 at 5:17

[GoogleCodeExporter]

http://dl.dropbox.com/u/3394987/flowplayer.rtmp-3.2.10-dev.zip should fix 
partial issue, the sever sends metadata event during a seek. perhaps not a good 
idea to block it being dispatched but on the code end run a flag if its been 
called already.

Original comment by dani...@electroteque.org on 26 May 2012 at 8:30

[GoogleCodeExporter]

Hi onMetadata is being triggered after each seek in rtmp. What do you suggest 
to happen. 

Original comment by dani...@electroteque.org on 4 Jun 2012 at 8:45

[GoogleCodeExporter]

So the rtmp protocol _requires_ the _entire_ (unchanged) metadata to be 
retrieved at each seek?

Just curious.

If that is indeed the case, not firing onMetaData after the first time it was 
triggered might be a good idea.

What could possibly change in the metadata of a video file because of seeking? 
Again, just curious.

Original comment by blacktrashproduct on 4 Jun 2012 at 12:15

[GoogleCodeExporter]

ask the adobe / wowza perhaps it's part of the design. shall we set this up as 
a feature request to prevent onMetdata being triggered more than once during 
playback ? There is already a clip config to flag start has been dispatched, so 
the same could be done for metdata and the connection/stream client will know 
not to resend perhaps.  Apart from that not much else can be done thats what it 
does. 

Original comment by electrot...@gmail.com on 18 Jun 2012 at 4:52

[GoogleCodeExporter]

Changing to enhancement. 

Original comment by electrot...@gmail.com on 18 Jun 2012 at 4:53

• Added labels: Type-Enhancement
• Removed labels: Type-Defect