FFmpegSource

[hello_hello]

Originally Posted by flossy_cake

Not working for me unfortunately

I have the same issue with the 64 bit versions of ffms2_r1386 and ffms2_r1387. I haven't tested the 32 bit versions yet.

FFMS2 with audio enabled (or FFAudioSource) produces an access violation error message (AvsPmod). I assumed it was a problem relating to running Avisynth in Wine on Linux originally, but I've also tested it on Windows 11 with the same result.

[StvG]

@flossy_cake, thanks for the samples. rffmode=0 is ok but rffmode=1 gives different results than lwlibavvideosource. Have to take a look.

@hello_hello, I have no issues with the following:

FFVideoSource("test.mkv")

a=FFMS2("test.mkv", atrack=-1)
#FFAudioSource("test.mkv")
AudioDub(a)
Waveform()

You can share a sample so I can reproduce the issue.

[eac3to_mod]

Referring to the manifest method:

Originally Posted by kedautinh12

I tried with your suggestion but Megui and AvsPmod don't work with r1386

Can you please explain more what you did and what "don't work"? Thank you. I am not aware of any failures of the manifest method.

[kedautinh12]

I follow step by step in utf8.txt (the file in DGDemux) with ffms r1386. Some step like run regedit file and change name DGIndexNVutf8 manifest file to Meguiuft8 manifest (sorry i can't remember exactly file name cause i don't near the PC now) and put same folder with megui.exe. But Megui.exe don't work with ffms2 r1386 when try index file. I tried it with AVSPmod but it's don't work too. Lately, I tried this step and it's work without change name of utf8 file
https://github.com/HomeOfAviSynthPlu...ent-1807345434

[eac3to_mod]

Your link talks about the beta setting. That is not what the manifest method is all about. I'm trying to address a possible issue with the manifest method. So why tell me about the beta setting method?

Nevertheless, I will try to duplicate your issue. Can you please tell me what versions of MEGUI and ffms you'd like me to try? Thank you.

[kedautinh12]

Megui 2944 x64 don't work with ffms2 r1386 and L-SMASH-Works 20231106 1147.0.0.0 but it's work with ffms r1387 and L-SMASH-Works 20231117 1156.0.0.0

Here my Megui 2944 you can try download from offical page but it's only work with avs+ 3.5 and you need MeGUI AvisynthWrapper from Pinterf to work with avs+ >=3.6 while my link already have this

[eac3to_mod]

We're just not communicating. I'll try to make it super simple.

I am trying to investigate a claimed failure of the manifest method. To do that I need you to tell me (nothing more, nothing less):

1. Exactly what software to use. Don't tell me try this, try that!
2. Give me the filename that you have problems with.
3. Tell me specifically what "don't work" means. Don't tell me what works and doesn't work. Just give me the failing scenario.

Thank you for your patience. I am trying to help.

[kedautinh12]

1, Megui 2944 x64
2, file name ác quá
3, Megui same notification error with AVSPmod when try indexing with ffms r1386
https://forum.doom9.org/showthread.p...55#post1993755

I thought you will fix easily with more info

[eac3to_mod]

That's perfect my friend! Thank you.

[flossy_cake]

Originally Posted by StvG

@flossy_cake, thanks for the samples. rffmode=0 is ok

rffmode=0 in my experience is not usable with NTSC DVDs containing repeat field flags either. It seems the only way to play back NTSC DVDs which use repeat fields flags is to obey those flags. DG talks about it here:

Originally Posted by https://www.rationalqm.us/dgmpgdec/DGIndexManual.html#FieldOp

Ignore Pulldown Flags - The pulldown flags are ignored. This allows one to obtain the raw encoded MPEG pictures, with no repeated fields. However, because repeated fields intended for display are ignored and not displayed, the resulting frame rate may differ from the source frame rate. It may even vary throughout the clip, due to irregular patterns of pulldown flags. If the pulldown is irregular, use of this option will cause the audio-video sync to change at different parts of the clip, and most likely sync will not be acceptable. This option is mostly intended for power users, who would use it as a diagnostic aid for inspecting the encoded MPEG pictures. Although this option ignores the flags, they are still stored in the D2V file although DGDecode will also ignore them.

Here is a longer clip from an NTSC DVD with repeat field flags where you should see the issue -- it wasn't obvious on the previous Lain clip as there weren't any audio cues correlating to anything on screen, but it was likely playing the video at the wrong rate due to ignorance of repeat field flags. If you leave the video playing for about 1 minute after the intro it should be out of sync by then. I was using:

video = FFVideoSource(clip, rffmode=0)
audio = FFAudioSource(clip)
AudioDub(video, audio)

[flossy_cake]

This may help with debugging... I saw Lwlibav includes the frame properties _EncodedFrameTop and _EncodedFrameBottom which say which source frame was used to generate the top and bottom fields of the current_frame.

Take this frame for example:



It says the top field of this frame was from frame 2475 and bottom field was from 2476. 2475 comes before 2476 so it means this particular frame should be top field first. I suspect the issue is that occasionally FFMS2 is getting this wrong and puts in the wrong location. But FFMS doesn't populate any frame properties from this clip. I looked at FFInfo() but it didn't show more useful info.

[kedautinh12]

I remember ffms2 already had frame properties

[flossy_cake]

Originally Posted by kedautinh12

I remember ffms2 already had frame properties

Sorry yes, StvG's version does -- the _FieldBased property:

_FieldBased   
0=frame based (progressive), 1=bottom field first, 2=top field first

There is also

GetParity (clip, int n)
Returns true if frame n is top field first of frame-based clip

Comparison LWLibAV vs FFMS: https://drive.google.com/u/0/uc?id=1...xport=download



Script used to render the above clip:

file = "c:\S01E02_cut.mkv"    # https://drive.google.com/u/0/uc?id=1QaVeLqnl0oOlclrb89O9NrkcWDGvKpzK&export=download

lwlav = LWLibavVideoSource(file, repeat=true)
lwlav = lwlav.Trim(938, 1042) ++ lwlav.Trim(2606, 2684) ++ lwlav.Trim(2779,2915)
lwlav = lwlav.ScriptClip("""	
	if (propGetAny("_FieldBased")==0){fb="progressive"}
	if (propGetAny("_FieldBased")==1){fb="BFF"}
	if (propGetAny("_FieldBased")==2){fb="TFF"}
	if (GetParity(current_frame)==true){gp="TFF"}
	if (GetParity(current_frame)==false){gp="BFF"}
	SubTitle("Correct" + "\n"
	\		+ "_Fieldbased: " + fb + "\n"
	\		+ "GetParity(): " + gp
	\		, align=5, text_color=$00FF00, lsp=0, size=30)
	\ .SubTitle("LWLibavVideoSource(file, repeat=true)", size=30)
	\ """)
lwlav = lwlav.Bob()

ffvs = FFVideoSource(file, rffmode=1)
ffvs = ffvs.Trim(938, 1042) ++ ffvs.Trim(2606, 2684) ++ ffvs.Trim(2779,2915)
ffvs = ffvs.ScriptClip("""
	if (propGetAny("_FieldBased")==0){fb="progressive"}
	if (propGetAny("_FieldBased")==1){fb="BFF"}
	if (propGetAny("_FieldBased")==2){fb="TFF"}
	if (GetParity(current_frame)==true){gp="TFF"}
	if (GetParity(current_frame)==false){gp="BFF"}	
	SubTitle("Incorrect" + "\n"
	\		+ "_Fieldbased: " + fb + "\n"
	\		+ "GetParity(): " + gp
	\		, align=5, text_color=$FF0000, lsp=0, size=30)
	\ .SubTitle("FFVideoSource(file, rffmode=1)", size=30)	
	\  """)
ffvs = ffvs.Bob()

StackHorizontal(lwlav, ffvs)

__________________________________________________________________________

P.S I deleted my previous 2x2 tiled comparison video as it was wrong because according to GetParity():

FFMS2(rffmode=1)             # some frames are TFF, others BFF
FFMS2(rffmode=1).AssumeTFF() # all frames TFF
FFMS2(rffmode=1).AssumeBFF() # all frames BFF

So my comparison script was wrong there, please ignore that (I've deleted it).

I suppose it's still useful for showing that FFMS2(rffmode=1).AssumeBFF() doesn't resolve the issue since doing a Bob() on that still shows frames presented in the wrong order.

[flossy_cake]

By the way it seems the _FieldBased prop is unreliable in both LWLibav & FFMS2 - this frame for example is clearly not progressive despite being flagged as such:




edit: now that I look at the actual definition of FieldBased, perhaps none of the frames should be flagged as _Fieldbased=0 (progressive). Fieldbased I think is what you get after a SeparateFields() - every frame is now a single field, and this clip isn't that. Maybe it's referring to what the decoder sees internally, not really sure.

Originally Posted by http://avisynth.nl/index.php/Interlaced_fieldbased

There is a field-based flag, but contrary to what you might expect, this flag is not related to interlaced video. In fact, all video (progressive or interlaced) is frame-based, unless you use AviSynth filters to change that. There are two filter who turn frame-based video into field-based video: SeparateFields and AssumeFieldBased.

Also I tried a ScriptClip ComplementParity workaround for FFMS2 and that still produced fields in nonlinear order (visible by framestepping through the bobbed output).

Perhaps this wasn't much of an issue in the past as most people do their IVTC/deinterlacing at half rate so half the frames get thrown away anyway and that reduces or eliminates the issue.

[real.finder]

in DVD case it's kinda complicated, back then this is https://github.com/Asd-g/MPEG2DecPlu...ent-1114307244 what I see do the job in these cases, you can read all comments if you like

[StvG]

Originally Posted by flossy_cake

By the way it seems the _FieldBased prop is unreliable in both LWLibav & FFMS2 - this frame for example is clearly not progressive despite being flagged as such:




edit: now that I look at the actual definition of FieldBased, perhaps none of the frames should be flagged as _Fieldbased=0 (progressive). Fieldbased I think is what you get after a SeparateFields() - every frame is now a single field, and this clip isn't that. Maybe it's referring to what the decoder sees internally, not really sure.



Also I tried a ScriptClip ComplementParity workaround for FFMS2 and that still produced fields in nonlinear order (visible by framestepping through the bobbed output).

Perhaps this wasn't much of an issue in the past as most people do their IVTC/deinterlacing at half rate so half the frames get thrown away anyway and that reduces or eliminates the issue.

Try this version.

I probably should remove _FieldBased when rffmode > 0. The frame you showed is constructed from fields of one frame marked as interlaced (bottom first) and one frame marked as progressive.

[flossy_cake]

Originally Posted by StvG

Try this version.

Oh my gosh you bloody beauty! Rffmode 1 appears to be working perfectly, and the Avisynth parity (getparity) stays locked for the whole clip which avoids potentially confusing any downstream deint/IVTC filters. Fantastic, really happy with this.



However I must use a different filter for audio otherwise FFMS crashes with that same message I posted earlier (hello_hello having same issue it seems).

Previously I wrote that using FFAudioSource instead of FFMS2 avoided the crash, but it turns out I had a different dll version that time - v1349 according to file properties. So v1349 doesn't crash, but your two most recent betas of v1387 are both crashing. Hopefully that offers a clue. I have tried the suggestions here and here without effect.

[flossy_cake]

Originally Posted by StvG

Try this version.

Hmm, seems to crash when multithreading is enabled:

ffms2(clip, rffmode=1)  # or FFVideoSource
bob()                   # remove this line = no crash
prefetch(4)

Sidenote: must remember to delete .ffindex files before trying a new dll version otherwise the old index files will be used by the new dll, and this was creating some bugged behaviour for me.

[StvG]

Originally Posted by flossy_cake

Hmm, seems to crash when multithreading is enabled:

ffms2(clip, rffmode=1)  # or FFVideoSource
bob()                   # remove this line = no crash
prefetch(4)

Sidenote: must remember to delete .ffindex files before trying a new dll version otherwise the old index files will be used by the new dll, and this was creating some bugged behaviour for me.

I can reproduce this crash and will take a look later.

About the audio. As I wrote I cannot reproduce the issue. You can share a sample that causes the crash and the used script.

[flossy_cake]

Originally Posted by StvG

About the audio. As I wrote I cannot reproduce the issue. You can share a sample that causes the crash and the used script.

For me it's crashing on all files, eg.

file = "C:\S01E02_cut.mkv"  #https://drive.google.com/u/0/uc?id=1QaVeLqnl0oOlclrb89O9NrkcWDGvKpzK&export=download

video = FFVideoSource(file, rffmode=1)
audio = FFAudioSource(file, track=-1)
AudioDub(video, audio)

Must be something system specific - here are my installed C++ runtimes





edit: also tried moving all dlls out of /plugins/ folders leaving only ffms2