FFmpegSource

[LigH]

Indexing will be necessary to provide random access in an AviSynth script, using closest previous GOP starts before a seek point. This is quite important if you consider multithreading, where each thread may request a different frame number, and sequential access will be improbable.

FFMS2 will not rely on the possible existence of a keyframe index chunk because not all supported media formats will contain one, so it prefers to create an own index, but only once, it will be reused each time you access the same source file. You may disable writing the cache file to disk, but FFMS2 will still need to gather positions of decoding starts, so if you don't let it write a cache file, it will need to build an index in RAM each time you process the script.

If you want to rely on an index already present in a media file, rather use a different source filter which does so (in this case, maybe QTSource, which will require QuickTime to be installed).

Furthermore, QuickTime movies should belong to the "ISO Media" container family, so the LSMASHVideoSource() filter of L-SMASH Works may be recommendable as another alternative; it will usually write an own index cache file as well, though, but might do that faster.

[RTW47]

Originally Posted by LigH

LSMASHVideoSource() filter of L-SMASH Works may be recommendable as another alternative; it will usually write an own index cache file as well, though, but might do that faster.

For lsmashvideosource() will the index always be stored inside ram, just like ffms2 with cache=false?

[LigH]

It may surprise you ... but L-SMASH Works contains a README file.

According to this one, there seems to be no cache file for the functions using the L-SMASH demultiplexer:

            LSMASHVideoSource(string source, int track = 0, int threads = 0, int seek_mode = 0, int seek_threshold = 10,
                              bool dr = false, int fpsnum = 0, int fpsden = 1, bool stacked = false, string format = "")

In contrast to the functions using libavformat as demultiplexer:

            LWLibavVideoSource(string source, int stream_index = -1, int threads = 0, bool cache = true,
                               int seek_mode = 0, int seek_threshold = 10, bool dr = false,
                               int fpsnum = 0, int fpsden = 1,
                               bool repeat = false, int dominance = 0, bool stacked = false, string format = "")

So it seems quite probable that LSMASHVideoSource() relies on media file internal index chunks. It will support only a few specific media formats, though: MP4, MOV, 3GPP

[foxyshadis]

It would be kind of nice if ffms could index on-demand for those huge files -- index up to the requested frame as frames are requested -- or in a background thread, but that means getting a developer interested, and so far no one seems to be. It would sure save time in those massive source situations.

[Myrsloik]

Originally Posted by foxyshadis

It would be kind of nice if ffms could index on-demand for those huge files -- index up to the requested frame as frames are requested -- or in a background thread, but that means getting a developer interested, and so far no one seems to be. It would sure save time in those massive source situations.

There's a huge problem with that idea. You don't know the framecount until it's too late to tell avisynth about it. That's why I never implemented it.

[mawen1250]

I've got wrong color when reading RGB24 image files (tested png and bmp) with ffms2.Source on VapourSynth.
Looks like the channels are swapped: BGR->GRB
The AviSynth's plugin works fine.

[Myrsloik]

Originally Posted by mawen1250

I've got wrong color when reading RGB24 image files (tested png and bmp) with ffms2.Source on VapourSynth.
Looks like the channels are swapped: BGR->GRB
The AviSynth's plugin works fine.

Doh, I forgot abour that detail. Use shuffleplanes to work around it until a fixed version is available.

[RTW47]

you can use ShufflePlanes() to fix output

[Myrsloik]

Now it's fixed in git. I guess there'll be another release in a week or two.

[Myrsloik]

I'm back with what I guess is kinda 2.22 rc1.

So what needs to be tested is that the functions FFmpegSource2, FFImageSource and FFCopyrightInfringement still work as expected. They're now integrated into the plugin for convenience reasons (normal users will no logner need to fidget with ffms2.avsi). Don't forget to replace ffms2.avsi or you may get unexpected results.

If someone has the patience to test all the arguments for FFmpegSource2 and FFImageSource that'd be great. I may have made a typo somewhere.

- 2.22
- avisynth: Make FFMS2 a shorter alias for FFmpegSource2 to save some typing (Myrsloik)
- avisynth: Moved all source functions in ffms2.avsi into the actual plugin (Myrsloik)
- avisynth: Use 2.6 RC API and add output support for all new colorspaces (Myrsloik)
- vapoursource: Fix swapped RGB channels bug introduced in 2.21 (Myrsloik)

[stax76]

Thanks for the update Myrsloik, I tested various things with 3 files, with one sample there is a async problem, it is a DVB capture muxed to mkv with dsmux, some info in case you have time and interest:

http://www.mediafire.com/watch/y4biq...g3vm/async.mkv

source filter which name I forgot: freeze, FAILURE
FFVideoSource: async
LWLibavVideoSource: OK
DSS: async

I posted the original TS file lately to the AviSynth+ thread:

http://forum.doom9.org/showthread.ph...64#post1723364

here is some technical info:

http://forum.doom9.org/showthread.ph...82#post1723382

It was explained there are different ways to handle things, a possible solution to achieve compatibility between tools and workflows might be agreeing to the same approach.

[videoh]

Originally Posted by stax76

FFVideoSource: async
LWLibavVideoSource: OK

Have you, or can you, compare the video output of these two frame-by-frame to determine if FFVideoSource is including or excluding extra frames at the start compared to LWLibavSource? And is the async constant or does it grow as the stream plays?

[manolito]

@stax76

FWIW I downloaded your async.mkv (it was packed into an FLV container), I also repacked your original .TS file into an MKV container using MKVMerge, and for all these source files the result was consistent:

Use DSS2Mod together with LAVFilters, ignore audio delays reported by MediaInfo if they are > 100ms, and get a result without any audio sync issues.

I tested it using AVStoDVD for MPEG2 output and also the old StaxRip version 1.1.9.0 for XviD and AVC output.


Cheers
manolito

[stax76]

Originally Posted by manolito

@stax76

FWIW I downloaded your async.mkv (it was packed into an FLV container), I also repacked your original .TS file into an MKV container using MKVMerge, and for all these source files the result was consistent:

Use DSS2Mod together with LAVFilters, ignore audio delays reported by MediaInfo if they are > 100ms, and get a result without any audio sync issues.

I tested it using AVStoDVD for MPEG2 output and also the old StaxRip version 1.1.9.0 for XviD and AVC output.


Cheers
manolito

Don't forget that DVB often has ads and errors, there could be various cut/trim points to remove ads. I had av sync problems with mkvmerge and DSS. I need something 100% reliable with cutting with possibility to retain original audio format.

[videoh]

Any chance of an answer to my query, stax76?

[stax76]

Originally Posted by videoh

Any chance of an answer to my query, stax76?

Comparing lsmash against ffms2 frame 77 is the same in the StaxRip preview and the frame count is also the same in the StaxRip preview, when I encode it's very surprising that lsmash is fine and ffms2 is not, this could be the issue a StaxRip user reported recently, I have no idea what's going on!

edit: 2.20 is fine

[stax76]

2.20 is sync, 2.21 is async, this must be the issue two StaxRip users reported:

Originally Posted by jkilez

Using the new 1.3.1.3 beta, I am getting 7 frames (300ms) of blank video added to the beginning of encoded videos causing audio sync issues. Actually the framecount stays correct (it cuts 300ms at the end), so the problem is more that the video is offset by 300ms. So far I have only had a chance to check this with an AVC source. The problem does not appear when previewing, only in the final encodes and happens regardless of output (1-pass/2-pass, Xvid/x264, AVI/MKV, AC3/MP3/None).

The problem appears to be with the ffms2 indexer that was updated. If I replace the /Apps/Plugins/ffms2 directory with the version that came with 1.3.1.0, there is no delay.

ETA: Just compared encodes from an MPEG-2 (DVD) source:
1.1.9.0 = 0 extra frames
1.3.1.0 = 0 extra frames
1.3.1.3 = 2 extra frames

[videoh]

Originally Posted by stax76

Comparing lsmash against ffms2 frame 77 is the same in the StaxRip preview and the frame count is also the same in the StaxRip preview, when I encode it's very surprising that lsmash is fine and ffms2 is not, this could be the issue a StaxRip user reported recently, I have no idea what's going on!

edit: 2.20 is fine

Thanks. It sure seems that ffms2 has a regression of some sort. Surely Myrsloik will look into it and we just need a little patience. Or you could diff the source code for the two versions to see what might have caused it.

[stax76]

Originally Posted by videoh

Thanks. It sure seems that ffms2 has a regression of some sort. Surely Myrsloik will look into it and we just need a little patience. Or you could diff the source code for the two versions to see what might have caused it.

I hope it's easy to fix, here is another finding:

Originally Posted by mini-moose

Thanks again for all the detailed responses.

I've been playing around with it. The encode speeds I get with threads=1 (that seems to be the main speed bottleneck) are really a lot slower than without. I tried it both ways with very low crf settings (like crf 25-26 and preset fast) and low resolution (1920x1080-->720x404), just to compare. Roughly 1/5 the speed (might be less depending on cpu).

Another thing I did, is try the new ffms 2.2.1 on 2 movies (neither seem to have null frames following the test you suggested) and both came out out of sync when I didn't use threads=1. Then switched back to 2.2.0, no issues there.

Maybe I'm doing something wrong, I don't know..

[videoh]

Just keep using 2.2.0 until something happens. Did you submit a trouble ticket?