L-SMASH Source

[ChaosKing]

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 (https://github.com/HolyWu/L-SMASH-Works/releases) 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 (http://avisynth.nl/index.php/LSMASHSource) 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 (https://x265.readthedocs.io/en/latest/cli.html#cmdoption-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 (http://avisynth.nl/index.php/LSMASHSource). I don't wanna change my script if possible. :thanks:

[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]

Don't append .lwi in your source.

:scared: 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 (http://avisynth.nl/index.php/LSMASHSource#Archived_Downloads) I've tried all previous version I was able to download and ver r935+26-20190712 (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases) 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]

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.

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]

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]

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]

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 (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases) still worked in MeGUI but updated iterations from r935+26-20190811 (http://avisynth.nl/index.php/LSMASHSource#Archived_Downloads) 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. :p

[hello_hello]

Why does your compiled version r935+2 (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases) still worked in MeGUI but updated iterations from r935+26-20190811 (http://avisynth.nl/index.php/LSMASHSource#Archived_Downloads) 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. :p

The release info says it happened with version r935+31-20190820
http://avisynth.nl/index.php/LSMASHSource#Archived_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.

[hello_hello]

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]

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.

[manolito]

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

Says who? Are there any coding guidelines which tell this?

LSmash is just following the good old DGIndex example, and I never heard any complaints about the d2v file format. I just rechecked with the latest DGIndex version:
DGIndexProjectFile16
1
F:\Download\DVD_test.mpg

[filler56789]

Says who? Are there any coding guidelines which tell this?

LSmash is just following the good old DGIndex example, and I never heard any complaints about the d2v file format. I just rechecked with the latest DGIndex version:

DGIndexProjectFile16
1
F:\Download\DVD_test.mpg


Atak has a point; an index file that does not hardcode the path to the source-file implies ~portability~. By the way, a .GRF file generated by GraphEdit or GraphStudio is not an index of course but it also breaks the portability of the source-file(s) because of the hardcoded paths.

[videoh]

You can omit full paths too with DGIndex, leaving just the bare filename, which makes things relative to the current directory, and such that the files can be moved together to a new location without needing re-indexing.

[hello_hello]

Says who? Are there any coding guidelines which tell this?

LSmash is just following the good old DGIndex example, and I never heard any complaints about the d2v file format. I just rechecked with the latest DGIndex version:

That's why I've mentioned DGIndex/DGDecode in a few posts, thinking from there it'd be natural to question why it's a problem for LSMash but not DGIndex. Instead there's been two posts claiming "end of story" status without explaining why it's a bad thing, or why an option to enable/disable it wouldn't keep everyone happy (and it'd allow Lsmash to keep playing nice with GUIs).

The cachefile argument is nice to have, but from the perspective of someone who uses a GUI, the ability to specify it's location isn't as useful when the index file doesn't know where the source is, as it can't be opened directly later on unless it's in the source folder. Could we have a show of hands from those who often use the cachefile argument without specifying a location other than the source folder? Does anyone regularly give index files fun names while still writing them to the same folders as the source?

What about something like this? If the cachefile argument isn't used, or of the index file is written to the source folder, by default LSmash would not save the full path to the index file. If the index file is not written to the same folder as the source, then by default LSmash would write the full path. A FilePath argument would allow the user to over-ride those defaults. Just a thought...

[StainlessS]

Embedding the filename in the index may or may not have been a good idea to begin with, but breaking things without good reason is also not a good idea.

EDIT: Is/was also a lousy (and lazy) idea for MeGUI to use embedded filename to load source, I was a bit shocked to discover that it did that.

[hello_hello]

EDIT: Is/was also a lousy (and lazy) idea for MeGUI to use embedded filename to load source, I was a bit shocked to discover that it did that.

I don't know if I'd call it lazy, because the path is saved to the index file, and LWLibavVideoSource can obviously open index files, and I suspect that's by design rather than accident. but if the index file wasn't located in the source folder there was no way to tell LWLibavVideoSource where to find it, until recently. Lsmash has only had a cachefile argument for roughly 15 minutes. Why is it considered normal for DGDecode to load d2v files but evil for everyone else?

