[FFmpeg-user] [hw] strange stream behaviour

[hw]

Moritz Barsnick <barsnick at gmx.net> writes:

> On Sat, Aug 12, 2017 at 12:15:01 +0530, Mettavihari D wrote:
>> if you have solved it I would be happy to know the solution
>> If not try to put -report into the command line.
>> 
>> ffmpeg -n -loglevel 8 -report -i http://example.com/foo.m3u8 -codec
>> copy -t 00:10:00 -f mpegts example
>> 
>> and post the output of the log file
>> you may then get a response which will be useful for me also
>
> I agree. At least to understand the "-t" issue, we need to see the
> complete, uncut console output from ffmpeg.
>
> Regarding the apparent stalling: I have no idea. ffmpeg with a high
> enough loglevel (probably default nowadays) reports which m3u8 segments
> it is opening. Does the progress line show any progress? Increase in
> number of frames, in size, does the time increase?

The server does not deliver, and when it does, it does not deliver what
could be considered a "stream".  I´ve got my recording software mostly
finished now, so I can see very well what the server does:


+ requests for the playlist sometimes time out (30s timeout)

+ maybe half the requests for segments listed in the playlist time out,
  and they can time out multiple times (The timeout I´m using for them
  varies; it can take several minutes to receive a segment in full.)

+ segments that appear later in the playlist can be duplicates of
  segments that appear earlier in the playlist, and there is no way to
  tell whether a segment is a duplicate or not before all desired
  segments have been received


I can only say: That sucks badly.

It´s amazing that the ppl running the server are even well paid for.

In any case, I can see how ffmpeg is unable to handle this.  Still I
think it´s a bug that ffmpeg sits around indefinitely trying to record
data that will never arrive.

> For m3u8, it might also be worth finding a tool which actually
> downloads the segments without de-/remuxing them. youtube-dl can
> basically do this, though I haven't figured out how with live m3u8 and
> with plain m3u8 URLs. Otherwise, write a downloader of your own (I have
> done it for non-live URLs) and see if the server does something
> incorrectly - like not providing the segments or stalling on them or
> something.

Yes, that´s what I did, and it´s what the server does.

I need to make a recording over a longer period of time to see if I am
still able to receive all segments, or if I get so far behind that some
will be missing, no matter what I do.


Is it normal to receive 62 duplicate segments when recording over a time
span of 10 minutes?  That is more than half of the segments, i. e. after
unlinking the 62 duplicates, 59 files remain.

But well, I put them together with cat, and the resulting video is
flawless.