L-SMASH Source

[kedautinh12]

Originally Posted by HolyWu

https://github.com/HolyWu/L-SMASH-Wo...ks_20191127.7z

• Fix MPEG-2 decoding issue with RFF flags. (maki-rxrz)
• Fix interlaced H.264 decoding issue in some files.

when i decoding LWLibavVideoSource("***.ts",repeat=true) with repeat=true can Fix MPEG-2 decoding issue with RFF flags (maki-rxrz) and Fix interlaced H.264 decoding issue in some files. Very nice

[LigH]

I found an MP4 video provided by the Mediathek of the German broadcaster ZDF. MediaInfo reports a framerate of 50 fps (720p50), AviSynth's Info() reports the same when using FFVideoSource or LwLibavVideoSource. But LSMASHVideoSource reports 0.0246 fps (1798/73073).

I wonder how to send you a sample. If I use any tool to cut out a small scene, it would create completely new headers, possibly fixing this issue. So I fear I would have to upload ~680 MB. And if you tried to download it using MediathekView, it might be geoblocked if you are outside Germany. (direct URL, may or may not work in a web browser)

[HolyWu]

Originally Posted by LigH

I found an MP4 video provided by the Mediathek of the German broadcaster ZDF. MediaInfo reports a framerate of 50 fps (720p50), AviSynth's Info() reports the same when using FFVideoSource or LwLibavVideoSource. But LSMASHVideoSource reports 0.0246 fps (1798/73073).

Well, I don't recommmend using LSMASHVideoSource as it's not frame accurate when random seeking even though it has the advantage of not requiring an index file. I once even considered dropping this filter from my fork.

[ChaosKing]

Originally Posted by HolyWu

Well, I don't recommmend using LSMASHVideoSource as it's not frame accurate when random seeking even though it has the advantage of not requiring an index file. I once even considered dropping this filter from my fork.

Hmm I only encountered inaccurate frame seeking once with LSMASHVideoSource. I use it sometimes with big (40gb+) lossless avc+mp4 files, so it would be nice to keep it in this fork :-)

[dREV]

I wanted to try updating 32 bit MeGUI 2525's lsmash that's on the wiki page in the hopes it'll stop the "Access Violation" thing it receives after indexing several m2ts files in a row and the program accumulates high memory MB's causing it to give errors only correcting when restarting the program plus I also noticed that as I frequently use film.trim sometimes the frame will be off by 1 frame but it'll still fit the frame cut amount which is really strange but doesn't happen often thankfully.

However, I'm receiving errors after it finishes idx then goes to oneclick and stops or continues to the next job. Thought of restarting MeGUI would fix that as it does when receiving the "Access Violation" but nope.

Used L-SMASH-Works_20191127 and used all previous versions with nothing.

The error says this:

--[Error] [12/4/2019 5:28:47 AM] An error occurred
---[Error] [12/4/2019 5:28:47 AM] Exception message: [Fatal]: Failed to avformat_open_input.
---[Error] [12/4/2019 5:28:47 AM] Stacktrace
----[NoImage]    at MeGUI.AviSynthClip..ctor(String func, String arg, AviSynthColorspace forceColorspace)
----[NoImage]    at MeGUI.AvsFile..ctor(String script, Boolean parse)
----[NoImage]    at MeGUI.lsmashFile..ctor(String fileName, String indexFile)
----[NoImage]    at MeGUI.OneClickPostProcessing.createAVSFile(String indexFile, String inputFile, Nullable`1 AR, Int32 desiredOutputWidth, 
Boolean signalAR, LogItem _log, AviSynthSettings avsSettings, 
Boolean autoDeint, VideoCodecSettings settings, Nullable`1& dar, Boolean autoCrop, Boolean keepInputResolution, Boolean useChaptersMarks)
----[NoImage]    at MeGUI.OneClickPostProcessing.StartPostProcessing()

Won't let me encode either

