2014-08-11, 12:30
Hi,
I'm investigating a bug in playing https hls streams. Example: the stream linked here.
Right now the way xbmc handles these hls streams is they parse the top level playlist, select an appropriate bandwidth stream, and then pass it off to FFMPEG (along with the user agent, cookies, etc).
FFMPEG plays it without any difficulty. I've added some logging and I can see that everything after the initial request for the top-level m3u8 looks correct (cookies are set, user agent is good, etc). What I cannot see is the header data for the initial request... its made by the CurlFile, but in my local build of xbmc, I can't seem to find a way to output the initial request. So I have two questions I hope someone can help with:
1) How can i view the encrypted ssl request to make sure its consistant with the subsequent requests made by ffmpeg? I tried to find the curl lib source to just print it like I do for FFMPEG, but I'm coming up short.
2) Any other thoughts on what could be stuffing this up?
I'm investigating a bug in playing https hls streams. Example: the stream linked here.
Right now the way xbmc handles these hls streams is they parse the top level playlist, select an appropriate bandwidth stream, and then pass it off to FFMPEG (along with the user agent, cookies, etc).
FFMPEG plays it without any difficulty. I've added some logging and I can see that everything after the initial request for the top-level m3u8 looks correct (cookies are set, user agent is good, etc). What I cannot see is the header data for the initial request... its made by the CurlFile, but in my local build of xbmc, I can't seem to find a way to output the initial request. So I have two questions I hope someone can help with:
1) How can i view the encrypted ssl request to make sure its consistant with the subsequent requests made by ffmpeg? I tried to find the curl lib source to just print it like I do for FFMPEG, but I'm coming up short.
2) Any other thoughts on what could be stuffing this up?