Open phloxic opened 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.
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.
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"
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 ?
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).
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?
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.
Yes its returning a type of live not dvr hence the problem, it has to be overriden after the parsing.
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 ?
How's this issue going?
Hi this is a feature request so i'm waiting on confirmation to actually do it, it's a simple change though.
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?
I just tried to run this and its down again.
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.
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.
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
have a look at the timestamp in the player.
Did you get any info on the timestamp issue?
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.
Sorry for that. Use this one instead. http://nscreenlivetest.media.hinet.net/live/pool/himedia-livestream03/hd-hdst-pc/himedia-livestream03.f4m
Is there any new progress on this issue?
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.
Would you explain what you meant by the encoding is bad and the timestamp never progresses? Thanks.
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
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 ?
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.
@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.
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
Hi, Do you have any idea on this?
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.
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
asstreamType
for DVR seems illegal. See also: http://flowplayer.org/forum/#!/plugins#hds-dvr-cannot-play-timeshi