L-SMASH Source

[Atak_Snajpera]

L-Smash detects this mpeg-2 as 59.94 fps instead of 23.976.

Sample -> https://www.mediafire.com/file/jp0a2hh8wz9uevy/Mpeg2-wrongfps.mkv/file

LoadPlugin("LSMASHSource.dll")
LWLibavVideoSource("Mpeg2-wrongfps.mkv")
info
Trim(0,-1)

And yes again FFVideoSource correctly returns 23.976.

[tebasuna51]

L-Smash detects this mpeg-2 as 59.94 fps instead of 23.976.

Like must be.

eac3to v3.34
command line: "C:\Portable\eac3to\eac3to.exe" "C:\tmp\Mpeg2-wrongfps.mkv"
------------------------------------------------------------------------------
MKV, 1 video track, 0:01:00, 60p /1.001
1: MPEG2, 480p24 /1.001 (16:9) with pulldown flags
[v01] The video bitstream framerate field doesn't match the container framerate. <WARNING>

Also DGSource output fps 59.94 because is the fps forced by the container (mkv header show this fps).
Many times we force the fps to be other than video stream to sync with audio.

If the true fps is 23.976 the mkv must be remuxed with that fps.

[fg118942]

HolyWu ver. 20190910.1
Cannot be read if non-ASCII characters are included in the path of a specific file.

For example, this file.
http://www.minori.ph/download/files/wind_demo.mpg

avs file
A = LWLibavAudioSource("C:\テスト\wind_demo.mpg")
V = LWLibavVideoSource("C:\テスト\wind_demo.mpg")
AudioDub(V, A)

[Atak_Snajpera]

Like must be.



Also DGSource output fps 59.94 because is the fps forced by the container (mkv header show this fps).
Many times we force the fps to be other than video stream to sync with audio.

If the true fps is 23.976 the mkv must be remuxed with that fps.
It should prioritize stream fps like ffms2. All duplicated frames should be automatically discarded.

https://i.imgsafe.org/b7/b7a76eb3fa.png

eac3to v3.34
command line: "C:\Portable\eac3to\eac3to.exe" "C:\tmp\Mpeg2-wrongfps.mkv"
------------------------------------------------------------------------------
MKV, 1 video track, 0:01:00, 60p /1.001
1: MPEG2, 480p24 /1.001 (16:9) with pulldown flags
[v01] The video bitstream framerate field doesn't match the container framerate. <WARNING>

[tebasuna51]

It should prioritize stream fps like ffms2.

It is your opinion, not mine.
The mkv is wrong muxed, point.

I extract the .m2v from the container with

eac3to Mpeg2-wrongfps.mkv Mpeg2-wrongfps.m2v -stripPulldown

And now LWLibavVideoSource("Mpeg2-wrongfps.m2v") work fine.

[Atak_Snajpera]

It is your opinion, not mine.
The mkv is wrong muxed, point.

MkvToolnix does that if you import vob files.

[fg118942]

I tried AVSMeter and VirtualDub2 and both program render the avs without any problem. However AvsPmod failed. Hence it's the program's issue.

It seems that it cannot be read when the character encoding of the avs file is Shift JIS.
In the case of UTF-8, it was able to read.

Is it possible to modify it to work correctly even if the character encoding is Shift JIS?
Otherwise, the AviUtl plug-in will have problems.

[Groucho2004]

It seems that it cannot be read when the character encoding of the avs file is Shift JIS.
In the case of UTF-8, it was able to read.

Is it possible to modify it to work correctly even if the character encoding is Shift JIS?
Otherwise, the AviUtl plug-in will have problems.
It should work if you change your system locale to Japanese.

[Atak_Snajpera]

