Hi, reply below.
On 27/09/2023 11:03, Torsten Kaiser wrote:
Waiting longer might not be helping. What if the first entry is indeed up to 5 seconds
long, then immediately switching the source to the next URL? New URL, new TLS-handshake.
Browsers do indeed wait longer and retry multiple times to get a lock to the next bit of
any web content. Visible to the user by the "hour glass".
But: Knowing the location of the source m3u8 could provide the opportunity to
download the playlist itself via [wget <m3u8-url>]. The following link to
Wikipedia describes the structure of m3u-files.
https://en.wikipedia.org/wiki/M3U
So it's all plain text. Media entries are local relative links or URLs, so you
may want to keep the m3u8's location
Replacing the m3u8-filename with one of the media entries in question (if local
append whole path, otherwise replace the whole construct with the URL-entry)
should be a valid URL to the media source, provided the issuer allows access
without evaluating the http-referer as being of its own realm.
So prepared, try to use ffmpeg with this single media file as input url ,
watching for errors.
No solution, but trying to circumvent suspected problems with certain entries
in the playlist, narrowing down the problem
(And learned for myself what hides behind HLS streaming)
On 27.09.23 09:00, Stein Rune Risa wrote:
Hi!
This is a very stable and well known source, so the network is also stable.
There are never any issues streaming through their official player.
I also see that the streams are delivered through well known CDN - so it
should be fine.
But I will try the xerror option. It is better to detect errors than
getting some problem with the file.
It also seems that the hiccup always happens within the first 5 seconds of
the stream - so there might be some "initial delay" when initializing the
stream. Is there some parameter for ffmpeg to kind of allow longer response
times from the source?
On Wed, Sep 27, 2023 at 8:16 AM Torsten Kaiser <i...@linux-rebellen.de>
wrote:
Looks like you download a known playlist from some unstable network
connection.
To get a grasp on this: If you set the -xerror switch like
ffmpeg -y -xerror -i https://file.com/myfiles.m3u8 -c copy /tmp/test.mkv
what happens? Download should stop at the first buggy/missing segment of
the playlist. Now repeat the download multiple times to see if the
problem is random or not.
Missing segments could be a DRM problem or invalid/outdated entries in
the playlist. If the download always misses the same segment it's most
likely the segment entry is invalid.
Buggy segments are most likely either already buggy in the source or a
network bottleneck. If the faults always occur on the same spot, then
the source itself is most likely already buggy. Encountered this myself
on legacy sources digitized from VHS tapes. Sometimes content is more
important than quality.
On 26.09.23 22:36, Stein Rune Risa wrote:
I am using ffmpeg to download some streaming to a mkv file. The stream parts
comes in a m3u8 file.
ffmpeg -y -i https://file.com/myfiles.m3u8 -c copy /tmp/test.mkv
In some cases, there have been some issues downloading some of the segments,
and the mkv files have parts where it freezes for some seconds before
continuing. I am now forced to check the file manually (by watching) and then
redownload if it has any issues.
I guess this happens because ffmpeg temporarily is not able to download some of
the segments referred to in the m3u8?
Is there some way that I can force ffmpeg to retry failed segments? Or at least
abort if it happens? I am kind of looking for a way to get rid of themanual
checking of the content.
As Torsten pointed out, the problem could be DRM or outdated/unavailable
segments. I have had no problems using the following code, with a user agent
string which keeps the website happy and downloads all segments from most
websites, maybe it will help with your instance. This example is to download a
copyright-free movie from PlexVideos:
ffmpeg -user_agent "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML,
like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" -i
"https://vod-content.plexvideos.com/streams/62be17835e5872e950b87398/0f59c0e3-59ad-4362-8cf2-11f8508c46f2/stream_6.m3u8"
-c copy -y the_brain_that_wouldn't_die.mkv.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".