FFmpegSource

[fvisagie]

Originally Posted by HolyWu

Yes.

Thanks for the confirmation.

One other alternative is LWLibavVideoSource(in LSMASHSource.dll of L-SMASH-Works).

Thanks, I'll try that,

Originally Posted by Selur

LWLibavVideoSource first Time I hear of it btw. where to get a up-to-date version of LSMASHSource.dll ? (https://code.google.com/p/l-smash/ and https://github.com/VFR-maniac/L-SMASH-Works/tree/master/AviSynth have no downloads; aside from source code)

as soon as we get hold of it .

I should also mention that even with the demuxing work-around, only seekmode=0 works completely correctly.

According to MediaInfo there are some bitrate-related differences between the original and remuxed files, which I don't have much control over as this was a straight-forward remux. However, the original also has

Video delay : -5ms

which the remuxed does not have. Getting this to 0 in the encode caused ffmpeg to throw many warnings but didn't help FFmpegSource. I also tried all adjustdelay options without any luck.

The above were all tried with both demuxer="default" and demuxer="lavf".

So I'm looking foward to trying LWLibavVideoSource.

[forclip]

Originally Posted by HolyWu

One other alternative is LWLibavVideoSource(in LSMASHSource.dll of L-SMASH-Works).

Thanks for the info! Nice to know that we have another one source filter for AviSynth

P.S. I've found where to download it, but not sure that it is allowed to post link here, so everyone who interested - just ask Google for "LSMASHSource.dll" + "blog-page_17".

[Selur]

Thanks!
I created a new thread for LSMASHSource (https://forum.doom9.org/showthread.php?t=167435), so all LSMASHSource related stuff can be posted there.

[Plorkyeran]

Originally Posted by qyot27

With r743+7 (+7 referring to https://github.com/tgoyne/ffms2), I'm getting segfaults when FFMS2 tries to load audio in a script being served to an FFmpeg build that uses the rewritten AviSynth demuxer. I reported it on AvxSynth's issues tracker first, and their analysis pointed back at FFMS2. I produced debug builds of both FFmpeg and FFMS2 and re-ran the test, which resulted in a segfault.

Can you upload a complete set of files which reproduces this, including debug symbols? I haven't been able to trigger it, both with and without libavresample support enabled.

[qyot27]

Originally Posted by Plorkyeran

Can you upload a complete set of files which reproduces this, including debug symbols? I haven't been able to trigger it, both with and without libavresample support enabled.

avxtest.7z
http://www.mediafire.com/?rcizx4ur7659djk

Contains a slightly newer build of FFmpeg that still exhibits the issue, the build of FFMS2, video file, and script. Both FFmpeg and FFMS2 have debug symbols. The script shows a sampling of fpsnum and fpsden values which spark the issue when used with SSRC, using the same framerates I mentioned in the previous post. It also shows working framerate/SSRC combinations that are still close to the non-working ones (as in, the difference between a denominator of 1000 vs. 1001).

My initial reason for thinking it was in the demuxer was because disabling the code that does fps/samples calculations in avisynth_read_packet_audio (here) allows those non-working framerates to work with SSRC (also, the fact that wavi, the old VFW-based AviSynth demuxer, and Windows Media Player 6.4 don't have problems with it in those fps/SSRC combos). But I was told that that is part of the code that keeps video and audio in sync when used together and that it seemed to stem from FFMS2 (and the backtrace I generated did show...something that had FFMS2's audio functions in it).

My testing environment:
Windows XP SP3, 512MBs PC133 SDRAM, 1GHz Celeron Coppermine

[Selur]

I got the following script on clip:

SetMemoryMax(768)
LoadPlugin("G:\Hybrid\avisynthPlugins\ffms2.dll")
Source = FFVideoSource("H:\TESTCL~1\CANONE~1.MOV",cachefile="H:\Temp\165714630mov_deb1536f480475f7d593219aa1afd74c_41.ffindex",fpsnum=29970,fpsden=1000)
SourceFiltered = Source
Source = Source.Crop(0,0,960,1088)
SourceFiltered = SourceFiltered.Crop(960,0,960,1088)
StackHorizontal(Source, SourceFiltered)
return last

when trying to open it with Virtual Dub I get:

Avisynth open failure:
Crop: you cannot use crop to enlarge or 'shift' a clip
(H:\Temp\tempPreviewAvisynthFile08_24_20_176.avs, line 5)

which first confused me until I looked at the MediaInfo output for this file, which contained:

Width : 1 920 pixels
Height : 1 080 pixels
Original height : 1 088 pixels

So from the looks of it, FFVideoSource doesn't return 1920x1088 as I assumed, but 1920x1080.
(so using ',1080)' instead of ',1088)' fixes the imminent problem, but I would prefer it if FFmpegSource would return 1088 lines,..)
-> is this behavior intended?

[LigH]

Probably yes. There are encoders which encode a height of 1088 lines (MOD 16) and store a cropping area of 1080 lines in the header. I remember that DGDecNV and DGAVCDec report something similar for FullHD AVC videos in their info windows while playing [F6].

[Selur]

but DGDecNV&Co only crops to 1080 if 'Options->Always crop 1088->1080' is enabled, since FFmpegSource doesn't have such an option, wouldn't it be more resonable to display the whole 1920x1088 pixels?

[Plorkyeran]

Originally Posted by LigH

There are encoders which encode a height of 1088 lines (MOD 16) and store a cropping area of 1080 lines in the header.

All encoders do this; it's the only way to encode a non-mod16 resolution. The 8 extra lines are garbage data, and and there shouldn't be any reason to want to see them.

[qyot27]

FFMS2 C-plugin r753

AviSynth/VapourSynth dual plugin
Optimized for Pentium III/SSE fpmath


Regarding the issue from before, I'm starting to think it's very dependent on hardware constraints. The same build of r753 exhibits the issue on my computer (running a [2001] Celeron Coppermine w/ 512MBs of RAM), but does not exhibit it on a [2006] Athlon64 Orleans w/ 2GB of RAM. My first impulse, as stated before, is that it may be some sort of memory size issue that mine gets tripped up on only because of how little I have (similar to the long-standing issue with matroskaparser.c when using any active level of optimization in GCC), the other one is that it may lie somewhere in the floating point math (or how the float stuff actually gets compiled) that the Athlon64 can compensate for but mine can't.

[Abs62]

r753 can't decode flac audio. No errors indicated, but output is empty data.

Upd.
It looks like the BytesPerSample variable don't set if codec return data not in planar format.

[zettai]

r753 and v2.17 have made a change whereby mpeg2 elementary streams are always interpreted as 25fps.

v2.16 works fine.

[qyot27]

No new build of FFMS2, but it does indeed seem that the weird framerate/SSRC issue in ffmpeg truly was in the demuxer as I first thought, because it doesn't do it now. There was recently a fix for the fact that the demuxer was off by one frame (causing the first frame to be truncated and the last frame to be duplicated; another issue was that it was inserting a null frame/sample into the video/audio before real decoding started, but that doesn't seem to be what caused the issue - it was also fixed) and this may have been what underlaid the problem, unless it was just a general libavformat problem that got fixed by some other commit.

[Soliloquy]

Is it possible to read x264's 444 lossless (not 100% on the terms there, hah) with ffms2 or should i be using something else?
Tried using the previously mentioned r753 build in vapoursynth and I get a very green output.

[TheRyuu]

ffms2-2.18-rc1.7z

Includes both 32 and 64-bit compiles.
Requires SSE2 capable CPU and XP SP3 or newer.

Changelog for 2.18:

• Fix regression (r483) with rffmode that caused it to error out even if using the default output colorspace. (TheRyuu)
• High(er) quality YUV->RGB conversion. (TheRyuu)
• Fix indexing on files with cover art. (TheRyuu)
• Add support for libav/ffmpeg built with msvc, this is the default on windows when building with msvc. (TheRyuu)
• Remove postproc support. (TheRyuu)
• Added VapourSynth support. (Myrsloik)
• ffmsindex can now output keyframe numbers to a file while indexing. (Plorkyeran)
• configure now defaults to building a shared library, except when building MinGW/Cygwin, since you usually want static for those. (Plorkyeran)
• The source color space and color range used when converting with swscale can now be overridden. (Plorkyeran)
• Fix issues with unicode filenames when building with mingw. (Plorkyeran)
• Fix progress reporting when indexing files with non-zero initial timestamp with haali's splitter. (Plorkyeran)
• Add support for formats with packet durations but no packet timestamps. (Plorkyeran)
• Fix corruption when seeking in VC-1 in MKV. (Plorkyeran)
• Fix bug that resulted in files opened with Haali's splitter sometimes always decoding from the beginning on every seek. (Plorkyeran)
• Add support for VP8. (Plorkyeran)
• Fix crash when indexing video formats with no parser. (Plorkyeran)
• Fix compilation errors with recent versions of libav/ffmpeg. (Plorkyeran)
• Fix NVOP handling with frame-based threading (aka zero-size frames with mp4 bug). (Plorkyeran)
• Add support for vc1image. (Plorkyeran)
• Use the container SAR when the codec SAR is unset when opening via lavf. (Plorkyeran)
• Actually set the ColorRange and ColorSpace of frames when nothing has been overridden. (Plorkyeran)
• Add support for files without timestamps to lavf audio. (Plorkyeran)
• Fix handling of audio delay with invalid inital timestamps. (Plorkyeran)
• Sort of partially fix interlaced H.264. (Plorkyeran)
• Fix errors when the client asks for audio past the end of the file. (Plorkyeran)
• Fix rounding error with MKV timestamps that resulted in things getting a FPS like 60001/1001. (TheRyuu)
• Bump required version to libav 0.8/FFmpeg 0.9. (Plorkyeran)
• Switch to avcodec_decode_audio4. (Plorkyeran)
• Add support for planar audio from lavc. (Plorkyeran)
• Add SetOutputFormatA for audio resampling/mixing using libavresample. (Plorkyeran)

There may be a few additional things not listed because the changelog wasn't updated yet.

[Abs62]

ffms2-2.18-rc1 don't decode flac audio like r753 (see my post above).
And it hangs after jump back from current frame. It seems the cache iterator "cachePos" in FFMS_AudioSource::GetAudio() becomes invalid after Cache.erase() in FFMS_AudioSource::CacheBlock().

[filler56789]

FFMS2 doesn't support MKVs with RealVideo wrapped in VFW-mode

Avisynth open failure:
FFVideoSource: video codec not found

Sample file: http://www.mediafire.com/?aab0uxsf55ef9ru

[mastrboy]

Is indexing of larger lossless avi huffyuv been fixed in 2.18-rc1?

Ref former posts:
http://forum.doom9.org/showthread.php?p=1594019#post1594019
http://forum.doom9.org/showthread.php?p=1594170#post1594170
http://forum.doom9.org/showthread.php?p=1595022#post1595022
http://forum.doom9.org/showthread.php?p=1595010#post1595010

[TheRyuu]

Originally Posted by mastrboy

Is indexing of larger lossless avi huffyuv been fixed in 2.18-rc1?

Ref former posts:
http://forum.doom9.org/showthread.php?p=1594019#post1594019
http://forum.doom9.org/showthread.php?p=1594170#post1594170
http://forum.doom9.org/showthread.php?p=1595022#post1595022
http://forum.doom9.org/showthread.php?p=1595010#post1595010

Try it.

[mastrboy]

Seems fixed
Same amount of frames as the revision before indexing broke on my files when using ffvideosource.
Also backwards seeking seems to have gotten quite a speedup? (at least in avspmod)