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
the
manual checking of the content.
_______________________________________________
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".
_______________________________________________
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".
_______________________________________________
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".
_______________________________________________
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".
