Hi all,
I'm trying to debug the following scenario - I have a plugin (that I wrote) that locates an m3u8 playlist. However, the server requires cookies to be sent along with the requests for all the segments.
I can see XBMC properly manage the cookies. It's a variable bitrate list. It also selects the appropriate list of segments and receives the list itself so the cookie jar works.
The problem lies in passing the cookies from XBMC to ffmpeg. In GetFFMpegOptionsFromURL there's new code to take the cookies from CURL and pass them as ffmpeg's "cookies" option.
This seems to work ok, but in Wireshark I can see an empty Cookie header (null string actually).
Is there a way to build ffmpeg in debug so I can see what's going on inside ? Maybe it's the way XBMC passes the cookies string, or some other bug.
I'm working on Windows. Any help is appreciated.
You need to do this on Linux. Just configure XBMC with --enable-debug and you are ready to go.
Hi,
thanks for the info but it will take too much time to set up a Linux box for this. I made some headway and think I've found the problem.
I've added log prints to the get_cookies function in http.c (libavformat).
Here is a pastebin xbmc.log file that shows the problem:
http://pastebin.com/jUQzNwtx
If you look for "ffmpeg" you'll see the debug prints. What basically happens is that the domain for the request is 32 chars long. However, the cdomain within the cookie is 33 chars long
because the cookie specifies it is valid for any sub-domain in that domain, which means it has a leading dot.
Since there is a length check there, the result would be -1 and the code jumps to the done_cookie label, thereby skipping it completely.
I should open a ticket in ffmpeg's tracker but I know team XBMC will not bump the version anyway. Is there a way to incorporate a patch for http.c in XBMC's Git ?
Will such a patch be ignored or be possible?
if its not intrusive and fixes a real issue, there is a good chance it will be pulled.
we only apply patches to ffmpeg which have been accepted upstream. please submit the patch to ffmpeg first.
Thanks guys, I'll come back later to update.
So, if they accept the fix, how is this handled afterwards? pull request?
pull request would be nice. let us know if you need assistance.
Hi again,
I've done the work with the ffmpeg team and submitted a patch. It was accepted into their git repository. I'm attaching a link to the commit.
https://github.com/FFmpeg/FFmpeg/commit/...73ca233b54
The scenario is explained in a ticket I opened:
https://trac.ffmpeg.org/ticket/3336
The patch fixes the issue of playing cookie protected HLS playlists with cookies that specify a sub-domain. I built XBMC with the fix and tested on Windows
and it works correctly.
What is the proper procedure from this point? (I'm rather new to the whole way of working with git). I have the fix in my xbmc fork so I see two options:
1. Pull request for this commit from my fork.
2. Somehow manually merge the commit from ffmpeg's git.
As I said before - I'm really hoping it gets included in Gotham so any help is appreciated.
Thanks in advance!
What we normally do is put together a .patch file as well as the commit to apply (the .patch is useful for when we update ffmpeg later on).
Then do a pull request with that (single commit is fine) and we can review and incorporate.
Thanks!
Jonathan
I lost you there :-)
Do you generate a patch file using git diff ? on what repository? ffmpeg's?
I was under the impression that a pull request is the method by which you can incorporate patches from a forked
repository, but XBMC is not forked from ffmpeg.
I'm probably missing a key concept here...
1. Apply your patch onto XBMC's internal ffmpeg.
2. Use git format-patch to produce a patch file similar to the other ones in the ffmpeg patch directory:
https://github.com/xbmc/xbmc/tree/master...eg/patches
3. Push your changes up to your xbmc repo on github.
4. Pull request from there to xbmc/xbmc.
...
5. We merge it into master.
Cheers,
Jonathan
Ok, so in this process my commit to the fork includes:
1. The updated code (applied by the patch).
2. The patch file itself, added to the XBMC patch file directory (from reading the readme in there..)
I'll go generate the patch file. Luckily, the ffmpeg-devel mailing list expects patches formatted by git format-patch so I learned
how that works :-)
Yup, exactly. The patches folder is so that we have a record of the patches applied on top of vanilla ffmpeg - it makes updating the internal copy of ffmpeg a bit easier.
(After Gotham the plan is to move ffmpeg into a separate repository - at that point it'll just be a fork of ffmpeg's git, thus removing the need to track the patches manually, and meaning all you need to do is ask us to pull in the appropriate commit
Cheers,
Jonathan
PR #4081 created. I apologize in advance for not doing so on a topic branch but it seemed ok since it's an ffmpeg backport.
Most importantly - thanks for all the help!