0

Protocols

Does the WDK only support HTTP protocol or does it support other streaming protocols like RTSP or RTMP/Flash?

by
19 Replies
  • QUOTE (c.penny67 @ Mar 13 2009, 02:58 AM) <{POST_SNAPBACK}>
    Does the WDK only support HTTP protocol or does it support other streaming protocols like RTSP or RTMP/Flash?


    The TV platforms don't currently support it, so even if the WDK did, it wouldn't help you.
    0
  • QUOTE (Jeremy Johnstone @ Mar 13 2009, 10:07 AM) <{POST_SNAPBACK}>
    The TV platforms don't currently support it, so even if the WDK did, it wouldn't help you.


    what protocols does the TV platforms support ? only http or any other protocols.
    I tried to give the videoplayer a UDP:// locator, and it can buffering,but cannot play, so what happened during this process,does the player support such streaming protocols?

    I use vlc streaming server to stream the video
    0
  • Does the framework and/or tv's actually support streaming at all? Because of this post I have been trying to get a stream playing in the simulator and on the samsung tv, but nothing seems to work. Neither WMV9 or MP4 via HTTP are being played.

    Is there a special way of using the videoplayer or mediaplayer classes to get streaming to work?

    I have build a widget based on the news widget and the videoplayer widget, to browse through categories of video and then playing them. I am using plain http download for the video's, which works with smaller files (< 60Mb) but when the files get bigger the videoplayer simply never starts and I can't get out of the player anymore (have to turn off the tv)

    Can anyone please help? I am sure there must be a solution, since I am not the only one that want's to play video's longer than a few minutes...

    TV:
    Samsung LE40B650
    Software Version: T-CHL7DEUC-2004.1

    Production simulator:
    Virtualbox, Ubuntu 8.04, ywe-wdk-0.9.7.6-i386
    0
  • QUOTE (Nico @ Oct 29 2009, 05:52 AM) <{POST_SNAPBACK}>
    I am using plain http download for the video's, which works with smaller files (< 60Mb) but when the files get bigger the videoplayer simply never starts and I can't get out of the player anymore (have to turn off the tv)



    The problem is that you aren't properly encoding your files based on the symptoms above. All encoders have an option for enabling "internet streaming" in the protocol (let me know your encoder and I can help) and that allows the file to be streamed over HTTP rather than enforcing the file to be downloaded before playback can begin. You are lucking out that the player has enough memory to buffer the files which did work in your test, otherwise you would have failed on them too.

    -Jeremy
    0
  • Hello,
    Apologies if this is a flood of questions:

    STREAMING TRANSPORT CONTROL:
    It looks to me like progressive download over HTTP is the only 'streaming' supported meaning the "download stream" will buffer and start playback before whole clip is fully downloaded, but there is no means for true streaming transport control i.e jumping to near the end of a video clip without having to download/watched up to that point. Can you confirm?

    STORAGE:
    Do the TV's require enough storage (Flash-Memory) for the whole video clip file size to view the last frame (Which would preclude playback of very long clips) or is there smart FIFO storing of only the next few seconds of buffering (Meaning no limit to the length of clips).?

    RTMP:
    Under the current no RTMP/Flash setup a BBC iplayer or HULLU "type" widget is not possible correct? (AFAIK iplayer uses RTMP within flash with sorenson / vp6 codec on non PC platforms). Are there real plans even if roadmap is a year or so away to include Flash Lite or even just the video components of Flash Lite within the Widget platform spec?

    TV CONNECTED DEVICES
    I am sure your sick of answering questions about flash but it would opens some cool areas like video conferencing widgets where OEMs could add a webcam&mic to the TV and expose to flash. If there is some other plan for this sort of situation I would love to know details.
    0
  • QUOTE (david4482 @ Nov 5 2009, 09:26 AM) <{POST_SNAPBACK}>
    Hello,
    Apologies if this is a flood of questions:

    STREAMING TRANSPORT CONTROL:
    It looks to me like progressive download over HTTP is the only 'streaming' supported meaning the "download stream" will buffer and start playback before whole clip is fully downloaded, but there is no means for true streaming transport control i.e jumping to near the end of a video clip without having to download/watched up to that point. Can you confirm?


    After studying ISO 14496-12 and ISO 13818-1,2,3 this limitation is mostly one of first-generation player architectures.

    We recently wrote a JMF DataSource for the Blackberry that shattered all those assumption. Not only did we overcome Blackberry's inability to download any file larger than 256K, we got it to play a 1-hour 100M 3GP file via HTTP. It is entirely possible for a player using HTTP to seek to particular times inside a piece of media, ESPECIALLY with an ISO 14496-12 -derived video.

    When we tricked the Blackberry JMF into thinking that the 100 Mbyte video was available locally we observed it read the first few bytes of the resource, then jump to the end (which we accomplished using the bog-standard Range: header) to slurp up the metadata which includes per-frame pointers. Once it had the metadata it was easy to fetch whatever subset of the URL contained the audio and video needed for rendering.

    The requirement that the metadata occur before the 'mdat' box is something that can be relaxed by investing less than a week of coding. Random access to files via HTTP is a blind spot for many coders. This obsolete limitation can be observed in mplayer, J2ME, and android. This limitation can and should be removed. The only question is how long it will take the various coders to read section 13.35 of RFC 2616.
    0
  • QUOTE (mutantbob @ Nov 5 2009, 11:40 AM) <{POST_SNAPBACK}>
    After studying ISO 14496-12 and ISO 13818-1,2,3 this limitation is mostly one of first-generation player architectures.

    We recently wrote a JMF DataSource for the Blackberry that shattered all those assumption. Not only did we overcome Blackberry's inability to download any file larger than 256K, we got it to play a 1-hour 100M 3GP file via HTTP. It is entirely possible for a player using HTTP to seek to particular times inside a piece of media, ESPECIALLY with an ISO 14496-12 -derived video.

    When we tricked the Blackberry JMF into thinking that the 100 Mbyte video was available locally we observed it read the first few bytes of the resource, then jump to the end (which we accomplished using the bog-standard Range: header) to slurp up the metadata which includes per-frame pointers. Once it had the metadata it was easy to fetch whatever subset of the URL contained the audio and video needed for rendering.

    The requirement that the metadata occur before the 'mdat' box is something that can be relaxed by investing less than a week of coding. Random access to files via HTTP is a blind spot for many coders. This obsolete limitation can be observed in mplayer, J2ME, and android. This limitation can and should be removed. The only question is how long it will take the various coders to read section 13.35 of RFC 2616.

    Very interesting. I'm not sure I understand what section 13.3.5 of RFC 2616 has to do with this though, as it is about Non-validating Conditionals. I assume you meant 13.3.5 as I could not find 13.35.
    0
  • QUOTE (Steve @ Nov 5 2009, 12:30 PM) <{POST_SNAPBACK}>
    Very interesting. I'm not sure I understand what section 13.3.5 of RFC 2616 has to do with this though, as it is about Non-validating Conditionals. I assume you meant 13.3.5 as I could not find 13.35.


    Magnificent. I mistyped it. Section 14.35 is the Range header.

    It allows you to retrieve a subsection of a URL. This is how you would retrieve the mdat box from the end/middle of any file derived from ISO 14496-12. It would also allow you to seek to the middle of a movie.
    0
  • Interesting stuff. I was wondering whether it would be possible to view content from the iPlayer or other services such as 4OD, or 5 On Demand. They all use Flash-based players but I'm not sure what actual files they stream behind the scenes.. iPlayer must use more than just one, since it can detect an iPhone & stream a Quicktime compatible file.
    0
  • BTW, there's an interesting post on this page about how they achieved it for the iPhone including the format they use.

    http://www.bbc.co.uk/blogs/bbcinternet/200...e_behind_t.html
    0
  • QUOTE (Matt @ Nov 6 2009, 05:01 AM) <{POST_SNAPBACK}>
    Interesting stuff. I was wondering whether it would be possible to view content from the iPlayer or other services such as 4OD, or 5 On Demand. They all use Flash-based players but I'm not sure what actual files they stream behind the scenes.. iPlayer must use more than just one, since it can detect an iPhone & stream a Quicktime compatible file.


    My recommendation would be to focus on HTTP rather than stream-of-the-month protocols. HTTP is a lot easier to cache on the edge to save network bandwidth and improve performance. I'm sure there are plenty of vendors who would love to sell your ISP in-house CDN boxes to accelerate streams for their paying customers, but there are free HTTP caches.
    0
  • I too am looking at implementing progressive download in a tv widget.
    This thread provides some clues, but there is still no direction/documentation/examples on implementing this essential feature.

    Am I missing some Yahoo TV documentation?

    Exactly how do I Initiate a video download as progressive?
    How do I Skip to next keyframe on a ffwd action?
    0
  • Hi

    Are there any encoding specifications listed anywhere? I have tried WMP9, VC1 and H264 all over http but always get an error in the simulator. Do the files need to be encoded at a particular size or aspect ratio?

    Any help would be much appreciated.
    0
  • QUOTE (josh.melrose@... @ Nov 17 2009, 08:50 AM) <{POST_SNAPBACK}>
    Hi

    Are there any encoding specifications listed anywhere? I have tried WMP9, VC1 and H264 all over http but always get an error in the simulator. Do the files need to be encoded at a particular size or aspect ratio?

    Any help would be much appreciated.

    Pg. 18 of the developer guide has the specs. The simulator is not necessarily a reliable way to test video. I have yet to get video working in my emulator, but it works fine when uploaded to a TV.
    0
  • QUOTE (josh.melrose@... @ Nov 17 2009, 08:50 AM) <{POST_SNAPBACK}>
    Hi

    Are there any encoding specifications listed anywhere? I have tried WMP9, VC1 and H264 all over http but always get an error in the simulator. Do the files need to be encoded at a particular size or aspect ratio?

    Any help would be much appreciated.



    Can you provide me the streams and I can try and get you better reasons for the failures?

    -Jeremy
    0
  • QUOTE (Jeremy Johnstone @ Dec 2 2009, 03:53 PM) <{POST_SNAPBACK}>
    Can you provide me the streams and I can try and get you better reasons for the failures?

    -Jeremy

    Does the videoplayer only support http?
    0
  • QUOTE (Shangan @ Apr 15 2010, 11:25 PM) <{POST_SNAPBACK}>
    Does the videoplayer only support http?


    Currently, only progressive http streaming is supported on all Televisions.
    Jim
    0
  • QUOTE (henrykemp@... @ Nov 9 2009, 01:59 AM) <{POST_SNAPBACK}>
    How do I Skip to next keyframe on a ffwd action?


    None of the TVs in production support ffwd on HTTP streams at this time. All you can do is seeking (aka jumping to a relative or absolute offset).

    -Jeremy
    0
  • mutantbob -> Can you reach out to me at tvwidgets [at] widgetrealm [dot] com?

    Look forward to connecting.
    0

Recent Posts

in General - Yahoo! TV Widgets