Seeking directly in VOB is broken as well. (That's why I remux to mkv with MKVToolnix)
https://i.imgsafe.org/b8/b8325a6496.png

Sample -> https://www.mediafire.com/file/ofuict89kudp98d/VTS_05_1_0.VOB/file

[tebasuna51]

MkvToolnix does that if you import vob files.

Seems than MkvToolnix read the

1: MPEG2, 480p24 /1.001 (16:9) with pulldown flags

like 30/1.001 interlaced then put 60p /1.001 like fields per second.

Maybe we need a feature/option request for MkvToolnix to ignore pulldown flags (like eac3to -stripPulldown) to obtain a mkv progressive at 24 /1.001

But for me it is not a problem of L-SMASH.

[stax76]

@HolyWu

There is an access violation happening with foreign ANSII characters like ü.

https://en.wikipedia.org/wiki/Windows-1252

https://mega.nz/#F!bkkByaIa!6I5p9jkfXCT-oMQljTF9Rw

[ChaosKing]

@HolyWu

There is an access violation happening with foreign ANSII characters like ü.

https://en.wikipedia.org/wiki/Windows-1252

https://mega.nz/#F!bkkByaIa!6I5p9jkfXCT-oMQljTF9Rw
Tested on german win10
UTF8 -> ok
Ansi -> access violation

But even the Windows Editor saves in UTF8 now...

[stax76]

Try with cachefile parameter, that's what is likely causing it because old builds without cachefile parameter are fine.

edit:

There is clearly an issue with this file but it's arbitrary, sometimes it loads, sometimes the staxrip preview shows access violation and other times StaxRip and VirtualDub2 silently terminate. :(

[stax76]

Thanks for the fix and the new build. :thanks:

[fg118942]

The issue seems to be solved.
Thank you so much.

[-QfG-]

I have trouble with the last both versions. Except Violation Error, if i will indexing my DNxHR HQX Content in a Quicktime Container.

[Atak_Snajpera]

https://github.com/HolyWu/L-SMASH-Works/releases/download/20190914/L-SMASH-Works_20190914.7z


VideoSource: Fix fallback to software decoder in prefer_hw.
LWLibav: Fix access violation in file name manipulation.





I'm not able to fix it. Need investigation by the origianl developer. A workaround is to extract the video track as .m2v file and it will work fine. Or alternatively use MPEG2Source which should be reliable for MPEG2 streams.




Please try and see whether the latest build fix your issue.

Ok. Would IT be difficult to add that auto option regarding hardware decoding? I'm asking because in distributed encoding mode some machines may have NVIDIA GPU and some Intel GPU.

[Atak_Snajpera]

https://github.com/HolyWu/L-SMASH-Works/releases/download/20190917/L-SMASH-Works_20190917.7z


VideoSource: Add prefer_hw=3.


It is almost perfect... ;) However... Lsmash does not check if hardware decoder supports specific codec. I have a Kepler GPU which does not support HEVC decoding and in this case prefer_hw=1/3 returns an error message.

[redbtn]

First of all, thank you HolyWu for updates!
Can I ask what matter to use hardware decoder? I have Nvidia RTX 2060, but I did test and didn't notice difference in encoding speed.
What decoder is preferred in my case? Thank you!

[poisondeathray]

First of all, thank you HolyWu for updates!
Can I ask what matter to use hardware decoder? I have Nvidia RTX 2060, but I did test and didn't notice difference in encoding speed.
What decoder is preferred in my case? Thank you!

It depends on your scenario

e.g if the bottleneck is your encoder/ encoding settings, or some filters, maybe offloading the decoding to GPU might not make much of a difference

eg. If decoding only uses 0.5% of your CPU (maybe SD footage), it might not make much of a difference either

Other scenarios might be different. e.g. Decoding UHD/4K footage might take significant CPU resources. Offloading that decoding task to GPU should free up CPU cycles to encode faster (if using a "CPU encoder" )

[redbtn]

It depends on your scenario

e.g if the bottleneck is your encoder/ encoding settings, or some filters, maybe offloading the decoding to GPU might not make much of a difference

eg. If decoding only uses 0.5% of your CPU (maybe SD footage), it might not make much of a difference either

Other scenarios might be different. e.g. Decoding UHD/4K footage might take significant CPU resources. Offloading that decoding task to GPU should free up CPU cycles to encode faster (if using a "CPU encoder" )Thank you for explaining. I encode 4k HDR > 1080p HDR using x265 and VapourSynth. So, I will try again, maybe I will see the difference. Is it right, that both software and hardware decoders work the same and no difference in quality or stability? Can I safely choose hardware decoder for all my encodes and don't worry about something goes wrong?

[poisondeathray]

