https://forum.selur.net/ Sun, 25 Oct 2026 19:26:43 +0000 MyBB https://forum.selur.net/thread-4521.html Sat, 24 Oct 2026 16:26:29 +0200 Shiniori]]> https://forum.selur.net/thread-4521.html
It was sitting beneath the "always use" inscription. How nicely it thinned out those thick lines—so effortlessly.


]]>
It was sitting beneath the "always use" inscription. How nicely it thinned out those thick lines—so effortlessly.


]]> https://forum.selur.net/thread-4520.html Sat, 24 Oct 2026 15:34:27 +0200 tamo_bln]]> https://forum.selur.net/thread-4520.html
I'm experiencing a possible job scheduling issue with Hybrid-2026.10.23.1-x86_64_oldGlibc.AppImage on Linux Mint 22.3 (64-bit). 

Encoding settings:

• SVT-AV1 4.0.1
  
• CRF 24, preset/speed 6
  
• Source: Blu-ray playlist
  
  00101.mpls
• Intended output:
  
  see debug log file

The video encoding itself completes successfully after approximately 12 minutes, with exit code 0. However, the subsequent cleanup and final rename steps do not complete as expected, and the job remains waiting.
The debug log repeatedly reports:

Currently running subjobs: 0, maximal: 1 -> free: 1 -> can't start ..._05_cleanUp, other subjobs still use the job folder

It also reports:

-> can't start ..._13_rename, since it's the last job to run

When I tried to restart the waiting rename job, Hybrid reset all 13 subjobs, including the completed video encoding, and started the entire process again. I stopped this second attempt to avoid encoding everything again.
The temporary directory associated with the blocked cleanup job contains an

.lwi

index file for

00101.m2ts

. Running

lsof +D

on the directory returned no output.
I have prepared a

HybridDebugOutput.zip

containing the debug information. I'll send you a PM with the password for the archive.

Could you please take a look and see whether this might be a job scheduling, dependency tracking, or temporary-directory cleanup issue?

Thank you!

  HybridDebugOutput.zip (Size: 648,71 KB / Downloads: 8) ]]>
I'm experiencing a possible job scheduling issue with Hybrid-2026.10.23.1-x86_64_oldGlibc.AppImage on Linux Mint 22.3 (64-bit). 

Encoding settings:

• SVT-AV1 4.0.1
  
• CRF 24, preset/speed 6
  
• Source: Blu-ray playlist
  
  00101.mpls
• Intended output:
  
  see debug log file

The video encoding itself completes successfully after approximately 12 minutes, with exit code 0. However, the subsequent cleanup and final rename steps do not complete as expected, and the job remains waiting.
The debug log repeatedly reports:

Currently running subjobs: 0, maximal: 1 -> free: 1 -> can't start ..._05_cleanUp, other subjobs still use the job folder

It also reports:

-> can't start ..._13_rename, since it's the last job to run

When I tried to restart the waiting rename job, Hybrid reset all 13 subjobs, including the completed video encoding, and started the entire process again. I stopped this second attempt to avoid encoding everything again.
The temporary directory associated with the blocked cleanup job contains an

.lwi

index file for

00101.m2ts

. Running

lsof +D

on the directory returned no output.
I have prepared a

HybridDebugOutput.zip

containing the debug information. I'll send you a PM with the password for the archive.

Could you please take a look and see whether this might be a job scheduling, dependency tracking, or temporary-directory cleanup issue?

Thank you!

  HybridDebugOutput.zip (Size: 648,71 KB / Downloads: 8) ]]> https://forum.selur.net/thread-4519.html Fri, 23 Oct 2026 11:03:16 +0200 tamo_bln]]> https://forum.selur.net/thread-4519.html Hybrid version: 2026.10.09.1 (Linux 64-bit, Linux Mint 22.3)
Problem:
When processing Blu-ray playlist

01768.mpls

