L-SMASH Source

[manolito]

It can. I haven't tested with vob files, but I've seen the problem with both ffms2 and lsmash for AVI and MKV sources. I think it's something to do with jitter in the source timecodes, but it's possible that when the frame rate is constant and you tell ffms2 or lsmash to convert to that constant frame rate, they'll drop and repeat frames in places when in theory they should do nothing. As a result I never use frame rate conversion unless I want to convert the frame rate.
https://forum.doom9.org/showpost.php?p=1703007&postcount=4395


If this is true then I would call it a bug in ffms2 and lsmash.

In most of my scripts with ffms2 and lsmash I do not even use the fpsnum and fpsden parameters, I use ChangeFPS(..) right after the source filter call. This method solves 2 problems in 1 step:
First of all it does the VFR to CFR conversion (if applicable), and secondly the ChangeFPS command ensures linear access to the source filter. This is necessary for AVS+ in MT mode, because without linear access the speed of the source filter will drop to a snail's pace.

[hello_hello]

If this is true then I would call it a bug in ffms2 and lsmash.

It was a problem reported by a couple of other people too, after the ffms2 CFR to VFR conversion was automatically added to scripts by MeGUI, and I've seen lsmash do the same. That was actually my idea, as I thought it'd solve the problem of not being able to use MeGUI to convert VFR sources automatically, but then the CFR source problem appeared, plus it relied on MeGUI getting the new constant frame rate right, which should always be 29.97fps for NTSC-type sources, or at least the same as the maximum frame rate. These day's MeGUI's OneClick encoder can extract the timecodes from MKVs and use them for a VFR encode, so there's no need for a messy constant frame rate conversion. For DVD encoding I understand a constant frame rate is necessary, but when the destination is MKV I rarely contemplate a VFR to CFR conversion rather than a VFR output.

In most of my scripts with ffms2 and lsmash I do not even use the fpsnum and fpsden parameters, I use ChangeFPS(..) right after the source filter call. This method solves 2 problems in 1 step:
First of all it does the VFR to CFR conversion (if applicable), and secondly the ChangeFPS command ensures linear access to the source filter. This is necessary for AVS+ in MT mode, because without linear access the speed of the source filter will drop to a snail's pace.

I'm experiencing déjà vu. Have we had this conversation before?
I don't understand how ChangeFPS can convert VFR sources to a constant frame rate. Say you have a source that's a mixture of film (soft telecine) and video and it's 50-50, so the average frame rate is 26.938fps. Without frame rate conversion or honouring repeat flags, that's how ffms2 and lsmash decode it. The film sections would play too quickly and the video sections too slowly, and the A/V sync would be lost. If you use ChangeFPS to change the frame rate to 29.97fps (for example), it'll add frames to both the film and video sections to bring the frame rate up to 29.97fps, but they'll both still play at the wrong speed. The film sections would have less frames added than if they were being decoded at 23.976fps and the video sections would have frames added that wouldn't be if they were decoded at 29.97fps. An ffms2 or lsmash frame rate conversion at least ensures the extra frames are added where they're supposed to be, because they're aware of how the source frame rate varies. ChangeFPS isn't.

I kind of get how ChangeFPS could ensure more linear frame requests from the source filter, but have you tried RequestLinear() from the TIVTC package? I think by default it requests frames 50 at a time from the upstream filter and caches 10 frames itself, although both can be adjusted.

[TheFluff]

But the real problem about audio sync does come from the source filter. Captured transport streams often have a huge audio delay. Your sample has an audio delay of -632 ms, after repacking to MKV the delay is -631 ms (almost identical). And different source filters treat such delays differently.

For DirectShow based souce filters as well as for ffms2 my experience is that this delay has to be discarded when muxing converted audio and video streams. LSMASH hehaves differently, the delay needs to be honored for perfect audio sync. (I believe that the DG source filters behave identically). I think that the reason is that some source filters just delete video frames at the start before a valid key frame while others like LSMASH repeat the first valid video frame up to the point where the audio starts.

