Dear FFmpeg users,
I've encountered OOM "issue" when encoding PNG image to AVIF using ffmpeg. I
have an example of successful conversion for the image about 6000x1800x32, but
a bit larger image 7147×1783×32 causes OOM.
Any idea why image raster of 7147×1783×4 ~ 50 MB requires ~ 3 GB of memory
Please do not top-post on this list.
___
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".
And also
I was actually able to reproduce this and see what it wrote in the logs.
This is the error it gets when reading first ts segment from the playlist:
[https @ 022951e4eec0] Stream ends prematurely at 2097152, should be
4743992s speed=N/A
[https @ 0229522014c0] Opening '
Since the freeze seems to appear only with the first entry in the
playlist, within the first download, you also could try to "plow the
road" before actually trying to download via ffmpeg.
e.g. something like this:
wget --spider
sleep 1
ffmpeg
In spider-mode wget doesn't actually download
Ok - I think I will investigate the output from ffmpeg for some of the
failed cases to see what happens. But ffmpeg does somehow skip some
segments, but next time they might be OK.
I also learnt that I can use xerror parameter to stop if it encounters
errors. Then it is easy to detect it without
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
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.00,
104482862-732449232-0.ts?version_hash=c77e8452
#EXTINF:10.00,
104482862-732449232-90.ts?version_hash=c77e8452
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
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
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
10 matches
Mail list logo