--[Error] [12/4/2019 6:04:14 AM] Error starting job
---[Error] [12/4/2019 6:04:14 AM] Exception message
----[NoImage] Calling setup of processor failed with error 'The file Z:\projectbackup\megui\work\02lfrdg1.uif\00002.m2ts.avs cannot be opened.
----[NoImage] Error message for your reference: [Fatal]: Failed to avformat_open_input.
----[NoImage] (Z:\projectbackup\megui\work\02lfrdg1.uif\00002.m2ts.avs, line 2)'
---[Error] [12/4/2019 6:04:14 AM] Stacktrace:    at MeGUI.core.gui.JobWorker.startEncoding(TaggedJob job)
---[Error] [12/4/2019 6:04:14 AM] Inner exception: null

Line 2 is simply this: LWLibavVideoSource("Z:\projectbackup\megui\work\02lfrdg1.uif\00002.m2ts.lwi")

I have no issues when using r929 version except for the above mentioned. Maybe I'm doing something wrong but reading the log from what little I understand perhaps its at my end and I don't know how to solve it in MeGUI since it asked me awhile back to end the avs script with YV12 and its coming back to haunt me or I'm also using HBD with fake lsb with SetFilterMTMode + Prefetch(1) with 720p 4:4:4 HEVC 10 bit or a combination of it all.

As mentioned the pipeline for the fake lsb uses that too to both get around having to use --y4m and I dunno how to go about it for my script without it as HEVC won't let me as I don't know any other method or I just am not aware of it.

If anybody can let me know if I am doing something wrong. If I can't update I'll be fine using r929 version. I don't wanna change my script if possible.

[HolyWu]

Originally Posted by dREV

Line 2 is simply this: LWLibavVideoSource("Z:\projectbackup\megui\work\02lfrdg1.uif\00002.m2ts.lwi")

Don't append .lwi in your source.

[StainlessS]

Nice catch HW

[Pat357]

It was my own stupid fault :
I used LibavSMASHSource instead of LWLibavSource : this can never work for a webm container !!

My apologies for my mistake.

[dREV]

Originally Posted by HolyWu

Don't append .lwi in your source.

Can you help me understand what you mean? Because this 00002.m2ts.lwi is created by the MeGUI program itself.

The MeGUI program has a avisynth configuration dialog field that has already <input> then under it is where I place my script and the program does the rest all via one-click.

I don't know if I can do anything within the <input> code.

From the Wiki I've tried all previous version I was able to download and ver r935+26-20190712 or whatever version this is was able to work. The rest do the same error as the current version but with some difference.

[LigH]

Always use the name of the media file in LwLibavVideoSource. In MeGUI, open the media file in the dialog, not the index file.

If MeGUI prefers to load the index file instead of the media file in a specific operation mode, it is an issue in MeGUI and should be discussed in its related threads, with all possibly relevant details, how you use it, step by step, click by click...

You can still manually edit the generated AviSynth script in MeGUI before you add a task to its queue, to possibly walk around this issue, if you don't use it in a fully automated mode.

[MeteorRain]

A quick guess is the plugin used to read the media file inside lwi. Now the field is gone (why not), it's not possible to find the media file by index file.

So please always use media file as the source. lwi is just an index.

[dREV]

Originally Posted by LigH

Always use the name of the media file in LwLibavVideoSource. In MeGUI, open the media file in the dialog, not the index file.

If MeGUI prefers to load the index file instead of the media file in a specific operation mode, it is an issue in MeGUI and should be discussed in its related threads, with all possibly relevant details, how you use it, step by step, click by click...

You can still manually edit the generated AviSynth script in MeGUI before you add a task to its queue, to possibly walk around this issue, if you don't use it in a fully automated mode.

The programs seems to want to load the index file instead then starts encoding from the source. I've tried to edit the avs script to target the source but not sure if I did it wrong or if MeGUI won't budge. The latest version of MeGUI still uses the same version from 2017 which takes a while to index compared to both HolyWu and MeteorRain's versions. The one that worked as noted above takes almost a minute which is way better but would like to use HolyWu for that 1 frame fix.

I'll ask the author of MeGUI and see if any replies.

Originally Posted by MeteorRain

A quick guess is the plugin used to read the media file inside lwi. Now the field is gone (why not), it's not possible to find the media file by index file.

