flowplayer / flash

Flowplayer Flash, the video player for the Web
http://flowplayer.org
283 stars 183 forks source link

streamType value "dvr" not allowed by spec #207

Open phloxic opened 10 years ago

phloxic commented 10 years ago

HDS spec http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/hds/pdfs/adobe-media-manifest-specification.pdf says:


11.22 The element SHALL be a string representing the way in which the media is delivered. The value SHALL be "live", "recorded", or "liveOrRecorded". It is assumed that all representations of the media have the same stream type, hence its placement under the document root. This element MAY be present. The default value SHALL be “liveOrRecorded”.


And under '2. Conventions':


“MUST”, “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.


So our requirement to specify dvr as streamType for DVR seems illegal. See also: http://flowplayer.org/forum/#!/plugins#hds-dvr-cannot-play-timeshi

danrossi commented 10 years ago

That is not correct that is how the parser and index handler manages dispatching DVR events internally not at the plugin level which handles the event. No DVR streamtype no DVR event. Have a look how wowza do it. This has to be configured appropriately in FMS.

phloxic commented 10 years ago

Isn't it an Adobe standard? So their spec should be decisive, not Wowza's implementation? If you looked at the thread I've also encouraged to try dvr streamType regardless - according to user player gets stuck at loading animation; waiting for a minimal sample with latest release.

danrossi commented 10 years ago

If it has "live" in it it's treated as live etc and won't do fragment appending. Thats why wowza has a dvr end point it changes it to "dvr"

danrossi commented 10 years ago

I can devise something to manipulate the type of the manifest after it's returned from the parser. This might work around this issue.

so

clip: { dvr: true }

will configure it as a "dvr" string. Is that what you are after ?

phloxic commented 10 years ago

Not all users can control their streaming servers apparently, so for those cases this would be good. Also in general: While it setting the streamType to dvr in the manifest is documented now, one tends to look at player config and settings and not editing manifest files. Having the power to govern this from the player side alone would certainly the reduce the still recurring dvr question (even from those who can set up their server to generate manifests with streamType dvr).

chuic commented 10 years ago

Hello, The flowplayer support team suggest me to join this thread to get the quickest reponse. The test stream url was provided in the mail list. What can I do to accelerate to solve this issue?

chuic commented 10 years ago

Please use the HDS Stream below as a test url. http://nscreenlivetest.media.hinet.net/live/pool/erictest-rtmptest01/nms-hd-hds/erictest-rtmptest01.f4m The DVR Period is set to 600 seconds. I had tried the url with flowplayer. It seems like the time in control bar can render dvr info properly but not the scroll bar. Here's the test page. http://mp4aptest.media.hinet.net/verifyPlayer/HDSPlayer_3.2.18.aspx?MediaPath=http://nscreenlivetest.media.hinet.net/live/pool/erictest-rtmptest01/nms-hd-hds/erictest-rtmptest01.f4m Hope this could be helpful.

danrossi commented 10 years ago

Yes its returning a type of live not dvr hence the problem, it has to be overriden after the parsing.

danrossi commented 10 years ago

I agree there is too many occurrances on FMS/AMS because there is no default manifest config for this it's just setup as live which is silly. @anssip ok to do ?

chuic commented 10 years ago

How's this issue going?

danrossi commented 10 years ago

Hi this is a feature request so i'm waiting on confirmation to actually do it, it's a simple change though.

chuic commented 10 years ago

flowplayer Hi, I found something interesting. As you can see the picture above, the onPlayStatus event in clip get the info type dvr. It seems that a module does parse this manifest as a dvr stream. Hope this would help. Is it possible to you to release a patch for testing?

danrossi commented 10 years ago

I just tried to run this and its down again.

chuic commented 10 years ago

Try this one: http://mp4aptest.media.hinet.net/verifyPlayer/HDSPlayer_reconnect.aspx?MediaPath=http://nscreenlivetest.media.hinet.net/live/pool/himedia-livestream03/hd-hds-pc/himedia-livestream03.f4m

danrossi commented 10 years ago

Sorry about the misunderstanding. It seems if you have some dvr metadata like

<dvrInfo
    windowDuration="600">
  </dvrInfo>

It will detect it as dvr and send the appropriate events internally which the plugin uses to update the dvr time. If this is missing it needs the streamType set to dvr. The plugin detects this to update the clip property to "dvr"

I think what you are trying to get at is you cannot seek into the dvr area, I am experiencing this and have to debug it.

danrossi commented 10 years ago

there is serious timestamp issues, the duration is not being updated correctly and the fragment timestamp just stays the same it's very strange. Check your backend perhaps thats why seeking is not working.

chuic commented 10 years ago

I tried a player that can play and seek correctly. Here's the link http://mp4aptest.media.hinet.net/grindplayer/grindplayer.html?src=http://nscreenlivetest.media.hinet.net/live/pool/himedia-livestream03/hd-hds-pc/himedia-livestream03.f4m

danrossi commented 10 years ago

have a look at the timestamp in the player.

chuic commented 10 years ago

Did you get any info on the timestamp issue?

danrossi commented 10 years ago

http://nscreenlivetest.media.hinet.net/live/pool/himedia-livestream03/hd-hds-pc/himedia-livestream03.f4m is now a live stream only there is no dvr information. The timestamp is progressing normally with this one.

chuic commented 10 years ago

Sorry for that. Use this one instead. http://nscreenlivetest.media.hinet.net/live/pool/himedia-livestream03/hd-hdst-pc/himedia-livestream03.f4m

chuic commented 10 years ago

Is there any new progress on this issue?

danrossi commented 10 years ago

I don't see anything wrong, you have dvr metadata in your feed so it can have a streamtype of live. If there is no dvr information it needs to have a streamtype of dvr but it looks like I can possibly change this fixing a bug for something different. Your encoding is bad, look at the timestamp it never progresses.

chuic commented 10 years ago

Would you explain what you meant by the encoding is bad and the timestamp never progresses? Thanks.

chuic commented 10 years ago

I also found a OSMF Player that can parse this test stream correctly and can seek through past 30 minutes. I embedded the above dvr stream inside. Here's the test link: http://mp4aptest.media.hinet.net/verifyPlayer/osmfTest.html

danrossi commented 10 years ago

As I keep explaining, seek back and observe the timestamp it keeps jumping backwards this is not normal. It should be progressing naturally. I've never seen this before. Perhaps it has something to do with this window setting but I doubt it. Stream isn't playing for me though. Try a different stream. How are you publishing the stream exactly , FMS or Wowza ?

chuic commented 10 years ago

You might check the network traffic. Now the stream is a black picture and no sound. But when looking at the network traffic, you can see the request for fragment keeping on. When you shift the time, the player requested for previous fragment which can be told from the sequential number of requested fragment.

danrossi commented 10 years ago

@blacktrash I fixed the other issue when no dimensions are set which is required and standard on f4m feeds. however overriding the dvr setting requires a feed setup like this for testing. Ie stream type as live but is actually dvr and no window duration tag set. It picks up as dvr if the window duration config is set. If there is such a stream let me know and I can push it through with this change.

chuic commented 10 years ago

The test stream is online. http://nscreenlivetest.media.hinet.net/live/pool/himedia-livestream03/hd-hdst-pc/himedia-livestream03.f4m The osmf page can play the stream well and can time-shift. http://mp4aptest.media.hinet.net/verifyPlayer/osmfTest.html

Please check this again. Thanks

chuic commented 10 years ago

Hi, Do you have any idea on this?

danrossi commented 10 years ago

I've lost track now with what the problem is exactly. I will try to find the time to setup a stream with a window duration in wowza to see what its doing.