L-SMASH Source

[kedautinh12]

L-SMASH-Works 20230611
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases


Fixed _EncodedFrameTop and _EncodedFrameTop, close #32. Changed behavior - they are showed only when there are frames to be repeated.
Fixed _FieldBased when repeat is not false.
Used libraries:

FFmpeg d78bffb.
l-smash 2c0696c.
obuparse 055be27.
zlib 1.2.13.
dav1d 1.2.1.
libxml2 v2.11.4.
nv-codec-headers n12.0.16.0.
xxHash v0.8.1.
mfx_dispatch 5a3f178.

[flossy_cake]

Unfortunately not fixed in latest version:

Here is a clip which LWlibavVideoSource cannot seem to play properly: https://drive.google.com/file/d/1lHB_EPFEKAQEiKab5LlYq0EyY9OOObeT/view?usp=share_link


file = "480i multiple cadences.mkv"

AudioDub(LWlibavVideoSource(file, repeat=true), LWLibavAudioSource(file, stream_index=-1))

ScriptClip(last, """SubTitle(String(propGetAny(last, "_FieldBased")))""")


https://i.ibb.co/3yd8PbB/1.png



However I have done rips of my own physical copy NTSC dvd's using MakeMKV and those work fine with repeat=true so I'm thinking it's some issue with the software that was used to create the MKV file. In all cases it's MPEG2 video stream remux.

Another test clip same problem: https://rationalqm.us/misc/lainvob.vob

[tebasuna51]