I doubt your theory regarding incomplete GOP's is correct. In the FFMS2 case, if you're also decoding audio with it, what you're seeing is probably just the default audiodelay setting (https://github.com/FFMS/ffms2/blob/master/doc/ffms2-avisynth.md#int-adjustdelay---1). That is, if you have a -631ms delay in the container, that means (in practical terms) that the audio stream should start playback 631ms before the video stream. With the default audiodelay setting, FFMS2 will then discard the first 631ms of the audio stream in order to make video and audio start at the same time. Since Avisynth doesn't support timecodes for neither audio nor video, there's no way for it to know that one stream starts before another, so cutting off the audio or filling it in with silence is the only way to adjust sync. Other source filters probably just default to giving you the audio as it is.


I don't understand how ChangeFPS can convert VFR sources to a constant frame rate.

You are correct, it can't (because it lacks access to the timecodes). If the source was actually VFR, it would indeed cause desync.


As far as the discussion regarding honoring repeat field flags/soft pulldown or not, I basically think both sides are wrong. Honoring RFF's only really makes sense if you intend for the output to be interlaced, or if you're intending to deinterlace the entire stream because it's mostly interlaced content anyway and you can't be bothered to treat it as hybrid. In any other situation you're just doing a lot of pointless work by adding fields you're going to remove later anyway. Additionally, RFF's are a way of saying "look, this is actually progressive, but we have to pretend it's interlaced for compatibility reasons", so there's no reason to honor them if you don't actually want interlacing in the first place.

However, in the context of Avisynth specifically, not honoring RFF's is kind of a pain in the ass. Avisynth doesn't have any per-frame metadata, not even timecodes, so there's no builtin way of signalling which frames are interlaced and which aren't, nor any way of dealing with VFR, so dealing with the hybrid content that disregarding RFF's is likely to result in requires significantly more manual effort than it does in e.g. Vapoursynth. So in that context honoring RFF's does make life easier.

[manolito]

So far everybody has been telling me that my way of dealing with NTSC clips with irregular pulldown or hybrid content will inevitably lead to A/V sync problems.

Then I asked (repeatedly) for a link to such a clip which would prove it. All I got was a link to a clip which is absolutely useless to judge A/V sync.

Please let me ask for it again:
I need a clip taken from a DVD which will show that my way of dealing with such clips is flawed. And which will hopefully allow me to find a way to deal with it without using DGIndex.

[TheFluff]

I haven't had a DVD drive in my computer for years now and I've deleted most of the old stuff that could be interesting, so I can't help you there. The clip would have to be fairly long too to make audio desync really noticeable, a few minutes at least.

[videoh]

Suppose a 29.97 stream's first half is video with no pulldown and the second half is pure soft 3:2 pulldown. If I understand correctly, the suggestion is to ignore pulldown and then apply ChangeFPS. But what does this really mean? You're going to have to specify some decimated frame rate, but you can't just assume 23.976 because that would be correct only for the second half. And we don't want any ChangeFPS action on the first half anyway. For totally irregular pulldown it could be any old crazy rate you would have to choose correctly if ChangeFPS is going to be any good.

I've also seen progressive transport streams with bursts of soft frame repeats in an irregular manner (presumably for compression of black or static video). How will your way deal with those? You have to honor the frame repeats.

my way of dealing with such clips

I would welcome a more detailed explanation of your proposed handling for hybrid and irregular pulldown. Sure it could be reasonable for pure soft 3:2 pulldown, but that's not what we are talking about. Can you give your exact script for handling lainvob.vob your way?

Sure, implementing pulldown correctly and doing random access for it in a source filter is challenging and difficult, but that's not a good reason to do the wrong thing.

[hello_hello]

Then I asked (repeatedly) for a link to such a clip which would prove it. All I got was a link to a clip which is absolutely useless to judge A/V sync.

