-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash inside sws_scale with certain inputs #576
Comments
Oh, my no. Well, not by choice, and not in the sense that I have any particular knowledge of that code — @eisneinechse and @jonoomph would be the go-tos/primaries. But in the sense that I'd like to see this fixed and can help turn the wheels on getting a PR merged, yes definitely.
Absolutely! Heck, I'd be interested in you submitting it unpolished, or polishing it along the way. If it's truly in an un-finished state, just throw It's always easiest to discuss code changes in the context of the actual code, and the simplest path to that is an open PR. While it's possible to view branches in forked repos, comment on commits, and discuss in-development changes that way, it's just not as convenient. (For starters, it makes it much harder for any third parties to find or jump into those conversations.)
Mmm, I see where we have libopenshot/include/FFmpegUtilities.h Line 162 in 414a2cd
...in multiple places, actually: libopenshot/include/FFmpegUtilities.h Line 178 in 414a2cd
I suspect that was done because that's how all of the int avpicture_layout(const AVPicture* src, enum AVPixelFormat pix_fmt, int width, int height,
unsigned char *dest, int dest_size)
{
return av_image_copy_to_buffer(dest, dest_size,
(const uint8_t * const*)src->data, src->linesize,
pix_fmt, width, height, 1);
}
int avpicture_get_size(enum AVPixelFormat pix_fmt, int width, int height)
{
return av_image_get_buffer_size(pix_fmt, width, height, 1);
}
int avpicture_alloc(AVPicture *picture,
enum AVPixelFormat pix_fmt, int width, int height)
{
int ret = av_image_alloc(picture->data, picture->linesize,
width, height, pix_fmt, 1); ...But I can also see where, in terms of the modern FFmpeg API, that's just wrong, and was only done out of necessity for the (That was even a documented limitation of the
By hardcoding |
So, yes, I'll assume that we want to continue to allocate image buffers ourselves, rather than take advantage of the FFmpeg helper functions to handle that sort of thing. (Perhaps those helpers don't DTRT with respect to the rest of our code paths, especially where older API compatibility has to be preserved — a valid reason to call Rather than just switching to hardcoding
So, #define AV_ALLOCATE_IMAGE(av_frame, pix_fmt, width, height) \
av_image_alloc( \
av_frame->data, av_frame->linesize, width, height, \
pix_fmt, av_cpu_max_align())
#define AV_GET_IMAGE_SIZE(pix_fmt, width, height) \
av_image_get_buffer_size(pix_fmt, width, height, av_cpu_max_align()) ...would be far superior to our current Digression: FFmpeg compatibilityThis marks yet another way that FFmpeg 3.2 is especially problematic for us. (It's already lacking in Travis tests, because it isn't part of any still-supported Ubuntu LTS release. Xenial uses FFmpeg 2.8, and Bionic jumps right to 3.4.) It may make sense at some point to realign our various revision "lanes" along a split of FFmpeg 4.0+ / FFmpeg 3.4+ / FFmpeg 2.x (with FFmpeg 3.0 and 3.2 explicitly not supported), in contrast with our current split which consists of:
There's no question in my mind that at least the last one should be dropped regardless. My open PR #455 proposes to do just that, and would make FFmpeg 2.4 our minimum compatible version — though I'd prefer to be even less conservative, and drop support for all FFmpeg < 3.4, if not < 4.0. |
I don't personally see any value in supporting the old ffmpegs, and the pain associated with it is very large. I'd love to drop < 3.4 or even better, < 4.0 |
Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention. This issue will be closed, as it meets the following criteria:
We'd like to ask you to help us out and determine whether this issue should be reopened.
Thanks again for your help! |
It's easily reproducible to get both invalid reads and writes (causing a crash; valgrind shows more detail of what's wrong) by using an input video whose width is not a multiple of 4. The underlying issue is that the alignment passed to a bunch of libav functions is 1, but for sws_scale to work in general it is apparently supposed to be 32 (the answer here helped me a lot: https://stackoverflow.com/questions/31253485/how-do-you-resize-an-avframe/31270501#31270501 ).
@ferdnyc this seemed up your alley--I have a rough patch that fixes the problem. Would you be interested in me polishing it up and submitting it? I'd love a second set of eyes because this is tricky stuff.
The text was updated successfully, but these errors were encountered: