Kodi Community Forum
AppleHTTP m3u8 files no longer passed to ffmpeg? - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: AppleHTTP m3u8 files no longer passed to ffmpeg? (/showthread.php?tid=123486)

Pages: 1 2


AppleHTTP m3u8 files no longer passed to ffmpeg? - micahg - 2012-02-20

Hi,

I'm trying to sort out a problem that has occured over the past few weeks. Basically, I think that the NHL changed something in their m3u8 files (unicode playlist files) that now has xbmc trying to play them as normal playlists instead of letting ffmpeg play the files as an applehttp stream. For more information see http://forum.xbmc.org/showthread.php?tid=118853&page=5 at around post 43.

In any case, up until a few weeks ago we could just point xbmc at the http://...m3u8 file and it would not try to parse it itself and (I assume) would pass it directly to ffmpeg for play, which worked. Now, it is trying to parse these files on its own. It is able to play them, but there is a long pause between playlist items and the playlist is started from the beginning (instead of at the end, which is preferable for a live event).

So I'm looking for suggestions or comments in trying to come up with a fix. With a newer version of ffmpeg the plugin could just use applehttp://...m3u8, since this demuxer now exists and I think everything would work fine. What are the odds of a resync before Eden is released?

The other (probably incorrect) option I'm trying to think of would be to somehow indicate that this file shouldn't actually be parsed as a playlist by xbmc, and should be handed down to ffmpeg -- any ideas?

TIA


- Thiele - 2012-02-22

I think I have the exact same problem. I created a ticket a while ago, but no response or solution so far. Please see this link for background info and logs: http://trac.xbmc.org/ticket/12447


- micahg - 2012-02-22

Thanks @Thiele, I'll check later to see if it is the same issue.


- Thiele - 2012-02-24

micahg Wrote:Thanks @Thiele, I'll check later to see if it is the same issue.

Any update?


- micahg - 2012-02-24

None yet. I've been trying to track down the area of code when i have time, but haven't got there yet.


- micahg - 2012-03-01

OK, spiff (Arne) has already posted code that fixes this bug. Is there any reason this code cannot be accepted into XBMC? Perhaps we could restrict it to only force m3u8 files that are prefixed with http:// directly onto ffmpeg (right now the code does it for any m3u8 files):

https://github.com/cptspiff/xbmc/commit/27814f16d1612d2d267134d990e8da2e0f65278e


- micahg - 2012-03-01

There is also this bug already that seems closer (more of a feature request though): http://trac.xbmc.org/ticket/11175


- Thiele - 2012-03-01

I'm happy to see that there is some progress :-)


- apok - 2012-03-01

What's the protocol for submitting bugfixes? Can we just cut a minimal patch for passing http and m3u8 to ffmpeg and submit it to that bug ticket?


- micahg - 2012-03-01

I talked with Spiff and this isn't getting in to Eden. After release though ffmpeg is getting a resync (I'm told) so at that point changes can be made to use applehttp:// which should allow plugin developers to use the m3u8 files again.


- apok - 2012-03-01

Depending on which ffmpeg version they go with, they might find that applehttp and hls+http protocols are deprecated/discouraged (at least with the latest build I tested with).


- micahg - 2012-03-01

where did you read that?


- apok - 2012-03-01

L:\ffmpeg-git-a4c22e3-win64-static\bin>ffplay applehttp://www.somedomain.tld/test.m3u8
ffplay version N-38292-ga4c22e3 Copyright © 2003-2012 the FFmpeg developers
built on Feb 27 2012 14:55:47 with gcc 4.6.2
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil 51. 41.100 / 51. 41.100
libavcodec 54. 4.100 / 54. 4.100
libavformat 54. 1.100 / 54. 1.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 62.101 / 2. 62.101
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 7.100 / 0. 7.100
libpostproc 52. 0.100 / 52. 0.100
[applehttp @ 0000000001CAF520] The applehttp protocol is deprecated, use hls+http://www.somedomain.tld/test.m3u8 as url instead.
[applehttp @ 0000000001CAF520] Using the hls protocol is discouraged, please try using the hls demuxer instead. The hls demuxer should be more complete and work as well as the protocol implementation. (If not, please report it.) To use the demuxer, simply use http://www.somedomain.tld/test.m3u8 as url.


- micahg - 2012-03-02

oh wow. That is a recent. But its not all bad, they did modify things so that instead of specifying applehttp://blah you specify hls+http://blah. On the other hand, this also gets the error message about using the demuxer... however, I don't think this one is deprecated (just discouraged).


- Thiele - 2012-03-03

You guys have any idea when this will be fixed in XBMC?