, Hybrid extracts an AC-3 audio stream with a duration of approximately 2 hours, 55 minutes and 33 seconds, although the selected playlist is only 8 minutes and 33 seconds long.
The resulting MKV has the correct video duration but an excessively long audio track. The issue also occurs when extracting the audio without re-encoding.
Steps to reproduce:

1. Open a Blu-ray folder in Hybrid.
   
2. Select playlist
   
   01768.mpls
   (duration approximately 00:08:33).
   
3. Select the AC-3 audio track and enable audio passthrough.
   
4. Start the processing job.
   
5. Inspect the resulting audio duration.
   

Expected result:
AC-3 audio corresponding to the selected playlist, approximately

00:08:33.376

(16,043 AC-3 frames).
Actual result:
The extracted audio is approximately

02:55:33.856

long.
Investigation:
Hybrid generates the following FFmpeg command (abbreviated):

ffmpeg -y -threads 8 -analyzeduration 200M -probesize 200M \   -i "bluray:/path/to/BLU-RAY_DISC" \   -playlist 1768 -angle 0 \   -map 0:1 -vn -sn -acodec copy output.ac3

Notice that

-playlist 1768

and

-angle 0

are placed after

-i

.
I independently reproduced the problem using Hybrid's bundled FFmpeg 8.0.1 with the same argument order:

video:0KiB audio:411479KiB time=02:55:33.47

Using my separately compiled FFmpeg Git Master build with

-playlist 1768

placed before

-i

correctly extracts the intended playlist, producing 16,043 AC-3 packets.
The correct playlist consists of the consecutive clips

00780.m2ts

,

00781.m2ts

and

00782.m2ts

.
This strongly suggests that the Blu-ray playlist selection options are positioned incorrectly in Hybrid's generated FFmpeg command.
I have attached the compressed Hybrid debug output.
Additional information:

• Hybrid's bundled FFmpeg version: 8.0.1
  
• The problem is reproducible without audio or video re-encoding.
  
• The Blu-ray source files have not been modified.
  

]]> Hybrid version: 2026.10.09.1 (Linux 64-bit, Linux Mint 22.3)
Problem:
When processing Blu-ray playlist

01768.mpls

, Hybrid extracts an AC-3 audio stream with a duration of approximately 2 hours, 55 minutes and 33 seconds, although the selected playlist is only 8 minutes and 33 seconds long.
The resulting MKV has the correct video duration but an excessively long audio track. The issue also occurs when extracting the audio without re-encoding.
Steps to reproduce:

1. Open a Blu-ray folder in Hybrid.
   
2. Select playlist
   
   01768.mpls
   (duration approximately 00:08:33).
   
3. Select the AC-3 audio track and enable audio passthrough.
   
4. Start the processing job.
   
5. Inspect the resulting audio duration.
   

Expected result:
AC-3 audio corresponding to the selected playlist, approximately

00:08:33.376

(16,043 AC-3 frames).
Actual result:
The extracted audio is approximately

02:55:33.856

long.
Investigation:
Hybrid generates the following FFmpeg command (abbreviated):

ffmpeg -y -threads 8 -analyzeduration 200M -probesize 200M \   -i "bluray:/path/to/BLU-RAY_DISC" \   -playlist 1768 -angle 0 \   -map 0:1 -vn -sn -acodec copy output.ac3

Notice that

-playlist 1768

and

-angle 0

are placed after

-i

.
I independently reproduced the problem using Hybrid's bundled FFmpeg 8.0.1 with the same argument order:

video:0KiB audio:411479KiB time=02:55:33.47

Using my separately compiled FFmpeg Git Master build with

-playlist 1768

placed before

-i

correctly extracts the intended playlist, producing 16,043 AC-3 packets.
The correct playlist consists of the consecutive clips

00780.m2ts

,

00781.m2ts

and

00782.m2ts

.
This strongly suggests that the Blu-ray playlist selection options are positioned incorrectly in Hybrid's generated FFmpeg command.
I have attached the compressed Hybrid debug output.
Additional information:

• Hybrid's bundled FFmpeg version: 8.0.1
  
• The problem is reproducible without audio or video re-encoding.
  
• The Blu-ray source files have not been modified.
  

]]> https://forum.selur.net/thread-4517.html Wed, 21 Oct 2026 16:05:32 +0200 VCRvideocapturing]]> https://forum.selur.net/thread-4517.html I am using version 2025.11.09.1
I got Virus.Moyv
C:/Program Files/Hybrid/64bit/ffmbc.exe
I have quarantined it but I am worried about this]]> I am using version 2025.11.09.1
I got Virus.Moyv
C:/Program Files/Hybrid/64bit/ffmbc.exe
I have quarantined it but I am worried about this]]> https://forum.selur.net/thread-4516.html Mon, 19 Oct 2026 10:12:03 +0200 lameuser]]> https://forum.selur.net/thread-4516.html Is it legit ?


]]> Is it legit ?


]]> https://forum.selur.net/thread-4514.html Fri, 16 Oct 2026 11:03:51 +0200 LigH]]> https://forum.selur.net/thread-4514.html 64bit\license\GPLv2.txt; reason = Error 183: A file which already exists cannot be created. This was caused by a file LICENSE. already existing in my old Hybrid installation directory which prevents the creation of a subdirectory license\ until it gets deleted first.]]> 64bit\license\GPLv2.txt; reason = Error 183: A file which already exists cannot be created. This was caused by a file LICENSE. already existing in my old Hybrid installation directory which prevents the creation of a subdirectory license\ until it gets deleted first.]]> https://forum.selur.net/thread-4513.html Tue, 13 Oct 2026 13:58:57 +0200 Parth09]]> https://forum.selur.net/thread-4513.html
I'm using Hybrid's VIVTC handling on telecined NTSC film sources (720x480/486, ProRes 422 HQ)
and noticed something in the generated VapourSynth script that I'd like to check with you.

Settings: Filtering > (De-)Interlace/Telecine > Auto deinterlace handling: VIVTC (Vapoursynth)
VFM tab: Mode "2-way match + 3rd match on combed (p/c + n)", Deinterlacer: QTGMC (preset slow),
Order 0, Field 2, Mi 80, Block 32/32, Exclude 16/16, Scene threshold 12, Chroma matching on, Mic match 1.
Seen with Hybrid 2026.09.06.1, 2026.09.26.1 (macOS) and the 2026.10.01.1 Linux AppImage.

The generated script contains:

  clip2clip = clip
  clip2clip = qtgmc.QTGMC(Input=clip2clip, Preset="slow", TFF=False, ...)
  yv12 = core.resize.Bicubic(clip=clip2clip, format=vs.YUV420P8, range_in_s="limited")
  clip = core.vivtc.VFM(yv12, clip2=clip2clip, order=0, chroma=False)
  ...
  clip = core.std.FrameEval(clip=clip, eval=functools.partial(postprocess, clip=clip, deinterlaced=clip2clip), prop_src=clip)
  clip = core.vivtc.VDecimate(clip)

So VFM both analyses and outputs the already-deinterlaced QTGMC clip, never the original fields.
I measured this on 300 frames: VFMMatch was 'c' on 300/300 and every VFM output frame was
bit-identical to the QTGMC frame. Run on the original fields, VFM chose p on about two-thirds of
those frames, i.e. it actually re-paired fields. Over a full film, the chain's output is about
41 dB PSNR to the original fields, vs about 55 dB when VFM matches the original fields.

The vivtc docs describe clip2 as the format workaround with clip2 = the original
(yv12 = Bicubic(original); VFM(yv12, clip2=original)), and the post-processing example
applies the deinterlacer to the matched clip, used only for frames flagged _Combed.

Questions:
1. Is applying the selected Deinterlacer to every frame before VFM intended? I expected it to be
  used only for frames VFM still flags as combed.
2. If it isn't intended, could VIVTC mode generate VFM on the original (clip = 8-bit copy of the
  source, clip2 = source) with the deinterlacer only in the FrameEval post-processing?
