Ticket #2617 reports playback issues involving HLS - running this command: > ffplay > http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8[http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8] > -loglevel debug
results in this final line being printed: > http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8[http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8]: > Server returned 403 Forbidden (access denied) This is caused by libavformat terminating on faulty HTTP headers and, subsequently, upon finding #EXTM3U lines. The attached patch solves this by employing two new compilation flags: - FORBID_EXTM3U_LINES - causes termination when '#EXTM3U' is found; - FORBID_FAULTY_HTTP_HEADERS - causes termination upon faulty HTTP headers. The rationale is that - while parsing HTTP headers and M3U playlists - errors shouldn't abort the program execution; instead any usable data should be recovered as mush as possible, much like a HTML parser would do; also these flags operate upon compilation since users shouldn't normally be burdened with this kind of details - browsers don't prompt for loose HTML parsing either. One immediate advantage of this is that the user will be able to play any M3U playlist without being burdened with minor parsing errors; and there's no visible disadvantage. Verification is done simply by recompiling ffplay upon applying the patch - those flags will just be undefined and so these parsing errors will be ignored at runtime.
0001-make-libavformat-more-tolerant-fixes-2617.patch
Description: Binary data
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