Thank you for explaining. I encode 4k HDR > 1080p HDR using x265 and VapourSynth. So, I will try again, maybe I will see the difference. Is it right, that both software and hardware decoders work the same and no difference in quality or stability? Can I safely choose hardware decoder for all my encodes and don't worry about something goes wrong?

Money back guarantee :)

There were differences in earlier versions with CUVID, but this version looks to have fixed it

I don't think there has been enough testing to ensure everything works 100%

If something goes wrong, report it . That's the only way stuff gets fixed

[stax76]

Can I ask what matter to use hardware decoder? I have Nvidia RTX 2060, but I did test and didn't notice difference in encoding speed.
What decoder is preferred in my case? Thank you!

How many CPU cores? I don't think you gain something substantial if you have more than 4 cores, that's what my encoding test showed, sw 60 fps, hw 61 fps.

StaxRip hasn't the most efficient drawing implementation, dealing with 4K in the crop and preview dialog users get a noticeable improvement with a HW decoder.

[redbtn]

How many CPU cores? I don't think you gain something substantial if you have more than 4 cores, that's what my encoding test showed.

StaxRip hasn't the most efficient drawing implementation, dealing with 4K in the crop and preview dialog users get a noticeable improvement with a HW decoder.I have I5-9400f 6 core processor. On preset Slower x265 with some minor changes i get 2.4-2.6 fps.
So, if I can't see any difference after tests, the best way choose software decoder, right?

[Atak_Snajpera]

I have I5-9400f 6 core processor. On preset Slower x265 with some minor changes i get 2.4-2.6 fps.
So, if I can't see any difference after tests, the best way choose software decoder, right?

No wonder you see no differences with hardware decoding if encoder is only requesting on average 1 frame every 400ms.

[MeteorRain]

Hardware decoder can easily reach 200fps on 1080p source.

[Atak_Snajpera]

Hardware decoder can easily reach 200fps on 1080p source.

Decoding speed with blu-ray avc source is around 130fps on Kepler.
For comparison:
Q8200@2.8GHz reaches 100fps (~85% cpu usage)
Xeon E5-2690@3.2GHz reaches 440fps (~75% cpu usage)

[MeteorRain]

Thanks for correcting. Although those fps are "free" fps that does not fight with encoding speed at all. When transcoding HEVC 4k, having hardware decoder can free up large portion of CPU resources and leave them for encoding. I'd still use hardware decoder whenever possible to me.

[Atak_Snajpera]

Thanks for correcting. Although those fps are "free" fps that does not fight with encoding speed at all. When transcoding HEVC 4k, having hardware decoder can free up large portion of CPU resources and leave them for encoding. I'd still use hardware decoder whenever possible to me.

In theory yes but in practice no. Encoder will still be responsible for about 98% of CPU time. You will only see difference If you encode hevc 4k 100Mbps to low resolution with x264 and preset superfast.

[DJATOM]

If you're using heavy filters (like eedi3 or mdegrain), you'll definitely see an improvement in speed with HW decoder.

[Atak_Snajpera]

If you're using heavy filters (like eedi3 or mdegrain), you'll definitely see an improvement in speed with HW decoder.

Nope because those filters work on CPU creating additional bottleneck.

[DJATOM]

Nope because those filters work on CPU creating additional bottleneck.

Yeah, and offloading decoder to GPU saves CPU cycles for encoder and filters.

[sneaker_ger]

Atak_Snajpera is right. The more of my CPU time "cake" is spent on filtering and encoding the less impact HW decoding will make on speed. It doesn't mean HW decoding won't make encoding faster it's just that the percentage goes down. (Exception is if my CPU isn't utilized 100%.)

Imagine you use AV1 encoder with placebo settings and very slow filtering (QTGMC+waifu2x) and software decoding of source. Then 99% of CPU time is spent on encoding+filtering, 1% on SW decoding. If you replace SW decoding with HW decoding you only free up that 1%. If you use no filtering and very fast encoder settings (x264 preset ultrafast) maybe you have 70% encoding and 30% SW decoding. Then replacing SW by HW decoding can increase speed much more.

[Atak_Snajpera]

Yeah, and offloading decoder to GPU saves CPU cycles for encoder and filters.

You do not realize how encoding chain works. Encoder determines how fast IT needs frames from decoder. Any filtering in avisynth will only slow down frame requests.

[ChaosKing]

# Latest lsmash Nvidia gpu
Output 3001 frames in 34.80 seconds (86.24 fps) # SMDegrain(clip, tr=1)
Output 3001 frames in 88.24 seconds (34.01 fps) # SMDegrain(clip, tr=3)
# CPU
Output 3001 frames in 40.83 seconds (73.51 fps) # SMDegrain(clip, tr=1)
Output 3001 frames in 95.05 seconds (31.57 fps) # SMDegrain(clip, tr=3)
Tested on ryzen 2600, GTX 1070 in vapoursynth
source is 1080p AVC

[DJATOM]

You do not realize how encoding chain works. Encoder determines how fast IT needs frames from decoder. Any filtering in avisynth will only slow down frame requests.

I'm talking about CPU usage, not how frame requests works. Obviously software decoder will leave less room for other stuff and that was my point. You still can repeat your mantra about frame requests, but you can't say "software decoder is free for CPU", right?

[Atak_Snajpera]

I'm talking about CPU usage, not how frame requests works. Obviously software decoder will leave less room for other stuff and that was my point. You still can repeat your mantra about frame requests, but you can't say "software decoder is free for CPU", right?

Check this out!

CPU: Intel Q8200@2.8GHz
GPU: NVidia GT 710 (Kepler)
SSD: Yes

Source Blu-ray John Carter (first 10 minutes)
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=3, N=18
Muxing mode : Container profile=@0.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 10 min 0 s
Bit rate mode : Variable
Bit rate : 26.9 Mb/s
Maximum bit rate : 40.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.541
Stream size : 1.88 GiB (98%)
Default : No
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


ScriptSW.avs
LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("C:\Temp\Video.mkv",cachefile="C:\Temp\Video.mkv.lwi",prefer_hw=0)
return video

ScriptHW.avs
LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("C:\Temp\Video.mkv",cachefile="C:\Temp\Video.mkv.lwi",prefer_hw=1)
return video

Decoding speed test in AVSMeter
Software Decoding
Log file created with: AVSMeter 2.9.6 (x64)
Script file: C:\Temp\scriptSW.avs

[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1.0 (Build 7601)

CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.80GHz / Yorkfield (Core 2 Quad) 2M
MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1
4 physical cores / 4 logical cores

Video card: NVIDIA GeForce GT 710
GPU version: GK208
Video memory size: 1024 MiB
OpenCL version: OpenCL 1.2 CUDA
Graphics driver version: 26.21.14.3615 (NVIDIA 436.15) / Win7 64


[Avisynth info]
VersionString: AviSynth+ 0.1 (r2772, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2018-12-20, 12:55:18 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+


[Clip info]
Number of frames: 14405
Length (hh:mm:ss.ms): 00:10:00.809
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: i420
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 14405 (0 - 14404)
FPS (min | max | average): 76.92 | 256.0 | 124.1
Process memory usage (max): 85 MiB
Thread count: 10
CPU usage (average): 92.8%

GPU usage (average): 1%
VPU usage (average): 0%
GPU memory usage: 130 MiB

Time (elapsed): 00:01:56.122


[Script]
LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("C:\Temp\Video.mkv",cachefile="C:\Temp\Video.mkv.lwi",prefer_hw=0)
return video


Hardware Decoding
Log file created with: AVSMeter 2.9.6 (x64)
Script file: C:\Temp\scriptHW.avs

[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1.0 (Build 7601)

CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.80GHz / Yorkfield (Core 2 Quad) 2M
MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1
4 physical cores / 4 logical cores

Video card: NVIDIA GeForce GT 710
GPU version: GK208
Video memory size: 1024 MiB
OpenCL version: OpenCL 1.2 CUDA
Graphics driver version: 26.21.14.3615 (NVIDIA 436.15) / Win7 64


[Avisynth info]
VersionString: AviSynth+ 0.1 (r2772, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2018-12-20, 12:55:18 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+


[Clip info]
Number of frames: 14405
Length (hh:mm:ss.ms): 00:10:00.809
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: i420
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 14405 (0 - 14404)
FPS (min | max | average): 38.94 | 148.9 | 122.6
Process memory usage (max): 91 MiB
Thread count: 8
CPU usage (average): 13.2%

GPU usage (average): 22%
VPU usage (average): 99%
GPU memory usage: 230 MiB

Time (elapsed): 00:01:57.449


[Script]
LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("C:\Temp\Video.mkv",cachefile="C:\Temp\Video.mkv.lwi",prefer_hw=1)
return video

Results when encoding in x264 (logs -> https://www.mediafire.com/file/9cs3pj8d2funidx/Logs.7z/file )
https://i.imgsafe.org/28/286ce8b657.png

The slower encoder the less you get from hardware decoding! It would be even worse if I added any filtering in AviSynth like MDegrain. Not to mention about a lot slower x265. Deal with it! Most of the time you get placebo effect

[MeteorRain]

Time saved is time saved. Whatever slower preset you choose, the amount of CPU resource HW decoder saves you is basically the same.

The CPU resources saved always equals to the total cost of SW decoder demands, minus the effort to copy pictures from graphics card buffer, right?

Saving 5 minutes off 10 minutes ultrafast encoding is great, but saving 5 minutes off 50 minutes medium encoding is not bad either.
It's like upgrading your CPU from 3600 to 3600X for free. It's a free 5 minutes, I'll take it.

[DJATOM]

Fortunately I'm using Vapoursynth nowadays. Looks like it's both fine with HW and SW decoding (no penalty over HW decoding with heavy filtering).

[Atak_Snajpera]

Time saved is time saved. Whatever slower preset you choose, the amount of CPU resource HW decoder saves you is basically the same.

The CPU resources saved always equals to the total cost of SW decoder demands, minus the effort to copy pictures from graphics card buffer, right?

Saving 5 minutes off 10 minutes ultrafast encoding is great, but saving 5 minutes off 50 minutes medium encoding is not bad either.
It's like upgrading your CPU from 3600 to 3600X for free. It's a free 5 minutes, I'll take it.

Keep in mind that this was the BEST case scenario. Add some MDegrain or/and some HDR->SDR tonemapping plus x265 and you will be lucky if you even see 1 minute saved! It's simple! The more you throw tasks on CPU the less speed gap between software and hardware decoding you get.

[MeteorRain]

What's wrong with 1 minute saved?

[videoh]

Keep in mind that this was the BEST case scenario. Add some MDegrain or/and some HDR->SDR tonemapping plus x265 and you will be lucky if you even see 1 minute saved! It's simple! The more you throw tasks on CPU the less speed gap between software and hardware decoding you get. The absolute time saved depends only on the stream length, not the amount of SW stuff you do. Yes, the percent savings gets reduced by more SW work, but not the absolute amount as you suggest: "you will be lucky if you even see 1 minute saved".

[videoh]

What's wrong with 1 minute saved? Atak would refuse a free ten-dollar bill because it is too small. ;)

[Atak_Snajpera]

Atak would refuse a free ten-dollar bill because it is too small. ;)

Neuron2 triggered when somebody attacks hardware decoding... I wonder why... ;)

[videoh]

BTW, many filters have been GPU accelerated and there is nothing to stop others from being ported to GPU. It's not just about the decoder.

[Atak_Snajpera]

Bonus x265
https://i.imgsafe.org/28/286ce86c97.png

[videoh]

Ah, data. Sweet.

If you make available that 10-minute source clip I'd like to try this with a high-end nVidia GPU (2080 Ti) and DGSource() under both Avisynth+ and Vapoursynth (native). Can you please do that for us? Thank you. If you need access to my FTP just send me a PM.

DJATOM says he can't duplicate your effect so it would be nice to get some other data points.

[MeteorRain]

Actually I would like to see some performance testing on downscaling 4K UHD BD to 1080P and encoded by x265 medium. I assume this is a very legit scenario.

[videoh]

Sure, let's do both. But we should all use the same stream.

[redbtn]

Actually I would like to see some performance testing on downscaling 4K UHD BD to 1080P and encoded by x265 medium. I assume this is a very legit scenario.Which downscaler should I use? I can make tests. I prefer spline64 for 4k to 1080p, but maybe there are something better?