[FFmpeg-user] ffmpeg retry failed segments

[Torsten Kaiser]

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 <info at 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 at ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".