Please support AviSynth+ r4001 (https://forum.doom9.org/showthread.php?p=1989323#post1989323) including the audio channel mask.

[kedautinh12]

Report here will be faster
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues

[tebasuna51]

Report here will be faster


Done https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/35

[tebasuna51]

A new version to test in https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/35

For me work fine with some samples ac3, eac3 and dts.

[kedautinh12]

L-SMASH-Works 20230716
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases

AviSynth: set audio property Channel Mask (#35).
Used libraries:

FFmpeg e62f344.
l-smash 2c0696c.
obuparse f40598f.
zlib 1.2.13.
dav1d 1.2.1.
libxml2 v2.11.4.
nv-codec-headers n12.0.16.0.
xxHash v0.8.1.
mfx_dispatch 5a3f178.

[almosely]

Just wanted to report that I have updated from L-SMASH-Works (2022-11-09) to the newest and it did not work for me anymore. I tried to play a youtube video from 2017 ...

LWLibavVideoSource("Federer.vs.Nadal.720p.HD.Australian.Open.Final.2017.mkv", format="YUV420P8", prefer_hw=1)

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 7 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 7 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 3 h 18 min
Bit rate : 3 778 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 (60000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.068
Stream size : 5.24 GiB (96%)
Default : Yes
Forced : No

... but it stuttered and had pixel errors all over. Hardware is GeForce GTX 660 TI and Core i7-3770. Windows 10.

Then I tried backwards until L-SMASH-Works (2023-05-07) is working for me again. So 06 and 07 aren't working anymore. I am using the newest AVS+ 64 and my C++ Runtimes are up to date too. Just my 2ct.

[kedautinh12]

Report here will be faster
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues

[FranceBB]

Also keep in mind that hardware accelerated decoding has always been a hit and miss.
If you want something reliable, software decoding is the way to go (i.e don't specify prefer_hw=1).

[almosely]

Never had any problems like that with L-Smash or DGDecNV in the last 10 years - so no hit-n-miss for me. Encoding without hw-acc-decoding is much slower.

[FranceBB]

Wow, I'm very surprised to see that it's actually stable even with videos with ref larger than 4.
Anyway, as kedautinh12 rightly pointed out, asd-g is the one keeping the development ongoing for LWLibav.
He generally listens to user, but he prefers to keep track of issues through GitHub rather than through posts on Doom9.
Please report the regression on GitHub by opening an issue here: https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues
I'm sure he'll take a look at it. :)

[almosely]

Already done before your two posts ;-) And he looked at it.

[Atak_Snajpera]

Never had any problems like that with L-Smash or DGDecNV in the last 10 years - so no hit-n-miss for me. Encoding without hw-acc-decoding is much slower.

Have you done some real tests?
Encoding process for example x265 will consume ~95% of CPU time while decoding rest ~5%.

I wouldn't say that extra 5% will give you much faster encoding.

[almosely]

Real tests? I am encoding almost daily for over 20 years. Of course I am talking out of experience. With AVS I started with xvid, then changed to x264 and since a few years to x265. A few days ago I was encoding a 1080p video (usually I encode 720p). With software decoding: 6 fps. With hardware decoding 9 fps. So 50% faster in that usecase ...

[Atak_Snajpera]

So you encoded exactly the same video file twice right?

[almosely]

So, why is that you think everybody else is doing it wrong? ...

[almosely]

So, I did some tests, even reverted to earlier AVS and plugin-versions from that encoding-time, but sadly I cannot reproduce that penomenon anymore. I do not have that particular file anymore.

But I do remember, I started an encode with hw-decoding on (as usual). The estimated encoding time has been about 8 hours and the fps had been around 9. That did not change after having a look at that estimation a few hours later. The next day that encode ended somewhere after approx. 6 hours with an encoder crash. That happens sometimes, rarely, and usually changing a bit of the parameters of requestlinear solves that issue. So I wanted to get that encode finished correctly but did not want to risk another crash. That's why I gave hw-decoding switched off a try. I did not change anything else. Then the estimated encoding time was something about 12 hours and the fps were about 6 and that was true after the job finished - it crashed too, but after approx. 11 hours. So, hw on/off wasn't the reason fot that. Then I had to start a third encode for the last minutes to glue the peaces together in the end. Those crashes started with AVS+ (when prefetch(x,y) was introduced) and I have no idea what's the reason for that. There wasn't running anything in the background that time.

And I remember that I made some tests some years ago with hw-dec on/off and everytime hw-dec on has been faster, a bit, not as much as with that particular file, but faster, without any cost in power (watts). So I use hw-dec on every time.

[Atak_Snajpera]

So, why is that you think everybody else is doing it wrong? ...

Placebo effect

source AVC blu-ray 1080p (no avisynth filters!)
https://i.postimg.cc/RVtMFv0R/Untitled-1.png

source HEVC HDR10 UHD 2160p (no avisynth filters!)
https://i.postimg.cc/W158DFXL/Untitled-2.png

If you use software encoder x265 (with default medium preset) bottleneck is so huge that hardware decoding does not help.
Basically decoder most of time is sitting idle and waiting for requests from encoding process.

In my case decoding process was using less than 5% of CPU time.

I really do not care about that few percent and prefer much stable CPU decoding.

[almosely]

Come on ... You are one person out of billions. The world is bigger than your imagination and experience. What is the meaning of compairing completely different hardware, yours and mine?

I am not using any default presets.

"In my case" and "I really do not care about" is the whole point of this.

I just wanted to report an error within the last two updates, no more.

[Atak_Snajpera]

That's why I asked if you did a REAL tests. Your claim that hardware decoding gives huge speed boost in encoding time is a lie.
If you do some filtering for example denoising/tonemapping in avisynth then you won't even get those 5% because even more time will be used by your cpu.
Hardware decoding is a placebo effect in this case. Deal with it.

[almosely]

You are rude, disrespectful, short-sighted, conceited and unreasonable. I won't exchange another word with you.

[LigH]

Nevertheless, he is right. Compared to the efforts of a video encoder, decoding with or with out GPU support is a negligible difference.

Run your scripts through AVSMeter, compare these "benchmark" durations with the encoding duration: That ratio should tell you where the real bottleneck is.

[real.finder]

even if Atak_Snajpera is right, I think it's better to have both option just in case, also I think hardware decoder can help with weak cpu cases like laptop or low end or old hardware

[guest]

You are rude, disrespectful, short-sighted, conceited and unreasonable. I won't exchange another word with you.

So now we have some other opinions...

Either way, Atak has the knack of coming across like that, so props for you saying so, not many do !!!

[kedautinh12]

So now we have some other opinions...

Either way, Atak has the knack of coming across like that, so props for you saying so, not many do !!!

Long time to see, old man :D

[guest]

Long time to see, old man :D

How did you find me :D

Yep, keeping an Ultra-low profile these days, kinda lost interest :(

You're not posting as often as you used to, either.

[tebasuna51]

You are rude, disrespectful, short-sighted, conceited and unreasonable. I won't exchange another word with you.

Please guys remember the forum rule:
4) Be nice to each other and respect the moderator. Profanity and insults will not be tolerated. If you have a problem with another member turn to the respective moderator and if the moderator can't help you send a private message to Doom9.

There are 2 questions here:
1) Save time using GPU decode? A little but yes.
2) Last L-SMASH-Works-20230716 have a bug? I think so, then almosely is right and we can say thanks for the report.

1) I have a cheap Nvidia GeForce GT 1030 and running AvsMeter you can see the GPU decode is slow than with my CPU:
AviSynth+ 3.7.3 (r4003, 3.7, x86_64) (3.7.3.0)
Over "Roger Federer v Rafael Nadal Full Match Australian Open 2017 Final.mp4":
Number of frames: 304982
Length (hh:mm:ss.ms): 03:23:19.280
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25/1)
Colorspace: i420
06/07/2023 NVIDIA GeForce GT1030
FFVideoSource DgSource 249
-------------------- ---------------------
Frames processed: 304982 (0 - 304981) 304982 (0 - 304981)
FPS (min | max | average): 281.3 | 1807 | 960.5 149.9 | 489.9 | 474.5
Process memory usage (max): 190 MiB 335 MiB
Thread count: 25 17
CPU usage (average): 74.5% 8.6%

GPU usage (average): 2% 57%
VPU usage (average): 0% 74%
GPU memory usage: 402 MiB 459 MiB
GPU Power Consumption (average): 13.6 W 15.9 W

Time (elapsed): 00:05:17.510 00:10:42.809

But when I recode the file with x264 (crf 20) the DgSource avs is fast than FFVideoSource with the same stats (see log files):

DgSource encoded 304982 frames, 59.71 fps, 4513.20 kb/s (5107 sec)
FFVideoSource encoded 304982 frames, 57.89 fps, 4513.20 kb/s (5269 sec)
It is only 2:42 over 1:27:49 encode but maybe with a better GPU can go until the 5:17 used by the CPU decoder.

2) But when I test L-SMASH-Works-20230716 I see than there are something wrong:
LSMASHVideoSource 15/07/2023
----------------------------------
prefer_hw=0 prefer_hw=1
--------------------- ---------------------
Frames processed: 304982 (0 - 304981) 304982 (0 - 304981)
FPS (min | max | average): 45.87 | 2711 | 89.62 26.73 | 580.8 | 80.34
Process memory usage (max): 236 MiB 225 MiB
Thread count: 26 16
CPU usage (average): 19.6% 7.6%

GPU usage (average): 2% 15%
VPU usage (average): 0% 23%
GPU memory usage: 373 MiB 399 MiB
GPU Power Consumption (average): 13.7 W 14.2 W

Time (elapsed): 00:56:42.960 01:03:16.199
The full encode (prefer_hw=1) have different stats (see the log) and:
LSMASHVideoSource encoded 304982 frames, 44.84 fps, 5384.67 kb/s (6801 sec, 1:53:21)
And is wrong (https://www.sendspace.com/file/hfuk86), the prefer_hw=0 play fine and with same stats than both before(slow than DgSource).

[kedautinh12]

Try test ver
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/36#issuecomment-1665742509

[tebasuna51]

20230611 version is also wrong
20230507 work fine with prefer_hw=1
20230804 test version work fine now

[guest]

Try test ver
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/36#issuecomment-1665742509

Nice :)

And now there's a newer "test" build available.

[guest]

FYI @ tebasuna51

Originally Posted by almosely

You are rude, disrespectful, short-sighted, conceited and unreasonable. I won't exchange another word with you.

Please guys remember the forum rule:

4) Be nice to each other and respect the moderator. Profanity and insults will not be tolerated. If you have a problem with another member turn to the respective moderator and if the moderator can't help you send a private message to Doom9.

Thats all well & good, but there a handful of members that can come across as being rude, just like @ almosely mentioned, and generally nobody says anything.

So, I'm on his side, and the member targeted, is one of the rude ones.

I've had first hand experience.

[Selur]

Is there a separate .exe that could create the .lwi cache file?

[qyot27]

Is there a separate .exe that could create the .lwi cache file?
One exists in this patch:
https://github.com/afontenot/L-SMASH-Works/commit/522f5575e775deda382a3709883a3e85b13d8331

It hasn't been submitted upstream, though.

[kedautinh12]

L-SMASH-Works 20230806 1129.0.1.0
#36 - reverted HomeOfAviSynthPlusEvolution/FFmpeg@402d98c

Used libraries:

FFmpeg e521879.
l-smash 2c0696c.
obuparse f40598f.
zlib 1.2.13.
dav1d 1.2.1.
libxml2 v2.11.4.
nv-codec-headers n12.0.16.0.
xxHash v0.8.1.
mfx_dispatch 5a3f178.
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases/tag/1129.0.1.0

[tebasuna51]

I make a test with that last version L-SMASH-Works 20230806 1129.0.1.0 and the same file in my previous post (https://forum.doom9.org/showthread.php?p=1990413#post1990413)

The x264 stats and bitrate are the same than DgSource or FFVideoSource using prefer_hw=1 or not, but are slow:
DgSource("C:\tmp\Test.dgi") encoded with x264 -crf 20 at 59,71 fps 5107,720 s. = 1:25:07.720
FFVideoSource("C:\tmp\Test.mp4") encoded with x264 -crf 20 at 57,89 fps 5268,301 s. = 1:27:48.301
LSMASHVideoSource("..", prefer_hw=1) encoded with x264 -crf 20 at 49.06 fps 6216,510 s. = 1:43:36.510
LSMASHVideoSource("C:\tmp\Test.mp4") encoded with x264 -crf 20 at 48.92 fps 6234,300 s. = 1:43:54.300


And using AvsMeter the decoding time is still the same than show in point 2) of my previous post, near 1 h. when DgSource/FFVideoSource are 10/5 m.
At beginning AvsMeter show values like DgSource, with hw=1, or FFVideoSource, but after the CPU/GPU usage go to low values and finish with that big time.
Maybe someone can test this behaviour.

[StvG]

I make a test with that last version L-SMASH-Works 20230806 1129.0.1.0 and the same file in my previous post (https://forum.doom9.org/showthread.php?p=1990413#post1990413)

The x264 stats and bitrate are the same than DgSource or FFVideoSource using prefer_hw=1 or not, but are slow:
DgSource("C:\tmp\Test.dgi") encoded with x264 -crf 20 at 59,71 fps 5107,720 s. = 1:25:07.720
FFVideoSource("C:\tmp\Test.mp4") encoded with x264 -crf 20 at 57,89 fps 5268,301 s. = 1:27:48.301
LSMASHVideoSource("..", prefer_hw=1) encoded with x264 -crf 20 at 49.06 fps 6216,510 s. = 1:43:36.510
LSMASHVideoSource("C:\tmp\Test.mp4") encoded with x264 -crf 20 at 48.92 fps 6234,300 s. = 1:43:54.300


And using AvsMeter the decoding time is still the same than show in point 2) of my previous post, near 1 h. when DgSource/FFVideoSource are 10/5 m.
At beginning AvsMeter show values like DgSource, with hw=1, or FFVideoSource, but after the CPU/GPU usage go to low values and finish with that big time.
Maybe someone can test this behaviour.

LSMASHVideoSource is the only function from the listed that doesn't create index.

What about testing LWLibavVideoSource?

[tebasuna51]

Despite the recommended method LSMASHVideoSource to open a .mp4 seems don't work better.
Using LWLibavVideoSource, and after a few seconds (<10) creating the .lwi, is the faster method with same stats and bitrate than others:
DgSource("C:\tmp\Test.dgi") encoded with x264 -crf 20 at 59.71 fps 5107,720 s. = 1:25:07.720
FFVideoSource("C:\tmp\Test.mp4") encoded with x264 -crf 20 at 57.89 fps 5268,301 s. = 1:27:48.301
LWLibavVideoSource("..", prefer_hw=1) encoded with x264 -crf 20 at 60.11 fps 5073,731 s. = 1:24:33.731
LWLibavVideoSource("C:\tmp\Test.mp4") encoded with x264 -crf 20 at 57.93 fps 5264,664 s. = 1:27:44.664

Fast using GPU or only CPU, the problem with AvsMeter is gone and is fast decoding with GPU:

LWLibavVideoSource
----------------------------------
prefer_hw=1 prefer_hw=0
--------------------- ---------------------
304982 (0 - 304981) 304982 (0 - 304981)
126.0 | 615.7 | 577.0 247.8 | 2420 | 958.8
168 MiB 213 MiB
16 26
7.0% 76.7%

65% 1%
88% 0%
756 MiB 664 MiB
16.3 W 13.7 W

00:08:48.532 00:05:18.073

For me LSMASHVideoSource can't be recommended at all.

[StvG]

Despite the recommended method LSMASHVideoSource to open a .mp4 seems don't work better.
Using LWLibavVideoSource, and after a few seconds (<10) creating the .lwi, is the faster method with same stats and bitrate than others:
DgSource("C:\tmp\Test.dgi") encoded with x264 -crf 20 at 59.71 fps 5107,720 s. = 1:25:07.720
FFVideoSource("C:\tmp\Test.mp4") encoded with x264 -crf 20 at 57.89 fps 5268,301 s. = 1:27:48.301
LWLibavVideoSource("..", prefer_hw=1) encoded with x264 -crf 20 at 60.11 fps 5073,731 s. = 1:24:33.731
LWLibavVideoSource("C:\tmp\Test.mp4") encoded with x264 -crf 20 at 57.93 fps 5264,664 s. = 1:27:44.664

Fast using GPU or only CPU, the problem with AvsMeter is gone and is fast decoding with GPU:

LWLibavVideoSource
----------------------------------
prefer_hw=1 prefer_hw=0
--------------------- ---------------------
304982 (0 - 304981) 304982 (0 - 304981)
126.0 | 615.7 | 577.0 247.8 | 2420 | 958.8
168 MiB 213 MiB
16 26
7.0% 76.7%

65% 1%
88% 0%
756 MiB 664 MiB
16.3 W 13.7 W

00:08:48.532 00:05:18.073

For me LSMASHVideoSource can't be recommended at all.

Thanks for sharing. What's the used ffms2 version?

[tebasuna51]

Your ffms2_r1363 (https://forum.doom9.org/showthread.php?p=1989259#post1989259) 06/07/2023

BTW the differences between
FFVideoSource("C:\tmp\Test.mp4") encoded with x264 -crf 20 at 57.89 fps 5268,301 s. = 1:27:48.301
LWLibavVideoSource("C:\tmp\Test.mp4") encoded with x264 -crf 20 at 57.93 fps 5264,664 s. = 1:27:44.664
aren't important and can be for other run process (I try run alone but not all can be controlled)

The AvsMeter is best (5:17.510) for FFVideoSource, (5:18.073) LWLibavVideoSource.

The best, only a few, option seems LWLibavVideoSource("..", prefer_hw=1) with a good GPU.

[kedautinh12]

L-SMASH-Works 20231003 1141.0.0.0
Added support for BGR0.
The last requested frame is used to set _FieldBased (repeat=true).
Added frame property _AbsoluteTime.
Used libraries:

FFmpeg b4f9170.
l-smash 2c0696c.
obuparse f40598f.
zlib 1.3.
dav1d 1.2.1.
libxml2 v2.11.5.
nv-codec-headers n12.0.16.0.
xxHash v0.8.2.
mfx_dispatch 5a3f178.
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases

[FranceBB]

Thank you asd-g, as always, for everything.
Over the years LWLibav has become my de facto indexer for pretty much everything.
The amount of care you put towards fixing the issues that are reported and implementing the features that are requested has been hugely appreciated.
Thank you on behalf of all my colleagues too! :)

[kedautinh12]

L-SMASH-Works 20231010 1144.0.0.0
Fixed _AbsoluteTime start_time.
Fixed raw bitstreams fps (FFmpeg new API).
Used libraries:

FFmpeg b4f9170.
l-smash 2c0696c.
obuparse f40598f.
zlib 1.3.
dav1d 1.2.1.
libxml2 v2.11.5.
nv-codec-headers n12.0.16.0.
xxHash v0.8.2.
mfx_dispatch 5a3f178.
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases

[kedautinh12]

L-SMASH-Works 20231106 1147.0.0.0
AviSynth: reverted harmful commits about UTF-8 filenames.
Used libraries:

FFmpeg 2c85a07.
l-smash 2c0696c.
obuparse f40598f.
zlib 1.3.
dav1d 1.3.0.
libxml2 v2.11.5.
nv-codec-headers n12.1.14.0.
xxHash v0.8.2.
mfx_dispatch f6aac45.
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases

[FranceBB]

The special character names tackling shenanigan continues... xD
No but jokes aside, hopefully this is gonna be sorted once and for all.
As to the other part of the update, thank you asd as always.
I just pulled it to my test bench and I'll be testing it out after my regular cappuccino. :)

[kedautinh12]

L-SMASH-Works 20231117 1156.0.0.0
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases

[flossy_cake]

Thank you asd-g, as always, for everything.
Over the years LWLibav has become my de facto indexer for pretty much everything.
The amount of care you put towards fixing the issues that are reported and implementing the features that are requested has been hugely appreciated.
Thank you on behalf of all my colleagues too! :)

Yes I would like to echo this sentiment. Without LWLibav I don't think Avisynth would be much use for my growing DVD library. LWLibav is the only filter that seems to understands MPEG2 properly, particularly the repeat field flags and field order. It also seems highly compatible with 264 and 265, never had an issue with those, and supports 10-bit pixel formats too. Seek times are nice and quick too. I've read it's "frame accurate" too, which I don't actually know the meaning of -- does it mean current_frame can be relied on? So let's say you're trying to count frames after a scenechange or something, you can rely on knowing when you are exactly, say, 3 frames after a scenechange? I've not had any issues with this so I'm guessing it's working as intended.

The only negative thing I could say about LWLibav is the large file size of the .lwi cache files and the time it takes to generate them. I would very much like to see multithreading of the .lwi cache file creation process. That would personally benefit me the most when screening DVD's on HTPC to eliminate the sometimes lengthy wait times before video playback begins.

[FranceBB]

does it mean current_frame can be relied on? So let's say you're trying to count frames after a scenechange or something, you can rely on knowing when you are exactly, say, 3 frames after a scenechange?


That's exactly right. It won't miss frames while decoding so if you move to frame 3325, let's say, you can be absolutely confident that every time you move there it will always be frame 3325. ;)

[flossy_cake]

Don't forget about DGIndex and DGIndexNV.

Ah yes, my apologies to Donald Graft :o

From what I can tell though the required d2v index file cannot be created within an Avisynth script, so unfortunately that is a dealbreaker for me. It looks like maybe the DGIndexNV one can, but that is limited to NVidia GPUs which is also a dealbreaker even though I use an Nvidia GPU, I need my scripts to work on more than just NVidia systems.

[StvG]

... LWLibav is the only filter that seems to understands MPEG2 properly, particularly the repeat field flags and field order...

If your video is in mkv this ffms2 (https://forum.doom9.org/showthread.php?p=1993933#post1993933) is ok with MPEG2. It also adjusts the field frame prop/getparity per frame.