 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Server Forum / Windows Media Server / December 2007Server side playlists and src param..
Hi! I have specified a src in the playlist like this: lpp://Publishingpoint?WMContentBitrate=20000 But even though the publishing point does have a stream below 20 000 Bps this parameter is ignored. It works however when applied directly to the file name for an on-demand publishing point. Am I missing here something or is this really not working? Thanks! Atmapuri >Hi! > [quoted text clipped - 9 lines] > >Am I missing here something or is this really not working? It *may* be overriden by server or publishing point limit values : http://www.microsoft.com/windows/windowsmedia/howto/articles/urlmodifiers.aspx#u rlmodifiers_advancedfaststart refers specifically to player and distribution server applications. You've got an unusual example by using lpp, which doesn't then go over the network layer for data transfer efficiency within the same server. So as a guess, using this scheme it's intended that you establish your limit on the publishing point which references the lpp protocol / path instead. Currently I would expect using lpp to deliver the complete stream content referenced by the stream URL to the secondary publishing point, then to apply any limits supplied on the secondary publishing point to output only matching stream bitrates specified To force it to go over the network layer instead, what happens if you specify publishing point URL instead as a local (but real) URL such as http://127.0.0.1/Publishingpoint?WMContentBitrate=20000 ? HTH Cheers - Neil ------------------------------------------------ Digital Media MVP : 2004-2007 http://mvp.support.microsoft.com/mvpfaqs Hi! I forgot about the publishing point limits. Thanks a lot! About URL param for WMContentBitrate, will this work with any media player? I mean, is this server parameter passed always to the server? Will the player and server still try to negotiate different (higher) speeds. I was looking at how to deliver each stream quality on its own publishing point so that those issues could be bypassed. Is there a way to reduce the buffering time delay between publishing points (cca 30s) for that purpose? > To force it to go over the network layer instead, what happens if you > specify publishing point URL instead as a local (but real) URL such as > http://127.0.0.1/Publishingpoint?WMContentBitrate=20000 ? No effect of the WMContentBitrate param. All the same. Can you please explain what is the difference between lpp in http link, with an example please? What is complete content, wrapper playlist etc.. Thanks! Atmapuri >>Hi! >> [quoted text clipped - 33 lines] > Digital Media MVP : 2004-2007 > http://mvp.support.microsoft.com/mvpfaqs >I forgot about the publishing point limits. Thanks a lot! Yeah I did wonder what you were up to specifying parameters ;-) >About URL param for WMContentBitrate, will this work >with any media player? I mean, is this server parameter passed >always to the server? Yes, if you pass it to the player (or use it in a http or rtsp URL to the server from a distribution server) it should be passed. There may be some versions of the player which don't respect that - I'd suspect Mac WMP9 and Pocket PC versions *may not* (though they may do) Other player versions including WMP6.4 should pass any URL parameters since it's simply part of the request string for the content. >Will the player and server still try to negotiate different (higher) speeds. The contenbitrate is part of the negotiation process, and limits the server from sending anything ~higher~ than the specified limit. It may still stream select from any of the remaining lower bitrate streams though. So if you had 400, 300, 200 and 100kbps streams and set a contentbitrate of 350kbps, the server would ignore the 400kbps stream, then negotiate with the player and try to deliver 300 and lower as determined from the network capability of the player. Note Mac and PPC WMP don't negotiate correctly and *may* only receive the lowest possible bitrate as a result (they don't actually log their network capacity to the server so it plumps for the safest - lowest bitrate) >I was looking at how to deliver each stream quality on its own publishing >point so that those issues could be bypassed. You may be trying to solve an issue that doesn't exist ? >Is there a way to reduce the buffering time delay between publishing points >(cca 30s) for that purpose? There should be no delay using lpp:// as above, so you're on the right track there. >> To force it to go over the network layer instead, what happens if you >> specify publishing point URL instead as a local (but real) URL such as [quoted text clipped - 46 lines] >> Digital Media MVP : 2004-2007 >> http://mvp.support.microsoft.com/mvpfaqs ------------------------------------------------ Digital Media MVP : 2004-2007 http://mvp.support.microsoft.com/mvpfaqs Hi! I forgot about the publishing point limits. Thanks a lot! About URL param for WMContentBitrate, will this work with any media player? I mean, is this server parameter passed always to the server? Will the player and server still try to negotiate different (higher) speeds. I was looking at how to deliver each stream quality on its own publishing point so that those issues could be bypassed. Is there a way to reduce the buffering time delay between publishing points (cca 30s) for that purpose? > To force it to go over the network layer instead, what happens if you > specify publishing point URL instead as a local (but real) URL such as > http://127.0.0.1/Publishingpoint?WMContentBitrate=20000 ? No effect of the WMContentBitrate param when used inside the src attribute. All the same. Can you please explain what is the difference between lpp in http link, with an example please? What is complete content, wrapper playlist etc.. Thanks! Atmapuri >>Hi! >> [quoted text clipped - 33 lines] > Digital Media MVP : 2004-2007 > http://mvp.support.microsoft.com/mvpfaqs |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.