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".
