0

Video chapters and timecodes

What exactly does nextChapter and prevChapter do when playing a stream? Do these take chapter codes out of mp4 containers?

Also is there any way to arbitrarily skip to a time code within a file or http video stream?

by
13 Replies
  • QUOTE (Wade @ Apr 30 2009, 04:54 PM) <{POST_SNAPBACK}>
    What exactly does nextChapter and prevChapter do when playing a stream? Do these take chapter codes out of mp4 containers?

    Also is there any way to arbitrarily skip to a time code within a file or http video stream?


    nextChapter and prevChapter are not supported. Are you seeing this in the developer docs?

    As to arbitrarily skipping ahead, this will be supported soon. Once the API is implemented I will update the forums with more information.

    -Jeremy
    0
  • QUOTE (Jeremy Johnstone @ May 1 2009, 10:38 AM) <{POST_SNAPBACK}>
    nextChapter and prevChapter are not supported. Are you seeing this in the developer docs?

    As to arbitrarily skipping ahead, this will be supported soon. Once the API is implemented I will update the forums with more information.

    -Jeremy


    Yes, these functions are listed under TVPlaybackControl. If the API for arbitrary jumping is coming soon though, that's good enough for our purposes.

    I have a few other questions/issues with video playback in general. I had an old widget that was handling everything manually using direct calls to tv.mediaPlayer, but after digging around in the Y! Video widget and some of the KONtx includes, I found KONtx.videoplayer and KONtx.control.VideoTransportOverlay, which both work fantastically well inside the simulator, and do seemingly nothing on the actual TV hardware. There's very little documentation on video playback as is, and of course none on these two, so I probably shouldn't be using them. Are these two objects going to be implemented in the future, or something with similar features?
    0
  • QUOTE (Wade @ May 1 2009, 10:53 AM) <{POST_SNAPBACK}>
    Yes, these functions are listed under TVPlaybackControl. If the API for arbitrary jumping is coming soon though, that's good enough for our purposes.

    I have a few other questions/issues with video playback in general. I had an old widget that was handling everything manually using direct calls to tv.mediaPlayer, but after digging around in the Y! Video widget and some of the KONtx includes, I found KONtx.videoplayer and KONtx.control.VideoTransportOverlay, which both work fantastically well inside the simulator, and do seemingly nothing on the actual TV hardware. There's very little documentation on video playback as is, and of course none on these two, so I probably shouldn't be using them. Are these two objects going to be implemented in the future, or something with similar features?



    The video player and video transport overlay are recent updates to the KONtx Framework and I'm working on adding these to the Developer Guide in the next release.

    The JavaScript TV API (including TVPlaybackControl) is a generated interface from the OEM's media player implementation. Please note that Playback Control Support enumeration constants are used by the OEM to indicate which TVPlaybackControl functionality is supported by the OEM's specific media player (see path.control.doesSupport()). The KONtx Framework provides a toolbox of media player functionality that sits on top of the JavaScript TV API.

    Thank you,
    Kelly
    0
  • QUOTE (TVWidgetDocs @ May 1 2009, 12:22 PM) <{POST_SNAPBACK}>
    The video player and video transport overlay are recent updates to the KONtx Framework and I'm working on adding these to the Developer Guide in the next release.

    The JavaScript TV API (including TVPlaybackControl) is a generated interface from the OEM's media player implementation. Please note that Playback Control Support enumeration constants are used by the OEM to indicate which TVPlaybackControl functionality is supported by the OEM's specific media player (see path.control.doesSupport()). The KONtx Framework provides a toolbox of media player functionality that sits on top of the JavaScript TV API.

    Thank you,
    Kelly


    Oh good, I really would like to keep using those objects. Regarding the disconnect between the simulator and the actual TV however, would you have any clue as to why I'm getting nothing but a black screen on the TV? Here's my relevant createView code:
    CODE
    	createView: function() 
    {
    this.controls.overlay = new KONtx.control.VideoTransportOverlay().appendTo(this);
    this.controls.videoplayer = new KONtx.videoplayer();
    this.controls.videoplayer.attachAccessory(this.controls.overlay);
    /* Must overload the _getVideoURL function as our CDN URLs expire too quickly */
    this.controls.videoplayer._getVideoURL = function()
    {
    var url = new URL();
    var result = url.fetch(this._playlist[this._currentVideoPos].urls.base);
    var doc = XMLDOM.parse(result);
    return doc.evaluate("string(sctp/response/url)");
    }
    }


    The updateView calls changePlaylist with all the appropriate URLs, and then startPlaylist. As I've mentioned, the simulator handles this fine (except for the poor video render performance), but the TV gives me a blank screen. No overlay, no video, no audio, all I can do is press Return to get back to my sidebar widgets. I also hope overloading _getVideoURL is not a problem, this is something we sort of depend upon as our service URLs have time constraints on them, so loading an entire playlist beforehand would cause all but maybe the first two items to expire.
    0
  • I believe you are not directly writing over the _getVideoURL function like you are thinking. I believe the code should look like the below with the call to the function definition changed.


    CODE
    	createView: function() 
    {
    this.controls.overlay = new KONtx.control.VideoTransportOverlay().appendTo(this);
    this.controls.videoplayer = new KONtx.videoplayer();
    this.controls.videoplayer.attachAccessory(this.controls.overlay);
    /* Must overload the _getVideoURL function as our CDN URLs expire too quickly */
    this._getVideoURL = function()
    {
    var url = new URL();
    var result = url.fetch(this._playlist[this._currentVideoPos].urls.base);
    var doc = XMLDOM.parse(result);
    return doc.evaluate("string(sctp/response/url)");
    }
    }
    0
  • QUOTE (WidgetRealm @ May 1 2009, 02:55 PM) <{POST_SNAPBACK}>
    I believe you are not directly writing over the _getVideoURL function like you are thinking. I believe the code should look like the below with the call to the function definition changed.


    CODE
    	createView: function() 
    {
    this.controls.overlay = new KONtx.control.VideoTransportOverlay().appendTo(this);
    this.controls.videoplayer = new KONtx.videoplayer();
    this.controls.videoplayer.attachAccessory(this.controls.overlay);
    /* Must overload the _getVideoURL function as our CDN URLs expire too quickly */
    this._getVideoURL = function()
    {
    var url = new URL();
    var result = url.fetch(this._playlist[this._currentVideoPos].urls.base);
    var doc = XMLDOM.parse(result);
    return doc.evaluate("string(sctp/response/url)");
    }
    }


    Nope, that doesn't do what I'm looking for, and does not work on the simulator. _getVideoURL is a method on KONtx.videoplayer(), not the SideBarView, and it's used for traversing the playlist array stored inside KONtx.videoplayer(). What I want to do is store a slew of intermediate URLs inside the videoplayer class, and when it attempts to load the next one, pull the intermediate URL to get the real URL. This is useful as it lets us have time expiring URLs, as well as lets us track actual play calls when using a third party CDN. On the simulator I am able to override the videoplayer._getVideoURL just fine, but some part of my video player is not working correctly on the actual TV, with no logging facilities I can't be certain what's failing.

    What I can garner from watching server logs while running the TV is that updateView is running as it pulls the list of intermediate URLs. After that, I never see another call to the server and the TV leaves me at a blank screen. I would at least expect to see a call to the intermediate URL, which would happen even if _getVideoURL weren't properly overridden, but I get nothing. It's almost as if the KONtx.videoplayer doesn't behave at all similar to the version found in the simulator, but I'm grasping at straws here myself.

    I don't suppose there's any way I could get some sort of logging facility on the TV to try to figure out where exactly it's failing? Most things have been good enough between the simulator and the hardware, but this doesn't behave at all like what I was expecting.
    0
  • That sounds extremely strange.

    Perhaps, moving the function call out of the createView and only activating the list pull when the updateView is activated. Is the URL pull needed only once or every time the Video player is activated?
    0
  • QUOTE (WidgetRealm @ May 1 2009, 04:26 PM) <{POST_SNAPBACK}>
    That sounds extremely strange.

    Perhaps, moving the function call out of the createView and only activating the list pull when the updateView is activated. Is the URL pull needed only once or every time the Video player is activated?


    It's a little odd, I'm sure, but the function isn't really in createView, it's being attached/overloaded to the instance of KONtx.videoplayer that is created. Doing this in updateView would be like reinstantiating it every time you come back to the player view, even if it's already cached with the updated _getVideoURL().

    Here's the process flow we're using, maybe to help illustrate better what I'm going for.

    1. Query server for a play list
    2. Server returns a list of Video IDs
    3. Store said IDs locally, to avoid unnecessary round trips
    4. When playing back, do a request to our server with the Video ID (http://foobar.com/retrieve/videostream?id=1234)
    5. Server generates a hashed token for our CDN which expires in 30 minutes, and feeds it back in XML to the client
    6. Client parses server response, pulls the actual (CDN with hashed token) URL to the video stream (http://cdn.com/video1234.mp4?auth_token=12346786)


    I suppose I can manage this externally by subscribing to messages, and feeding one item at a time to the videoplayer class, but it is duplicating a decent chunk of work on the client, which already is overtaxed. As you've seen, I've been trying to move steps 4, 5 and 6 into the _getVideoURL function, as that function is called every time a new item is played. As I've mentioned, this all works great on the emulator, I'm just worried I might be doing something wrong at a deeper level. I'm going to take some time and rewrite it for now using messages and single length play lists managed outside of the videoplayer class until we can figure out a better solution.
    0
  • QUOTE (Wade @ May 1 2009, 12:34 PM) <{POST_SNAPBACK}>
    Oh good, I really would like to keep using those objects. Regarding the disconnect between the simulator and the actual TV however, would you have any clue as to why I'm getting nothing but a black screen on the TV? Here's my relevant createView code:

    The updateView calls changePlaylist with all the appropriate URLs, and then startPlaylist. As I've mentioned, the simulator handles this fine (except for the poor video render performance), but the TV gives me a blank screen. No overlay, no video, no audio, all I can do is press Return to get back to my sidebar widgets. I also hope overloading _getVideoURL is not a problem, this is something we sort of depend upon as our service URLs have time constraints on them, so loading an entire playlist beforehand would cause all but maybe the first two items to expire.


    The reason for the disconnect in experience is that the Samsung TVs until late this afternoon did not have the same Framework code which the WDK does have. If you turn your TV on, load up the dock, leave it sit for 10 minutes, then power cycle the TV, it should load the updates now that they are released.

    Unfortunately the TV will then have newer code than the WDK has and the Video API changed slightly (but critically). I will lobby for at minimum a new Framework package to be sent out to those working on video widgets early next week.

    When I get home tonight I will try and document the relevant changes on the forum so you can start writing code against the new APIs which you will receive soon in the next WDK. The APIs as they stand now will be backwards compatible going forward, just we had to make a few tweaks after getting feedback from early adopters.

    -Jeremy
    0
  • QUOTE (Jeremy Johnstone @ May 1 2009, 06:13 PM) <{POST_SNAPBACK}>
    The reason for the disconnect in experience is that the Samsung TVs until late this afternoon did not have the same Framework code which the WDK does have. If you turn your TV on, load up the dock, leave it sit for 10 minutes, then power cycle the TV, it should load the updates now that they are released.

    Unfortunately the TV will then have newer code than the WDK has and the Video API changed slightly (but critically). I will lobby for at minimum a new Framework package to be sent out to those working on video widgets early next week.

    When I get home tonight I will try and document the relevant changes on the forum so you can start writing code against the new APIs which you will receive soon in the next WDK. The APIs as they stand now will be backwards compatible going forward, just we had to make a few tweaks after getting feedback from early adopters.

    -Jeremy


    Thank you very much Jeremy! I was beginning to think I was going to have to start harassing my POC with hourly builds until I could get something that works on the TV properly. I'm glad to know it's just a WDK version mismatch. I don't have the TV at my disposal at the moment, but I'll get to my office to test tomorrow. I'll look forward to the documented changes coming, and I guess work with the version mismatch for the next few days until the software WDK catches up.
    0
  • Jeremy - thank you! I am guessing the update will also take care of the playlist stopping issue. Much appreciated.
    0
  • QUOTE (WidgetRealm @ May 1 2009, 10:39 PM) <{POST_SNAPBACK}>
    Jeremy - thank you! I am guessing the update will also take care of the playlist stopping issue. Much appreciated.


    It should! If you see any issues, be sure and let me know asap.

    -Jeremy
    0
  • QUOTE (Jeremy Johnstone @ May 1 2009, 06:13 PM) <{POST_SNAPBACK}>
    The reason for the disconnect in experience is that the Samsung TVs until late this afternoon did not have the same Framework code which the WDK does have. If you turn your TV on, load up the dock, leave it sit for 10 minutes, then power cycle the TV, it should load the updates now that they are released.

    Unfortunately the TV will then have newer code than the WDK has and the Video API changed slightly (but critically). I will lobby for at minimum a new Framework package to be sent out to those working on video widgets early next week.

    When I get home tonight I will try and document the relevant changes on the forum so you can start writing code against the new APIs which you will receive soon in the next WDK. The APIs as they stand now will be backwards compatible going forward, just we had to make a few tweaks after getting feedback from early adopters.

    -Jeremy


    Jeremy,

    I've updated my TV, now I get a little bit further, but still no actual video playback and not seeing any of the requests I was attempting to overload, but at least now I'm seeing the videotransport overlay. Is there any ETA on the video changes, as well as the up to date framework?
    0

Recent Posts

in General - Yahoo! TV Widgets