Please let me ask for it again:
I need a clip taken from a DVD which will show that my way of dealing with such clips is flawed. And which will hopefully allow me to find a way to deal with it without using DGIndex.

The clip videoh uploaded will lose AV sync if it's not dealt with correctly. The spot it's easiest to see is around the 41 second point where she mouths the word "much" to the sung vocal.
I don't know whether you've looked at the sample encodes I uploaded here (https://forum.doom9.org/showthread.php?p=1896725#post1896725), but the A/V sync is okay for all the samples in the zip file, but not the separate average frame rate encode.

Another way to check the A/V sync is to open the original sample and an encoded version in different instances of MPC-HC and play them together. I have MPC-HC configured so I can pause and resume playback quickly by clicking on the video (I disable double clicking switching to full screen and use a middle click for that instead, because a double click for fullscreen is mental anyway). When they're running, it's then easy to quickly pause and resume playback for one instance of MPC-HC until the audio of both are in sync. Generally after a few fast double clicks on each instance of the player as required, you can sync the audio well enough to hear it start to phase cancel, rather than hearing a delay between them. With the audio in sync, the video should be too.
I sometimes use that method to check the A/V sync for CFR encodes (compared to the source to make sure any audio delay is correct when I suspect it's not). If the audio is phasing and the scene changes happen at exactly the same time in both players, you know the A/V sync is the same.

PS. If you try the MPC-HC method it's best to set "left down" for the play/pause option. If I remember correctly, "left up" lets you drag the player around by clicking on the video and holding the left mouse button down, and it can interfere with the ability to quickly pause and resume playback by clicking on the video. For "left down", the player doesn't have to try to guess what you're wanting to do when you click on the video.

[videoh]

Thank you, hello_hello. Seems I have hit the theoretical part and you have hit the empirical part. Gonna be tough to beat!

[hello_hello]

But the real problem about audio sync does come from the source filter. Captured transport streams often have a huge audio delay. Your sample has an audio delay of -632 ms, after repacking to MKV the delay is -631 ms (almost identical). And different source filters treat such delays differently.

For DirectShow based souce filters as well as for ffms2 my experience is that this delay has to be discarded when muxing converted audio and video streams. LSMASH hehaves differently, the delay needs to be honored for perfect audio sync. (I believe that the DG source filters behave identically). I think that the reason is that some source filters just delete video frames at the start before a valid key frame while others like LSMASH repeat the first valid video frame up to the point where the audio starts.

I only just looked at the sample, but as soon as I see a negative audio delay in an MKV I check to see what's required to remove it. In the case of that sample, the video stream has a positive video delay of 631ms which MediaInfo reports as a -631ms audio delay. The simple fix is to remux it while applying a -631ms delay to every stream. You'll be left with either a zero or a small positive audio delay after MKVToolNix cuts the beginning of the audio.

If you open that sample with gMKVExtractGUI you'll see what's happening. If gMKVExtractGUI extracts the audio, it'll write a -631 delay to the extracted stream under the assumption the 631ms video delay will be lost during re-encoding. Most extraction programs would just write a zero delay. If you were to remux it with the original video while applying the -631ms delay, which would be a natural assumption, the A/V sync will change.
Writing the audio delay relative to the video when extracting the audio was actually my idea, after realising a video delay isn't all that uncommon.
The author of MKVCleaver kindly took it one step further so MKVCleaver can be configured to write both audio delays to the audio stream. The delay relative to the video and also the container audio delay. MediaInfo reporting a negative audio delay is a strong indication there's a positive video delay in an MKV, because for MKV there's no such thing as negative delays, but it's possible for the audio delay to be positive even when there's a video delay, if the audio delay is larger.

Anyway, as gMKVExtractGUI shows you both the stream delays and the video/audio delays relative to each other, it's easy to work out what's going on. I've no idea how the different source filters handle that sort of thing when decoding the audio in the original container. They should start decoding where the video starts, but remuxing the sample as an MKV while applying a -631ms delay to both the audio and video will remove that variable. I use the original audio most of the time rather than re-encode it, or if I do encode it I extract it first anyway, so it's more important to know the relative delay than the container delay.

The first delay for each stream is the container delay. The second delay for the audio stream shows their relative delays. The second delay for the video stream is the relative delay minus any audio container delay, I think. That one confuses me.

Remuxed

https://i.postimg.cc/TYCZS34m/01.gif

Remuxed while applying a -131ms delay to both streams

https://i.postimg.cc/RZhjzxkY/02.gif

Remuxed while applying a -631ms delay to both streams

https://i.postimg.cc/7YxFm2mw/03.gif

Here's what the help files say...

FFMS2:
int adjustdelay = -1
Controls how audio delay is handled, i.e. what happens if the first audio sample in the file doesn't have a timestamp of zero.
The following arguments are valid:

- **-3**: No adjustment is made; the first decodable audio sample becomes the first sample in the output.
- **-2**: Samples are created (with silence) or discarded so that sample 0 in the decoded audio starts at time zero.
- **-1**: Samples are created (with silence) or discarded so that sample 0 in the decoded audio starts at the same time as frame 0 of the first video track. This is the default, and probably what most people want.
- **Any integer >= 0**: Same as -1, but adjust relative to the video track with the given track number instead.
If the provided track number isn't a video track, an error is raised.
-2 obviously does the same thing as -1 if the first video frame of the first video track starts at time zero.
In some containers this will always be the case, in others (most notably 188-byte MPEG TS) it will almost never happen.

Lsmash
av_sync (default : false)
Try Audio/Visual synchronization at the first video frame of the video stream activated in the index file if set to true.

[manolito]

Yes, this is what I found out by trial and error a while ago when DVB-T2 was introduced in Germany (HEVC video, E-AC3 or AAC-LATM audio). The captured transport streams always have this huge audio delay, and for DSS2Mod and ffms2 these delays have to be ignored, for LSMASH the delays must be corrected.

So this is all caused by different default behavior of these source filters. Why in the world can the relevant source filter authors not agree on a uniform behavior?

The problem is that I never use my source filters manually, they are called by a GUI where the call mostly is hard-coded in the GUI. Either users cannot edit this call at all, or it requires that the user edits the generated AVS script.

This is not an option for most users. These GUIs are geared at average users, not at video specialists like you and DG. Since some of these GUIs are no longer maintained, it may be possible to use newer helper applications (like AVS filters or encoders), but only if the newer versions stick with their original defaults. This is the main reason why I always hate when the author of a tool which is widely used by other software suddenly decides that he wants to change defaults or calling conventions without any regard for backwards compatibility. MediaInfo is a good example, most GUIs which use it stopped working with versions after 18.5. And now the same thing happens with the latest LSMASH build by HolyWu. I really hate this, I call it "Apple Attitude".

[Myrsloik]

...

So this is all caused by different default behavior of these source filters. Why in the world can the relevant source filter authors not agree on a uniform behavior?

...


The source files are incorrectly flagged so often anything automatic will fail. We encoders are all so elitist because WE KNOW BETTER THAN THE MACHINES!

[videoh]

@manolito

Are you going to give us your script for lainvob.vob that does things "your way"?

[manolito]

Oh sure, I thought that you had noticed my reply here:
https://forum.doom9.org/showthread.php?p=1896679#post1896679

MediaInfo reports this:
Frame rate : 29.970 (30000/1001) fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First

And since no pulldown flags are reported, AVStoDVD treats it like a 29.97 interlaced TFF clip. The AVS script generated by AVStoDVD looks like this:
LoadCPlugin("E:\Programme\AVStoDVD\Lib\ffms2.dll")
Audio = FFAudioSource("F:\Download\lainvob.vob", track=-1)
Video = FFVideoSource("F:\Download\lainvob.vob", track=-1, fpsnum=2997, fpsden=100, colorspace="YV12", seekmode=2)
Video = Video.ConvertToYV12(interlaced=true)
AudioDub(Video, Audio)

ffms2 does not honor pulldown flags, so the fpsnum and fpsden parameters insert duplicates to bring up the frame rate to 29.97 fps. The resulting clip looks every bit as good as the original to me, and I cannot detect any A/V sync problems (within the limits of the clip characteristics).

The converted clip is here:
https://www.sendspace.com/file/0zcoxv

[hello_hello]

And since no pulldown flags are reported, AVStoDVD treats it like a 29.97 interlaced TFF clip.

Just for the sake of arguing, doesn't "treating it like a 29.97 interlaced TFF clip" and telling ffms2 to do a VFR to 29.97fps CFR conversion seem a little contradictory? If it's a 29.97 interlaced TFF clip there's no need to a VFR to CRF conversion. :)

ffms2 does not honor pulldown flags, so the fpsnum and fpsden parameters insert duplicates to bring up the frame rate to 29.97 fps. The resulting clip looks every bit as good as the original to me, and I cannot detect any A/V sync problems (within the limits of the clip characteristics).

Yeah, there's no reason why that shouldn't be in sync.
Because the sample is animation you get get away with lots of duplicate frames and not see a difference. If it was live action though, with lots of film sections, every fourth frame being repeated would probably get annoying fairly quickly.

I wonder why a program dedicated to DVD encoding wouldn't tell ffms2 to honour the pulldown flags by default, especially for a 29.97fps source? The script seems to indicate it's encoding the video as interlaced anyway..... although now I'm thinking about it, I recall the ffms2 help file says it'll throw an error if honouring repeat flags is enabled but the stream doesn't have any. I can't say I've tested that, but I have no idea what the logic behind that behaviour might be.

[hello_hello]

This is the main reason why I always hate when the author of a tool which is widely used by other software suddenly decides that he wants to change defaults or calling conventions without any regard for backwards compatibility. MediaInfo is a good example, most GUIs which use it stopped working with versions after 18.5. And now the same thing happens with the latest LSMASH build by HolyWu. I really hate this, I call it "Apple Attitude".

I'm still waiting to learn why one of the methods I suggested for determining when lsmash writes the source path to the index file wouldn't keep GUI's that use them as the source happy while not inconveniencing those who like to move and rename their source/index files.

[TheFluff]

I recall the ffms2 help file says it'll throw an error if honouring repeat flags is enabled but the stream doesn't have any. I can't say I've tested that, but I have no idea what the logic behind that behaviour might be.
That line is not strictly accurate, I think. AFAIK, you'll only get an error if you try to apply RFF's to a video stream encoded using a codec that's incapable of supporting them at all.

[videoh]

Thank you, manolito, for your script. It's easy to show that it is producing garbage compared to a proper conversion. I'll just look at video here (although audio sync also fluctuates significantly). Your script is producing 29.97 when most people will want 23.976 without dupes. Nevertheless, I omit the TDecimate call in my version so as to be able to compare the methods. Also note that I do not deinterlace either in DGSource() or via TFM() postprocessing, so the DG method is deriving good progressive frames throughout. Here is the script I use for comparing the methods:

LoadCPlugin("ffms2.dll")
manolito = FFVideoSource("lainvob.vob", track=-1, fpsnum=2997, fpsden=100, colorspace="YV12", seekmode=2).subtitle("manolito")

loadplugin("d:\don\Programming\C++\dgdecnv\DGDecodeNV\x32\release\dgdecodenv.dll")
loadplugin("D:\Don\Programming\C++\Avisynth filters\tritical stuff\TIVTC\tivtc.dll")
dgsource("G:\Streams\MPG\Pulldown\lainvob.dgi",fieldop=0)
dg=tfm(PP=0).subtitle("DG")
#tdecimate()

stackhorizontal(dg,manolito)

Now load the script in VirtualDub and step linearly from the beginning. There will be lots of laced frames seen in the manolito version. Here are some notable locations:

548
606
714
730-840 birds are interlaced
876 lacing on scene change
900 lacing on scene change
933- lots of laced frames from here

Don't do random access because ffms2 doesn't do it correctly and my numbers above are for linear play from the beginning.

Any reasonable person would reject the manolito method. It's way worse than "not optimal". As several have claimed, the correct way to handle material like this is to honor the pulldown and then do IVTC using (for example) TFM/TDecimate.

[manolito]

Now load the script in VirtualDub and step linearly from the beginning. There will be lots of laced frames seen in the manolito version.

You don't get it. I DO NOT watch my movies by stepping through the frames. It is meaningless.

Of course my conversion has interlaced frames. When I make a DVD the common recommendation is to keep interlaced sources interlaced and let the TV handle the deinterlacing.

I showed the 2 versions of the clip to a friend without telling him what to look for (he is a journalist for a public TV broadcaster). He could not tell which version was which.

I think we can stop this here...

[videoh]

I think we can stop this here...
No way, Jose.

Of course my conversion has interlaced frames. Translation: Of course my method sucks.

DG derangement is a terrible thing. I will pray for you.

[TheFluff]

You don't get it. I DO NOT watch my movies by stepping through the frames. It is meaningless.

Of course my conversion has interlaced frames. When I make a DVD the common recommendation is to keep interlaced sources interlaced and let the TV handle the deinterlacing.

I showed the 2 versions of the clip to a friend without telling him what to look for (he is a journalist for a public TV broadcaster). He could not tell which version was which.

I think we can stop this here...

If you want interlaced output then why on earth would you not honor pulldown flags? :confused:

[videoh]

Echoing TheFluff, if you are "making a DVD" why is any conversion necessary at all? The lainvob.vob clip is already a DVD sample.

People want to make film-rate MKVs, etc. Your script fails badly for that. The progressive frames are waiting there, begging to be extracted.

a journalist for a public TV broadcaster That explains everything. Fake news!

[manolito]

If you want interlaced output then why on earth would you not honor pulldown flags? :confused:
I already said this repeatedly:

I use a GUI for my conversions. For DVD conversions I use AVStoDVD. AVStoDVD analyzes the source using MediaInfo. For the clip in question MediaInfo DOES NOT report pulldown flags, it reports 29.97 interlaced TFF instead. And if AVStoDVD thinks that there are no pulldown flags then it will NOT try to honor them.

To save the reputation of AVStoDVD I have to add that whenever it encounters an MPEG2 or VOB source it strongly suggests to index the source with DGIndex. And DGIndex does honor pulldown flags by default. I just have my reasons to avoid DG software as much as I can...

[videoh]

I just have my reasons to avoid DG software as much as I can... As I said, DG derangement is a terrible thing. Care to share those reasons with us?

Don't forget that we now have other source filters that do the right thing by honoring pulldown. I'm happy to know that DG tools have blazed the trail!

Did you have any comment on my earlier questions? For example, how would you handle a transport stream with irregular frame repeats?

[TheFluff]

Actually, I just realized that if you do this:
Video = FFVideoSource("F:\Download\lainvob.vob", track=-1, fpsnum=2997, fpsden=100, colorspace="YV12", seekmode=2)
What you're effectively doing is just applying pulldown. 60i sections will be left as they are, while 24p sections with RFF flags will get one of every 4 frames repeated, resulting in 30p. So you've effectively gotten the same result as honoring pulldown flags would have, except it's gonna look more stutter-y than normal soft pulldown would have, because instead of having the usual 3:2 cadence where every other frame gets an extra field, every fourth frame gets two extra fields instead. You put all of the catch-up you've accumulated over four frames in one place instead of spreading it out.

So yeah, don't do that. I still think ignoring pulldown flags is the best default and gives the best result in general if your goal is to encode progressive, but for your use case I don't see how it makes any sense.

e: Stephen got there first

[manolito]

Don't forget that we now have other source filters that do the right thing by honoring pulldown.
We have just one, and this is the latest HolyWu build of LSMASH. ffms2 and DSS2Mod are not following your lead so far.

Did you have any comment on my earlier questions? For example, how would you handle a transport stream with irregular frame repeats?
I did ask several times for a link to such a file. No result...

Care to share those reasons with us?
Bad Karma

[manolito]

What you're effectively doing is just applying pulldown.

Yes, I do know this. I repeat frames instead of fields, and most folks agree that repeating fields should give smoother motion. Being from PAL land I always found that even standard 3:2 NTSC pulldown results in ugly motion judder, it's just that people from NTSC land are so used to it that they don't even notice it any more.

[TheFluff]

I'd say what most people probably do around here is encode progressive content as progressive without duplicate frames, actually. Either by ignoring pulldown flags or by applying IVTC. They don't actually make interlaced displays anymore, y'know?

[Groucho2004]

They don't actually make interlaced displays anymore, y'know?Yes, but manolito is quite passionate about his good old CRT TV (as well as a non-SSE2 CPU). To each his own.

[manolito]

Groucho, you are absolutely correct. Keeping my old hardware I do hardly sacrifice anything, and I keep my carbon dioxide footprint low. Sustainability, repair instead of throwing things into the trash bin...

//OT//
I saw that you have compiled a ColorMatrix 2.6 build which I could use for UHD sources. It just does not like my non-SSE2 CPU. Any chance for a build which does not require SSE2?

It is not really too important because my ancient non-SSE2 computer will hardly see any UHD source files. But I like to have consistent tool versions on all of my machines.
//End OT//

[Groucho2004]

Any chance for a build which does not require SSE2?No problem.

[Richard1485]

Being from PAL land I always found that even standard 3:2 NTSC pulldown results in ugly motion judder, it's just that people from NTSC land are so used to it that they don't even notice it any more.

Yeah, but the judder caused by duplicating every fourth frame is noticeably worse than the result of 2:3 pulldown. Being accustomed to the latter doesn't make the former any less annoying.

[TheFluff]

Groucho, you are absolutely correct. Keeping my old hardware I do hardly sacrifice anything, and I keep my carbon dioxide footprint low. Sustainability, repair instead of throwing things into the trash bin...

I don't know much about CO2 emissions caused by the manufacture of TFT screens, but considering the German insistence on burning coal for power generation, the energy savings you would've had by now if you had switched to a TFT panel with a LED backlight 10 years ago would probably have made up for the manufacturing emissions several times over... You could've bought used, too.

Like, yeah, I can absolutely sympathize with repairing things, I do it myself a lot, but come on. Don't pretend this is anything other than obstinacy at this point.

[real.finder]

Groucho, you are absolutely correct. Keeping my old hardware I do hardly sacrifice anything, and I keep my carbon dioxide footprint low. Sustainability, repair instead of throwing things into the trash bin...


Correct me if I am wrong, but isn't the old hardware (especially old CPU and GPU) need more power to do the same operation that can be done in new hardware? which mean more energy and heat which mean again more carbon dioxide footprint?

[Groucho2004]

Correct me if I am wrong, but isn't the old hardware (especially old CPU and GPU) need more power to do the same operation that can be done in new hardware? which mean more energy and heat which mean again more carbon dioxide footprint?Yes, especially a CRT consumes a lot more power than a modern LCD/LED screen as TheFluff already mentioned.

[MeteorRain]

Yes, Core and Nehalem burns more coal to run. Nehalem idles at 100w while i7-9700k idles at 40w. When they are loaded they use more electric.

[Groucho2004]

Yes, Core and Nehalem burns more coal to run. Nehalem idles at 100w while i7-9700k idles at 40w. When they are loaded they use more electric.manolito uses a P3 Coppermine from around 2000 (130 nm manufacturing process).

[real.finder]

Yes, especially a CRT consumes a lot more power than a modern LCD/LED screen as TheFluff already mentioned.

yes but not like old cpu vs new one, old CRT will need around 100 W but LCD need maybe around 50 W, but if you use some old cpu (non-SSE2) to did some filtering it will use around 100 W for many Hours for whole video, but same filter and video in Modern cpu (even sandy bridge) will be only few minutes with that 100 W

[Groucho2004]

yes but not like old cpu vs new one, old CRT will need around 100 W but LCD need maybe around 50 WIt depends, I guess. My old 32 inch Sony CRT used about 130 W, my current Panasonic 42 inch LCD (which is already 7 years old) 35 W.

[Groucho2004]

Coppermine is a 180 nm processor (wiki (https://en.wikipedia.org/wiki/List_of_Intel_Pentium_III_microprocessors#%22Coppermine%22_(180_nm))).Ooops, got that mixed up with Tualatin methinks.

[Atak_Snajpera]

on a modern 8x 5 GHz 95 W processor
Haha! More like 300+ W.

[StainlessS]

To Whom it may concern,

# LSMASHSource_x86_20200118(HolyWu).dll

LSMASHVideoSource("...") # Access Violation, it dont like the ellpisis, [also bad with 1 or 2 dots]

[LigH]

Who ever would test it without a proper filename :D ... in the DVD Studio I worked for, long ago, we called this class of tests "janitor tests", because a janitor would have no clue which kind of parameter is sensible. Today it would be called "fuzzing", I believe :p

[StainlessS]

Thanx HolyWu.
Of course '...' filename should never be used, but Access Violations should also never occur.
[I just checked AviSource("...") just to see if same happened, nope, no A.V. all OK].

Ah LigH, reminiscing about his days as a janitor, such a dreamer :)
[Fuzzing, also User Friendly, or Idiot Proofing(my favourite)]

EDIT: Fuzzing, automated providing of a mixture of random inputs intention to catch problems, [did not know that, not quite Idiot Proofing]:- https://en.wikipedia.org/wiki/Fuzzing

[hello_hello]

https://github.com/HolyWu/L-SMASH-Works/releases/download/20200207/L-SMASH-Works_20200207.7z
LWLibav: Restore the functionality of opening index file as source.

Awesome! Thank you!

[dREV]

https://github.com/HolyWu/L-SMASH-Works/releases/download/20200207/L-SMASH-Works_20200207.7z


Update to FFmpeg-20200207-343ccfc.
LWLibav: Restore the functionality of opening index file as source.


:eek: It's working on MeGUI's One-Click! Testing it out and so far the index file size is waaaay smaller too.

Thanks for including it back. :D

[FranceBB]

https://github.com/HolyWu/L-SMASH-Works/releases/download/20200207/L-SMASH-Works_20200207.7z


Update to FFmpeg-20200207-343ccfc.
LWLibav: Now only certain frames are marked as interlaced internally when enable repeat control. Although it had no effect on the decoded pictures whether the stream contain repeat flags or not, it did affect the value of frame property _FieldBased in VapourSynth for streams containing repeat flags.
LWLibav: Improve the logic of frame rate deduction.
LWLibav: Restore the functionality of opening index file as source.
AviSynth/LibavSMASH: Fix crash when open an invalid file path.


Thank you for the new version! :)

[Taurus]

@HolyWu
As always: :thanks:
A big Thank You from me.

[Nico8583]

Hi, the same DLL is used for both AviSynth and VapourSynth ? Thank you.

[poisondeathray]

Hi, the same DLL is used for both AviSynth and VapourSynth ? Thank you.

Yes , same dll

[Nico8583]

Yes , same dll
Thank you, I'll try it !