3. Only order and chroma reach VFM in the script; the Block 32/32 (and other VFM tab values) don't
  seem to be passed. Is that expected?

P.S. In case it's useful for other users: with 720x486 sources, the YUV420P8 match clip has 243-row
chroma planes, and vivtc's compareFieldsSlow (field=0) reads one row past the end of the plane
(curnf on row 243). On Linux this intermittently segfaults vspipe in vivtc.so (it never crashed on
macOS for us). Padding the match clip to 488 rows (std.AddBorders(bottom=2)) avoids it.

Thanks for Hybrid and for any insight!]]>
I'm using Hybrid's VIVTC handling on telecined NTSC film sources (720x480/486, ProRes 422 HQ)
and noticed something in the generated VapourSynth script that I'd like to check with you.

Settings: Filtering > (De-)Interlace/Telecine > Auto deinterlace handling: VIVTC (Vapoursynth)
VFM tab: Mode "2-way match + 3rd match on combed (p/c + n)", Deinterlacer: QTGMC (preset slow),
Order 0, Field 2, Mi 80, Block 32/32, Exclude 16/16, Scene threshold 12, Chroma matching on, Mic match 1.
Seen with Hybrid 2026.09.06.1, 2026.09.26.1 (macOS) and the 2026.10.01.1 Linux AppImage.

The generated script contains:

  clip2clip = clip
  clip2clip = qtgmc.QTGMC(Input=clip2clip, Preset="slow", TFF=False, ...)
  yv12 = core.resize.Bicubic(clip=clip2clip, format=vs.YUV420P8, range_in_s="limited")
  clip = core.vivtc.VFM(yv12, clip2=clip2clip, order=0, chroma=False)
  ...
  clip = core.std.FrameEval(clip=clip, eval=functools.partial(postprocess, clip=clip, deinterlaced=clip2clip), prop_src=clip)
  clip = core.vivtc.VDecimate(clip)

So VFM both analyses and outputs the already-deinterlaced QTGMC clip, never the original fields.
I measured this on 300 frames: VFMMatch was 'c' on 300/300 and every VFM output frame was
bit-identical to the QTGMC frame. Run on the original fields, VFM chose p on about two-thirds of
those frames, i.e. it actually re-paired fields. Over a full film, the chain's output is about
41 dB PSNR to the original fields, vs about 55 dB when VFM matches the original fields.

The vivtc docs describe clip2 as the format workaround with clip2 = the original
(yv12 = Bicubic(original); VFM(yv12, clip2=original)), and the post-processing example
applies the deinterlacer to the matched clip, used only for frames flagged _Combed.

Questions:
1. Is applying the selected Deinterlacer to every frame before VFM intended? I expected it to be
  used only for frames VFM still flags as combed.
2. If it isn't intended, could VIVTC mode generate VFM on the original (clip = 8-bit copy of the
  source, clip2 = source) with the deinterlacer only in the FrameEval post-processing?
3. Only order and chroma reach VFM in the script; the Block 32/32 (and other VFM tab values) don't
  seem to be passed. Is that expected?

P.S. In case it's useful for other users: with 720x486 sources, the YUV420P8 match clip has 243-row
chroma planes, and vivtc's compareFieldsSlow (field=0) reads one row past the end of the plane
(curnf on row 243). On Linux this intermittently segfaults vspipe in vivtc.so (it never crashed on
macOS for us). Padding the match clip to 488 rows (std.AddBorders(bottom=2)) avoids it.

Thanks for Hybrid and for any insight!]]> https://forum.selur.net/thread-4511.html Sun, 11 Oct 2026 07:05:50 +0200 nomad]]> https://forum.selur.net/thread-4511.html and thanks for your efforts.

Unfortunately, I can't install Hybrid on a Mac under Sequoia 15.8.1.
Yes, I know it's not notarised, but if I go for Privacy and Security, it doesn't show up. 
Usually, after having tried to open it directly and hitting Cancel, one should be able to allow it there.

What to do?