While I'm defending MeGUI....
If I remember correctly adding Lsmash as an indexer wasn't completely straightforward. I don't think older versions report the indexing progress because I recall Zathor saying he had to find a way to let MeGUI know when it finished, and MeGUI had to be taught to move the index files to the working directory so lsmash wouldn't be embarrassed in the company of cachefile enabled indexers.

So.... the index files are in the working directory and it's time to create a new script from scratch. MeGUI can open d2v index files and until recently it worked the same way for lsmash, but not so much for ffms2 because the index file has no idea where the source file is. You can work around it by manually moving/copying the index file to the source directory and open it as the source in MeGUI's script creator. MeGUI will create a new script with the index file specified for the cachefile argument. I assume the index file must be named correctly for MeGUI to get the source name right.

[Atak_Snajpera]

Says who? Are there any coding guidelines which tell this?

Mr. Common sense my friend... No guidelines needed.

[hello_hello]

Mr. Common sense my friend... No guidelines needed.

Does the source path saved to the index file play any part in determining if the source and index file are a match? I assume not, given it's no longer written to the index file, so would it be logical to assume it only tells Lsmash where to find the source that's expected to match?

My questions are.... well they're not actually my questions, but Mr. Common Sense will hassle me relentlessly until I ask on his behalf.....

Mr. Common Sense is keen to understand why the source/path info in the index file couldn't be ignored when LWLibavVideoSource is opening a video file directly, and why it wouldn't function exactly as it does without it. He's quite adamant the freedom to rename or move files won't change whether the source/path info in the index file is ignored or it's not written-in the first place.

Mr. Common Sense is insisting if the source info written to the index file is only used when an index file becomes the source for LWLibavVideoSource it's so obviously common sense that the index file should include the video file's location, not including it becomes borderline mental. There's no cachefile-equivalent argument for specifying the video file's location when opening index files.

Mr. Common Sense wants me to emphasise his/my entire post is purely a common sense view of how the world should work, with possibly no basis in reality, due to common sense being so uncommon. :)

[Atak_Snajpera]

Does the source path saved to the index file play any part in determining if the source and index file are a match? I assume not, given it's no longer written to the index file, so would it be logical to assume it only tells Lsmash where to find the source that's expected to match?

My questions are.... well they're not actually my questions, but Mr. Common Sense will hassle me relentlessly until I ask on his behalf.....

Mr. Common Sense is keen to understand why the source/path info in the index file couldn't be ignored when LWLibavVideoSource is opening a video file directly, and why it wouldn't function exactly as it does without it. He's quite adamant the freedom to rename or move files won't change whether the source/path info in the index file is ignored or it's not written-in the first place.

Mr. Common Sense is insisting if the source info written to the index file is only used when an index file becomes the source for LWLibavVideoSource it's so obviously common sense that the index file should include the video file's location, not including it becomes borderline mental. There's no cachefile-equivalent argument for specifying the video file's location when opening index files.

Mr. Common Sense wants me to emphasise his/my entire post is purely a common sense view of how the world should work, with possibly no basis in reality, due to common sense being so uncommon. :)
You are barking under wrong tree. You should bark under MeGUI tree...

[hello_hello]

You are barking under wrong tree. You should bark under MeGUI tree...

It's not about MeGUI. It's about fixing something in lsmash that wasn't broken (in my opinion).
Mr. Common Sense is beginning to suspect if there's a good argument for never writing the source path to the index file, someone would've offered it by now, or maybe explained why I'm wrong for thinking it should at least be optional, or something....

On a completely different subject, the usual expression is "barking up the wrong tree (https://en.wikipedia.org/wiki/Barking_up_the_wrong_tree)", in case you weren't aware. Unless that's an alternative version I've not heard before. :)

[Are_]

Nothing is broken in lsmash, only something is broken in megui if you try to use an unsupported fork of that plugin on that gui. Is as simple as using another fork, or asking the megui author for an update.

[hello_hello]

