 |
@PhyllisSmith, Excellent, now Heroine Virtual Ltd. is the sole rights owner. One might get the idea that Mr Williams and Mr Morrow are both Good Guy. |
 |
@Olaf: changed the "About" in settings -- first of all to remove the word "cin5", put in Cinelerra-GG and then just say modifications by Morrow. |
|
|
I see, PhyllisSmith, but then you have to do it consistently. In the settings "About" there is still Morrow as the rights holder, so get rid of that. |
|
|
@Andrew QUOTE from note 2455: (1:1) I tried it via qemu-user emulation, it worked https://randrianasulu.livejournal.com/13352.html The above was interesting! but I only had time to watch part of it and not the whole 41 minutes. @Olaf "three added files identify Adam Williams (2015) as the copyright holder. So these are from HV?" No, we just continuously maintain the copyright notice at the front of each file so as to ensure that there are no copyright issues and that everyone realizes that the Cinelerra program exists due to the creation by Adam. @Everyone Moving commentary and information to 0000341. |
|
|
A simple test run in the basic setting shows no "buffer overflow". Convert: A useful innovation that was missed for a long time. - Unlimited freedom: "08b title07 Sandra: Everlasting Love - FFvHuff-Flac.convert-mkv.convert-mp4.convert-mkv.mov" - Instead of "Convert", I propose "Transcode" (https://en.wikipedia.org/wiki/Transcoding). - The three added files identify Adam Williams (2015) as the copyright holder. So these are from HV? |
|
|
Checked in fix for voluminous "buffer overflow" when using proxy with default mpeg.mpeg today. Created "Convert..." under the Settings pulldown which allows for converting ALL the loaded asset media to be rendered in a different format and loaded onto the timeline. Choices include: tag name to add to media filename, whether to remove original media just from the project, and beep volume. See example attached. BIGGEST gain from using this is if you have media that is not "seekable", that is, you can play it from the beginning but can not move to another spot and have the audio or video play correctly. For example as shown by Andrew in the file: LD_160909_2.avi the audio only works correctly if you play from the beginning. That example file provided by Andrew is at: https://yadi.sk/i/ivzmAc2UGq-Wwg
convert.png (19,382 bytes) |
|
|
A patch for the "buffer underflow" emanating from ffmpeg has been generated and is being tested. It may or may not be checked in because carrying patches for ffmpeg is not necessarily desirable. But have basically verified that even though there are a voluminous amount of these Error messages which should probably be Warn messages instead, it does not seem to impact the result. The ffmpeg code that is affected has the word "FIXME" in that area but it does not look like any fix is pending. There are now currently 7, going on 8, patches for ffmpeg that CinGG finds necessary. Some feedback on "allowing the user to use proxies in full resolution (1:1)". Working on coming up with a gui layout for this. Thinking about a separate pulldown below "Proxy settings..." called "Convert Media" for the following reasons: 1) it is not a proxy that is going to look pixelated unless the user uses poor quality 2) definitely want to include the audio too ! 3) do not need to switch back and forth like you would proxy 4) this "convert" will only be on the "original" media -- not any changes you have performed NEED FEEDBACK on this proposal. The usefulness of this 1:1 conversion is that it still looks good and now this media is seekable if it was not before. |
|
|
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! |
 |
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 ..... https://sourceforge.net/p/libdv/mailman/message/5915766/ I tried it via qemu-user emulation, it worked https://randrianasulu.livejournal.com/13352.html 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 ..... |
|
|
By the way: the default codec for proxies is mpeg.mpeg (mpeg2video) and when creating proxies the user is killed by "buffer underflow". |
|
|
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. |
|
|
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" }, |
|
|
Attaching line drawing that is really dumb looking but I thought it might help for visualization. ; )
pixel_block.txt (214 bytes) |
|
|
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. |
- Anonymous