TIA]]> and thanks for your efforts.

Unfortunately, I can't install Hybrid on a Mac under Sequoia 15.8.1.
Yes, I know it's not notarised, but if I go for Privacy and Security, it doesn't show up. 
Usually, after having tried to open it directly and hitting Cancel, one should be able to allow it there.

What to do?

TIA]]> https://forum.selur.net/thread-4510.html Fri, 09 Oct 2026 22:14:47 +0200 The_Tinkerer]]> https://forum.selur.net/thread-4510.html
They have a problem with dropping frames when converting. The resulting files have lesser frame counts than the sources, causing the audio to go out of sync.

This is most likely caused by these stupid old Windows WMV encoders skipping frames that they drop as static or duplicate (still openings, short low-change sections, etc.).

Windows Media encoders commonly did this to save bits on an Internet where many people still used dial up and it could make a significant difference in loading times.

The problem is that AviSynth drops these frames (there's usually only 1-3 seconds worth) and stacks the remaining ones in order, but, there's slightly less frames, and the audio will go out of sync. (To be fair, FFprobe also drops these frames when scanning the file with "-count_frames" and reports the exact same lower total for the frame count.)

The fix for a .mp4 re-encode would be to go to Misc -> Overwrite Input -> Frame rate, and enter 29.970030 (30,000/1001, the video's input frame rate).

The expected result would then be to see in the AviSynth script preview:

LWLibavVideoSource("F:\cj\fix\Test.wmv",fpsnum=30000,fpsden=1001,cache=false,dr=true,format="YUV420P8", prefer_hw=0,repeat=true)

That should fix it, however, currently, Hybrid does not insert ",fpsnum=30000,fpsden=1001" into the line, leaving it like this:

LWLibavVideoSource("F:\cj\fix\Test.wmv",cache=false,dr=true,format="YUV420P8", prefer_hw=0,repeat=true)

So, Hybrid's AviSynth scripting code needs to be fixed so that when Misc -> Overwrite Input -> Frame rate has something entered, it should be inserting the correct corresponding ",fpsnum=x,fpsden=x" frame rate info the "LWLibavVideoSource" line in the AviSynth script. (I do believe that Hybrid is currently doing this correctly in Vapoursynth.) If the user has something specified in  Misc -> Overwrite Output -> Frame rate to for some reason, then that frame rate should be entered into the AviSynth script in the "AssumeFPS(x,x)" line towards the end.

Just for quick reference in case it might be helpful, common rational values for standard video frame rates:

• 23.976 fps (NTSC Film): fpsnum=24000, fpsden=1001
  
  
• 24.0 fps (True Film): fpsnum=24, fpsden=1
  
  
• 29.97 fps (NTSC Video): fpsnum=30000, fpsden=1001
  
  
• 30.0 fps: fpsnum=30, fpsden=1
  
  
• 59.94 fps (NTSC High Frame Rate): fpsnum=60000, fpsden=1001
  
  
• 60.0 fps: fpsnum=60, fpsden=1
  
  
• 25.0 fps (PAL): fpsnum=25, fpsden=1
  
  
• 50.0 fps (PAL High Frame Rate): fpsnum=50, fpsden=1
  

For now, a quick fix would be to enter the "LWLibavVideoSource("F:\cj\fix\Test.wmv",fpsnum=30000,fpsden=1001,cache=false,dr=true,format="YUV420P8", prefer_hw=0,repeat=true)" line into a filter on the Custom tab, inserting it at the very top by putting it in Insert before -> ColorMatrix. There will then be two "LWLibavVideoSource" lines in the script, but since the Custom one comes after the first one generated by Hybrid, the Custom one will override it.]]>
They have a problem with dropping frames when converting. The resulting files have lesser frame counts than the sources, causing the audio to go out of sync.

This is most likely caused by these stupid old Windows WMV encoders skipping frames that they drop as static or duplicate (still openings, short low-change sections, etc.).

Windows Media encoders commonly did this to save bits on an Internet where many people still used dial up and it could make a significant difference in loading times.

