View Issue Details

IDProjectCategoryView StatusLast Update
0000337Cinelerra-GG[All Projects] Bugpublic2019-11-11 14:52
ReporterOlaf Assigned ToPhyllisSmith  
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000337: Proxy: Video is not congruent.
DescriptionThe video of the proxy is slightly shifted to the left and upwards and therefore not congruent.
Remember: Tools like the mask work in the pixel area with several decimal places.
The shift is in direct connection with the forced scaling in proxy settings.
Steps To ReproduceCreate proxy and then switch between activate and deactivate proxy. (Tested with ProRes and FFvHuff.)
Additional InformationWorkaround: Create proxy with CGG, overwrite the proxy in original size with ffmpeg (e.g.: ffmpeg -i IN -c:v prores -profile:v 0 -an OUT.proxy*).
TagsNo tags attached.




2019-11-11 14:36

manager   ~0002456

Last edited: 2019-11-11 14:52

View 2 revisions

I like the idea of 1:1 being allowed for a proxy for the reason that as a result a video file with no keyframes -- thus making seeks next to impossible -- when proxied will allow for seeking. Adding this to GG's impossibly growing list of "things to do".

Also, mpeg.mpeg flooding with buffer underflow should probably be addressed too.

Forgot to mention that, yes, swscale is used so maybe one of the other possibilities that Andrew mentioned may be faster without creating the side effect of jumpiness. But I don't think anyone is that concerned about testing all of them to see!



2019-11-11 12:25

reporter   ~0002455

Hm, while making 1:1 (non-scaled) proxy was not as simple as just removing some checks ..I found cool trick from libavcodec! Apparently, for some codecs (mjpeg, dv, mpeg1/2, xvid, flv1, jpeg2000) you (still) can decode at much lower resolution by setting "lowres" parameter, so DV will be playable on Pentium2, and so on :} Cool, sort of auto-proxy. Not useful for h264/h265/vp9/av1, but still ....

May be this parameter will be removed eventually, (it was marked as deprecated for some time), but right now it still around.
I found some hints about it on libdv mailing list, one developer (of old CinCV) suggested one can use such mode for timeline thumbnails, for example .....

I tried it via qemu-user emulation, it worked

So, if you really want to get some idea how old machines worked with video editing - you always can emulate :}

as for 0002404 by Olaf
For me mpeg.mpeg not killing CinGG literally, just flood console with some warnings .....


2019-11-07 08:56

reporter   ~0002404

By the way: the default codec for proxies is mpeg.mpeg (mpeg2video) and when creating proxies the user is killed by "buffer underflow".


2019-11-07 08:36

reporter   ~0002403

The problem could partly be solved by allowing the user to use proxies in full resolution (1:1). The codecs FFvHuff (and other HuffYUV derivatives), ProRes and DNxHD are quite suitable for this. Request and reason for this is well known and was already a topic on the old CV mailing list.


2019-11-07 01:21

reporter   ~0002401

If this code uses swscale - then there are more scaling methods (not sure if all of them work):

static const AVOption swscale_options[] = {
    { "sws_flags", "scaler flags", OFFSET(flags), AV_OPT_TYPE_FLAGS, { .i64 = SWS_BICUBIC }, 0, UINT_MAX, VE, "sws_flags" },
    { "fast_bilinear", "fast bilinear", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_FAST_BILINEAR }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "bilinear", "bilinear", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_BILINEAR }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "bicubic", "bicubic", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_BICUBIC }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "experimental", "experimental", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_X }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "neighbor", "nearest neighbor", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_POINT }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "area", "averaging area", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_AREA }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "bicublin", "luma bicubic, chroma bilinear", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_BICUBLIN }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "gauss", "Gaussian", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_GAUSS }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "sinc", "sinc", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_SINC }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "lanczos", "Lanczos", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_LANCZOS }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "spline", "natural bicubic spline", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_SPLINE }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "print_info", "print info", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_PRINT_INFO }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "accurate_rnd", "accurate rounding", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_ACCURATE_RND }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "full_chroma_int", "full chroma interpolation", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_FULL_CHR_H_INT }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "full_chroma_inp", "full chroma input", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_FULL_CHR_H_INP }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "bitexact", "", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_BITEXACT }, INT_MIN, INT_MAX, VE, "sws_flags" },
    { "error_diffusion", "error diffusion dither", 0, AV_OPT_TYPE_CONST, { .i64 = SWS_ERROR_DIFFUSION}, INT_MIN, INT_MAX, VE, "sws_flags" },


2019-11-07 00:26

manager   ~0002399

Attaching line drawing that is really dump looking but I thought it might help for visualization. ; )

pixel_block.txt (214 bytes)
|    |    |
| 1  | 2  |  <- a block of 4 pixels
|    |    |   nearest neighbor picks the 1 pixel so it looks like it goes up and to the left
|    |    |
| 3  | 4  |
|    |    |
pixel_block.txt (214 bytes)


2019-11-07 00:20

manager   ~0002398

Last edited: 2019-11-07 00:24

View 3 revisions

Yes, this is due to downsampling using "Nearest Neighbor" in proxy.C, line 718: 1.0, TRANSFER_REPLACE, NEAREST_NEIGHBOR)

Nearest neighbor is the fastest method for proxy and that really is the point of Proxy, i.e. TO BE FAST. As a test, we switched to CUBIC_LINEAR and a 22 second video proxied to 1/2 size went from taking 6 seconds with Nearest to 15 seconds for Cubic. BUT, with Nearest, it does not "look" like the video moves up and to the left. With Nearest, it does seem to jump but that is just due to the downsampling way that Nearest Neighbor works -- in a 4 block pixel, it picks the upper left hand corner to display the proxy. An attempt at a line drawing will be attached (so that it does not get reformatted).

Changing the code would only slow proxy down so we do not want to change it. I plan to mark this Closed in a couple of days unless someone comes up with code that works and is still just as fast.

Issue History

Date Modified Username Field Change
2019-11-02 10:40 Olaf New Issue
2019-11-07 00:20 PhyllisSmith Assigned To => PhyllisSmith
2019-11-07 00:20 PhyllisSmith Status new => acknowledged
2019-11-07 00:20 PhyllisSmith Note Added: 0002398
2019-11-07 00:21 PhyllisSmith Note Edited: 0002398 View Revisions
2019-11-07 00:24 PhyllisSmith Note Edited: 0002398 View Revisions
2019-11-07 00:26 PhyllisSmith File Added: pixel_block.txt
2019-11-07 00:26 PhyllisSmith Note Added: 0002399
2019-11-07 01:21 Andrew-R Note Added: 0002401
2019-11-07 08:36 Olaf Note Added: 0002403
2019-11-07 08:56 Olaf Note Added: 0002404
2019-11-11 12:25 Andrew-R Note Added: 0002455
2019-11-11 14:36 PhyllisSmith Note Added: 0002456
2019-11-11 14:52 PhyllisSmith Note Edited: 0002456 View Revisions