0
1
I'm attempting to cut a gif using -ss
and -t
in FFmpeg but it's drastically decreasing the quality in comparison to the original gif.
I'm using this command:
ffmpeg -y `
-i "S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo EL.gif" `
-ss 1.65 -t 1.65 `
"S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo Short.gif"
I've tried using -c copy
but I get an error saying Error writing trailer
, I also see that there is a gif muxer -c:v gif
but I can't seem to find any options for it.
Is what I'm attempting to do possible, cutting a gif without losing quality?
Full log:
PS C:\Windows\system32> ffmpeg -y `
>> -i "S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo EL.gif" `
>> -ss 1.65 -t 1.65 `
>> "S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo Short.gif"
ffmpeg version N-94652-g808a6717e0 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9.1.1 (GCC) 20190807
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt
libavutil 56. 33.100 / 56. 33.100
libavcodec 58. 55.101 / 58. 55.101
libavformat 58. 31.104 / 58. 31.104
libavdevice 58. 9.100 / 58. 9.100
libavfilter 7. 58.101 / 7. 58.101
libswscale 5. 6.100 / 5. 6.100
libswresample 3. 6.100 / 3. 6.100
libpostproc 55. 6.100 / 55. 6.100
Input #0, gif, from 'S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo EL.gif':
Duration: 00:00:04.01, start: 0.000000, bitrate: 34953 kb/s
Stream #0:0: Video: gif, bgra, 853x480 [SAR 64:64 DAR 853:480], 30 fps, 30 tbr, 100 tbn, 100 tbc
Stream mapping:
Stream #0:0 -> #0:0 (gif (native) -> gif (native))
Press [q] to stop, [?] for help
Output #0, gif, to 'S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo Short.gif':
Metadata:
encoder : Lavf58.31.104
Stream #0:0: Video: gif, bgr8, 853x480 [SAR 1:1 DAR 853:480], q=2-31, 200 kb/s, 30 fps, 100 tbn, 30 tbc
Metadata:
encoder : Lavc58.55.101 gif
frame= 49 fps= 40 q=-0.0 Lsize= 9301kB time=00:00:01.64 bitrate=46460.4kbits/s speed=1.33x
video:9301kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000210%
Original gif creation:
ffmpeg -y `
-i "S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo EL.ts" `
-vf fps=30,scale=-1:480:flags=lanczos,palettegen `
"S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo EL.png"
ffmpeg -y `
-i "S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo EL.ts" `
-i "S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo EL.png" `
-filter_complex "fps=30,scale=-1:480:flags=lanczos[x];[x][1:v]paletteuse" `
"S:\Videos\Saved Clips\PSW\Mad Wooloo\Mad Wooloo EL.gif"
Share full log. – Gyan – 2019-11-17T15:58:20.363
I've added the full log to the end of the post originally via Pastebin, but it looks like someone edited it right into the post. Not sure why I didn't think to look through the log first but I can see that the pixel format is changing from bgra to bgr8, can't seem to keep it bgra though as the gif muxer says bgra is invalid. I'm also noticing that
100 tbc
is changing to30 tbc
though I'm not sure that matters. Last but not least I'm noticing that the output gif only looks worse than the original once I post it in Discord, when viewed directly on my PC it looks fine... see video in post. – Nimble – 2019-11-17T19:17:45.947Few more discoveries, the output gif looks fine when viewed on mobile Discord just not the desktop application. Furthermore, I can use the
-c copy
option just not in conjunction with 'accurate' seek, where I put-ss
after the input. I can put-ss
before the input but then I can't cut as accurately as I'm wanting. However, when I do get a command with-c copy
to run the output looks fine on Desktop Discord, so definitely seeming likebgr8
is the culprit. Weird thatbgra
isn't compatible with the gif muxer, especially when considering that I created the gif using FFmpeg, see post. – Nimble – 2019-11-17T19:51:21.157It was me who edited in the log. We prefer to have everything here. What I meant was showing the log that exhibits the error writing the GIF, not the one that succeeds. But yes, the pixel format may be the culprit. How are you getting
-c copy
to run though, when the pixel format cannot be written? And perhaps you can show the log from the original video creation. The GIF encoder cannot createbgra
output… – slhck – 2019-11-17T21:21:18.780I see what you mean about posting the log with the error, but I found that the error was popping because I was using
-c copy
in conjunction with 'accurate seek'. I can get-c copy
to work when using the more inaccurate seek (where you put-ss
before the input not after), but the problem is that I kinda need accurate seek to get the results I want.-c copy
bypasses the gif muxer, basically when you invoke-c copy
you're choosing not to re-encode, thus bgra is retained. In quite the pickle... can't use accurate seek with-c copy
and can't use-pix_fmt bgra
with gif muxer. – Nimble – 2019-11-17T21:43:27.677I could cut the video before creating the gif, but seek (
-ss
) doesn't cut as exact on my video file as it does the gif file. I believe this is because the video has some unique / harsh settings (forced keyframe intervals, no scene changes, etc.) to ensure that it parts correctly using FFmpeg's-segment
demuxer. I could cut the video to an exact frame with something like Adobe premiere but I find that Adobe's exports are multitudes larger than FFmpeg's and it's important to keep files as small as possible when sharing online in something like Discord. Once again, quite the pickle. – Nimble – 2019-11-17T21:51:39.890