The problem is that AviSynth drops these frames (there's usually only 1-3 seconds worth) and stacks the remaining ones in order, but, there's slightly less frames, and the audio will go out of sync. (To be fair, FFprobe also drops these frames when scanning the file with "-count_frames" and reports the exact same lower total for the frame count.)

The fix for a .mp4 re-encode would be to go to Misc -> Overwrite Input -> Frame rate, and enter 29.970030 (30,000/1001, the video's input frame rate).

The expected result would then be to see in the AviSynth script preview:

LWLibavVideoSource("F:\cj\fix\Test.wmv",fpsnum=30000,fpsden=1001,cache=false,dr=true,format="YUV420P8", prefer_hw=0,repeat=true)

That should fix it, however, currently, Hybrid does not insert ",fpsnum=30000,fpsden=1001" into the line, leaving it like this:

LWLibavVideoSource("F:\cj\fix\Test.wmv",cache=false,dr=true,format="YUV420P8", prefer_hw=0,repeat=true)

So, Hybrid's AviSynth scripting code needs to be fixed so that when Misc -> Overwrite Input -> Frame rate has something entered, it should be inserting the correct corresponding ",fpsnum=x,fpsden=x" frame rate info the "LWLibavVideoSource" line in the AviSynth script. (I do believe that Hybrid is currently doing this correctly in Vapoursynth.) If the user has something specified in  Misc -> Overwrite Output -> Frame rate to for some reason, then that frame rate should be entered into the AviSynth script in the "AssumeFPS(x,x)" line towards the end.

Just for quick reference in case it might be helpful, common rational values for standard video frame rates:

• 23.976 fps (NTSC Film): fpsnum=24000, fpsden=1001
  
  
• 24.0 fps (True Film): fpsnum=24, fpsden=1
  
  
• 29.97 fps (NTSC Video): fpsnum=30000, fpsden=1001
  
  
• 30.0 fps: fpsnum=30, fpsden=1
  
  
• 59.94 fps (NTSC High Frame Rate): fpsnum=60000, fpsden=1001
  
  
• 60.0 fps: fpsnum=60, fpsden=1
  
  
• 25.0 fps (PAL): fpsnum=25, fpsden=1
  
  
• 50.0 fps (PAL High Frame Rate): fpsnum=50, fpsden=1
  

For now, a quick fix would be to enter the "LWLibavVideoSource("F:\cj\fix\Test.wmv",fpsnum=30000,fpsden=1001,cache=false,dr=true,format="YUV420P8", prefer_hw=0,repeat=true)" line into a filter on the Custom tab, inserting it at the very top by putting it in Insert before -> ColorMatrix. There will then be two "LWLibavVideoSource" lines in the script, but since the Custom one comes after the first one generated by Hybrid, the Custom one will override it.]]> https://forum.selur.net/thread-4509.html Fri, 09 Oct 2026 22:04:49 +0200 davebtw]]> https://forum.selur.net/thread-4509.html
Since more the 50% of my work consists in de-interlacing my old videos, I found this feature extremely helpful and almost it always made the correct selection.  

I have read online explanations and I can understand some of the reasons it was removed.  However, for me this will cause a lot more work that I formerly was able to do quickly.  

Is there any way I can duplicate that detection and filtering choices?  Could you add back in in the future this option?  Help Please, this is the primary reason I use Hybrid tools which I love, and I have donated several times to support your work.

Regards,

-david BTW]]>
Since more the 50% of my work consists in de-interlacing my old videos, I found this feature extremely helpful and almost it always made the correct selection.  

I have read online explanations and I can understand some of the reasons it was removed.  However, for me this will cause a lot more work that I formerly was able to do quickly.  

Is there any way I can duplicate that detection and filtering choices?  Could you add back in in the future this option?  Help Please, this is the primary reason I use Hybrid tools which I love, and I have donated several times to support your work.

Regards,

