Moritz Barsnick <[email protected]> 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. _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
