mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-25 15:15:51 +03:00
[GH-ISSUE #38] Odd numbered dimensions crash FFmpeg encoder #36
Labels
No labels
copy cats
duplicated
future feature
pull-request
⬜ Accepted
⬜ Completed
⬜ Help Wanted 💪
⬜ In Progress
⬜ Missing Details
⬜ Pending
⬜ Waiting For Answer ⏳
🆕 feature preview
🔷 Bug 🐛
🔷 Out Of Scope
🔷 Out Of Scope
🔷 Question
🔷Enhancement
🔷Enhancement
🔷Invalid / External
🔷Knowledge Base
🔷Won't Fix
🕑 High
🕑 High
🕑 High
🕕 Medium
🕙 Low
🕛 Critical
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ScreenToGif#36
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
@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.
@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
@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 (Apr 18, 2017):
With the fixes made for v2.7, this bug should not happen anymore (unless I forgot something).