After investigating a question which was posed in this forum here http://forums.runrev.com/viewtopic.php?f=70&t=16963…I've discovered that m3u8 files play back on the IOS native player on a mobile stack without problems but they cannot play back these same files on the LC desktop player on a desktop stack.
Disclaimer: I've only tested this on OSX 10.8.4.
and yes, I know that the conventional wisdom and general implementation of the Apple HLS technology is handled mostly through HTML5 on the web browser.
But what if we want to play these m3u8 files with the desktop player from inside an LC desktop app (stack) just as we are able to do with an LC mobile app?
I've tried to play a m3u8 playlist through the Quicktime player on OSX and when I go to "file-->open location" and then enter the url containing my m3u8, it plays the file.
But I also tried "file-->open url" in Quicktime player 7 and QT7 cannot read nor play these files.
So, is there a bug in the actual LC desktop player code or could it be still using an obsolete QT code which needs to be updated?
Or am I the only one with this issue?
Any input you have would be greatly appreciated,
Camster.
LC desktop player cannot play m3u8 files?
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Re: LC desktop player cannot play m3u8 files?
Hi Camster,
If QT7 can't read the files, then it isn't a LiveCode bug. Since m3u8 contains UTF8 encoded file URL's, maybe you can just read the file and play those files one by one.
Kind regards,
Mark
If QT7 can't read the files, then it isn't a LiveCode bug. Since m3u8 contains UTF8 encoded file URL's, maybe you can just read the file and play those files one by one.
Kind regards,
Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
Re: LC desktop player cannot play m3u8 files?
Ok, let me rephrase this problem, this way:
While, QT x player can read the m3u8 files,
QT7 player cannot,
AND
While, the LC mobile player can read the m3u8 files,
The LC desktop player cannot.
QT7 is based on old technology and code (32 bit…older codecs...etc)
QT x is based on newer architecture (fully native 64 bit…uses modern codecs…etc)
If the LC Mobile player can read these files and
if the LC desktop player cannot,
then the later must be based on either on an obsolete QTKit (from Apple)
or else on a buggy/incomplete or defective code implementation of the QTkit framework. The actual desktop code does not seems to allow it to "opt" and switch to the QT x optimized technology which alone can read the new HLS files.
With the QTkit, a developer is able to control and choose to opt and adopt QT x for playback or use the older QT7 code with one method call. This switch is transparent to the users.
More about this QT architecture here:
https://developer.apple.com/library/mac ... -CH111-SW1
So, my point here is to show that the code used in the LC desktop player, which is based both on the QTkit from Apple and on the LC code development, is not doing the switching correctly in order to read the HLS files.
Apple who is providing the QTkit obviously did not implement the LC desktop player code in LiveCode, did they? Therefore the LC desktop player is "buggy" and/or obsolete and especially to a commercial developer and others who needs to use this technology. This must be "fixed" so it can read and play the m3u8 files just like the LC mobile player does. Hence, my post.
Mark, thank you for your suggestion to read the m3u8 one by one but this will not work for this adaptive live stream technology which is usually based on 4 to 10 second segmentations of many .TS files. I am afraid this solution would not work, especially when companies need to read hundreds of these streams in real time.
Trust me, fixing the desktop player is a much better, cheaper and more professional solution. (please take this from a developer with almost 30 years of pro. programming…)
Best regards,
Camster.
While, QT x player can read the m3u8 files,
QT7 player cannot,
AND
While, the LC mobile player can read the m3u8 files,
The LC desktop player cannot.
QT7 is based on old technology and code (32 bit…older codecs...etc)
QT x is based on newer architecture (fully native 64 bit…uses modern codecs…etc)
If the LC Mobile player can read these files and
if the LC desktop player cannot,
then the later must be based on either on an obsolete QTKit (from Apple)
or else on a buggy/incomplete or defective code implementation of the QTkit framework. The actual desktop code does not seems to allow it to "opt" and switch to the QT x optimized technology which alone can read the new HLS files.
With the QTkit, a developer is able to control and choose to opt and adopt QT x for playback or use the older QT7 code with one method call. This switch is transparent to the users.
More about this QT architecture here:
https://developer.apple.com/library/mac ... -CH111-SW1
So, my point here is to show that the code used in the LC desktop player, which is based both on the QTkit from Apple and on the LC code development, is not doing the switching correctly in order to read the HLS files.
Apple who is providing the QTkit obviously did not implement the LC desktop player code in LiveCode, did they? Therefore the LC desktop player is "buggy" and/or obsolete and especially to a commercial developer and others who needs to use this technology. This must be "fixed" so it can read and play the m3u8 files just like the LC mobile player does. Hence, my post.
Mark, thank you for your suggestion to read the m3u8 one by one but this will not work for this adaptive live stream technology which is usually based on 4 to 10 second segmentations of many .TS files. I am afraid this solution would not work, especially when companies need to read hundreds of these streams in real time.
Trust me, fixing the desktop player is a much better, cheaper and more professional solution. (please take this from a developer with almost 30 years of pro. programming…)
![Smile :)](./images/smilies/icon_smile.gif)
Best regards,
Camster.