starred/ScreenToGif

Fork 0

mirror of https://github.com/NickeManarin/ScreenToGif.git synced 2026-04-25 23:25:52 +03:00

[GH-ISSUE #38] Odd numbered dimensions crash FFmpeg encoder #1404

New issue

Closed

opened 2026-03-01 18:45:14 +03:00 by kerem · 4 comments

kerem commented

2026-03-01 18:45:14 +03:00

Owner

Originally created by @ghost on GitHub (Nov 22, 2016).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/38

Hi Nicke,

I tried to use this tool to encode a gif to a WebM file and the FFmpeg encoder kept pitching errors. All other encoders worked fine. I pulled source and examined it, extracted the shell execution string, then ran it myself outside of the program, executing FFmpeg directly. FFmpeg doesn't like having an odd number for the width dimension. I got into that state because I have 50% dpi scaling on my secondary monitor and it rounded it to an odd number when it captured it. FFmpeg wouldn't even attempt a conversion, it just kicked back a generic failure with something along the lines of "Byte Array not convertible."

I got around this by converting the capture group to a compatible dimension, but it took hours. I'd rather just have the program tack on a line of #000000 bits to the edge just to make everything line up (alternately flat out lie about the dimensions and give it an extra pixel col/row). Also, FFmpeg should really handle that case with more grace :|. Lots of falling down all over the place, and not much on you!

Thanks,
--Erick Lewis

Originally created by @ghost on GitHub (Nov 22, 2016). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/38 Hi Nicke, I tried to use this tool to encode a gif to a WebM file and the FFmpeg encoder kept pitching errors. All other encoders worked fine. I pulled source and examined it, extracted the shell execution string, then ran it myself outside of the program, executing FFmpeg directly. FFmpeg doesn't like having an odd number for the width dimension. I got into that state because I have 50% dpi scaling on my secondary monitor and it rounded it to an odd number when it captured it. FFmpeg wouldn't even attempt a conversion, it just kicked back a generic failure with something along the lines of "Byte Array not convertible." I got around this by converting the capture group to a compatible dimension, but it took hours. I'd rather just have the program tack on a line of #000000 bits to the edge just to make everything line up (alternately flat out lie about the dimensions and give it an extra pixel col/row). Also, FFmpeg should really handle that case with more grace :|. Lots of falling down all over the place, and not much on you! Thanks, --Erick Lewis

kerem

2026-03-01 18:45:14 +03:00

closed this issue
added the
🔷 Bug 🐛
label

kerem commented

2026-03-01 18:45:15 +03:00

Author

Owner

@NickeManarin commented on GitHub (Nov 22, 2016):

Hi Erick,

I was working with this issue this weekend, this problem indeed happens with a high DPI environment. Windows gives me strange values for the Top, Left, Width and Height, like 15.677778. Rounding this values sometimes gives me different values.

I'll keep working on trying to fix this issue before release a new version. Thanks for the feedback.

@NickeManarin commented on GitHub (Nov 22, 2016): Hi Erick, I was working with this issue this weekend, this problem indeed happens with a high DPI environment. Windows gives me strange values for the Top, Left, Width and Height, like 15.677778. Rounding this values sometimes gives me different values. I'll keep working on trying to fix this issue before release a new version. Thanks for the feedback.

kerem commented

2026-03-01 18:45:15 +03:00

Author

Owner

@ghost commented on GitHub (Nov 22, 2016):

Thanks for responding Nicke!

Like I said, the easiest solution was just to resize it until it found an acceptable dimension and FFmpeg didn't kick back the stream. Probably not the best way to go about it, but definitely most expedient, also known as every programming discussion ever.

If I can help out, let me know, this is outside my area of expertise but I've already got the code and examined a few exceptions.

--Thanks,
Erick Lewis

@ghost commented on GitHub (Nov 22, 2016): Thanks for responding Nicke! Like I said, the easiest solution was just to resize it until it found an acceptable dimension and FFmpeg didn't kick back the stream. Probably not the best way to go about it, but definitely most expedient, also known as every programming discussion ever. If I can help out, let me know, this is outside my area of expertise but I've already got the code and examined a few exceptions. --Thanks, Erick Lewis

kerem commented

2026-03-01 18:45:15 +03:00

Author

Owner

@NickeManarin commented on GitHub (Nov 25, 2016):

Hi Eric,

Can you share with me a faulty recording (with one of the frames with a different resolution)?
I want to narrow down my work that needs to be done. I already know that the "Title Frame" might be the cause. Maybe other thing could generate the same problem.

@NickeManarin commented on GitHub (Nov 25, 2016): Hi Eric, Can you share with me a faulty recording (with one of the frames with a different resolution)? I want to narrow down my work that needs to be done. I already know that the "Title Frame" might be the cause. Maybe other thing could generate the same problem.

kerem commented

2026-03-01 18:45:15 +03:00

Author

Owner

@NickeManarin commented on GitHub (Apr 18, 2017):

With the fixes made for v2.7, this bug should not happen anymore (unless I forgot something).

@NickeManarin commented on GitHub (Apr 18, 2017): With the fixes made for v2.7, this bug should not happen anymore (unless I forgot something).

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ScreenToGif#1404

No description provided.

Rows
Columns