[ 
https://issues.apache.org/jira/browse/FLEX-33374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erik Thomas updated FLEX-33374:
-------------------------------

    Description: 
The spark VideoDisplay on Mobile devices delays streaming video from FMS 4.5 
for about a minute before it begins playing. 

I've attached a project that displays this behavior. Run it in AIR on your 
desktop or in a simulator, then run it on a device that's using WiFi with the 
same bandwidth as your computer to see the difference.

This is probably a problem in OSMF but I'm posting it here for visibility to 
the problem.

UPDATE 2/1/2013 - I wrote my own video controller and display classes that just 
use NetConnection, NetStream, and Video classes. This is a more optimized 
solution for mobile anyway, to not use heavyweight OSMF classes underneath the 
spark VideoPlayer and VideoDisplay classes. So I'm not waiting on this fix and 
suggest anyone building a mobile video player should do what I did anyway. Of 
course we have to do our own bandwidth testing which requires a server-side asc 
on FMS, but that's actually working better than VideoDisplay's adaptive 
bitrates anyway that resize the video way too often. And I'll still have to add 
some reconnect logic in case the stream is interrupted.

  was:
The spark VideoDisplay on Mobile devices delays streaming video from FMS 4.5 
for about a minute before it begins playing. 

I've attached a project that displays this behavior. Run it in AIR on your 
desktop or in a simulator, then run it on a device that's using WiFi with the 
same bandwidth as your computer to see the difference.

This is probably a problem in OSMF but I'm posting it here for visibility to 
the problem.

UPDATE 2/1/2013 - I wrote my own video controller and display classes that just 
use NetConnection, NetStream, and Video classes. This is a more optimized 
solution for mobile anyway, to not use heavyweight OSMF classes underneath the 
spark VideoPlayer and VideoDisplay classes. So I'm not waiting on this fix and 
suggest anyone building a mobile video player should do what I did anyway. Of 
course we have to do our own bandwidth testing which requires a server-side asc 
on FMS, but that's actually working better than VideoDisplay's adaptive 
bitrates anyway that resize the video way too often.

    
> spark VideoDisplay and VideoPlayer fails to stream video on mobile devices
> --------------------------------------------------------------------------
>
>                 Key: FLEX-33374
>                 URL: https://issues.apache.org/jira/browse/FLEX-33374
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: Spark: VideoPlayer
>    Affects Versions: Adobe Flex SDK 4.6 (Release)
>         Environment: FlashBuilder 4.7 on Windows 7, iPad 3, iPhone 4, remote 
> FMS 4.5 server, FLV Video source in 112K bitrate.
>            Reporter: Erik Thomas
>            Priority: Minor
>         Attachments: VideoDisplay.jpg, VideoPlayback.zip
>
>
> The spark VideoDisplay on Mobile devices delays streaming video from FMS 4.5 
> for about a minute before it begins playing. 
> I've attached a project that displays this behavior. Run it in AIR on your 
> desktop or in a simulator, then run it on a device that's using WiFi with the 
> same bandwidth as your computer to see the difference.
> This is probably a problem in OSMF but I'm posting it here for visibility to 
> the problem.
> UPDATE 2/1/2013 - I wrote my own video controller and display classes that 
> just use NetConnection, NetStream, and Video classes. This is a more 
> optimized solution for mobile anyway, to not use heavyweight OSMF classes 
> underneath the spark VideoPlayer and VideoDisplay classes. So I'm not waiting 
> on this fix and suggest anyone building a mobile video player should do what 
> I did anyway. Of course we have to do our own bandwidth testing which 
> requires a server-side asc on FMS, but that's actually working better than 
> VideoDisplay's adaptive bitrates anyway that resize the video way too often. 
> And I'll still have to add some reconnect logic in case the stream is 
> interrupted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to