• 1
  • 25
  • 26
  • 27
  • 28
  • 29(current)
FFmpeg version bump + XBMC add-on patches.
Quote:FYI; FFmpeg 2.0 was released yesterday.

Summarized changelog of new new major features from http://ffmpeg.org
July 10, 2013, FFmpeg 2.0
We have made a new major release (2.0) It contains all features and bugfixes of the git master branch from 10th July. A partial list of new stuff is below:
...
- 3D LUT filter (lut3d)
...
Sorry to necro this thread, does the above mean that when/if ffmpeg2.0 is incorporated into xbmc that xbmc will have 3dlut support, similar to what madvr does today? If so that would be excellent!

Big Grin
Reply
(2013-09-01, 21:22)shahid_xbmc Wrote: Latest Gotham build still doesn't support HLS that needs cookies

I've actually encountered this problem before. Here's a link to my post - http://forum.xbmc.org/showthread.php?tid=169172
(a bit long, needs to be read carefully..)

I had problems building XBMC on Windows and then couldn't continue working on it. I managed to find the problems and have
some time to try again. The problem IMO is passing the cookies from XBMC to ffmpeg.

FFmpeg does support cookies and all, but sometimes those cookies are set when the add-on communicates with the server.
Therefore, XBMC should be able to somehow pass those to ffmpeg which isn't handled today.

Once ffmpeg has the actual cookies it should manage.

Also, another problem is that some of those fancy content providers (Akamai being one) are able to be very picky.
XBMC will attempt to discover the MIME type using a HEAD request. In my case, the server rejects HEAD requests
completely. Re-sending it as GET works though. To overcome this I set the MIME type myself at the python level.
Crooked, but worked :-).
Reply
Small update -

I fixed my environment and built XBMC successfully on windows. While there is new support for passing cookies from XBMC to ffmpeg, it still doesn't work.
I can see, in GetFFMpegOptionsFromUrl that the code accesses CURL's cookies, sets them as the "cookies" option for ffmpeg.

In Wireshark I can see a Cookie: header but the value is null, possibly due to an ffmpeg bug. If this requires any sort of fix to ffmpeg, what can be done ?

I've read that the team bumps the ffmpeg version only once per major version..
Reply
we intent to do this more frequently but this requires some changes to the build process first. work on this has started.
Reply
i hope this can help
ffmpeg 2.1.3
https://github.com/mrdominuzq/xbmc/tree/xbmc-ffmpeg2

all patches are applied besides the backports.

there are still some deprecrated things.
Reply
@mrdominuzq: https://github.com/FernetMenta/FFmpeg/co...bmc-master
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
just a minor version ahead Tongue

another question, is there a reason why we compile with w32threads instead of pthreads ?
Reply
We are in the process of moving ffmpeg out of the internal tree and we'll look at the build process too.

EDIT: we use pthreads on platforms where pthreads are available.
Reply
perfect thanks for the answer Smile
Reply
(2014-02-13, 19:12)mrdominuzq Wrote: another question, is there a reason why we compile with w32threads instead of pthreads ?

Because this would require to add another library for windows and we have already quite a dll mess which needs to be cleaned in a near future. What is the gain on using pthreads on windows instead of w32threads?
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
i dont think there is a gain using pthreads over w32threads or visa versa Smile
Reply
(2013-12-31, 00:10)voguemaster Wrote:
(2013-09-01, 21:22)shahid_xbmc Wrote: Latest Gotham build still doesn't support HLS that needs cookies

I've actually encountered this problem before. Here's a link to my post - http://forum.xbmc.org/showthread.php?tid=169172
(a bit long, needs to be read carefully..)

I had problems building XBMC on Windows and then couldn't continue working on it. I managed to find the problems and have
some time to try again. The problem IMO is passing the cookies from XBMC to ffmpeg.

FFmpeg does support cookies and all, but sometimes those cookies are set when the add-on communicates with the server.
Therefore, XBMC should be able to somehow pass those to ffmpeg which isn't handled today.

Once ffmpeg has the actual cookies it should manage.

Also, another problem is that some of those fancy content providers (Akamai being one) are able to be very picky.
XBMC will attempt to discover the MIME type using a HEAD request. In my case, the server rejects HEAD requests
completely. Re-sending it as GET works though. To overcome this I set the MIME type myself at the python level.
Crooked, but worked :-).

Could you tell me how to fix problem i got some akamai m3u8(akamai AES HLS) urls that doesnt play on xbmc windows(and xbmc little black box ) live tv add on!
Reply
(2015-01-18, 17:38)david14 Wrote:
(2013-12-31, 00:10)voguemaster Wrote:
(2013-09-01, 21:22)shahid_xbmc Wrote: Latest Gotham build still doesn't support HLS that needs cookies

I've actually encountered this problem before. Here's a link to my post - http://forum.xbmc.org/showthread.php?tid=169172
(a bit long, needs to be read carefully..)

I had problems building XBMC on Windows and then couldn't continue working on it. I managed to find the problems and have
some time to try again. The problem IMO is passing the cookies from XBMC to ffmpeg.

FFmpeg does support cookies and all, but sometimes those cookies are set when the add-on communicates with the server.
Therefore, XBMC should be able to somehow pass those to ffmpeg which isn't handled today.

Once ffmpeg has the actual cookies it should manage.

Also, another problem is that some of those fancy content providers (Akamai being one) are able to be very picky.
XBMC will attempt to discover the MIME type using a HEAD request. In my case, the server rejects HEAD requests
completely. Re-sending it as GET works though. To overcome this I set the MIME type myself at the python level.
Crooked, but worked :-).

Could you tell me how to fix problem i got some akamai m3u8(akamai AES HLS) urls that doesnt play on xbmc windows(and xbmc little black box ) live tv add on!


I sincerely doubt XBMC/Kodi has a problem playing those now. All those problems were basically fixed in FFmpeg and XBMC has better support for it too.
Are the playlists playable in VLC via Open URL? If so, then maybe there's a problem. I often saw content providers making it harder to access the streams
without doing some sort of fancy "security" stuff like providing the proper ticket or having the cookie contain a token that is valid for that session
(which is in turn generated by making requests in a special manner).

If the stream/playlist isn't playable via VLC as well this probably means it's not XBMC's fault..
Reply
  • 1
  • 25
  • 26
  • 27
  • 28
  • 29(current)

Logout Mark Read Team Forum Stats Members Help
FFmpeg version bump + XBMC add-on patches.0