Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
7th December 2018, 14:58 | #1 | Link |
Registered User
Join Date: Dec 2013
Location: France
Posts: 64
|
VD2 and FFMPEG Update
Simple question, please :
In the new version of VirtualDub2 (Version 20/43073), the FFMPEG Plugins/Codecs have been updated with the latest version FFmpeg 4.1 of November 6, 2018. Yes or No ? Thanks |
8th December 2018, 12:38 | #2 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
Not updated
__________________
VirtualDub2 |
8th December 2018, 12:51 | #3 | Link |
Registered User
Join Date: Dec 2013
Location: France
Posts: 64
|
Thank you shekh for your answer and your great work on VirtualDub2.
If I asked this question, it is because we are seeing encoding anomalies in H264 with the new version of Windows 10/1809. With the version of Windows 10/1803, there is no problem of encoding with the plugins of VD2. Therefore, I assumed that an FFMPEG update could solve this problem. But I'm not sure. It's just a guess. |
8th December 2018, 14:02 | #4 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
Encoding H264 is handled by x264-8.vdplugin which is built around libx264, not FFMpeg. Anyway, it has very little connection with the OS, have no idea how it can cause issues.
__________________
VirtualDub2 |
8th December 2018, 16:38 | #5 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
Quote:
Is this on the same hardware ? Or different computers ? Did you rule out system specific causes ? eg. overheating, bad memory, bad psu etc.. ? |
|
8th December 2018, 19:31 | #6 | Link |
Registered User
Join Date: Dec 2013
Location: France
Posts: 64
|
Hello,
To be more specific, you may know an application called FILM9 that I co-authored. This application is completely free and uses the great tools that are Avisynth and VirtualDub. Since late October, we have used VirtualDub2 (thanks to Shekh). That said, several people have reported anomalies with the H264 encoding. We suspect Version 1809 of W10, but without any certainty. There may be other reasons like RAM, CPU and others ... This problem is very recent. On my PC which is still in V1803, I have no problem. Here. We seek to help those who encounter this problem. For information, here is the link for FILM9 : http://contact41766.wixsite.com/film9 Thanks for your advice |
8th December 2018, 20:32 | #7 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
Quote:
I'm asking for a better description of " several people have reported anomalies with the H264 encoding." Because that will help to narrow down what the underlying problem might be eg. Is it misorderered frames ? macroblocking artifacts ? wrong colors etc... or something else entirely , such as stops encoding halfway, wrong number of frames ? ie. What do you mean by "anomolies" ? . It's a very vague description Does everyone report the same type of "anomolies" or different ? |
|
9th December 2018, 09:58 | #8 | Link |
Registered User
Join Date: Dec 2013
Location: France
Posts: 64
|
Hello,
I understand your questions. It's logic. I will try to be more precise. FILM9 uses Lagarith, ProRes, FFV1 and H264 encoding capabilities. Everything works perfectly with its Codecs EXCEPT THE H264. With the H264, we have sometimes illogical operating disparities : 1st example: With 2 completely identical PCs (I7-2600K, 3.40Ghz, 16GB RAM) PC1 / W10 V1803 : H264 encoding works normally. It's slow, but it work. PC2 / W10 V1809 : crash at the beginning of the encoding (see error message). Whatever the number of pixels to process. VirtualDub Error : Video compression error: An unknown error occured (may be corrupt data). (error code -100) Other examples reported by the users of which we do not know the characteristics of the PC : - with H264 encoding 1280x720 (or lower): it works - with a H264 1920x1080 encoding : Crash at the beginning of the encoding. Of course, we assume saturation or poor indexing of memory. We know the limitations of 32 bits tools. But this disparity of malfunctions, ONLY in H264, could suggest that one can improve. But where ? Are there parameters that need to be adjusted ? Are there any priority updates to propose ? etc ... In any case, thank you for your advice. |
9th December 2018, 15:18 | #9 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
A quick hack to help with memory is to enable "large address aware" flag. You can use extra\auxsetup.exe, "Enable LAA" button.
__________________
VirtualDub2 |
9th December 2018, 20:42 | #11 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
Quote:
Very likely memory related , because the 1280x720 encode completes, but 1920x1080 fails. h264 encoding in the commonly used configurations will utilize more memory than the others, mainly because of long GOP encoding. Many frames are held in memory at one time. You can reduce the memory consumption by adjusting some settings - shorter lookahead values, shorter GOP's (default is 250 , reduce keyint value), but you will reduce compression efficacy prores, lagarith are I-frame only (intra encoding, single frames), and ffv1 is usually short GOP's or I-frame. As expected, they consume less memory Or use 64bit process, or try to split up the processes I don't know why different w10 version behaves differently. But the slowness is probably from swapping memory (pagefile) |
|
10th December 2018, 10:15 | #12 | Link |
Registered User
Join Date: Dec 2013
Location: France
Posts: 64
|
Agree with you on a memory problem.
Your idea of adjusting the GOP is interesting. There is no direct setting in the x264-8.vdplugin interface. But, that must be possible in the "Extra Command Line". I do not master this possibility very well. Could you give us an example of a weaker GOP to set. Thank you. |
10th December 2018, 11:24 | #13 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
In "Select video compression" dialog use "Force keyframes every .. frames".
__________________
VirtualDub2 |
10th December 2018, 14:04 | #14 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
I think it'd be better to reduce the maximum gop size instead, as at least then x264 can still try to place keyframes where it makes sense, such as the first frame of a scene.
Adding the following to the "extra command line" section would give you the x264 default maximum gop size (10 seconds at 25fps). --keyint 250 You probably wouldn't want to go any lower than 24 or 25 (1 second). The default lookahead for the "medium" speed preset is 40. For "slow" it's 50 and for "slower" it's 60. You could try restricting it to something less. --rc-lookahead 20 |
10th December 2018, 16:34 | #15 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Instead of what?
__________________
Groucho's Avisynth Stuff |
11th December 2018, 10:06 | #17 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
What shekh recommended does exactly the same as "--keyint xxx".
So, you're basically saying that it would be better to reduce the GOP size instead of reducing the GOP size. Also, reducing the GOP size and lookahead value was already recommended by poisondeathray.
__________________
Groucho's Avisynth Stuff |
11th December 2018, 14:07 | #18 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
The help file even implies the "force keyframes every" option isn't the same as maximum gop size. "Many modern codecs do adaptive key frame placement and more complex data rate regulation, and place all their settings in their configuration dialog." Quote:
It seems he was allowed, or did you send shekh a PM to let him know he repeated one of poisondeathray's recommendations? |
||
11th December 2018, 14:55 | #19 | Link |
Registered User
Join Date: Dec 2013
Location: France
Posts: 64
|
Thank you for your advice to everyone.
We have done many tests, but for the moment nothing really meaningful. We agree that the problem is related to memory management and is directly related to the GOP. In FILM9, the H264 encoding is programmed into a VD2 ".vdscript" file. Shekh's advice is immediately visible in the line "VirtualDub.video.SetCompression(0x34363258, X, 10000.0, "x264-8.vdplugin");" This has an influence. Different values were tested. A value of X = 10 seems to give the best results, but it is not enough to lift some crash. The tips for "Extra Command Line" are less obvious to implement. We did not see any impact in the line "VirtualDub.video.SetCompData(9336, "xxxxxxxx");" It would take a specific example of a extra command line to, for example, halve the influence of the GOP and see if there is a real difference. Thanks |
11th December 2018, 15:58 | #20 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
That's why I can't see myself ever using Win10. It sounds like a Windows update broke something.
Maybe it'd be easier to encode in 2 steps for a while. Output a lossless intermediate file using huffyuv or Lagarith etc, then re-encode the lossless file with x264. PC2 / W10 V1809 : crash at the beginning of the encoding (see error message). Whatever the number of pixels to process. If it's happening as soon as you start encoding, it's possibly not a memory issue. I see film9 requires the K-Lite Mega Codec Pack. Maybe the Windows 10 update broke/changed something there? |
Thread Tools | Search this Thread |
Display Modes | |
|
|