Tiger SVG test case fails sporadically with different output sizes

[2swap]

The case as defined with 1024x768 output passes for me, but changing the dimensions to anything that is not a scaling of that same aspect ratio yields varied memory errors. I have so far seen double free or corruption (out) and free(): invalid pointer.
In the test, I modified the code as follows:

		MovieReader reader("svg_image", width, height);
		{
			MovieWriter writer("svg_image2", width, height);
			{
				vector<uint8_t> pixels;	
				while (1)
				{
					if (!reader.getFrame(pixels))
						break;
				
					writer.addFrame(&pixels[0]);
				}
			cout << "1" << endl;
			}
			cout << "2" << endl;
		}
			cout << "3" << endl;
	}

and furthermore I added logging to the deconstructor of MovieWriter, suspecting that the error was in there:

MovieWriter::~MovieWriter()
{	
			cout << "a" << endl;
	// Writing the delayed frames:
[...]
	cairo_surface_destroy(cairo_surface);
			cout << "z" << endl;
}

The result that I see is:

Writing frame 35 (size = 28)
Writing frame 36 (size = 34)
Writing frame 37 (size = 28)
Writing frame 38 (size = 28)
1
2
a
Writing frame 39 (size = 28)
Writing frame 40 (size = 475)
Writing frame 41 (size = 27)
Writing frame 42 (size = 27)
Writing frame 43 (size = 27)
Writing frame 44 (size = 27)
Writing frame 45 (size = 27)
Writing frame 46 (size = 27)
Writing frame 47 (size = 27)
Writing frame 48 (size = 237)
Writing frame 49 (size = 27)
Writing frame 50 (size = 164)
Writing frame 51 (size = 27)
Writing frame 52 (size = 27)
Writing frame 53 (size = 27)
Writing frame 54 (size = 27)
Writing frame 55 (size = 27)
Writing frame 56 (size = 141)
Writing frame 57 (size = 27)
Writing frame 58 (size = 27)
Writing frame 59 (size = 27)
Writing frame 60 (size = 138)
Writing frame 61 (size = 27)
Writing frame 62 (size = 27)
z
free(): invalid pointer

This is confusing to me: it seems like the moviewriter deconstructor completes as expected, since "z" is printed, but for whatever reason when that local scope defined by the brackets is closed, something else is causing this memory error (since "3" is not printed.)

Wondering if you have any idea. I am using this for a project and I ran into the same error, and I would like to avoid needing to check SVG size every time to match its aspect ratio, assuming that is in fact the issue.

[dmikushin]

Hi @2swap thanks for reporting this. Does valgrind reveal the issue in more detail?

[2swap]

Yeah - looks like there are bad writes on the following line:
sws_scale(swsCtx, ((AVPicture*)pFrame)->data, ((AVPicture*)pFrame)->linesize, 0, c->height, ((AVPicture *)pFrameRGB)->data, ((AVPicture *)pFrameRGB)->linesize);
in MovieReader::getFrame().
Unfortunately I have to run but I'll be back later to investigate further

Also I should note that I get valgrind memory errors even with the correct dimensions - i'm just going to investigate the new one that shows up with the change of dimensions.

[dmikushin]

Not all Valgrind messages are errors, some are legitimate false-positives. But the diff between the two versions as you mentioned indeed should make sense. Most likely, the memory corruption is caused by writing beyond the ((AVPicture *)pFrameRGB)->data buffer boundaries.

[2swap]

No luck so far - any suggestions you have for docs on all of these library function calls?

[2swap]

Ok - I was able to resolve the issue by changing the line from
swsCtx = sws_getContext(c->width, c->height, c->pix_fmt, ...
to
swsCtx = sws_getContext(c->width, c->height, AV_PIX_FMT_BGR24, ....
Printing out the format it was using and reading through the enum, I find c->pix_fmt == AV_PIX_FMT_NONE
So it appears to me this mismatch is what caused the problem. I still have no idea what this is doing under the hood though.

Of course, this fix probably wouldnt work if we read from any video with a different format.

[2swap]

p.s. still seeing strange artifacts in the "copied" video. e.g.:

svg_image2.mp4

Going to worry about that in the morning though.

edit: no it was just because I should have been using AV_PIX_FMT_YUV420P instead of BGR.

[dmikushin]

Thanks for working on this!

still seeing strange artifacts in the "copied" video

This noise looks like skewed pixels. Typically, this is happening when image descriptor does not match the line width in the actual data buffer. Or, if new image incompletely overwrites a data buffer, which was used for older image.

[2swap]

I think you might need to replace
rsvg_handle_free(handle);
with something like
rsvg_handle_close(handle, nullptr);