I don't know why or what you are insisting upon.

There's no insisting taking place. I'm just waiting for someone to answer a single question I've asked or to explain what problems were fixed by the change. I'm starting to accept that's not realistic, as even beginning my last post with "it's not about MeGUI" didn't help.

FFMS2 also doesn't write the source path to the index file. Does any of the FFMS2/MeGUI users (except you) complain or get annoyed because he/she couldn't directly use the index file as the source for whatever ridiculous reasons?

I've explained how MeGUI works around that shortcoming, but as long as the index file is in the same folder as the source you can "open it" to create a new script. A GUI can't add the cachefile argument to a script if the index file isn't in the source folder because it can't know it exists, and if it is in the source folder there's probably no need to use the cachefile argument anyway.

It's simply that an user updated a plugin on his/her own but MeGUI hasn't been updated yet to keep up with the latest changes. Since MeGUI can use the media file as the source and make use of the cachefile argument for FFMS2, the developer of MeGUI can just do the same thing as well for lsmash.

Obviously.... and someone donating their time to update a program or plugin is something I appreciate even when they've changed something I'd prefer they hadn't, and even when the change forces someone else to donate their time to accommodate it. I mostly use a PC running XP and an old version of lsmash, so I only posted here because I stumbled across the lsmash/MeGUI question and the replies seemed to indicate it's not common knowledge lsmash could open index files directly. I still think removing that ability completely was the wrong choice, but for some reason everyone wants to talk about MeGUI instead.

[hello_hello]

The index file is rebuilt needlessly due to InputFilePath field when the users move/rename the files or the folder containing the files to another folder/drive, or when open the media file on another computer via network path. It simply offers no real benefits at all.

Do you mean aside from allowing you to open the index file directly? Was it not possible to open the index file in notepad to change the InputFilePath field after renaming or moving files?

Because the author of lsmash never formally documented it in the readme to tell the users to open the index file directly.

That does seem odd, but it explains how the change could've been made without knowing it'd break something.

Please tell me under what circumstances would an user bother to take another unnecessary step to modify the script and append .lwi at the end of source path just for LWLibavVideoSource to specifically open the index file while it already could directly open the media file just fine.

In that scenario, I can't think of a reason to do so.

You kept yelling how useful that ability was for everyone

Are you mistaking calmly answering questions for yelling or are you being childish?

but actually the point was only meant to satisfy the bad design of MeGUI. Fortunately we have other more actively developed/maintained GUIs in the forum and the users can have better choices.

Which other GUI's are you referring to? I'd like to try them. I assume you're referring to GUI's that index a source but don't repeat the process if you open it a second time. Which one would you recommend and how does it work in that respect?

I use AVISynthesizer quite a bit for creating scripts. In case you're not aware of it, you create templates to use via Explorer's right click menu and AVISynthesizer adds the path/source details and creates the script. When the index file wasn't in the source folder you could previously use it instead of the source, or even create a new script manually without requiring any tedious typing for the cachefile argument, and even when doing so to open it in avspmod.
Admittedly, that sort of thing only qualifies as a minor annoyance, but we all do things differently. Not everyone creates a script to open and index a source in avspmod before moving or renaming the source file.

I honestly don't care that much if lsmash remains the way it is, but the refusal to acknowledge there might have been a better way to solve the source renaming/moving problem does baffle me a little, as does attempting to blame a GUI or label it as badly designed, especially if the change was made without knowing index files could be used as the source.

[Are_]

I know I already bit the bait but, shouldn't we ignore the obvious troll? He doesn't use the plugin but he's just wasting others time with ridiculous questions nobody cares just because he's probably bored and all. In the last post he even retorted to mild insulting, sad view.

[LigH]

I'm not fond of religious wars in technical forums.

[hello_hello]

I know I already bit the bait but, shouldn't we ignore the obvious troll? He doesn't use the plugin but he's just wasting others time with ridiculous questions nobody cares just because he's probably bored and all. In the last post he even retorted to mild insulting, sad view.

