Okay, this is driving me MORE insane... FPS parameter x264 CMD + AVS...

[Lathe]

I swear, I THOUGHT I followed what I needed to add in the AVS script in order to specify the FPS. But, when I try to process the x264 CMD line to convert an HEVC file to X264, I keep getting the error that the FPS needs to be specified!

I've added: AssumeFPS(24000,1001) to the AVS script (that's actually all I'm doing with it) but, I keep getting this error in the CMD line:

C:\WINDOWS\system32>F:\EXECUTABLES\BD-RBV06128\BD_Rebuilder\Tools\x264L.exe "E:\x\test.avs" --level 4.1 --ref 4 --deblock -1:-1 --psy-rd 1.00:0.25 --preset medium --crf 14 --output "D:\Encode.264"

avs [error]: DirectShowSource: I can't determine the frame rate
of the video, you must use the "fps" parameter.

(E:\x\test.avs, line 1)
x264 [error]: could not open input file `E:\x\test.avs'

I'm just using the BDRB X264.exe, that's why I'm going there. EVERYTHING is exactly the same as what I always use for the CMD line X264/AVS processing, but this time this keeps happening. Now, I KNOW the DirectShow is not the very best way to do this, but that is all I know and it always works, so I don't want to try anything else as far as loading the MKV file for now please.

I was SURE that is what I had to do, but no go... What am I missing here. Thanks!

[poisondeathray]

avs [error]: DirectShowSource: I can't determine the frame rate
of the video, you must use the "fps" parameter.


It tells you the error - specify the fps parameter of DirectShowSource


DirectShowSource("video.mkv", fps=23.976)
AssumeFPS(24000,1001)


(Or better yet, use a more reliable source filter)

[Lathe]

It tells you the error - specify the fps parameter of DirectShowSource


DirectShowSource("video.mkv", fps=23.976)
AssumeFPS(24000,1001)


(Or better yet, use a more reliable source filter)

Heh, oh yeah I remember now :) Thanks Bro! Yeah, I know everyone always says to use a different source filter, but this (so far) is the only one I know for now. But yeah, I forgot where you needed to add it.

Appreciate it!

[Lathe]

It tells you the error - specify the fps parameter of DirectShowSource


DirectShowSource("video.mkv", fps=23.976)
AssumeFPS(24000,1001)


(Or better yet, use a more reliable source filter)

OOPS! Now I'm getting a weird error showing a completely different AR than the actual file (or at least how MediaInfo shows it)

Here is the MediaInfo of the file:

HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 29 min
Bit rate : 9 000 kb/s
Width : 1 920 pixels
Height : 1 040 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0

Okay, here is the error I'm getting on the CMD line:

C:\WINDOWS\system32>F:\EXECUTABLES\BD-RBV06128\BD_Rebuilder\Tools\x264L.exe "E:\x\test.avs" --level 4.1 --ref 4 --deblock -1:-1 --psy-rd 1.00:0.25 --preset medium --crf 16 --output "D:\Encode.264"

avs [info]: 527x800p 0:0 @ 24000/1001 fps (cfr)

resize [error]: resolution 527x800 is not compliant with colorspace i420

WTH...?!

[poisondeathray]

It's DirectShow - try fixing your directshow configuration . Maybe try installing LAV filters

***Better idea is a reliable source filter

[Lathe]

It's DirectShow - try fixing your directshow configuration . Maybe try installing LAV filters

***Better idea is a reliable source filter

Apparently so... :) Thanks!

[Atak_Snajpera]

In year 2024 people are still fighting with DirectShowSource() madness? What's next? People still encoding with XviD?

[Lathe]

In year 2024 people are still fighting with DirectShowSource() madness? What's next? People still encoding with XviD?

Hey, hey, hey...! I'm still a Newbie with this stuff :) I don't use it very often, and didn't know what to do. Okay... I'll look into what other whatever it is I'm supposed to use.

Do you think you would mind, please, kindly letting me know what it is I should look into instead of Directshow? Thanks!

[qyot27]

FFmpegSource2 (https://github.com/FFMS/ffms2/releases) (or the C-plugin version of FFMS2 (https://forum.doom9.org/showthread.php?t=175173))
LSMASHSource (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases)
BestSource (https://github.com/vapoursynth/bestsource/releases)

[Lathe]

FFmpegSource2 (https://github.com/FFMS/ffms2/releases) (or the C-plugin version of FFMS2 (https://forum.doom9.org/showthread.php?t=175173))
LSMASHSource (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases)
BestSource (https://github.com/vapoursynth/bestsource/releases)

Thank you, I'll check them out!

[FranceBB]

I wonder if there are still some valid use cases for DirectShowSource() when it comes to decoding other codecs in 2024.
This is beyond what the original poster, Lathe, was trying to do (decoding an H.265 HEVC file).
Of course, ffms2 and LWLibav are always gonna be better when it comes to codecs they support as they're gonna be frame accurate and support a whole variety of bit depths and colorspaces, however the real "strength" of DirectShowSource() comes from the codecs they cannot decode.
I'm talking about proprietary codecs for which there's no open source decoder available.
Those used to be far more common in the past, so I'm actually wondering whether there are still some of them out there.
Generally speaking, when you had to work with a proprietary codec, they used to give you an msi installer that would install it as a system codec so that other programs could use the proprietary decoder (like the various NLE, players etc).
In that case of course the only way to decode such a file in Avisynth was to use DirectShowSource() that would then call Microsoft Direct Show which would serve the frames decoded by whatever decoder was installed on the system.
Of course, by default, Windows can decode almost nothing and most people install the LAV Filters which are free and open source, but in that case it doesn't make much sense to use DirectShowSource() as not only it would produce non frame accurate results, but it's also limited to 8bit which is a no-go for most video sources nowadays given that H.265 made the use of high bit depth much more common than it ever was with H.264.
In that case, using ffms2 or lwlibav as pointed out by others is better, but... if you have a closed source proprietary codec with a proprietary decoder installed on the system then DirectShowSource() is the only way to go and that's probably why it's still there. :)
On that note, if we go down the history lane, I still remember that several years ago (long before my days at Sky and even before Viewster, during my early Crunchyroll days in what feels like a lifetime ago) some studios used to send us files in Canopus HQ.
We had the official decoder installed and there was no open source decoder available so the only way to decode those was to use DirectShowSource() after installing the decoder.
Nowadays this is no longer the case as Canopus HQ, HQA, HQX and its lossless version are all decodable via ffmpeg which means that both LWLibavVideoSource() and FFVideoSource() can index those files just fine.
Still, it used to be a big deal back then.
When Blackmagic released their new Blackmagic RAW format, I really hoped they would release a similar DirectShow compatible decoder, but they didn't.
Neither did Sony with their Sony RAW codec or RED with their .r3d files or indeed Arri with their Arri RAW codec.
Most companies nowadays release a plugin for the most common NLE (generally AVID, Premiere and if you're lucky Davinci) and to convert those files without having to go through a NLE you have to install whatever proprietary software they release like Sony Catalyst and ARC (ARRI RAW Converter). In the case of Blackmagic you can use their proprietary player, but still...
The point I'm trying to make is: there seems to be no company releasing a DirectShow compatible decoder nowadays and really the only thing that still seems to be kept updated is LAV which is based on libav, the same we would get with LWLibav or FFVideo or BestSource.
So... I'm really wondering what the future of DirectShowSource() is gonna be and whether it's gonna end up like AVISource(), I mean still there for compatibility reasons but mostly unused...

[wonkey_monkey]

What's next? People still encoding with XviD?

https://forum.doom9.org/showthread.php?p=2002581#post2002581

:rolleyes:

[Lathe]

I wonder if there are still some valid use cases for DirectShowSource() when it comes to decoding other codecs in 2024.
This is beyond what the original poster, Lathe, was trying to do (decoding an H.265 HEVC file).

Wow, that is quite a history of these codecs, thanks for the interesting information! I'm always trying to learn. I DO have LAV filters installed because I use BDRB and it requires them. But, I have NO bloody idea how to use them in reading a file to use in an x264 CMD line :)

I guess I'd better do some reading! I ended up just plugging it into Handbrake and doing a generic x264 encode with whatever parameters I could set. I THINK I used a CRF setting that I suppose was a bit too high. It converted an HEVC 6 Gig file into a 15 Gig x264 file :D I was a tad surprised because I've used a CRF of 16 before and never noticed that much of an increase of size. The movie DOES look good, but I'm GUESSING perhaps it is because I am going from HEVC to x264, maybe in 'unpacking' the HEVC file it somehow 'expands' it size wise more so to convert it to x264. So, maybe in the future if I am converting an HEVC file, I should use a higher number CRF. I guess I'll hafta experiment a bit...

[Lathe]

https://forum.doom9.org/showthread.php?p=2002581#post2002581

:rolleyes:

Well, at least I am a BIT further along than that one... :D

[FranceBB]

Wow, that is quite a history of these codecs, thanks for the interesting information!

No worries. :)



I'm GUESSING perhaps it is because I am going from HEVC to x264, maybe in 'unpacking' the HEVC file it somehow 'expands' it size wise more so to convert it to x264. So, maybe in the future if I am converting an HEVC file, I should use a higher number CRF. I guess I'll hafta experiment a bit...

Well, it's not much of an H.265 advantage over H.264 but rather the fact that you set a very low crf.
In general, x265 yields 35% better compression efficiency compared to x264 at UHD resolutions, however this is only a theoretical difference and in your case it's much smaller as you're encoding a FULL HD content.

Click here to download L-SMASH-Works-r1194.0.0.0.7z (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases/download/1194.0.0.0/L-SMASH-Works-r1194.0.0.0.7z)

Unzip it and inside you'll find an x86 and an x64 folder.
Take LSMASHSource.dll inside the x64 folder and put it in your plugins+ folder (it's generally in C:\Program Files (x86)\AviSynth+\plugins64+).

Then open your AVS Script.avs in AVSPmod mod (you can get it from here: AvsPmod_v2.7.7.3_.Windows_x86-64.zip (https://github.com/gispos/AvsPmod/releases/download/2.7.7.3/AvsPmod_v2.7.7.3_.Windows_x86-64.zip) ).

Extract AVSPmod mod in whatever location you want (like on the desktop etc) but NOT in C:\Program Files\

AVSPmod mod can help you write the script and it will tell you if you make any mistakes.

In this case you can start with the following script:


video=LWLibavVideoSource("your_video.mxf")
audio=LWLibavAudioSource("your_audio.mxf", stream_index=1)

AudioDub(video, audio)


Then hit the "compute" button (the arrow at the bottom left).


https://i.imgur.com/GGVps8A.png

Now, from the moment you hit that it will take a while before you're gonna be able to see the preview.
That's expected 'cause LWLibav is "indexing" a file.
Basically an indexer will create an index file (in the case of LWLibav it will create an .lwi file in the same directory as your source file). Inside that index file it's gonna store a bunch of info about the video and the audio so that it will be able to decode it afterwards. Indexing can take a very long time, especially if you're dealing with very big files over an SMB Share. I still remember having to index the 4K Apple ProRes 12bit Remaster of Batman in an SMB Share over a 1 Gbit/s connection. It took 7 hours. I see that your file is in E: which is hopefully a locally attached Sata III disk so it will be much faster (and hopefully the file is much smaller than several hundred GBs). Anyway, once the lwi file is created and it stops growing, you're gonna be able to move across the file and also listen to the audio and that's gonna be frame accurate. What does it mean? Well, it means that, no matter how many times you close and open it, or you move across the file or you apply a filter and compute, if you go to let's say frame 1000, you're always positively absolutely gonna see the very same frame. With DirectShowSource() this is not guaranteed as it will call Microsoft DirectShow which will then use the LAV Filters to decode it in real time, so if you go to frame 1000 you're gonna see one frame, but if you move back and forth and go back to frame 1000 you *might* see a different frame (perhaps the one before or the one after). Now the advantage of DirectShowSource() is that the decoding starts right away as it's done on the fly, you don't have to wait the indexing time, but of course the downside is that your output isn't gonna be frame accurate. On the other hand, with LWLibavVideoSource() and LWLibavAudioSource() you need to wait for the indexer to create the index file but then your result will be frame accurate.

Now, some containers already have an "index" inside themselves. This is true for ISO containers like mp4 and mov, which means that you could use LSMASHVideoSource() and LSMASHAudioSource() to avoid having to wait the indexing time as long as your sources are in those containers. The problem with this - and the reason why it's not recommended - is that unless you absolutely trust the source, then there's no guarantee that the index inside the container is correct. What I'm saying with this is that while LWLibav recreates the index file by decoding the raw streams inside the container, LSMASH doesn't and just blindly trusts the info of the container, which means that if those are wrong, then the decoded output will also be wrong.

Anyway, after that, if your source is 10bit (just an assumption given that it's H.265 but you can easily check it at the bottom right in AVSPmod mod) and you're encoding at 8bit you might add the following:

ConvertBits(bits=8, dither=1)

This will perform the Floyd Steinberg Error Diffusion to bring everything to 8bit planar.


As for the x264 encoding options, --crf 16 is very very low (i.e very very high quality) so it's normal that you got a bigger file. You might wanna increase it a bit. I generally use --crf 18 for high quality sources like UHD BD which have 50 Mbit/s and --crf 22 when I have to re-encode transport streams or web soruces that generally don't exceed 25 Mbit/s. You could technically go even further, but I consider anything beyond --crf 22 to be losing too much quality and anything to beyond --crf 25 to be not worth it with 25 being my absolute hard limit for x264.

[DTL]

DirectShowSource may be also about realtime sources like network streams or capture cards or USB cameras and others. DirectShow not only about static files processing.

There is also ffdshow filter for DirectShow with inserting AVS processing into DirectShow graph. So reatime processing with AVS and feed to industrial interfrace like SDI output is possible.

[Lathe]

No worries. :)




Well, it's not much of an H.265 advantage over H.264 but rather the fact that you set a very low crf.
In general, x265 yields 35% better compression efficiency compared to x264 at UHD resolutions, however this is only a theoretical difference and in your case it's much smaller as you're encoding a FULL HD content.

WOW! Now THAT is what I'd call F'n helpful! :D Thank you so much. I will absolutely study and go over this.

REALLY appreciate all the time and trouble you put into this!

Cheers!

Jaime.

[Lathe]

DirectShowSource may be also about realtime sources like network streams or capture cards or USB cameras and others. DirectShow not only about static files processing.

There is also ffdshow filter for DirectShow with inserting AVS processing into DirectShow graph. So reatime processing with AVS and feed to industrial interfrace like SDI output is possible.

Good to know, thank you!

[DTL]

"In general, x265 yields 35% better compression efficiency compared to x264 at UHD resolutions,"

It may not be very fair to compare codecs between different resolutions. Especially with UHD. Because typical users see very small quality/resolution benefits with the step from HD to UHD. But sample count is 400% to 1600% increase with UHD-1 and UHD-2. And RAW bitrate too.

So it may be easy enough to hide very small 35% 'better compression' with simply some more lossy compression and to show math correct bitrate reduction. Best codecs compression comparison is with SD resolution where even small degradation is much better visible. Also at the long era of SD the best processing math was designed like up to 1/4 sample precision processing. In the era of HD and UHD the quality of content and processing became much worse but sample count increase still hides sample-level quality degradation.

So MPEG-LA still can do its business until the end of current (white) civilization simply adding +XX% of compression to more and more UHD with less and less visible quality change each 10..20 years. Each generation of MPEG codec is simply some working balance with current industry available computing performance at production and consumer side. If the industry still progresses with computing performance for real time hardware - the MPEG-LA can make a more resource-consuming MPEG encoder and sell it one more time. While the main residuals of white civilization stuck with Xvid and SD resolution for general moving pictures content exchange at 'free Internet' as enough quality/performance balance.

[Lathe]

"In general, x265 yields 35% better compression efficiency compared to x264 at UHD resolutions,"

It may not be very fair to compare codecs between different resolutions. Especially with UHD. Because typical users see very small quality/resolution benefits with the step from HD to UHD. But sample count is 400% to 1600% increase with UHD-1 and UHD-2. And RAW bitrate too.

So it may be easy enough to hide very small 35% 'better compression' with simply some more lossy compression and to show math correct bitrate reduction. Best codecs compression comparison is with SD resolution where even small degradation is much better visible. Also at the long era of SD the best processing math was designed like up to 1/4 sample precision processing. In the era of HD and UHD the quality of content and processing became much worse but sample count increase still hides sample-level quality degradation.

So MPEG-LA still can do its business until the end of current (white) civilization simply adding +XX% of compression to more and more UHD with less and less visible quality change each 10..20 years. Each generation of MPEG codec is simply some working balance with current industry available computing performance at production and consumer side. If the industry still progresses with computing performance for real time hardware - the MPEG-LA can make a more resource-consuming MPEG encoder and sell it one more time. While the main residuals of white civilization stuck with Xvid and SD resolution for general moving pictures content exchange at 'free Internet' as enough quality/performance balance.

Quite interesting, thank you!