[FFmpeg-user] ffmpeg retry failed segments

Stein Rune Risa steinrr at gmail.com
Wed Sep 27 13:30:40 EEST 2023


The entries in the m3u8 file looks like this:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.000000,
104482862-732449232-0.ts?version_hash=c77e8452
#EXTINF:10.000000,
104482862-732449232-900000.ts?version_hash=c77e8452
#EXTINF:10.000000,
104482862-732449232-1800000.ts?version_hash=c77e8452
#EXTINF:10.000000,
104482862-732449232-2700000.ts?version_hash=c77e8452
#EXTINF:10.000000,
104482862-732449232-3600000.ts?version_hash=c77e8452
#EXTINF:10.000000,
104482862-732449232-4500000.ts?version_hash=c77e8452

And there are nothing wrong with these, it is just that sometimes streaming
the m3u8 with ffmpeg, causes the output mkv file to have a "freeze" after 5
seconds, and then the video goes on playing. The hypothesis is that it has
not downloaded some of the first ts-segments successfully. If I try once
more, it normally is OK.

So looking for a way to either retry or abort on error.

SR


On Wed, Sep 27, 2023 at 11:04 AM Torsten Kaiser <info at linux-rebellen.de>
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 <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".
> _______________________________________________
> 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".
>


More information about the ffmpeg-user mailing list