FFS, that'll teach me to post about something that doesn't effect me at the moment simply to help someone else understand a problem they were having. I do use the plugin, but I don't use the current version and I made the reason for that clear. I'm sorry you didn't understand... and all... but in case I need to state the obvious, I'd prefer to eventually use a more recent version, only I'd rather it retained the ability to open index files.

For the record, it's not the 1990's and the only trolls in forums are the ones who troll by insulting others with accusations of trolling. Did you forget to discuss the topic or were you just bored?

[videoh]

Suppose you want to load a series of M2TS files which are scattered in a directory and not in sort order (just about any bluray/UHD disk). Another case is multiple VOBs from a DVD. Loading a DGIndex(NV) project file will conveniently and automatically load them all in order, because the file list is stored in the index file. Without that you'd have to navigate to and tediously select all the files again every time you want to work on the project again. Is this something applicable here? If smash whatever can only load one source file then it would be irrelevant. I don't know enough about the smash stuff to know if this is relevant, but it sure is a big advantage for DGIndex(NV) to have that capability.

[videoh]

I'm not fond of religious wars in technical forums. LigH arrogantly thinks that what he is fond of is an important consideration. Newsflash, nobody cares what you are fond of.

[MeteorRain]

Sorry for not keeping an eye on this thread for a few days. Let me add some point from my view.

The fundamental difference between dgindex / dgnv and lsmash / ffms is that dg index is generated using a standalone tool while lsmash / ffms index is (usually) generated by the plugin itself.

That's why I was so confused by the behavior of MeGUI. You have to use the source file as the parameter passed to lsmash in order to create an index. Why would it change that parameter (completely unnecessarily) to the index then?

For dgindex and dgnv it's pretty natural to use index because you create the index first. Besides, as videoh said, dg family supports loading multiple files in a single shot, which makes more sense for it to load an index.

[hello_hello]

Suppose you want to load a series of M2TS files which are scattered in a directory and not in sort order (just about any bluray/UHD disk). Another case is multiple VOBs from a DVD. Loading a DGIndex(NV) project file will conveniently and automatically load them all in order, because the file list is stored in the index file. Without that you'd have to navigate to and tediously select all the files again every time you want to work on the project again. Is this something applicable here? If smash whatever can only load one source file then it would be irrelevant. I don't know enough about the smash stuff to know if this is relevant, but it sure is a big advantage for DGIndex(NV) to have that capability.

I don't actually know if lsmash can open split vob files as a single file as I've always used DGIndex for that, but it's the same as ffms2... by default it ignores repeat flags and outputs the average frame rate. It's probably fine if the ultimate goal is a variable frame rate encode, but I've seen a few threads at VideoHelp where someone has ripped a DVD with MakeMKV and indexed with lsmash and posted to ask why the audio sync is all over the place.

As far as I know there's no way to load multiple sources as a single index file or project.

[hello_hello]

That's why I was so confused by the behavior of MeGUI. You have to use the source file as the parameter passed to lsmash in order to create an index. Why would it change that parameter (completely unnecessarily) to the index then?

I can only repeat what I've repeated several times. The main advantage of being able to open an index file directly is when it's not in the source folder. That's why MeGUI works the way it does. It can index the source for you Monday, move the index file to the working directory, and Wednesday you can open it to create a script. It couldn't work that way for ffms2, but Lsmash had the ability to open index files and the person maintaining MeGUI was clever enough to make use of it. It baffles me why anyone would think that's a bad thing.

If lsmash wrote the path to the index file while indexing, but ignored it unless an index file is used as the source, it seems to me it'd be the best of both worlds. I honestly don't understand why there's so much resistance to the idea. Why break functionality unnecessarily? Even if the response was "can't be bothered", or "don't care" it'd make more sense to me than denying there's ever a reason to open index files. I often do because I rarely keep them in the source folder, so it saves having to specify each source location plus the cachefile argument for the index file in a new script, and we already know one of the most popular GUIs opens index files and it'll break.

[kedautinh12]

So how did you right click on a nonexistent index file in the explorer when the index wasn't created yet for new media files? Didn't you still need a script and point the media file as source to let LWLibavVideoSource create the index file first? Then you either modify the existing script or create another new script and point the index file as source for LWLibavVideoSource just because you want to directly open the index file so deadly.

I see you hardwork with l-smash source, can you continute with ffmpegsource??

[hello_hello]

Of course it was. That's what the users did before, not only because of the file/folder being moved/renamed for some reasons, but also the file being opened from another computer using network path. But why must the users bother to edit the index file when they can avoid this unnecessary step once and for all?

I didn't say they should have to. Not that I recall complaints from users who move/rename source files after indexing, so I'm not sure how it was determined they found it a problem or troublesome.

So how did you right click on a nonexistent index file in the explorer when the index wasn't created yet for new media files? Didn't you still need a script and point to the media file as source to let LWLibavVideoSource create the index file first? Then you either modify the existing script or create another new script and point to the index file as source for LWLibavVideoSource just because you want to directly open the index file so deadly.

After explaining numerous times?
At the risk of bringing MeGUI into it again, I often add a batch of indexing jobs to the job queue, let MeGUI run them while moving the index files to the specified location(s), and later I create the scripts from scratch. There's no scripts to copy or modify. MeGUI does the indexing "behind the scenes" via a command prompt... or something. You can't do the same thing with ffms2 unless the index files are in the source folder, which is often a determining factor for me when choosing which indexer to use.
I often use Avisynthesizer to create scripts using the index file as the source, and sometimes I do that rather than copy or modify an existing script because it's more convenient, or sometimes I get MeGUI to run a batch of indexing jobs and create the scripts myself etc.

And to go around in circles again, MeGUI is designed so the user isn't required to have any knowledge of Avisynth including how to open a source in a script, and I can't think of a GUI of that type that doesn't require the user to open a source file. I did ask for examples of the GUIs you claimed to be better choices with no response, but in MeGUI's case, the Script Creator can add the cachefile argument as long as it's configured to automatically open after indexing. To open a source that's already been indexed, the index file must be in the source folder or of a type the Script Creator can open directly, otherwise MeGUI can't know it exists. Are there psychic GUIs I'm unaware of, or is a bad thing MeGUI allows you to specify a working directory while still avoiding re-indexing whenever possible?

I've offered several suggestions as to how I think it'd be possible to have the best of both worlds, but they've been ignored in preference to insisting everybody does things the same way, or labelling a GUI as badly designed for having the audacity to use existing functionality, and that's something I find a little hard to understand.

[dREV]

MeGUI has a field section called "Working" which is where index files goes. It doesn't have to be set to target to a specific folder as it'll create a folder with the indexed file where ever the m2ts file is without moving it which is its default. However, even with leaving it on its default using the latest lsmash it'll still give the errors I've pointed at #1085 (https://forum.doom9.org/showthread.php?p=1892043#post1892043). Image here https://i.ibb.co/4jSWfZh/vampi.jpg

I also agree that it's not cool to call MeGUI out of date when it's been using something that was included in lsmash. Somehow the author knew about it but was taken out cuz the updaters didn't know why it was there or something. So if the MeGUI author wants to resort to having to update lsmash I'll be fine using MeteorRain's working one till then despite not being able to use that 1 frame fix. :)

Suppose you want to load a series of M2TS files which are scattered in a directory and not in sort order (just about any bluray/UHD disk). Another case is multiple VOBs from a DVD. Loading a DGIndex(NV) project file will conveniently and automatically load them all in order, because the file list is stored in the index file. Without that you'd have to navigate to and tediously select all the files again every time you want to work on the project again. Is this something applicable here? If smash whatever can only load one source file then it would be irrelevant. I don't know enough about the smash stuff to know if this is relevant, but it sure is a big advantage for DGIndex(NV) to have that capability.

I don't actually know if lsmash can open split vob files as a single file as I've always used DGIndex for that, but it's the same as ffms2... by default it ignores repeat flags and outputs the average frame rate. It's probably fine if the ultimate goal is a variable frame rate encode, but I've seen a few threads at VideoHelp where someone has ripped a DVD with MakeMKV and indexed with lsmash and posted to ask why the audio sync is all over the place.

