Advice regarding URL Service?

Dev Community Dev/API Corner
1

Unfortunately, I am unable to build my URL service properly without either making a HTTP request in the MediaObjectsForURL() function or passing an additional arg to said function (which would kind of defeat the purpose of the URL service).  In this situation, would it be advisable to use the URL service anyway or forego the URL service entirely and build and play my VideoClipObjects within the channel itself?

2

A common work-around for the need to make extra HTTP requests, is to segregate those into a separate PlayVideo() function. Then the PlayVideo() is invoked via a Callback for the key to the MediaObject's PartObject. eg.

return [
		MediaObject(
			parts = [PartObject(key=Callback(PlayVideo, url=url))],
			container = Container.MP4,
			optimized_for_streaming = True,
			video_codec = VideoCodec.H264,
			audio_codec = AudioCodec.AAC,
			audio_channels = 2
		)
	]

That way, the extra HTTP requests are not made until the client requests playback. In your PlayVideo() function you can make the necessary HTTP requests to determine the final video url and return it like so:

def PlayVideo(url):
  # do necessary steps to find final video_url
  return Redirect(video_url)

If part of the issue is that you don't know ahead of time what container/codecs are used for a given video, you can set the @deferred decorator on your MediaObjectsForURL() function. That tells clients that not to resolve the MediaObjects until a play request is made. That way you can make the necessary requests to find the details and pass it back as appropriate without slowing down loading of long lists of Video Objects.

@deferred
def MediaObjectsForURL(url):
  #make necessary requests to determine final video url and codec/container info
  return Media_Objects 

This method has a couple downsides. First, clients won't be able to display the fancy media-flags indicating what type of media is being represented. Second (and possibly more important), the PMC client can't handle @deferred. The next-generation client PHT, currently in PlexPass-only beta, can. Development on PMC is (for all intents and purposes) frozen so, it won't be added there. If you expect PMC clients to make up a significant portion of your target audience, you might be better off skipping out on the @deferred.

The other option for handling codec/container info that is unknown prior to determining the final video url, is to ignore it. This is a less than ideal approach and will result in most clients automatically requesting that every video be transcoded. It does however work in most cases.

3

Thanks for the advice.  Your right, my main issue is that there can be any number of videos of varying resolution and format available at the target url.  My current workaround is to use a PlayVIdeo() function and to limit to only the video formats that I know are common across all pages.  This is not ideal as many shows have HD versions and those are being left behind.  The @deferred approach is interesting, but until PHT is out of PlexPass, its probably not the way to go.

I am considering adding another level to my navigation which will allow users to select quality before building the MediaObject.  Something like:

- Show

     - Season

          - Episode (I guess I'll have to use a DirectoryObject etc for this)

               - Quality (HTTP Reqauest goes here)

                    - Play video now... etc

This means that it only performs a http request once the episode has been selected, limiting it to one request.  However, it kind of makes the url service useless and I could just then build my mediaobject in the code.  Not ideal, but would work.

4

I had a discussion with Mike(I currently use that decorator in the ViasatPlay plugin Service):

- It works ok with PMC to use the @deferred decorator but only if you are not using stacked content, i.e. multiple PartObjects

So you should be able to build a functioning URL service after all?

5

So you should be able to build a functioning URL service after all?

Thanks for the update.  I'll check it out.  How would this go with other clients such as Android and iOS?  I did end up using the URL service, however not necessarily in the capacity it was designed.  My plugin will actually do the requests to determine the desired video content and append the relevant info to the video url before passing that to the url service. Then, the url service extracts that information from the url and uses it to return the desired video as a single MediaObject.  I'm writing a check now so that the URL service can tell if the url has come from the plugin or somewhere else (for example, Plex It) and to resort to a default fallback if it doesnt have the appended information. Its unconventional, but it works.

6

I know it works with iOS and PlexConnect, not sure about Android.

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.