Open leftearsons opened 3 months ago
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: Source URL of the video https://cv-h.phncdn.com/hls/videos/202106/29/000000000/1080P_4000K_000000000.mp4/index-v1-a1.m3u8?6MB50lVyuE3XsoDstxOgtlFIS5WiZafP8gykHFLhkeDN6QJHJBdWP584qIVpgkovqyG90vdUcANTJdoyQlEEIfY01AREoa2bE6fFAIgGstWPRzp1XagL4Q1HkrjiEh4ABMzCcuW3ncZCD-Hczh2S2Gc_Jq2YdMpAmbrbbQwUJO0FbaTzlGiD5mri4xWZD0MTNeizdYeJK-w Last 16 simbols are cutted by FFmpeg https://cv-h.phncdn.com/hls/videos/202106/29/000000000/1080P_4000K_000000000.mp4/index-v1-a1.m3u8?6MB50lVyuE3XsoDstxOgtlFIS5WiZafP8gykHFLhkeDN6QJHJBdWP584qIVpgkovqyG90vdUcANTJdoyQlEEIfY01AREoa2bE6fFAIgGstWPRzp1XagL4Q1HkrjiEh4ABMzCcuW3ncZCD-Hczh2S2Gc_Jq2YdMpAmbrbbQwUJO0FbaTzlGiD5mri4xW
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? Just to add here that this seems to be happening only with some specific video providers and not always (8-9 out of 10 times though). Any thoughts what could possibly cause such issues? Is it possible that this could be related to any 3rd party library installed or even to the specific stream URLs format? This issue was first started about a year ago and was not there in the past, even for the same video provider that currently faces the issue. I would really appreciate if you could have a second look on this, since this affects our production systems, causing a lot of issues. Thank you!
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