FFmpegSource

[ChaosKing]

My results for ffms2 5.0

[rgr]

What does it mean?
"Fixed all issues with FFmpeg 6.1 which is now the minimum requirement"

Can I load the avs file into "ffmpeg version 2024-02-26-git-a3ca4beeaa-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers built with gcc 12.2.0 (Rev10, Built by MSYS2 project)" ?

[LigH]

FFmpegSource contains an own core of FFmpeg (libavcodec, libavformat) to be able to read different source media formats into AviSynth. It does not matter where you load that AviSynth script into.

Version 6.1 of FFmpeg is the minimum requirement for FFmpeg sources to build the FFmpegSource AviSynth plugin with. If you don't compile it, it doesn't matter to you.

[wonkey_monkey]

Is there any way (for me, as a user) to speed up FFmpegSource audio seeking?

I'm opening some blu-ray rips (my own) with multiple DTS-MA/DTS tracks and I'm getting significant pauses, sometimes of several seconds, when jumping around in the video and hitting play in VirtuaDub2. It seems to be due to audio, because if I open the files without audio, or remove the audio track in Avisynth, the pauses disappear.

LSmashSource2 failed to open it; LibavSource2 worked and doesn't have any pauses. I've always used FFmpegSource up until now though, and it's quite a bit quicker to load initially.

[Myrsloik]

Originally Posted by wonkey_monkey

Is there any way (for me, as a user) to speed up FFmpegSource audio seeking?

I'm opening some blu-ray rips (my own) with multiple DTS-MA/DTS tracks and I'm getting significant pauses, sometimes of several seconds, when jumping around in the video and hitting play in VirtuaDub2. It seems to be due to audio, because if I open the files without audio, or remove the audio track in Avisynth, the pauses disappear.

LSmashSource2 failed to open it; LibavSource2 worked and doesn't have any pauses. I've always used FFmpegSource up until now though, and it's quite a bit quicker to load initially.

Not without extra steps, no. You can reencode the audio to flac and use either ffms2 or bestsource which will be fast.

But why are you even using this for latency sensitive previewing?

[wonkey_monkey]

Originally Posted by Myrsloik

But why are you even using this for latency sensitive previewing?

You make it sound like it's an unreasonable thing to do. It's not; LibavSource2 manages it just fine. I just thought there might be a way FFmpegSource could match it.

Edit: I don't think FFmpegSource is indexing audio properly in MKV files.

[pintcat]

I'd also love to see a 32bit version of this plugin since I'm forced to use a couple older programs which do support AVISynth, but are only availabe as 32bit/x86 making me stick to the older v2.40 of FFMS2.

[rgr]

FFMS2 (last version) can't open a file when the AviSynth script is encoded in e.g. CP-1250, not UTF.
The old version of FFMS2 (2390), LWLibavVideoSource and BestSource don't have this problem (but the latter has been indexing my file for a few minutes and there's no end in sight - but at least it works).

[StvG]

I don't know what you're referring by "newer version than r2390" but there is no newer version than r2390. The plugin from github and this from codeberg are different so they shouldn't be treated as just "older / newer".

[tebasuna51]

Of course are different versions, but your r2390 is older (2020) than 5.0 (2024) from Myrsloik.

The question is this file:

LoadPlugin("C:\Test\StvG\ffms2.dll")
FFVideoSource("C:\Ñu.mkv")

saved like ANSI or UTF8 (without BOM) work fine.

But using C:\Test\5.0\ffms2.dll only work saved as UTF8 (without BOM).
There are other differences (see the links and the ChaosKing tests #2617 and #2941) and select your preference.

[rgr]

I don't really have a choice, as I haven't found a version other than 2390 that works properly with ANSI.

[StvG]

Originally Posted by tebasuna51

Of course are different versions, but your r2390 is older (2020) than 5.0 (2024) from Myrsloik.

The question is this file:

saved like ANSI or UTF8 (without BOM) work fine.

But using C:\Test\5.0\ffms2.dll only work saved as UTF8 (without BOM).
There are other differences (see the links and the ChaosKing tests #2617 and #2941) and select your preference.

r2390 is not from 2020 - it's from 2024-03-06.

The official ffms2 doesn't handle ANSI and will not handle it until there is change in its code. If you don't see changes in the changelog about it don't expect to magically work.

[tebasuna51]

Originally Posted by StvG

r2390 is not from 2020 - it's from 2024-03-06.

You are right I mistake the folder date (2022-04 image 1) with the file date (2024-03 image 2) but still the 5.0 is newer (2024-05 image 3).

BTW the preference must be by other differences, not by not support ANSI avs files when there are free tools (notepad++) to easy change ANSI <-> UTF8 codification.

I don't know how rgr make the avs files but some tools (like MeGUI) make avs with UTF8 already.

[tebasuna51]

I don't know if is still valid the differences here:

ffms2 r2390 [StvG] StvG publicó esto 2024-03-06 06:18:34 +00:00
Differences compared to 5.0-RC2:
1 In some cases can be seek accurate while 5.0-RC2 is not
2 AviSynth: GetParity and _FieldBased are set per frame
3 AviSynth: rffmode=1 that uses every frame tff/bff
4 AviSynth: set _EncodedFrameTop and _EncodedFrameBottom (rffmode > 0)
5 AviSynth: both ANSI and UTF8 file names are supported
6 _ColorRange is set per frame
7 Supported older AviSynth+ version that doesn't have audio channel mask property

Some comments:
2 and 6) I don't know when is needed GetParity, _FieldBased and _ColorRange set per frame

7) Use Avs+ older than 3.7.3 it is not recommended at all.

5) Problem already commented

3 and 4) rffmode removed in 5.0. To evaluate the impact read the help in RC 4:

##### int rffmode = 0
Controls how RFF flags in the video stream are treated; in other words it's equivalent to the "field operation" mode switch in DVD2AVI/DGIndex.
Valid modes are:

- **0**: Ignore all flags (the default mode).
- **1**: Honor all pulldown flags.
- **2**: Equivalent to DVD2AVI's "force film" mode.

Note that using modes 1 or 2 will make `FFVideoSource` throw an error if the video stream has no RFF flags at all.
When using either of those modes, it will also make the output be assumed as CFR, disallow vertical scaling and disallow setting the output colorspace.
`FFPICT_TYPE` will also not be set as the output is a combination of several frames.
Other subtle behavior changes may also exist.

Also note that "force film" is mostly useless and only here for completeness' sake, since if your source really is safe to force film on, using mode 0 will have the exact same effect while being considerably more efficient.

1) About the seek accurate we have the ChaosKing test (image). Seems we need set seekmode = 0 (slow seek) for mpeg2.VOB (standard DVD), mpeg1.mpg and VC1.mpg. The default seems valid for other files.
The help about this parameter can be interesting:

##### int seekmode = 1
Controls how seeking is done. Mostly useful for getting uncooperative files to work.
Valid modes are:

- **-1**: Linear access without rewind; i.e. will throw an error if each successive requested frame number isn't bigger than the last one.
Only intended for opening images but might work on well with some obscure video format.
- **0**: Linear access (i.e. if you request frame `n` without having requested all frames from 0 to `n-1` in order first, all frames from 0 to `n` will have to be decoded before `n` can be delivered).
The definition of slow, but should make some formats "usable".
- **1**: Safe normal. Bases seeking decisions on the keyframe positions reported by libavformat.
- **2**: Unsafe normal. Same as mode 1, but no error will be thrown if the exact seek destination has to be guessed.
- **3**: Aggressive. Seeks in the forward direction even if no closer keyframe is known to exist. Only useful for testing and containers where libavformat doesn't report keyframes properly.

[StvG]

Originally Posted by tebasuna51

I don't know if is still valid the differences here:

Some comments:
2 and 6) I don't know when is needed GetParity, _FieldBased and _ColorRange set per frame

7) Use Avs+ older than 3.7.3 it is not recommended at all.

5) Problem already commented

3 and 4) rffmode removed in 5.0. To evaluate the impact read the help in RC 4:

2, 3, 4 - discussed, discussed and next posts.

7 - keep in mind the official ffms2 will just crash instead to give error message.

The latest official ffms2 5.0 (2024-05-28) have changes that significantly impact the decoding (https://github.com/FFMS/ffms2/pull/437). This is the main reason that I wrote that both variants shouldn't be considered as just newer/older.

[rgr]

Originally Posted by tebasuna51

I don't know if is still valid the differences here:


Some comments:
2 and 6) I don't know when is needed GetParity, _FieldBased and _ColorRange set per frame

7) Use Avs+ older than 3.7.3 it is not recommended at all.

5) Problem already commented

3 and 4) rffmode removed in 5.0. To evaluate the impact read the help in RC 4:


1) About the seek accurate we have the ChaosKing test (image). Seems we need set seekmode = 0 (slow seek) for mpeg2.VOB (standard DVD), mpeg1.mpg and VC1.mpg. The default seems valid for other files.
The help about this parameter can be interesting:

Other:
- 2390 does not set PAR for each frame separately (but rather sets it, but from the stream property, not from the frame property)
- 2390 for AVI files (captured from a DV camera) recognizes incorrect fps (50.32 or 49.68 or similar instead of 50)
- 2390 does not handle VFR correctly, but I don't think any ffms2 does

[StvG]

Originally Posted by rgr

Other:
- 2390 does not set PAR for each frame separately (but rather sets it, but from the stream property, not from the frame property)
- 2390 for AVI files (captured from a DV camera) recognizes incorrect fps (50.32 or 49.68 or similar instead of 50)
- 2390 does not handle VFR correctly, but I don't think any ffms2 does

Can you elaborate?

- PAR: can you show example of what you mean?
- AVI fps: it looks like rounding errors. Can you share short video sample with this issue?

[rgr]

- PAR
When I read an AVI file from a DV camera that is partly recorded in 4:3 and partly in 16:9, the 2390 version returns the same PAR for each frame. LWLibavVideoSource changes the PAR to the correct one for each frame, MPC also changes the aspect ratio from where the PAR changes.

- AVI (M2TS)
My mistake -- it's an M2T file. I'll give the link privately, because ffms2 has bigger problems with it anyway

- VFR
https://files.fm/u/cemhy7vrmx (upload in progress... 6 files)

[StvG]

The tebasuna51 comment you quoted is about the differences between the ffms2 version not between ffms2 and LSMASHSource/other source filter.
To be clear - the differences you wrote are between ffms2 and LSMASHSource not between the ffms2 versions.

Thanks for the samples.
You can test this version. It sets _SARxxx frames props per frame and uses more robust fps calculation.

Edit: The file you shared (M2T one) is damaged (has video corrupted packages) - https://i.ibb.co/TxCGxwTR/Untitled.png

[FranceBB]

Hey StvG, thank you for picking up ffms2 and maintaining it while Myrsloyk was away, I think everyone here appreciates what you've done during this time.
To me and plenty others your builds are now the de facto standard and main branch of ffms2.
After talking to asd-g, he introduced a new parameter in LWLibavAudioSource() which I think FFAudioSource() would also greatly benefit from.
Such a parameter is a boolean called "fill_audio_gaps" which can be set to either true or false.
What it does is basically read the PTS while indexing and - if there's a gap in the audio track - it fills it with silence so that the audio stays synced with the video and ends up having the same duration instead of being shortened (and therefore desynced) from the point of the gap onwards.
Here's the commit: https://github.com/HomeOfAviSynthPlu...d62c4fffc512a5
I tested it and it seems to be working reliably well and it could help in plenty of occasions, especially with .ts and .mxf containers in which CRC Errors are very common as there might be plenty of issues with incoming signals that are recorded, so my question is: would you be interested in adding a similar parameter/feature in FFAudioSource()?