As far as I know there's no way to load multiple sources as a single index file or project.

Would that even work when using trim? When I find banding sections I have to do multi-uses of the same m2ts file (banding here, sharpening here, anti-aliasing here, etc) and that would be really helpful cuz it takes a loooong time (well the 2017 lsmash MeGUI was using but even with MeteorRain's working one still takes time) but I guess it won't if I use trim? I don't really know what the index does. Does it index the entire m2ts file or is it frame based indexing?

I have my MeGUI setup to use lsmash via One Click > Config > Other tab > Indexer / Opener Priority and seems to ignore those and goes directly to DGI. To nitpick on this I dunno why it varies between DVD's with regards to how it does VOBs because I've had some DVD's where it only did each single episode while in others it did the entire DVD episodes into one huge container. :eek:

[hello_hello]

MeGUI has a field section called "Working" which is where index files goes. It doesn't have to be set to target to a specific folder as it'll create a folder with the indexed file where ever the m2ts file is without moving it which is its default. However, even with leaving it on its default using the latest lsmash it'll still give the errors I've pointed at #1085 (https://forum.doom9.org/showthread.php?p=1892043#post1892043). Image here https://i.ibb.co/4jSWfZh/vampi.jpg

I don't use OneClick, but I assume MeGUI still uses the index file as the source for lsmash in the script even when it's in the source folder because there's previously been no reason not to.

Would that even work when using trim? When I find banding sections I have to do multi-uses of the same m2ts file (banding here, sharpening here, anti-aliasing here, etc) and that would be really helpful cuz it takes a loooong time (well the 2017 lsmash MeGUI was using but even with MeteorRain's working one still takes time) but I guess it won't if I use trim? I don't really know what the index does. Does it index the entire m2ts file or is it frame based indexing?

It'd be better to discuss this elsewhere if need be, but I'm not sure exactly what you mean anyway. I'll send you a PM shorty so we can do it that way if you like.

I have my MeGUI setup to use lsmash via One Click > Config > Other tab > Indexer / Opener Priority and seems to ignore those and goes directly to DGI. To nitpick on this I dunno why it varies between DVD's with regards to how it does VOBs because I've had some DVD's where it only did each single episode while in others it did the entire DVD episodes into one huge container. :eek:

I'm guessing, but it probably ignores the preferred indexer and uses DGIndex for vob files due to the problem I mentioned earlier.
Vob files are generally indexed as a single file when they're sequentially numbered. There's often a title for each episode, but sometimes there's just a single title with the episodes divided by chapters and that'd be why sometimes all the episodes are encoded together. It depends how the DVD is authored. I'll explain how I re-author DVDs before encoding to solve that problem in the PM.

Edit: I tried to send you a PM but you have them disabled.

[dREV]

It'd be better to discuss this elsewhere if need be, but I'm not sure exactly what you mean anyway. I'll send you a PM shorty so we can do it that way if you like.

Sorry for not writing my words more properly I hope this will do better. The index is not based on what's in the AviSynth script such as if trim were to be used, correct?

For example, if I have a banding scene from frames (200, 500) and I get lsmash to index and encode these scenes it's not really doing it for those scenes but for the m2ts file itself? I'll then have to run the lsmash index 2 more times to do frames scenes (0, 199) and frames (501, 33000) to finish up the episode.

It'll be very helpful if I can just index once and get straight to encoding especially when I use trim as it could take up to 2 to 50 different frames for just 1 single episode which could take a very long time to do. Especially on the original MeGUI lsmash which I've timed it to be over well an 1 hour or two and movies are worse as the numbers shoot even higher.

I'm guessing, but it probably ignores the preferred indexer and uses DGIndex for vob files due to the problem I mentioned earlier. Vob files are generally indexed as a single file when they're sequentially numbered. There's often a title for each episode, but sometimes there's just a single title with the episodes divided by chapters and that'd be why sometimes all the episodes are encoded together. It depends how the DVD is authored. I'll explain how I re-author DVDs before encoding to solve that problem in the PM.

Edit: I tried to send you a PM but you have them disabled.

Sorry I never expected to receive any messages. Sorry if I wasted your time if you wrote stuff via PM. I'm not looking to re-author DVD's as I just do backups in mkv. Thanks for your offer

[poisondeathray]

Sorry for not writing my words more properly I hope this will do better. The index is not based on what's in the AviSynth script such as if trim were to be used, correct?

Yes, index is for the main video


For example, if I have a banding scene from frames (200, 500) and I get lsmash to index and encode these scenes it's not really doing it for those scenes but for the m2ts file itself? I'll then have to run the lsmash index 2 more times to do frames scenes (0, 199) and frames (501, 33000) to finish up the episode.


No, you only need to index once, the whole video

[hello_hello]

For example, if I have a banding scene from frames (200, 500) and I get lsmash to index and encode these scenes it's not really doing it for those scenes but for the m2ts file itself? I'll then have to run the lsmash index 2 more times to do frames scenes (0, 199) and frames (501, 33000) to finish up the episode.

While sometimes you can't know there's problems with an encode till after it's done, that's why I don't use the OneClick encoder, as normally I'd preview the Avisynth output before encoding and try to do everything in a single script, but even if you encode the video in sections you should be able to re-use the index file. If your workflow is causing MeGUI to create a new script and re-index the source for each section you encode you should change it if you can. OneClick is really designed to be an automatic process. If you're creating complex scripts and/or fixing problems it's probably not the best choice.

LWLibavVideoSource("D:\Video.m2ts.lwi")
MaybeSomeFilterHere()
MaybeAnotherOne()
A = last
B = A.SomeDebanding()
A.Trim(0, 199)\
++B.Trim(200, 500)\
++A.Trim(501, 0).MaybeAnotherFilter().OrTwo()
MaybeSomethingElse()

By the way, I had a better look at your previous screenshot and it seems even when you don't specify a working directory, OnceClick creates a subfolder with a random name in the source directory, so it'd put the index file in that folder and open it directly. OneClick probably always creates subfolders regardless of the output location, but as I said, I don't use it.

Especially on the original MeGUI lsmash which I've timed it to be over well an 1 hour or two and movies are worse as the numbers shoot even higher.

That seems an extremely long time even for a 1080p source with several audio streams. I just indexed a 1080p movie with the old XP compatible lsmash and it took 70 seconds. It was only 6GB but it was the largest MKV I had handy. Sometimes indexing a 1080p Bluray movie can take a while, but I don't think I've indexed a movie that came close to an hour to complete.

Sorry I never expected to receive any messages. Sorry if I wasted your time if you wrote stuff via PM. I'm not looking to re-author DVD's as I just do backups in mkv. Thanks for your offer

The idea of re-authoring them first is so the episodes can be encoded individually. It's easy to do and doesn't take long.
To keep discussing MeGUI itself though, it'd probably be better to do so elsewhere rather than sidetrack this thread too much.

[Atak_Snajpera]

@HolyWu
Could you help me to decrypt those values?
Index=0,POS=9566774,PTS=-9223372036854775808,DTS=35085050,EDI=0
Key=1,Pic=1,POC=2,Repeat=1,Field=0

My guesses
Index -> stream index
POS -> position in file
PTS -> ?
DTS -> ?
EDI -> ?
Key -> keyframe
Pic -> ?
Repeat -> ?
Field -> Interlaced field

Also What is purpose of these entries?

<StreamDuration=0,0>-9223372036854775808</StreamDuration>
<StreamIndexEntries=0,0,16061>
POS=0,TS=0,Flags=1,Size=0,Distance=0
POS=12116,TS=500500,Flags=1,Size=0,Distance=0
POS=26960,TS=1101100,Flags=1,Size=0,Distance=0
POS=95503,TS=1601600,Flags=1,Size=0,Distance=0
POS=154509,TS=2002000,Flags=1,Size=0,Distance=0
POS=215660,TS=2452450,Flags=1,Size=0,Distance=0
POS=314434,TS=2752750,Flags=1,Size=0,Distance=0
POS=476442,TS=3253250,Flags=1,Size=0,Distance=0
POS=658539,TS=3753750,Flags=1,Size=0,Distance=0
POS=763885,TS=4104100,Flags=1,Size=0,Distance=0
POS=925780,TS=4654650,Flags=1,Size=0,Distance=0

[Atak_Snajpera]

They seem to be used for format which doesn't support seeking natively.
For example raw stream unmuxed in container (.264 , .265 , ivf) ?

[LigH]

Probably also MPEG Transport Stream (and Program Stream?): No internal index chunk, originally designed to be "played-a-live" ;) in a broadcast; seeking is only possible in a kind of interval bisection method: test seek with good guess assuming a rather constant average bitrate, read next found GOP timestamps, calculate new difference, new test seek with a better guess...

[Atak_Snajpera]

Probably also MPEG Transport Stream (and Program Stream?): No internal index chunk, originally designed to be "played-a-live" ;) in a broadcast; seeking is only possible in a kind of interval bisection method: test seek with good guess assuming a rather constant average bitrate, read next found GOP timestamps, calculate new difference, new test seek with a better guess...

So another question would be Why do we need those entries for mkv,mp4 and others?

[LigH]

LwLibav*Source generally does not rely on internal index chunks of any container format. It always re-indexes content streams as they are demultiplexed by the libavformats splitters. Only a fresh index guarantees frame-exact seeking; internal index chunks chould have been damaged, missing, or been built by "incompetent" software...

LSMASH*Source relies on index chunks of ISO Base Media container formats only.

[Atak_Snajpera]

LwLibav*Source generally does not rely on internal index chunks of any format. It always re-indexes content streams as they are demultiplexed by the libavformats splitters. Only a fresh index guarantees frame-exact seeking; internal index chunks chould have been damaged, missing, or been built by "incompetent" software...

I meant why do we need those extra entries in index if we already have this above

<LSMASHWorksIndexVersion=0.0.2.0>
<LibavReaderIndexFile=16>
<FileSize=2465531781>
<FileHash=0x94ac5e38>
<LibavReaderIndex=0x00000100,1,mpegvideo>
<ActiveVideoStreamIndex>+0000000000</ActiveVideoStreamIndex>
<ActiveAudioStreamIndex>-0000000002</ActiveAudioStreamIndex>
<StreamInfo=0,0>
Codec=2,TimeBase=1/1200000,Width=720,Height=480,Format=yuv420p,ColorSpace=6
</StreamInfo>
Index=0,POS=0,PTS=-9223372036854775808,DTS=0,EDI=0
Key=1,Pic=1,POC=0,Repeat=1,Field=0
Index=0,POS=7988,PTS=-9223372036854775808,DTS=50050,EDI=0
Key=0,Pic=2,POC=1,Repeat=1,Field=0
Index=0,POS=8576,PTS=-9223372036854775808,DTS=100100,EDI=0
Key=0,Pic=2,POC=3,Repeat=1,Field=0
Index=0,POS=9128,PTS=150150,DTS=150150,EDI=0
Key=0,Pic=3,POC=2,Repeat=1,Field=0
Index=0,POS=9446,PTS=-9223372036854775808,DTS=200200,EDI=0
Key=0,Pic=2,POC=5,Repeat=1,Field=0
Index=0,POS=10002,PTS=250250,DTS=250250,EDI=0
Key=0,Pic=3,POC=4,Repeat=1,Field=0
Index=0,POS=10320,PTS=-9223372036854775808,DTS=300300,EDI=0
Key=0,Pic=2,POC=6,Repeat=1,Field=0
Index=0,POS=10884,PTS=-9223372036854775808,DTS=350350,EDI=0

[l33tmeatwad]

Was just trying out the latest updates from HolyWu, apparently every version after 20190910 either crashes or gives an access violation on x86 with AviSynth+ 3.4.0; the x64 for the latest appears to work fine.