-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: HLS stream URLs get truncated in ffmpeg #1548
Comments
I have the same problem when downloading videos from PornHub. The site generates three types of links to videos. Two types of links are short and one type is long. FFmpeg cuts off part of the address, so the video does not download. For example: |
I'm not able to reproduce this on linux, even when using much longer urls. |
@Julusian are there any chances that this only takes place in Windows? |
This bug is Windows-specific. It can be reproduced with the following command: ffmpeg -y -i "https://cv-h.phncdn.com/hls/videos/202410/07/458776431/1080P_4000K_458776431.mp4/index-v1-a1.m3u8?YZV3BADjVrQI7TsPwCzpCBVtarJIGx4L5kK03HOOK8Z1DxlgTqArmrQatvpRliqGZa9WfJYhLrq_0SyVyQhdW2TvDrPLKAl2_a2WGAz58hH7Z2QwqAA3A_sURHrVh1pjgglylaPCGmDd7ry-frsOzGajIfvh1Z01NQ26JP1C7Ke7pyIz2ra9fvisGdRwGMElQ3uXATBMUw" -c:v copy -bsf:a aac_adtstoasc "test.mp4" Result:
|
Observed Behavior
It is observed that in some cases, the internal ffmpeg library, truncates the HLS URL which causes valuable authentication data to be discarded. This leads to invalid video stream urls and eventually to stopping HLS playback.
By looking at the logs, the issue seems to take place inside the 'https' thread, since the 'hls' thread always logs the correct (full length) URL path.
The pattern of the failing URLs makes me think that the root cause of this case, could be the query parameter length of the HLS URL, since it is only observed when the URL contains the authentication data in query parameters, instead of inside the URL path.
We have been loading HLS video streams from the same video providers for a long time and no change has been made on the video source, meaning that the same HLS URLs format used to work well with CCG v2.07.
I am adding for your reference the log files for those two cases, a faulty one (in which the URL contains path parameters) and a successful one (in which the URL contains only path parameters).
Faulty case:
Successful case:
Expected behaviour
When loading an HLS stream, we would expect CasparCG to start the playback of it's chunks without altering their URL, eventually causing validation errors on the video streaming server.
Steps to reproduce
Environment
Issue was not present in version 2.07
The text was updated successfully, but these errors were encountered: