L-SMASH Source

[speedyrazor]

Hi VFR maniac, you are a star!!!! Many thanks for sorting this out so quickly.
Sorry to appear stupid, but where can I download the LSMASHSource.dll from?

Kind regards.

[LigH]

Let's hope the_weirdo will publish builds soon.

[speedyrazor]

And here it is.....
Many thanks to VFR maniac and the_weirdo.

https://www.dropbox.com/sh/3i81ttxf0...VhYLasmwa?dl=0

And I can report that all is now working as it should with 24 bit audio.
Thanks againVFR maniac.

[speedyrazor]

Originally Posted by VFR maniac

Because the internal indexing occurs per each clip (video and individual audio channels), I guess.
To solve this, we need an implementation like the following method.

clip = LSMASHSource(source="source.mov")
v = LSMASHGetTrack(clip, track=1)
a1 = LSMASHGetTrack(clip, track=2)
a2 = LSMASHGetTrack(clip, track=3)
a3 = LSMASHGetTrack(clip, track=4)
a4 = LSMASHGetTrack(clip, track=5)
a5 = LSMASHGetTrack(clip, track=6)
a6 = LSMASHGetTrack(clip, track=7)
a7 = LSMASHGetTrack(clip, track=8)
a = MergeChannels(a1,a2,a3,a4,a5,a6,a7)
AudioDub(a,v)

I don't know if it can be achieved within AviSynth API restrictions.

Could something like

cache bool = true

be implemented, so it only looks at it once?

Kind regards.

[RTW47]

since there is no cache parameter for LSMASH*Source does this mean that index always is stored inside memory and discarded after the script is closed? (just like LWLibav*Source/FFMS2 with cache=false would?) because there is still some internal indexing involved, if i understood correctly. (more interested in vapoursynth version if there are any differences)

[speedyrazor]

Hi, I am trying to open a Quicktime Prores 444 file with LSMASHVideoSource but just get the below error:

[avisynth @ 029017e0] Avisynth: access violation at 0x0076F2E1 in C:\Program Files (x86)\AviSynth 2.5\plugins\LSMASHSource.dll, attempting to read from 0x00000000
(C:\Temp\SC_Test.avs, line 1)
C:\Temp\SC_Test.avs: Unknown error occurred

I am using this ASV script:

LSMASHVideoSource(source="Prores_444.mov", format="YUV444P10")

I have also tried various other 'format's.
Should LSMASHVideoSource be able to open Prores 444 files?

[VFR maniac]

444? not 4444?
LSMASHVideoSource should be able to open ProRes 422 and 4444 (XQ).

[speedyrazor]

Originally Posted by VFR maniac

444? not 4444?
LSMASHVideoSource should be able to open ProRes 422 and 4444 (XQ).

ffmpeg reports it to be this:

Stream #0:0(eng): Video: prores (ap4h / 0x68347061), yuv444p10le(bt709), 1920x1080, 22649 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 25 tbn, 25 tbc (default)

I have PM'd you a small sample.

Kind regards.

[VFR maniac]

The 4CC 'ap4h' represents Apple ProRes 4444.

I can't reproduce your bug. Here, it's processed normally.
I have a question to you. What ver. of AviSynth do you use?
AviSynth 2.5.8 can't handle some planar pixel formats.

If you don't use such old AviSynth, I guess you encountered miscompilation, but I'm not sure
Usually, MSVC+GCC is unstable, especially, when static linking is used.
Anyway, it is difficult to investigate without debug builds.

[speedyrazor]

Originally Posted by VFR maniac

The 4CC 'ap4h' represents Apple ProRes 4444.

I can't reproduce your bug. Here, it's processed normally.
I have a question to you. What ver. of AviSynth do you use?
AviSynth 2.5.8 can't handle some planar pixel formats.

If you don't use such old AviSynth, I guess you encountered miscompilation, but I'm not sure
Usually, MSVC+GCC is unstable, especially, when static linking is used.
Anyway, it is difficult to investigate without debug builds.

I am very sorry VFR maniac, I tried on a different system, and it worked fine. Sorry for wasting your time. I will do a re-install on the current system.

Kind regards.

[hello_hello]

I guess this is the place to report it......

The version of L-Smash currently on MeGUI's auto-update server (r783) doesn't seem to work at all on XP. Avisynth won't load it.
http://forum.doom9.org/showthread.ph...13#post1710813

I've reverted back to r768 and that works fine, although I have a question regarding the recently added variable to constant frame rate conversion. I haven't tested it with lots of sources, but should it work regardless of file type? So far I've had it working for AVIs and MP4s but it seems to have no effect when the source is MKV. Should it?

Thanks.

[sneaker_ger]

Works fine here with mkv (the_weirdo's 783). Be more specific and supply a sample.

[hello_hello]

Originally I thought it was specific to MKV because the frame rate conversion seemed to have no effect for the couple I tried but it turns out that's not correct. However it is producing odd results with some files so I'll try to split off a few small samples shortly. I can't upload large files as my internet connection is way too slow so I'll need to split some files and try to create small samples.

[Groucho2004]

Originally Posted by sneaker_ger

Works fine here with mkv (the_weirdo's 783).

It works fine because you're not using XP, right?
I already explained what the problem is in the Megui thread. r783 is not compatible with XP.

[sneaker_ger]

I was talking about VFR->CFR with mkv files, not the XP issue.

[hello_hello]

Okay.... here's a few little samples. Each file contains exactly the same video, remuxed into different containers. The duration is just over a minute. I don't know what the deal is with this particular video but if I had to pick who to believe in respect to frame count (for a constant frame rate) and duration, I'd always put my money on AviSource.

AVI
AviSource: 1593 frames, duration 00:01:06:441, 23.976fps.
FFMS2: Same as AviSource with and without frame rate conversion.
LWLibavVideoSource: Same frame count but only 0.3fps and a duration of 01:28:35:637. Adding "fpsnum=24000, fpsden=1001" frame rate conversion increases the total frame count to over 100,000.

TS
DirectShowSource: Same result as for AviSource above (minus one frame when convertfps=true is added).
FFMS2: Shows a little FFMS2 oddness in that the frame count changes by 3 when "fpsnum=24000, fpsden=1001" is used, but it is ffms2 and a TS file.
LWLibavVideoSource: Same result as for AviSource above when "fpsnum=24000, fpsden=1001" is added to the script. Without it the duration decreases by about 11ms.

MKV
DirectShowSource: Seems to behave pretty well for DirectShowSource aside from not liking the last 3 frames.
FFMS2: Behaves fairly well although when "fpsnum=24000, fpsden=1001" is added the frame count drops by three. It appears to be ignoring the first couple of frames.
LWLibavVideoSource: Agrees with AviSource above as to the total number of frames, but not the duration. Output is 24.471fps. There's no convincing it to change the frame rate. You can add "fpsnum=96000, fpsden=1001" to a script if you like, but the output will still be 24.471fps.

Make of that what you will.
I'm testing with L-Smash r768.

35MB zip file containing the video in three different containers. http://ge.tt/1PYYr0B2/v/0

As a side note, I've seen ffms do odd things with AVIs when frame rate conversion is added to the script, even when the specified frame rate is the original fame rate. That problem has been discussed a few times. The video from which I split the samples off for this post is the only one where I've seen ffms2 do the same thing for a different file type (ie MKV) but I'm having trouble splitting off a small sample without the problem going away.

Anyway..... could someone please tell me why ffms2 and L-Smash treat AVIs with null frames as variable frame rate? Given they're plugins for AviSynth I'd think it far more logical not to. That's a big part of the motivation for using fpsnum and fpsden when opening AVI's, to make sure the output is the correct constant frame rate, just like AviSource would do it.....

[Groucho2004]

There's nothing wrong with the video.

First I demuxed the h.264 stream to determine the properties. Frame rate is 23.976, 1594 frames.

Muxed to mkv, no problem with LWLibavVideoSource reading that mkv, frame rate and number of frames are fine.

FFMS2 however needs a "assumefps(24000, 1001)" in order to behave.

[sneaker_ger]

The mkv has a video delay so demuxing will change the results. I don't have time to look into this further at the moment.

[hello_hello]

You're probably right about the total frame count being 1594. MeGUI's preview displays 1593 bit I keep forgetting about the first frame being frame zero.

You might be able to demux and remux the video to get it to behave, but what about the MKV I uploaded? Can you use fpsnum and fpsden to change the frame rate? And what about the AVI, does LWLibavVideoSource lose the plot completely as it does for me?

Anyway, I think I've had enough for today. I've been messing around with this way too long. I'll probably check back tomorrow.

[hello_hello]

Originally Posted by sneaker_ger

The mkv has a video delay so demuxing will change the results. I don't have time to look into this further at the moment.

Ahh..... that might explain why sometimes the frame count changes by three or four, depending on the container and who's decoding, but I have no idea why there should be a delay. I remuxed the original MKV without any audio, then split it into sections until I found one that misbehaved, and it wasn't at the beginning.

See you tomorrow (tomorrow for me, at least).