View Profile
View Forum Posts
Private Message
I made four AVS scripts for videos which I want to subtitle before encoding and uploading. I'm using AVFS (Avisynth Virtual File System) to load the virtual AVI files into Subtitle Edit, which worked fine for the first two (based on the same source video), but it doesn't work for the other two, I get virtual audio files but no video, yet those scripts are opened with no issue in VirtualDub or MPC-HC. What am I missing ?
Script 1 => works properly in AVFS
Script 2 => works properly in AVFSCode:V = AVISource("E:\...\(1982) George Carlin - Carlin at Carnegie.avi", audio=false) A = WAVSource("H:\(1982) George Carlin - Carlin at Carnegie.wav") AudioDub(V, A).LanczosResize(640,480).Trim(52460, 68472).FadeIn(20).FadeOut(10)
Script 3 => no video in AVFSCode:V = AVISource("E:\...\(1982) George Carlin - Carlin at Carnegie.avi", audio=false) A = WAVSource("H:\(1982) George Carlin - Carlin at Carnegie.wav") AudioDub(V, A).LanczosResize(640,480).Trim(68360, 83412).FadeIn(10).FadeOut(20)
Contents of “error.log” :Code:V = AVISource("E:\...\(1990) George Carlin - Doin' It Again.avi", audio=false) A = WAVSource("H:\George Carlin - Cats and Dogs #2 (Doin' it again 1990).wav") AudioDub(V, A).LanczosResize(640,480).Trim(18470, 39330).FadeIn(20).FadeOut(20)
Script 4 => no video in AVFSCode:Video stream :- Duration: 20863 frames, 00:11:36.129 ColorSpace: YV12 Width: 640 pixels, Height: 480 pixels. Frames per second: 29.9700 (2997/100) FieldBased (Separated) Video: No Parity: Bottom field first. Field order: Unspecified Audio stream :- Audio length: 33414213 samples. 00:11:36.129 Samples Per Second: 48000 Audio Channels: 2 Sample Type: Integer 16 bit AvfsAviMediaInit: Clip has no supported video.
Contents of “error.log” :Code:V = AVISource("E:\...\(1997) George Carlin - 40 Years of Comedy.avi", audio=false) A = WAVSource("H:\(1997) George Carlin - 40 Years of Comedy.wav") AudioDub(V, A).LanczosResize(640,480).Trim(60770, 81704).FadeIn(20).FadeOut(20)
Code:Video stream :- Duration: 20937 frames, 00:11:38.598 ColorSpace: YV12 Width: 640 pixels, Height: 480 pixels. Frames per second: 29.9700 (2997/100) FieldBased (Separated) Video: No Parity: Bottom field first. Field order: Unspecified Audio stream :- Audio length: 33532732 samples. 00:11:38.598 Samples Per Second: 48000 Audio Channels: 2 Sample Type: Integer 16 bit AvfsAviMediaInit: Clip has no supported video.
File informations for the source files, if that's relevant :
– Scripts 1 & 2 :
– Script 3 :Code:Général Nom complet : E:\...\(1982) George Carlin - Carlin at Carnegie.avi Format : AVI Format/Info : Audio Video Interleave Taille du fichier : 683 Mio Durée : 47 min 51s Débit global moyen : 1 995 kb/s Application utilisée : Nandub v1.0rc2 Bibliothèque utilisée : Nandub build 1852/release Vidéo ID : 0 Format : MPEG-4 Visual Profil du format : Simple@L3 Paramètres du format : BVOP2 Paramètres du format, BVOP : 2 Paramètres du format, QPel : Non Paramètres du format, GMC : Pas de warppoints Paramètres du format, Matrice : Default (H.263) Identifiant du codec : XVID Identifiant du codec/Suggestion : XviD Durée : 47 min 51s Débit : 1 859 kb/s Largeur : 608 pixels Hauteur : 448 pixels Format à l'écran : 4/3 Images par seconde : 29,970 (30000/1001) Im/s Espace de couleurs : YUV Sous-échantillonnage de la chrominance : 4:2:0 Profondeur des couleurs : 8 bits Type de balayage : Progressif Mode de compression : Avec perte Bits/(Pixel*Image) : 0.228 Taille du flux : 636 Mio (93%) Bibliothèque utilisée : XviD 1.0.0 (UTC 2004-05-09) Audio ID : 1 Format : AC-3 Format/Info : Audio Coding 3 Nom commercial : Dolby Digital Identifiant du codec : 2000 Durée : 47 min 51s Type de débit : Constant Débit : 128 kb/s Canaux : 2 canaux Channel layout : L R Echantillonnage : 48,0 kHz Images par seconde : 31,250 Im/s (1536 SPF) Profondeur des couleurs : 16 bits Mode de compression : Avec perte Taille du flux : 43,8 Mio (6%) Alignement : Eparpillé à travers les interleaves Imbrication, durée : 64 ms (1,92 images vidéo) Imbrication, d. de pré-chargement : 500 ms ServiceKind/String : Complete Main
– Script 4 :Code:Général Nom complet : E:\...\(1990) George Carlin - Doin' It Again.avi Format : AVI Format/Info : Audio Video Interleave Taille du fichier : 637 Mio Durée : 59 min 26s Type de débit global : Variable Débit global moyen : 1 499 kb/s Bibliothèque utilisée : VirtualDub build 14303/release Vidéo ID : 0 Format : MPEG-4 Visual Profil du format : Simple@L3 Paramètres du format, BVOP : Non Paramètres du format, QPel : Non Paramètres du format, GMC : Pas de warppoints Paramètres du format, Matrice : Default (H.263) Identifiant du codec : XVID Identifiant du codec/Suggestion : XviD Durée : 59 min 26s Débit : 1 363 kb/s Largeur : 512 pixels Hauteur : 384 pixels Format à l'écran : 4/3 Images par seconde : 29,970 (30000/1001) Im/s Espace de couleurs : YUV Sous-échantillonnage de la chrominance : 4:2:0 Profondeur des couleurs : 8 bits Type de balayage : Progressif Mode de compression : Avec perte Bits/(Pixel*Image) : 0.231 Taille du flux : 580 Mio (91%) Bibliothèque utilisée : XviD 0.0.09 (UTC 2003-03-25) Audio ID : 1 Format : MPEG Audio Version du format : Version 1 Profil du format : Layer 3 Paramètres du format : Joint stereo Identifiant du codec : 55 Identifiant du codec/Suggestion : MP3 Durée : 59 min 26s Type de débit : Variable Débit : 121 kb/s Débit nominal : 128 kb/s Canaux : 2 canaux Echantillonnage : 48,0 kHz Images par seconde : 41,667 Im/s (1152 SPF) Mode de compression : Avec perte Taille du flux : 51,6 Mio (8%) Alignement : Alignée sur les interleaves Imbrication, durée : 24 ms (0,72 image vidéo) Imbrication, d. de pré-chargement : 500 ms Bibliothèque utilisée : LAME3.93a Paramètres d'encodage : -m j -V 4 -q 2 -lowpass 17.5 --abr 128
The only significant differences I can notice are the “variable” bitrate field under “General”, and the BVOP / QPel fields, I don't know what this is.Code:Général Nom complet : E:\- humour\George Carlin\George Carlin Collection\(1997) George Carlin - 40 Years of Comedy.avi Format : AVI Format/Info : Audio Video Interleave Taille du fichier : 521 Mio Durée : 59 min 3s Type de débit global : Variable Débit global moyen : 1 234 kb/s Bibliothèque utilisée : VirtualDub build 14303/release Vidéo ID : 0 Format : MPEG-4 Visual Profil du format : Simple@L3 Paramètres du format, BVOP : Non Paramètres du format, QPel : Non Paramètres du format, GMC : Pas de warppoints Paramètres du format, Matrice : Default (H.263) Identifiant du codec : XVID Identifiant du codec/Suggestion : XviD Durée : 59 min 3s Débit : 1 099 kb/s Largeur : 512 pixels Hauteur : 384 pixels Format à l'écran : 4/3 Images par seconde : 29,970 (30000/1001) Im/s Espace de couleurs : YUV Sous-échantillonnage de la chrominance : 4:2:0 Profondeur des couleurs : 8 bits Type de balayage : Progressif Mode de compression : Avec perte Bits/(Pixel*Image) : 0.187 Taille du flux : 464 Mio (89%) Bibliothèque utilisée : XviD 0.0.09 (UTC 2003-03-25) Audio ID : 1 Format : MPEG Audio Version du format : Version 1 Profil du format : Layer 3 Paramètres du format : Joint stereo Identifiant du codec : 55 Identifiant du codec/Suggestion : MP3 Durée : 59 min 3s Type de débit : Variable Débit : 120 kb/s Débit nominal : 128 kb/s Canaux : 2 canaux Echantillonnage : 48,0 kHz Images par seconde : 41,667 Im/s (1152 SPF) Mode de compression : Avec perte Taille du flux : 50,8 Mio (10%) Alignement : Alignée sur les interleaves Imbrication, durée : 24 ms (0,72 image vidéo) Imbrication, d. de pré-chargement : 533 ms Bibliothèque utilisée : LAME3.93a Paramètres d'encodage : -m j -V 4 -q 2 -lowpass 17.5 --abr 128
Side question :
– I had synchronization issues at first when trying to use AVISource with the audio enabled, and another issue which I don't quite remember (I did that months ago, couldn't find time to make the subtitles until now) with the one which has AC3 audio, so I resorted to extracting the audio as WAV with VirtualDub, then loading the audio separately in the scripts. Is this the recommanded method, or is there a more convenient way to deal with that kind of source without those extra steps ?
– Last time I checked, YouTube didn't propose a resolution of 640x480 for uploaded videos having even a slightly lower resolution than that. Is it still the case ? If so, does it make sense to resize to 640x480 before uploading, i.e. will it improve the visual quality ? And is LanczosResize a wise choice for that type of material ? (Needless to say, I don't have access to the source DVDs, which were never released in France as far as I know...)
+ Reply to Thread
Results 1 to 25 of 25
-
-
Simple workaround is to change the script, use ffms2 or lsmash instead of avisource .
Do you have 1 version of avisynth installed ? or both x86, x64 ?
Possible explanation is you're mixing up x86 x64 versions somewhere . Decoding pathway might different for 1&2 vs. 3&4
xvid 1.0 vs. xvid 0.0.09
In vdub, with the avs loaded, check file=>file information for each
There are different avfs versions - are you using the pismo mount, or the CLI version ?
Are you sure it was the AC3 version ? Usually with AVI, it's VBR MP3 problem. AC3 is CBR, less prone to issues. If it was a constant sync issue, then you can use DelayAudio (+/-)Side question :
– I had synchronization issues at first when trying to use AVISource with the audio enabled, and another issue which I don't quite remember (I did that months ago, couldn't find time to make the subtitles until now) with the one which has AC3 audio, so I resorted to extracting the audio as WAV with VirtualDub, then loading the audio separately in the scripts. Is this the recommanded method, or is there a more convenient way to deal with that kind of source without those extra steps ?
If it was MP3, EnsureVBRMP3Sync
http://avisynth.nl/index.php/EnsureVBRMP3Sync
Or use alternative source filter method like FFMS2, L-smash
YT is one of the few cases where upscaling to at least "HD" 720 height is beneficial . It allocates more bitrate in proportion, and even the sd version of hd, looks better than the sd version– Last time I checked, YouTube didn't propose a resolution of 640x480 for uploaded videos having even a slightly lower resolution than that. Is it still the case ? If so, does it make sense to resize to 640x480 before uploading, i.e. will it improve the visual quality ? And is LanczosResize a wise choice for that type of material ? (Needless to say, I don't have access to the source DVDs, which were never released in France as far as I know...)
Usually a sharper resizer in general for upscaling, you can try different ones . Default LanczosResize is 3 tap , you can try 4 for sharper for example, but you will get ringing artifacts. It depends on the source
You can do some small tests (e.g. upload a small test section), then evaluate,change, repeat. Because practices are changing at YT all the time. h264 seems to be going down in quality, and VP9 encodes going up in general . But it's not clear how/why YT makes VP9 available on some videos , but not others.Last edited by poisondeathray; 20th Nov 2018 at 12:14.
-
Thank you for this quick and thorough reply !
Simple workaround is to change the script, use ffms2 or lsmash instead of avisource.Avisynth+, which apparently uses both 32 bits and 64 bits plugins. But I get this message in "error.log" when trying to load with LSMASH / LWLibavVideoSource (no video and no audio in the virtual folder) :Do you have 1 version of avisynth installed ? or both x86, x64 ? Possible explanation is you're mixing up x86 x64 versions somewhere.
Modified script :Code:Cannot load a 64 bit DLL in 32 bit Avisynth: 'C:/Program Files (x86)/AviSynth+/plugins/SmoothAdjust 64b.dll'.
Strange because I copied those commands from a script I made a few months ago, which worked (to load MP4 files). But the DLL is loaded from a subfolder in MeGUI, it may have been updated since then.Code:LoadPlugin("C:\...\MeGUI\tools\lsmash\LSMASHSource.dll") V = LWLibavVideoSource("E:\...\(1990) George Carlin - Doin' It Again.avi") A = WAVSource("H:\George Carlin - Cats and Dogs #2 (Doin' it again 1990).wav") AudioDub(V, A).LanczosResize(640,480).Trim(18470, 39330).FadeIn(20).FadeOut(20)
And apparently installing or using StaxRip recently changed something, there's a “Setup Log 2018-10-26 #001.txt” in the Avisynth+ folder which lists many modifications made that day.
Same result with FFVideoSource + AVFS (same message in “error.log”), although quite oddly this gets opened in VirtualDub / MPC-HC.
Is there a way to verify this ?Decoding pathway might be different for 1&2 vs. 3&4
Indeed, another difference. How is it significant ?xvid 1.0 vs. xvid 0.0.09
I checked this before sending the first post, found no significant difference.In vdub, with the avs loaded, check file=>file information for each
[Script 1]
[Script 2]Code:Video: Frame size, fps (µs per frame): 640x480, 29.970 fps (33367 µs) Length: 16015 frames (8:54.36) Decompressor: Internal DIB decoder (YV12) Number of key frames: 16015 Min/avg/max/total key frame size: 460800/460800/460800 (7206750K) Min/avg/max/total delta size: (no delta frames) Data rate: 110481 kbps (0.01% overhead) Audio: Sampling rate: 48000Hz Channels: 2 (Stereo) Sample precision: 16-bit Compression: PCM (Uncompressed) Layout: 16022 chunks (0.03s preload) Length: 25649649 samples (8:54.36) Min/avg/max/total frame size: 112/6403/6404 (100194K) Data rate: 1536 kbps (0.37% overhead)
[Script 3]Code:Video: Frame size, fps (µs per frame): 640x480, 29.970 fps (33367 µs) Length: 15055 frames (8:22.33) Decompressor: Internal DIB decoder (YV12) Number of key frames: 15055 Min/avg/max/total key frame size: 460800/460800/460800 (6774750K) Min/avg/max/total delta size: (no delta frames) Data rate: 110481 kbps (0.01% overhead) Audio: Sampling rate: 48000Hz Channels: 2 (Stereo) Sample precision: 16-bit Compression: PCM (Uncompressed) Layout: 15061 chunks (0.03s preload) Length: 24112111 samples (8:22.33) Min/avg/max/total frame size: 4204/6403/6404 (94188K) Data rate: 1536 kbps (0.37% overhead)
[Script 4]Code:Video: Frame size, fps (µs per frame): 640x480, 29.970 fps (33367 µs) Length: 20863 frames (11:36.12) Decompressor: Internal DIB decoder (YV12) Number of key frames: 20863 Min/avg/max/total key frame size: 460800/460800/460800 (9388350K) Min/avg/max/total delta size: (no delta frames) Data rate: 110481 kbps (0.01% overhead) Audio: Sampling rate: 48000Hz Channels: 2 (Stereo) Sample precision: 16-bit Compression: PCM (Uncompressed) Layout: 20871 chunks (0.03s preload) Length: 33414213 samples (11:36.12) Min/avg/max/total frame size: 5372/6403/6404 (130525K) Data rate: 1536 kbps (0.37% overhead)
Code:Video: Frame size, fps (µs per frame): 640x480, 29.970 fps (33367 µs) Length: 20937 frames (11:38.59) Decompressor: Internal DIB decoder (YV12) Number of key frames: 20937 Min/avg/max/total key frame size: 460800/460800/460800 (9421650K) Min/avg/max/total delta size: (no delta frames) Data rate: 110481 kbps (0.01% overhead) Audio: Sampling rate: 48000Hz Channels: 2 (Stereo) Sample precision: 16-bit Compression: PCM (Uncompressed) Layout: 20945 chunks (0.03s preload) Length: 33532732 samples (11:38.59) Min/avg/max/total frame size: 5552/6403/6404 (130988K) Data rate: 1536 kbps (0.37% overhead)
Pismo Mount. What does it change ?There are different avfs versions - are you using the pismo mount, or the CLI version ?
The synchronization issue was probably with the VBR MP3 source AVI files. I tested again with the one which has AC3 audio (using AVISource to load video + audio directly) : the audio playback is jerky, there's a sort of constant stuttering (which is even worse than a simple desynchronization).Are you sure it was the AC3 version ? Usually with AVI, it's VBR MP3 problem. AC3 is CBR, less prone to issues. If it was a constant sync issue, then you can use DelayAudio (+/-)
If it was MP3, EnsureVBRMP3Sync
http://avisynth.nl/index.php/EnsureVBRMP3Sync
So in that case it would be worth it to upscale as high as 720, even with sources as low as 384 ? (From my observations I thought that 480p was a good compromise, while 360p is usually quite lousy.)YT is one of the few cases where upscaling to at least "HD" 720 height is beneficial . It allocates more bitrate in proportion, and even the sd version of hd, looks better than the sd version
What is a “tap” or “lobe” in layman's terms ? In the Resize doc it is stated that Lanczos “is NOT suited for low bitrate video; the various Bicubic flavours are much better for this” – but what is “low bitrate” in that context ?Usually a sharper resizer in general for upscaling, you can try different ones . Default LanczosResize is 3 tap , you can try 4 for sharper for example, but you will get ringing artifacts. It depends on the source
It may be overkill in a case like this to do such thorough testing (the source videos are not high quality to begin with, I just want a comfortably watchable result, with clear subtitles), but it's good to know.You can do some small tests (e.g. upload a small test section), then evaluate,change, repeat. Because practices are changing at YT all the time. h264 seems to be going down in quality, and VP9 encodes going up in general . But it's not clear how/why YT makes VP9 available on some videos , but not others.Last edited by abolibibelot; 20th Nov 2018 at 13:42.
-
Yes, but avisynth+ x86 is separate from avisynth+ x64 .Originally Posted by abolibibelot
A 64bit process in general has to have everything 64bit and vice-versa for 32bit (there are some exception workarounds like mp_pipeline where you can mix and match)
For example, if you use vdub2 x64, it will "load" avisynth x64 automatically . But if you use vdub2 x86, it will "load" avisynth x86 . Same with mpchc. mpchc x86 will only load avisynth x86 . If you had x64 plugins, it will cause error.
It looks like you are using avisynth+ x86 if you get 64bit dll load error . So I would just repeat it with ffms2 x86 , lsmash x86
If you open the AVI's directly in vdub x86, then use file=>file information, what does it say. It should reveal what decoder is being used, and that's usually the one AVISource x86 is usingIs there a way to verify this ?Decoding pathway might be different for 1&2 vs. 3&4
Not sure, but it might elicit a different decoder response, file=>file information with the AVI directly loaded in vdub should tell youIndeed, another difference. How is it significant ?xvid 1.0 vs. xvid 0.0.09
The CLI version is newer, works with vapoursynth too. But older version should work fine with x86
Pismo Mount. What does it change ?There are different avfs versions - are you using the pismo mount, or the CLI version ?
Not sure why it's not working for those 2 videos.
Higher produces sharper results . But more ringing artifacts. That's why using on "low bitrate" is not recommended - the artifacts will be enhanced and sharpened by a sharp resizerWhat is a “tap” or “lobe” in layman's terms ? In the Resize doc it is stated that Lanczos “is NOT suited for low bitrate video; the various Bicubic flavours are much better for this” – but what is “low bitrate” in that context ?Usually a sharper resizer in general for upscaling, you can try different ones . Default LanczosResize is 3 tap , you can try 4 for sharper for example, but you will get ringing artifacts. It depends on the source -
In this case I used VirtualDub2 x64 and MPC-HC x64, so that would seem consistent indeed.Yes, but avisynth+ x86 is separate from avisynth+ x64 .
A 64bit process in general has to have everything 64bit and vice-versa for 32bit (there are some exception workarounds like mp_pipeline where you can mix and match)
For example, if you use vdub2 x64, it will "load" avisynth x64 automatically . But if you use vdub2 x86, it will "load" avisynth x86 . Same with mpchc. mpchc x86 will only load avisynth x86 . If you had x64 plugins, it will cause error.
I tried explicitly loading ffms2 from the “Avisynth+\plugins” directory, it failed again, with the same error message ; then I just moved that “SmoothAdjust 64b.dll” file from “plugins” to “plugins64” (both 32b and 64b versions were in “plugins”), now it works with AVFS, as well as VirtualDub2 x86 / x64 (using FFVideoSource or LWLibavVideoSource, but still no video with AVISource). How come that file caused the scripts (and only some of them) to fail, even though it was not actually used in them ?It looks like you are using avisynth+ x86 if you get 64bit dll load error . So I would just repeat it with ffms2 x86 , lsmash x86
If you open the AVI's directly in vdub x86, then use file=>file information, what does it say. It should reveal what decoder is being used, and that's usually the one AVISource x86 is usingVirtualDub2 doesn't say anything about the decoder, but VirtualDubMod says :Not sure, but it might elicit a different decoder response, file=>file information with the AVI directly loaded in vdub should tell you
– Decompressor: ffdshow Video Codec (for the first file, XviD 1.0.0, the script of which worked right away)
– Decompressor: GEO-MPEG4 ASP (for the other two, XviD 0.0.09, the script of which didn't work with AVFS)
Now that's interesting. I recently installed a GeoVision codec, to try to solve a completely unrelated issue, apparently it's being used for other files than the AVI/GAVC ones it was intended for. How can I control that ? And what is the usual / recommanded decompressor for MPEG4-ASP videos ?
I also recently installed CCCP Codec Pack, both in 64b and 32b (that pack is recommanded to use some features of Scorp Video Thumbnails Maker, I first installed it in 64b, then was advised to install the 32b version on the forum dedicated to that tool) ; is it known to provoke conflicts of any kind ?
In a nutshell, what are the main advantages, and drawbacks if any, of switching from Avisynth to Vapoursynth ?The CLI version is newer, works with vapoursynth too. But older version should work fine with x86
But what is considered as a “low bitrate” in that context ? Do those particular files qualify ? Their bitrate is relatively high compared with typical Xvid encodes, and that type of footage should not be too demanding, but it's still highly compressed compared with the DVD source, and even DVD video is compressed enough to show artifacts, so I'm not sure what they mean here...Higher produces sharper results . But more ringing artifacts. That's why using on "low bitrate" is not recommended - the artifacts will be enhanced and sharpened by a sharp resizer -
autoloading directory will attempt to autoload everything. If there is a problematic .dll, it will give you error message, even if it's not used in the script. That's why some people keep very clean autoload directory (sometimes empty) . Some prefer to manually load everything (LoadPlugin). I keep minimal autoload (so in between; only frequently used items are autoloaded for me) . Another reason is it's slower with more "junk" in the autoload directory to initialize avisynth, because everything is loadedOriginally Posted by abolibibelot
if it was a 64bit pathway, you wouldn't get that error; so probably those scripts that were working were actually 64bit
It's a good idea to keep things organized, separate 64bit vs. 32bit .
Usually xvid. So you would need a 64bit version of xvid, if you had 64bit AVISource in a 64bit avs script. There is no current 64bit ffdshow, so that is probably running 32bit. I've never heard of GeoVision, but something is triggering that decoder pathway for those xvid 0.0.09 videos. Maybe you don't have another 64bit mpeg4-asp decoder installed, maybe GeoVision has a higher priority set. Maybe something with those 0.0.09 files cannot be decoded by other decodersIf you open the AVI's directly in vdub x86, then use file=>file information, what does it say. It should reveal what decoder is being used, and that's usually the one AVISource x86 is usingVirtualDub2 doesn't say anything about the decoder, but VirtualDubMod says :Not sure, but it might elicit a different decoder response, file=>file information with the AVI directly loaded in vdub should tell you
– Decompressor: ffdshow Video Codec (for the first file, XviD 1.0.0, the script of which worked right away)
– Decompressor: GEO-MPEG4 ASP (for the other two, XviD 0.0.09, the script of which didn't work with AVFS)
Now that's interesting. I recently installed a GeoVision codec, to try to solve a completely unrelated issue, apparently it's being used for other files than the AVI/GAVC ones it was intended for. How can I control that ? And what is the usual / recommanded decompressor for MPEG4-ASP videos ?
Alternatively , use ffms2 or lsmash. Negatives are requires indexing (clutter with index files, slower) . Benefit is you don't have mix ups like this if you don't keep a clean system with exactly known configurations for VFW / Directshow , x86 vs x64, etc..
Not sure, don't use them. There is a VFW system (which AVISource uses), and a DirectShow system (which directshowsource uses) . Both have x86 and x64 versions. You need to use do housekeeping things to keep them in order, with tools like codec tweak tool, vcswap, graphstudio etc.... You have to do things like change merits (priorities) in case there are competing decoders, or manually activate/deactivate some or all . Some people don't want/don't like tinkering so ffms2 / lsmash are better options for themI also recently installed CCCP Codec Pack, both in 64b and 32b (that pack is recommanded to use some features of Scorp Video Thumbnails Maker, I first installed it in 64b, then was advised to install the 32b version on the forum dedicated to that tool) ; is it known to provoke conflicts of any kind ?
A lot of overlap, but avisynth is more complete and has been around a lot longer. But you can use them both, pros/cons to each and in some situation they can complment each otherIn a nutshell, what are the main advantages, and drawbacks if any, of switching from Avisynth to Vapoursynth ?The CLI version is newer, works with vapoursynth too. But older version should work fine with x86
-So there are more filters available for avs. Sometimes there is some obscure filter you might need for something
-Audio is a big difference, Vapoursynth doesn't officially support audio (there are ways to pipe 2 streams including audio, but if you need audio processing, avisynth is better) .
-Vapoursynth tends to be better for higher bit depth handling and float formats
-Vapoursynth has native mulithreading, there is no need for manual tweaking or figuring out prefetch values (for avisynth+ mt)
-Some newer filters, research based, machine learning, are only available for vapoursynth. Likely because vpy is python based and many of the projects are python based. It's easier to make it vpy compatible
-You can load avisynth scripts directly in vapoursynth, and load most avisynth plugins as well. But you can only load some vapoursynth scripts in avisynth. avfs can get around this both ways , and make both compatible with basically everything (but there is overhead with avfs, not as fast)
Just look at it, you can't make a determination based on numbers alone without "seeing" it; because different content have different bitrate requirements. Higher bitrate doesn't necessarily mean high quality either; it might have been through "n" generations, for example. The higher bitrate might be as a result of artifacts.
But what is considered as a “low bitrate” in that context ? Do those particular files qualify ? Their bitrate is relatively high compared with typical Xvid encodes, and that type of footage should not be too demanding, but it's still highly compressed compared with the DVD source, and even DVD video is compressed enough to show artifacts, so I'm not sure what they mean here...Higher produces sharper results . But more ringing artifacts. That's why using on "low bitrate" is not recommended - the artifacts will be enhanced and sharpened by a sharp resizer
If there are significant artifacts, another option is filtering them before upscaling . There are dedicated upscaling scripts too.
If in doubt, just do a quick test . Takes a few minutes to see what looks betterLast edited by poisondeathray; 20th Nov 2018 at 16:25.
-
What are the contents of error.log for the two scripts that mount?Originally Posted by abolibibelot
-
I'm still using XP so I'm not familiar with 64 bit problems, but I haven't seen anyone else ask, so I thought I would....
It appears that Subtitle Edit comes in a 64 bit flavour, it can use VLC or MPC-HC for the video preview instead of the built-in media player, and it can open Avisynth scripts directly (I just checked a script with DGDecode doing the decoding, although it didn't include any audio), so whether you go all 32 bit or all 64 bit, why use AVFS?
Or.... there's a utility that comes with ffdshow called MakeAVIS, should you have it installed. ffdshow has to do the decoding for it to work and "Avisynth" needs to be enabled in it's codec list. When you run MakeAVIS it'll wrap a script into an AVI. It can also include the audio (as a wave file, from memory), or you can just wrap a video-only script into an AVI, open it with VirtualDub, add any type of audio that VirtualDub supports, then save that as a new AVI using Direct Stream Copy for both the video and audio. The result will be an AVI a few MBs larger than the size of the audio stream. You can even edit the video with VirtualDub and it'll save an edited version just as it would when editing a "normal" AVI.
As a side note, does anyone know if the required codec can be found as a standalone version? It'd be a pity to lose the MakeAVIS functionality when ffdshow becomes too old to install, or because it can't be installed for some reason.Last edited by hello_hello; 21st Nov 2018 at 01:04.
-
I noticed that the working scripts use asymmetric fades. Might just be a funny incident.
Also I notice that the videos 3 and 4 were created with Xvid 0.0.9, that may be incompatible to the VfW decoder used in AviSource; FFMS2 and L-SMASH Works may indeed help here.
Separation of ffvfw has been asked for several times. Very old separate versions may have existed, but the latest versions I only know in ffdshow. At least you may not have to install the DirectShow part, or could unregister all formats. -
@JVRaines
Same without the “Clip has no supported video” line :What are the contents of error.log for the two scripts that mount?
Code:Video stream :- Duration: 16015 frames, 00:08:54.367 ColorSpace: YV12 Width: 640 pixels, Height: 480 pixels. Frames per second: 29.9700 (2997/100) FieldBased (Separated) Video: No Parity: Bottom field first. Field order: Unspecified Audio stream :- Audio length: 25649649 samples. 00:08:54.367 Samples Per Second: 48000 Audio Channels: 2 Sample Type: Float 32 bit
@poisondeathray
Alright, some clean-up to do then... like in my appartment... *sigh*autoloading directory will attempt to autoload everything. If there is a problematic .dll, it will give you error message, even if it's not used in the script. That's why some people keep very clean autoload directory (sometimes empty) . Some prefer to manually load everything (LoadPlugin). I keep minimal autoload (so in between; only frequently used items are autoloaded for me) . Another reason is it's slower with more "junk" in the autoload directory to initialize avisynth, because everything is loaded
So the idea is to put plugins anywhere except in the specific Avisynth “plugins” folders ? Are there some restrictions, like forbidden spaces or accentuated characters ? (At least spaces don't seem to be a problem, since Avisynth+ is installed in “Program Files (x86)”.)
But why would one script run in 32b and another in 64b, with basically the same settings, only different sources ? How can I verify this ?if it was a 64bit pathway, you wouldn't get that error; so probably those scripts that were working were actually 64bit
Those two scripts work with MPC-HC 32b and VirtualDubMod 32b if that's any indication.
I don't remember exactly why I installed Avisynth+ rather than the basic Avisynth on this computer. From what I've read the 64b implementation is not so well optimized and many plugins are only available in 32b anyway.
@hello_hello
Wow... I thought that I was the last on Earth to make the switch !I'm still using XP so I'm not familiar with 64 bit problems, but I haven't seen anyone else ask, so I thought I would.... Isn't it supposed to be a huge risk when going online ? (Although my brother's 2004 laptop computer is running on XP, without an antivirus since I couldn't find a free one working without hassle, and has had no malware-related issue so far. He has some kind of disability, so when I gave him the computer I configured it so as to make it easier to use – renaming each program's shortcut with its basic function for instance, or keeping things as streamlined as possible –, and I regularly do remote maintenance, but he's wise enough to never attempt to install something or do anything that he doesn't understand, or go to shady-seedy websites... and I make sure that his files as well as the system are backed-up, so even if something goes wrong nothing's lost.)
I hate quite a few things with Windows 7, with regards to ergonomy and basic usage, but the main issue with XP was its inability to access HDDs beyond 2TB.
I didn't know that, quite simply, I didn't think that a subtitle editor could have such an advanced feature... But I just tried (with v. 3.5.6 64b), loading an Avisynth script as a regular video doesn't work (although .avs is indeed among the allowed extensions), and I can't find a specific command in the menu.It appears that Subtitle Edit comes in a 64 bit flavour, it can use VLC or MPC-HC for the video preview instead of the built-in media player, and it can open Avisynth scripts directly (I just checked a script with DGDecode doing the decoding, although it didn't include any audio), so whether you go all 32 bit or all 64 bit, why use AVFS?
@LigH.de
I had to split this one in two halves, since the duration of the total sequence would be beyond 15min. limit which was the limit on a regular YT account last time I checked ; so I purposefully placed a shorter fade-out at the end of part 1 and a shorter fade-in at the begining of part 2 (and a few seconds of overlap between the two). (It will be a thematic series of George Carlin talking about cats and dogs, from 1982 to 1997, subtitled in french, I promised that to someone about a year ago...)I noticed that the working scripts use asymmetric fades. Might just be a funny incident.
But how does this explain that the AVISource scripts work with VirtualDub / MPC-HC ?Also I notice that the videos 3 and 4 were created with Xvid 0.0.9, that may be incompatible to the VfW decoder used in AviSource; FFMS2 and L-SMASH Works may indeed help here.
Well, here I'm kinda lost... é_è (Having a cold doesn't help.)Separation of ffvfw has been asked for several times. Very old separate versions may have existed, but the latest versions I only know in ffdshow. At least you may not have to install the DirectShow part, or could unregister all formats.
What is “separation” in this context ? What should I unregister, how and why ?Last edited by abolibibelot; 21st Nov 2018 at 03:58.
-
Regarding the separation: This part of my answer was for hello_hello.
-
When I gave opening a script with Subtitle Edit a spin, it opened via DirectShow, so I assume you'd need the DirectShow version of the codec in this case. ffdshow's DirectShow and VFW configurations both include "Avisynth" in their lists of available codecs though. I'm pretty sure that's the one that has to be enabled for MakeAVIS to work.Originally Posted by LigH.de
-
If you have an application which uses the VfW API to read video, you need the ffvfw VfW codec.
If you have an application which uses the DirectShow API to read video, you need the ffdshow DirectShow filter (may it work on its own, or as bridge in addition to the ffvfw VfW codec).
Yes, both DirectShow decoder filter and VfW decoder can be configured to support "AviSynth" (AVIS) as codec. -
I'm pretty sure my next OS will be Linux Mint. I can't see myself using a newer Windows.Originally Posted by abolibibelot
@hello_hello
Wow... I thought that I was the last on Earth to make the switch !I'm still using XP so I'm not familiar with 64 bit problems, but I haven't seen anyone else ask, so I thought I would.... Isn't it supposed to be a huge risk when going online ? (Although my brother's 2004 laptop computer is running on XP, without an antivirus since I couldn't find a free one working without hassle, and has had no malware-related issue so far. He has some kind of disability, so when I gave him the computer I configured it so as to make it easier to use – renaming each program's shortcut with its basic function for instance, or keeping things as streamlined as possible –, and I regularly do remote maintenance, but he's wise enough to never attempt to install something or do anything that he doesn't understand, or go to shady-seedy websites... and I make sure that his files as well as the system are backed-up, so even if something goes wrong nothing's lost.)
I hate quite a few things with Windows 7, with regards to ergonomy and basic usage, but the main issue with XP was its inability to access HDDs beyond 2TB.
For the record, XP can read and write to hard drives larger than 2TB. It just can't format them. At least it can for hard drives of the USB variety, although I think the same applies to "internal" drives. I filled a 3TB portable drive to the brim with video for my sister recently, and I'm pretty sure my ex has a 4TB drive she's connected to this PC on a few occasions.
I haven't run antivirus or anti-malware software for years. Or a software firewall (I'm behind a router), and I sometimes travel to shady corners of the internet. Fortunately the days of drive-by infections courtesy of Microsoft's ActiveX are long gone. I've only been "infected" once. It was a couple of years ago and it was my fault. I installed a program while clicking through the installation options too quickly and forgot to disable the included adware crap and then I couldn't get rid of it. My ancient copy of Norton Ghost restored the image of my C partition in a couple of minutes though, fixing that hiccup. Picking up an infection does seem to be something you generally have to go out of your way for (as I did on one occasion), even when your OS is XP.Last edited by hello_hello; 21st Nov 2018 at 10:39.
-
There is a XP x64; then you can have 64bit problems too!Originally Posted by hello_hello
Only the top directory of the plugins folder . If you have subfolders it won't scan them .Originally Posted by abolibibelot
Spaces are ok; not sure about accented characters but I've seen them cause problems for other people (I don't have any) .
If a script opens directly in 32bit mpchc,vdub (through the AVI driver, not necessarily other methods) , that means that particular script is currently running through avisynth 32bit. But that exact same script can also run in a different pathway through 64bit mpchc,vdub. The first case is 32bit, the 2nd is 64bit.But why would one script run in 32b and another in 64b, with basically the same settings, only different sources ? How can I verify this ?if it was a 64bit pathway, you wouldn't get that error; so probably those scripts that were working were actually 64bit
Those two scripts work with MPC-HC 32b and VirtualDubMod 32b if that's any indication.
So usually the other application determines which version gets initialized. 64bit application will get 64bit avisynth. But if the application has both 32bit and 64bit versions, or if it can run both (some applications have a bridge to run both), that' s no help. AVFS can run both, so it could be either.
version() in the script will list that the current avisynth version is when run through a specific application. But the problem is a specific script might run through a different pathway if an application has both 32bit and 64bit versions.
Not any more; most commonly used plugins/scripts have 64bit versions by now . And avisynth+ 64bit MT is very well optimized, signifcantly faster (not just because of memory; even small scripts with low memory footprint run faster)I don't remember exactly why I installed Avisynth+ rather than the basic Avisynth on this computer. From what I've read the 64b implementation is not so well optimized and many plugins are only available in 32b anyway.
Also for vdub2 , when you open an AVI to check file=>file information ; you might have to explicitly select AVI as the input driver in the open dialog box to route it through VFW (instead of the caching input driver) . Older versions of vdub , vdubmod selected that automatically as higher priority
So check both 32bit, 64bit vdub file=>file information for those AVI's loaded directly with your default configuration . Then disable that GEO codec and check again. You can use codec tweak tool. ACM/VFW is the category you want to adjust -
@hello_hello
I'll try that later on, but right now it works with AVFS and FFMS2, so I'll just keep going with the subtitling, which is quite a chore in and of itself !When I gave opening a script with Subtitle Edit a spin, it opened via DirectShow, so I assume you'd need the DirectShow version of the codec in this case. ffdshow's DirectShow and VFW configurations both include "Avisynth" in their lists of available codecs though. I'm pretty sure that's the one that has to be enabled for MakeAVIS to work.
@poisondeathray
Indeed, I have previously opened those files in VirtualDub2 by drag-and-drop, if I open one through the “Open video file” menu and select “Audio/Video Interleave”, I get a warning about VBR audio and possible synchronization issues (for the two with MP3 audio), or a warning about truncated audio (for the one with AC3 audio – it exactly says : “AVI: Truncated or invalid compressed audio format detected (18 bytes, should be 36). Attempting to fix.” – perhaps this could explain the stuttering issue when played through Avisynth), then the “File information” display is similar to that of VirtualDubMod, and it does show the “Decompressor”.Also for vdub2 , when you open an AVI to check file=>file information ; you might have to explicitly select AVI as the input driver in the open dialog box to route it through VFW (instead of the caching input driver) . Older versions of vdub , vdubmod selected that automatically as higher priority
So check both 32bit, 64bit vdub file=>file information for those AVI's loaded directly with your default configuration . Then disable that GEO codec and check again. You can use codec tweak tool. ACM/VFW is the category you want to adjust
– VDub2 x64 shows “ffdshow Video Codec (XVID)” for all three videos
– VDub2 x86 shows “ffdshow Video Codec (XVID)” for the first one (Xvid 1.0.0) and “GEO-MPEG4 ASP (XVID)” for the other two (Xvid 0.0.9) (just like VirtualDubMod)
Interesting... If I open the original AVISource scripts in VDub2 x86 with “Avifile input driver”, the first two work fine, but the last two (the ones which couldn't get mounted by AVFS) appear as a garbled, upside-down, green picture, with some sort of low resolution grid over it, and seemingly a superposition of two distinct parts of the footage. In “File information”, the decompressor is reported as “Internal DIB decoder (YV24)”.If a script opens directly in 32bit mpchc,vdub (through the AVI driver, not necessarily other methods) , that means that particular script is currently running through avisynth 32bit. But that exact same script can also run in a different pathway through 64bit mpchc,vdub. The first case is 32bit, the 2nd is 64bit.
They play fine in VDub2 x64, and in “File information” the decompressor is reported as “Internal DIB decoder (YV12)”.
VirtualDubMod issues a warning saying “Couldn't locate decompressor for format 'YV24' (unknown)” and displays no picture at all.
Maybe there's a way to overlay the “version” information by placing that command at the end of an existing script ?So usually the other application determines which version gets initialized. 64bit application will get 64bit avisynth. But if the application has both 32bit and 64bit versions, or if it can run both (some applications have a bridge to run both), that' s no help. AVFS can run both, so it could be either.
version() in the script will list that the current avisynth version is when run through a specific application. But the problem is a specific script might run through a different pathway if an application has both 32bit and 64bit versions.
Alright then, I'll try again with the most recent update. Last time I used Avisynth (which was months ago) I couldn't get QTGMC to work, even though all the required plugins seemed to be in the right place, couldn't figure out why.Not any more; most commonly used plugins/scripts have 64bit versions by now . And avisynth+ 64bit MT is very well optimized, signifcantly faster (not just because of memory; even small scripts with low memory footprint run faster)
@hello_hello
These are most likely connected through an enclosure which uses a special “4K formatting”, meaning that the USB controler translates the actual 512 bytes sectors as 4K virtual sectors, which allows 32-bits Windows XP to access a volume of up to 16TB instead of 2TB with the old MBR partitioning scheme (since XP can't use the newer GPT format). But if the enclosure is opened and the drive is connected directly in SATA, the data it contains won't be recognized.For the record, XP can read and write to hard drives larger than 2TB. It just can't format them. At least it can for hard drives of the USB variety, although I think the same applies to "internal" drives. I filled a 3TB portable drive to the brim with video for my sister recently, and I'm pretty sure my ex has a 4TB drive she's connected to this PC on a few occasions.
https://www.klennet.com/notes/2018-04-14-usb-and-sector-size.aspx
When I was still using XP I tried some potential workarounds, including a special GPT driver designed by Paragon, it worked at first, I could write on a 3TB drive (plugged in SATA), but then there was some hiccup and the drive's contents were no longer accessible, so I abandoned that idea. Reliability is paramount when it comes to data storage, there are already enough SNAFUs as it is !
I try not to think about what's next, but indeed even Windows 7 will soon be on the way out, with regards to official support, while Windows 8/10 seem horrendous for any serious use. My mother's computer has Windows 8, sometimes I help her remotely and it's a real PITA (the OS I mean).I'm pretty sure my next OS will be Linux Mint. I can't see myself using a newer Windows.
But as far as I know there is no port or equivalent for Avisynth on Linux, so how do you plan to perform that kind of video-related tasks ? -
Weren't most "internal" drives doing something similar? I kind of remember all AF drives doing the translation thing at one stage for backwards compatibility. Maybe they don't anymore, but wasn't that the reason you needed to use a manufacture utility to align AF drives if you formatted them with XP? I have quite a few 2TB WD "internal" drives I mostly use as external drives in USB docks, and I'm pretty sure they all had to be aligned, or you could set a jumper to "XP position" before formatting. Maybe that's not quite the same thing. I wouldn't be surprised if accessing drives over 2TB was more a BIOS issue than an XP one. Or maybe I'm completely wrong. I haven't needed to think about any of that stuff for a while and my memory isn't the best.Originally Posted by abolibibelot
Vapoursynth is probably the way to go. There shouldn't be too much of a learning curve if you're relatively familiar with Avisynth (famous last words). I'd be playing around to familiarise myself with it now, but it doesn't support XPOriginally Posted by abolibibelot
I had a brief play with Linux Mint a while back. The system for running programs in Wine works quite seamlessly, assuming a program will run that way. I didn't get around to testing Avisynth, but if there's no other option, installing Windows as a Virtual OS was quite easy. Off the top of my head I can't remember which version of Mint it was (in respect to the desktop) but it was pleasantly XP-like. I'd planned to try some other Linux distros, but I liked Linux Mint enough not to bother. I should stop procrastinating a build a new PC to install it on permanently, but for quite a while I was the sucker building them for friends and family members and fixing their Windows problems as well as my own, and I'm sooooo over all that. I'll have to man-up sometime though.Last edited by hello_hello; 22nd Nov 2018 at 13:49.
-
So it looks like those last two 0.0.9 videos are eliciting a GEO codec response under x86 for whatever reason, and it's not decoding correctly through x86
I would just do some codec housekeeping . I would either disable (if you still need it for other things for some reason), or uninstall that GEO codec . Then repeat the tests. If you still have problems, instead of ffdshow (which has been abandoned years ago) , I would use xvid . Disable all mpeg4 components in the ffdshow configuration. If you still can't get it to work, then maybe direct stream copy a small cut sample and upload it
The reason why MPCHC plays video ok directly, is it's a different decoding system and pathway. Directshow, not VFW . If you want to tinker with your directshow system, you can investigate that if you want with graphstudio. The decoder with the highest merit will be connected automatically. You can change merits, disable/enable various codecs right in graphstudio as well -
It sounds like the ffms2 workaround is working for you , but for completeness' sake - There are ways to "force" x86 vs. x64 pathway for AVFS. (There are reasons why you might want to do this, e.g. certain filters or decoder might only exist in one or the other, maybe some heavy script requires more memory so x64 preferred, etc...)
You would use the vapoursynth avfs.exe . There are 2 versions, x86, x64. The vpy updated CLI versions can mount both avisynth scripts as well as vapoursynth scripts. The easiest way would be to download the vapoursynth portable versions , then extract avfs.exe using 7zip (make sure you keep them organized ,eg. put them in separate labelled folders)
Since your current x64 VFW decoding pathway is ok (because the vdub x64 test showed ffdshow x64, I'm assuming picture is ok, seeking is ok) , (and assuming you have avisynth x64 concurrently installed as well) , that AVISource script would be routed through the x64 pathway when avfs.exe x64 is called (and x86 when avfs.exe x86 is called) -
There is a VFW system (which AVISource uses), and a DirectShow system (which directshowsource uses) . Both have x86 and x64 versions. You need to use do housekeeping things to keep them in order, with tools like codec tweak tool, vcswap, graphstudio etc.... You have to do things like change merits (priorities) in case there are competing decoders, or manually activate/deactivate some or all.So I tried to do some “housekeeping” as you said (my actual house could really use some of that !), but so far I'm still kinda lost.So it looks like those last two 0.0.9 videos are eliciting a GEO codec response under x86 for whatever reason, and it's not decoding correctly through x86
I would just do some codec housekeeping. I would either disable (if you still need it for other things for some reason), or uninstall that GEO codec. Then repeat the tests. If you still have problems, instead of ffdshow (which has been abandoned years ago), I would use xvid. Disable all mpeg4 components in the ffdshow configuration. If you still can't get it to work, then maybe direct stream copy a small cut sample and upload it
The reason why MPCHC plays video ok directly, is it's a different decoding system and pathway. Directshow, not VFW . If you want to tinker with your directshow system, you can investigate that if you want with graphstudio. The decoder with the highest merit will be connected automatically. You can change merits, disable/enable various codecs right in graphstudio as well
The problem is that right now I still need that GeoVision codec to finish another task : Video Thumbnails Maker with its “Engine 2” module works with the system codecs (contrary to the “Crystal” and “Ultimate” modules which rely on embedded decoders) ; it didn't work until I installed the GeoVision codec, then it worked but had the same color issue as the other modules (Bt.601 instead of Bt.709) with 1920x1080 videos ; then I installed CCCP 32 bits, as advised on the support forum : it worked fine with the 1920x1080 videos, the screenshots have the right colors this time, and that part is about half way finished ; but I also have 704x576 GAVC videos to process, and for some reason VTM fails with those (even with the other rendering modules, and the other thumbnails preview generating tools I tried also have trouble dealing with those files) ; so they may require the specific GAVC decoder. (Strangely, those files show in VLC Media Player as a single frame being displayed for the whole duration of the video, even though MediaInfo reports them as being 25FPS.)
I tried : Codec Tweak Tool, VCSwap, GraphStudio, Win7DSFilterTweaker, InstalledCodec. If I disable LAV splitter for AVI in CCCP settings, it makes VTM crash. If I change “preferred DirectShow decoding filters” for H.264 from “ffdshow” to anything else (including “use merit”), VTM doesn't crash but fails to create thumbnails previews with those files (including the 1920x1080 ones). I tried tinkering some more with CCCP settings, reinstalling the GeoVision codec, to no avail ; at some point I couldn't get VTM + Engine 2 to work anymore, I had to use the reset / repair / re-register buttons (in CCCP settings) to make it work again. But I still can't get it to use the GeoVision codec instead (as I mentioned above, it did work before I installed CCCP 32 bits).
With VCSwap, I can't disable DirectShow filters, only VfW codecs can be tinkered with apparently.
With GraphStudio, I don't know what I'm doing...
In short, I'm looking for a convenient way to switch the decoding pathway used by Video Thumbnails Maker between LAV / ffdshow / DirectShow (I've seen these names for years but I still don't know exactly what they are and how they interact) and the GAVC codec. (Then when that task is finished I will probably remove the latter altogether to reduce clutter.)
EDIT 1 : With the current configuration, if I open one of these 704x576 GAVC files in VirtualDub2 32b with “Audio/video interleave input driver”, it apparently uses the GAVC codec (more precisely : “GEO-H264 V2 (GAVC)”), and the video is displayed with correct motion (as well as embedded timestamps). What I want it to get VTM to use the same pathway, and switch back to the CCCP way to process the other files.
If I open the same file with “Caching input driver” I get “Error reading source frame 0: unexpected end of stream”, and only one frame is displayed.
EDIT 2 : If I open one of these files in GraphStudio 32b, I get this :
If I click on “Insert Filter” and search for the GAVC codec, it appears like this :
The “Change merit” button does nothing. I can insert that GEO-H264 V2 decoder, but then trying to connect it to any of the other modules fails ; apparently it's a compressor, not a decompressor, but I can't find the GEO-H264 decompressor in the list.Last edited by abolibibelot; 27th Nov 2018 at 09:15.
-
I don't use any of those, cccp, gavc, vtm
But wouldn't an easy way be to diable gavc when you don't need it, enable it when you need it ?
Those GEO codecs are blue (ACM/ICM), which means VFW . So in codec tweak tool you should be able to access by pushing the ACM/VFW button for x86 (and for x64 if you have to) , and enable/disable GEO codec
For VTM, you 'd have to ask their developer to enable an option to use different decoders and splitters . It sounds pretty inflexible and prone to crashing, or maybe it's those specific files that elicit the crash -
This is all I see in ACM/VFW 32b :Those GEO codecs are blue (ACM/ICM), which means VFW . So in codec tweak tool you should be able to access by pushing the ACM/VFW button for x86 (and for x64 if you have to) , and enable/disable GEO codec
Right now it is not disabled, since VirtualDub2 uses it, but for some reason VTM insists on using CCCP since it's been installed (before that it worked with the GAVC codec), so I'm trying to do it the other way around, i.e. disable the filters / splitters included in CCCP, which is not working so far.But wouldn't an easy way be to diable gavc when you don't need it, enable it when you need it ?
It's more stable with the newer rendering modules based on embedded codecs, but they produce wrong colors as I mentioned before.For VTM, you 'd have to ask their developer to enable an option to use different decoders and splitters . It sounds pretty inflexible and prone to crashing, or maybe it's those specific files that elicit the crash
Even MPC-HC crashes with those files, with some settings I tried. -
I don't see it on the list, maybe it's so uncommon that it's not supported
Did you find it with vcswap ? right click and deactivate -
Yes it's there in VCSwap. But right now I'm trying to activate it, to get VTM to work with it, as it did before I installed CCCP. When I try to disable LAV Splitter for AVI files, it gets VTM and MPC-HC to crash ; removing “avi” in “LAV Splitter settings” doesn't work either (and it causes the crash of COM Surrogate, which apparently generates previews for video files in Explorer) ; removing “h264” from the “Formats” list in “LAV video settings” doesn't work either. Yet if I open one of these files with VDub2 32b and its internal AVI input driver, it works. So what is required for MPC-HC (and most likely also VTM) to use a VfW codec, which is apparently missing here ?
Well, I tried something more radical – I completely uninstalled CCCP (checked the “remove settings” box), and VTM uses the GAVC codec again... (And it works indeed with those weird 704x576 files.)
But if I re-install CCCP (which I will need), back to square one... So is there a more convenient way of switching between those two, by temporarily disabling the CCCP pathway without breaking anything ?
EDIT : Also, if I open the same file in GraphStudio, the pathway appears slightly different, but there's no mention of the GAVC codec, the “AVI decompressor” is reported as a DirectShow filter, just like before (yet if I play the file within GraphStudio it definitely uses the GAVC codec since it displays the embedded timestamps). So far I don't understand how this should be used to manage codecs, it doesn't seem intuitive anyway.
Last edited by abolibibelot; 27th Nov 2018 at 15:15.
-
I don't know. And I don't use GAVC, VTM, CCCP - so I'm just guessing. I don't know what VTM uses, directshow, vfw, or something else. No idea.
But if you disable other options and only GAVC is left, then VTM has no other option , it's "forced" to use it . Just like when you uninstalled CCCP. So you have to go one by one and figure out which ones it's using in order of preference.
Leave lav splitter, but disable the decoders one by one. Or lav decoder, or ffdshow
I have no idea what GAVC is supposed to be, is it some proprietary AVC variant ? If so, then you probably need to disable AVC variants in lav, ffdshow, plus whatever you have installed. If it's mpeg4-asp, then maybe disable those ones
QuoteSimilar Threads
-
Encoding AVS scripts
By EHarlen in forum Newbie / General discussionsReplies: 2Last Post: 13th Feb 2018, 18:04 -
why AVFS don't load AVS's script that contain 64bit plugin?
By marcorocchini in forum Newbie / General discussionsReplies: 1Last Post: 7th Aug 2017, 07:58 -
who use AVFS.dll/avisynth?
By marcorocchini in forum Newbie / General discussionsReplies: 0Last Post: 9th Mar 2017, 10:44 -
Cannot open AVS file in VirtualDub 1.10.4
By papcom in forum RestorationReplies: 34Last Post: 31st Mar 2015, 10:11 -
Create .avs files for MP4 and MKV to open in VirtualDub
By A2000 in forum Video ConversionReplies: 3Last Post: 24th Jan 2015, 09:59