So please always use media file as the source. lwi is just an index.

I can't do anything on that. I do everything via One-Click.

There is another method to encode using that program but I have zero experience how to go about it which is the first image on the official site https://sourceforge.net/projects/megui/ I have no idea how to encode without MeGUI doing its thing with the indexing in One-Click. If I can be given an example for me to try it out.

Is it just: Load l-smash > LWLibavVideoSource("path\00002.m2ts") ? Then the rest of my script?
Thanks for the replies.

[hello_hello]

Having read the last few posts....

MeGUI has been using the index file as the source for LWLibavVideoSource for as long as I can remember, just as it does for d2v index files. The Lsmash index file previously contained the path to the source file, so using it as the source in MeGUI's script creator worked as it does for DGIndex.
That's no doubt the issue, because MeGUI hasn't caught up to the change yet, which in my opinion is a step backwards. In the case of MeGUI, the working directory can be different to the directory where the source file is located, so opening the index file directly has always allowed the source to be re-opened in a new script by opening the index file, without MeGUI wanting to index it again, no matter where the index file is located (existing DGIndex index files can be used as the source for the same reasons). There's no way to manually type the source name/location when creating a new script via the script creator. You have to open a source file or an existing index file, and MeGUI creates a script using the index file as the source after indexing with Lsmash, or it expects to be able to open an existing one. It's a pity newer Lsmash versions don't work the same way, IMHO.

For ffms2, the path to the source isn't saved to the index file, but MeGUI still allows you to open the index file directly, however I think it must have the same name as the source file including the original extension, followed by the ffindex extension (that's how MeGUI creates the index file anyway). MeGUI then knows to create a script using the original file name for the source with the ffms2 cachefile argument pointing to the existing index file, rather than having to repeat the indexing process. It's not as convenient as indexing with DGIndex or Lsmash (once) was though, if you want to create a new script from scratch, because the index file has to be located in the same directory as the source file for it to work.
Does the newer Lsmash have the same cachefile argument, or is MeGUI going to be forced to re-index a source file to open it it in a new script (or maybe taught to check for an existing index file)?

One disadvantage of indexing with Lsmash in the past is it hasn't been possible for MeGUI to tell Lsmash not to index the audio when it's not necessary, which it can for ffms2. I also recall reading that this can now be done for newer LSmash versions, so it's no doubt another change that will require MeGUI to be updated for in the future.

PS I assume MeGUI always includes the original extension in the script and index file names to avoid conflicts when the output directory and the source directory are the same. ie for a source file named video.mkv the script would be named video.mkv.avs, the index file video.mkv.lwi, and the output file video.mkv.mkv.

[MeteorRain]

Originally Posted by hello_hello

You have to open a source file or an existing index file, and MeGUI creates a script using the index file as the source after indexing with Lsmash, or it expects to be able to open an existing one.

I don't use MeGUI and I never thought this was even a problem. During my life I never tried putting lwi in the source position, hence I had the wrong assumption.

So how does it index the source then. Usually I put the media in the source position, you know, lwlibavvideosource(media), load it in some sort of GUI and the indexing is done. You say that MeGUI creates index first and then creates the script? I'm very confused now.

[hello_hello]

Originally Posted by MeteorRain

I don't use MeGUI and I never thought this was even a problem. During my life I never tried putting lwi in the source position, hence I had the wrong assumption.

So how does it index the source then. Usually I put the media in the source position, you know, lwlibavvideosource(media), load it in some sort of GUI and the indexing is done. You say that MeGUI creates index first and then creates the script? I'm very confused now.

I don't use MeGUI's OneClick encoder as a previous poster does, but doing it the "manual" way you can either open a file with MeGUI's File Indexer and create an indexing job (the File Indexer lets you choose the indexer and also extracts the audio or creates a script to re-encode it as required), or you can open the source file directly with MeGUI's Script Creator, in which case MeGUI will open the File Indexer to index it first anyway. In the case of LSmash, once the indexing job has run it moves the index file to the working directory (if one is specified in it's options) and then opens the Script Creator using the index file as the source. There's also the option to run a batch of indexing jobs without opening the Script Creator each time, in which case the index files can be used as the source for the Script Creator later on.
I don't know exactly how MeGUI's File Indexer tells Lsmash to index a source, as it does that "behind the scenes", but the log file indicates it creates a script to open the source file which it runs, causing Lsmash to index.

The initial script created by MeGUI's Script Creator after indexing would look like this:
LWLibavVideoSource("D:\Episode 4.mkv.lwi")

It's always worked much the same way as indexing with DGIndex, where the index file becomes the source.
DGDecode_mpeg2source("D:\Episode 4.d2v")
For ffms2, I assume MeGUI uses the cachefile argument to create the index file in the working directory.

I checked and if you open a source file directly using the script creator and an lwi index file exists in the same directory, MeGUI appears to verify it's valid and uses the source file as the source in the script, rather than the index file. At least for MKVs. I haven't checked other file types, but for file types where it'd normally index with a different indexer by default, it'd probably insist on indexing again, so being able to open an index file directly would prevent that. There's no way to bypass the File Indexer completely if MeGUI thinks a source needs indexing though.

A way around the problem when using a newer version of Lsmash would be to manually create a script to open the source file, and to use that script as the source for MeGUI. When it's opened, Lsmash would automatically index the source file and MeGUI will patiently wait for the indexing to finish. Scripts can also be used as source files for the One Click encoder and batch encoding, but because MeGUI isn't seeing the source directly it can't know if it's anamorphic, and bypassing the File Indexer that way would mean the user would have to extract the audio themselves if they don't wish to re-encode it.

Not including the path to the source in the index file probably isn't the end of the world, but MeGUI will have to be changed for Lsmash so it doesn't use the index file as the source, and I assume the index file is always going to have to live in the source directory.

[dREV]

Originally Posted by MeteorRain

I don't use MeGUI and I never thought this was even a problem. During my life I never tried putting lwi in the source position, hence I had the wrong assumption.

Why does your compiled version r935+2 still worked in MeGUI but updated iterations from r935+26-20190811 compiled by HolyWu to the latest don't?

Was this .lwi taken out of the code or something? Is it possible to put whatever got it working to the latest lsmash? Perhaps then would the MeGUI author be willing to finally update.

[hello_hello]

Originally Posted by dREV

Why does your compiled version r935+2 still worked in MeGUI but updated iterations from r935+26-20190811 compiled by HolyWu to the latest don't?

Was this .lwi taken out of the code or something? Is it possible to put whatever got it working to the latest lsmash? Perhaps then would the MeGUI author be willing to finally update.

The release info says it happened with version r935+31-20190820
http://avisynth.nl/index.php/LSMASHS...ived_Downloads
Remove InputFilePath field from the index file. It's unnecessary and troublesome when users rename or move the source file.

Given it doesn't seem to be common practice to use the index file as the source in scripts, I'm not sure how including the source path could be much of a problem. If you moved or renamed the source file and opened it in a script, wouldn't lsmash just index it again anyway? And if you are using the index file as the source... don't move or rename the source file.

The ffms2-like cachefile argument is a welcome addition, although I've still found it a bit of an annoyance because you can't re-open the index file directly (with MeGUI) unless it's in the same directory as the source.

DGIndex has worked that way forever. The path to the source is stored in the index file and it becomes the source for DGDecode. Maybe a new argument to make including the source path optional might be a compromise? Obviously LWLibavVideoSource has the ability to open an index file, so it seems a pity to lose that completely when it'd often be useful.

[HolyWu]

Use a more maintained GUI other than MeGUI. End of the story.

[hello_hello]

Originally Posted by HolyWu

Use a more maintained GUI other than MeGUI. End of the story.

So that's why not writing the source path to the index file is an improvement rather than a step backwards... because MeGUI isn't always updated quickly. I'd not seen the obvious connection until now.

[Atak_Snajpera]

Originally Posted by hello_hello

So that's why not writing the source path to the index file is an improvement rather than a step backwards... because MeGUI isn't always updated quickly. I'd not seen the obvious connection until now.

Index file should not contain hardcoded Path to a file. End of the story.