-david BTW]]> https://forum.selur.net/thread-4508.html Fri, 09 Oct 2026 20:21:03 +0200 The_Tinkerer]]> https://forum.selur.net/thread-4508.html Avisynth32bit_2024.12.15.7z" file)?

Or an alternate Hybrid build that supports it? (I noticed a "Hybrid-2026.10.08.2-x86_64.AppImage" file at the above Google Drive link, but that's for Linux, and I'm not sure the "x86" part of the file name indicates support for 32bit AviSynth.)

I do usually use the 64 bit AviSynth anyways, but sometimes I need to use the 32 bit version of AviSynth for one reason or another. I guess I'll just have to revert to version 2026.03.21.1 for that, if 32 bit AviSynth support is gone for good.  ]]> Avisynth32bit_2024.12.15.7z" file)?

Or an alternate Hybrid build that supports it? (I noticed a "Hybrid-2026.10.08.2-x86_64.AppImage" file at the above Google Drive link, but that's for Linux, and I'm not sure the "x86" part of the file name indicates support for 32bit AviSynth.)

I do usually use the 64 bit AviSynth anyways, but sometimes I need to use the 32 bit version of AviSynth for one reason or another. I guess I'll just have to revert to version 2026.03.21.1 for that, if 32 bit AviSynth support is gone for good.  ]]> https://forum.selur.net/thread-4507.html Fri, 09 Oct 2026 13:34:39 +0200 Miranda]]> https://forum.selur.net/thread-4507.html
]]>
]]> https://forum.selur.net/thread-4506.html Thu, 08 Oct 2026 21:45:13 +0200 lameuser]]> https://forum.selur.net/thread-4506.html
At first ,many many thanks for your great work !

Well.
Few days ago i noticed SVT-AV1 - Tritium. Obviously it's an SVT-AV1 fork ,but far better than the mainline version.
Can you please add this encoder to Hybrid ?

https://github.com/Uranite/svt-av1-tritium

AFAIK only StaxRip supports it ,but the GUI and other functions.... 

Thanks! ]]>
At first ,many many thanks for your great work !

Well.
Few days ago i noticed SVT-AV1 - Tritium. Obviously it's an SVT-AV1 fork ,but far better than the mainline version.
Can you please add this encoder to Hybrid ?

https://github.com/Uranite/svt-av1-tritium

AFAIK only StaxRip supports it ,but the GUI and other functions.... 

Thanks! ]]> https://forum.selur.net/thread-4505.html Thu, 08 Oct 2026 20:36:44 +0200 Vhs-Digital-Buddy]]> https://forum.selur.net/thread-4505.html Please have a look at the following image.

https://ibb.co/wF2htp7Y

Those purple fields are part of the original recording. How can I get rid of them using Hybrid ? 
Currently, I run de-interlace with top field first, and it's been working really well on my videos, but this one is a bit problematic. I know that does not solve the problem, however what option might help running at the same time as de-interlace ?

Thanks for any help
Buddy/]]> Please have a look at the following image.

https://ibb.co/wF2htp7Y

Those purple fields are part of the original recording. How can I get rid of them using Hybrid ? 
Currently, I run de-interlace with top field first, and it's been working really well on my videos, but this one is a bit problematic. I know that does not solve the problem, however what option might help running at the same time as de-interlace ?

Thanks for any help
Buddy/]]> https://forum.selur.net/thread-4504.html Wed, 07 Oct 2026 06:41:35 +0200 Vhs-Digital-Buddy]]> https://forum.selur.net/thread-4504.html
I'm trying to run a de-flicker and de-interlace, however it's always 100% CPU usage.

Is there a way to not have it at 100% ? 

Because for the amount of time it works on a video, it seems quite excessive. I'm working on a desktop pc with Windows 11, and an 80 minute recorded video.]]>
I'm trying to run a de-flicker and de-interlace, however it's always 100% CPU usage.

Is there a way to not have it at 100% ? 

Because for the amount of time it works on a video, it seems quite excessive. I'm working on a desktop pc with Windows 11, and an 80 minute recorded video.]]>