Doom9's Forum forum

The Python scripts project is currently on hold because the afrocuban user is busy and unavailable, I am also not using PVD programs at the moment for personal reasons, and I do not know how long this will last.

Rigaya's HWEncs of course: https://github.com/rigaya/

ffms2 r2415 Diff from the original version @flossy_cake, you can read about the new parameters in the docs . @rgr, if you want, now you can again test fill_gaps.

SVT-AV1-HDR 4.2 "Ghost Robot" released. Seems to be rebased off current mainline, so a lot of changes inherited since last version. https://github.com/juliobbv-p/SVT-AV1-HDR/commits/main/

Quote: Originally Posted by DTL (Post 2050242) May be not best place to ask complex codec design question but still attempt: Given that: 1. Hexagon image sampling grid provides a bit (about 13% as Google AI says ?) more isotropic spatial resolution for natural imaging. 2. Current x264 MPEG encoder process in best way only square sampled buffers but not any optimized for processing of hex sampled buffers (while possible but with estimated up to 2..3x time larger output bitrate for same CRF). Can we make a mod of x264 with support of hex sampled frames ? For the decoder side it is nice to have the final stage conversion option to square sampling grid for standard displays. I understand it may be complex work for a very few human programmers left but maybe power of AI programming tools may help ? As a first quick AI reply: It is still too hard for current AI tools as complete project but may helps in parts (like standard square DCT is not applicable but may be replaced with Hex-DCT and the output can be processed with standard MPEG workflow. Also motion estimation engine need full redesign. What is hexagon image sampling anyways? Pixels are hexagonal?

why would you think AC3 encoding has been meaningfully improved at all? try mpc-be it also has an option to bitstream AC3 and to encode to AC3. this should be the newest available ac3 from i guess ffmpeg i highly doubt they ripped on old out and ship that.

Dolby have now sued Asus over Opus patents too: https://michael7924.substack.com/p/d...uit-asus-again

Dolby have now sued Asus over Opus patents too: https://michael7924.substack.com/p/d...uit-asus-again

May be not best place to ask complex codec design question but still attempt: Given that: 1. Hexagon image sampling grid provides a bit (about 13% as Google AI says ?) more isotropic spatial resolution for natural imaging. 2. Current x264 MPEG encoder process in best way only square sampled buffers but not any optimized for processing of hex sampled buffers (while possible but with estimated up to 2..3x time larger output bitrate for same CRF). Can we make a mod of x264 with support of hex sampled frames ? For the decoder side it is nice to have the final stage conversion option to square sampling grid for standard displays. I understand it may be complex work for a very few human programmers left but maybe power of AI programming tools may help ? As a first quick AI reply: It is still too hard for current AI tools as complete project but may helps in parts (like standard square DCT is not applicable but may be replaced with Hex-DCT and the output can be processed with standard MPEG workflow. Also motion estimation engine need full redesign.

I tried to ask google AI about comparison of sinc vs jinc based image sampling and restoration (including resizing like upsampling is interpolation up to full continuous restoration from sampled form). The answer is: 1. Sinc saves more diagonal frequencies (undistorted or less distorted) so produces more sharper looking images in comparison with jinc-based sampling/interpolation. But some disadvantage is anisotropy resolution (diagonal resolution up to sqrt(2) times larger in comparison with H and V directions). 2. Jinc produces all direction spatially isotropic resolution but carries less total details at the square sampling grid. The main source of anisotropy is not sinc vs jinc kernels but the spatial property of the 2D square sampling grid. There exists a solution: change the sampling grid from square to hexagonal (triangle) and it will produce much more spatially isotropic results and will work with the jinc kernel better. But hexagonal sampled images are not natural for typical image processing software and display devices so need to be converted into square sampling to be processed by most existing software. What is possible to test: 1. Make 2 conversion functions ConvertToHex() and ConvertToSquare() to go in and out of the hex sampled image domain. Hex sampled images also have rows and close to columns so can be stored in the same rectangular rows-scanned data buffers. The only difference may be odd and even rows need to be treated (in processing math) as half-sample

Has anyone considered updating QTGMC to take advantage of Avisynth+'s arrays, loops, and if {} else {}? bVec1-6 and fVec1-6, for example, can be substituted with arrays and iterated with loops, and if {} else {} makes things a lot more readable, e.g. (not fully tested; if I've mistranslated the logic then it only goes to prove my point :cool:): Code: bVec6c = IsClip(bVec6) bVec6 = bVec6c ? bVec6 : \ (maxTR > 5) ? eval("srchSuper_us.MAnalyse( isb=true, delta=6, "+MAnalyseString+MTString) : NOP() bVec6 = bVec6c || !RefineMotion || !(maxTR > 5) ? bVec6 : eval("srchSuper_us.MRecalculate(bVec6, "+MRecalculateString+MTString) bVec6 = bVec6c || !RefineMotion2 || !(maxTR > 5) ? bVec6 : eval("srchSuper_us.MRecalculate(bVec6, "+MRecalculateString2+MTString) [70+ more lines of repititions] fVec6c = IsClip(fVec6) fVec6 = fVec6c ? fVec6 : \ (maxTR > 5) ? eval("srchSuper_us.MAnalyse( isb=false, delta=6, "+MAnalyseString+MTString) : NOP() fVec6 = fVec6c || !RefineMotion || !(maxTR > 5) ? fVec6 : eval("srchSuper_us.MRecalculate(fVec6, "+MRecalculateString+MTString) fVec6 = fVec6c || !RefineMotion2 || !(maxTR > 5) ? fVec6 : eval("srchSuper_us.MRecalculate(fVec6, "+MRecalculateString2+MTString) can be replaced with: Code: for (i = 0, 5) { if (!IsClip(bVecs[i])) { if (maxTR > i) { bVecs = ArraySet(bVecs, eval(Format("srchSuper_us.MAnalyse( isb=true, delta={}, "+MAnalyseString+MTString, i + 1)), i) } if (RefineMotion && maxTR > i) { bVecs = ArraySet(bVecs, eval("srchSuper_us.MRecalculate(bVecs[i

If FFmpeg is detecting it as interlaced, then DGDecode is setting the _FieldBased frame property to TFF even in the case the video is progressive. In-script, you can change the property using propSet("_FieldBased", 0) , or you can selectively turn off FFmpeg reading the field property: Code: ffmpeg -avisynth_flags -field_order [...]