FFmpegSource

[Mug Funky]

roger: unless i'm misunderstanding your needs, you could use avisynth in ffdshow if you needed to work off something live.

this works rather well for realtime waveform and vectorscopes on a geurilla filmmaker setup.

[rogerdpack]

Originally Posted by Mug Funky

roger: unless i'm misunderstanding your needs, you could use avisynth in ffdshow if you needed to work off something live.

this works rather well for realtime waveform and vectorscopes on a geurilla filmmaker setup.

I assume you just use graphedit files for your input to avisynth then? Or, rather, how do you get live input to your avisynth per se?
Thanks1
-roger-

[hello_hello]

Originally Posted by rogerdpack

I assume you just use graphedit files for your input to avisynth then? Or, rather, how do you get live input to your avisynth per se?
Thanks1
-roger-

ffdshow has an AVISynth filter. Enable it and copy and paste your AVISynth script into the filter's text area. Also make sure the "Add ffdshow video source" checkbox is ticked.

If memory serves me correctly, ffdshow installs optional AVISynth plugins in order for it's AVISynth filter to work. If they're not in the AVISynth plugins folder (ffavisynth.avsi and ffavisynth.dll) then re-installing ffdshow while selecting the option to install them should fix that.

From there as long as you're decoding via DirectShow when encoding, and as long as ffdshow is doing the decoding, the script you added to ffdshow's AVISynth filter should run.

[rogerdpack]

Oh wow thanks hello_hello that is fascinating news. The question kind of still remains as to how to get "live" input into your avisynth script, but I have a kludgey work around in the form of the graphedit files...

[TheFluff]

Avisynth isn't really suited to processing streaming inputs, since it requires the length of the input to be known when the script is opened.

[rogerdpack]

I've had "reasonably good luck" by using it to play an incoming graphedit file source, and just specifying frames as 1 million. Obviously this is non optimal but hey, at least it tries.

[Gavino]

Originally Posted by hello_hello

If memory serves me correctly, ffdshow installs optional AVISynth plugins in order for it's AVISynth filter to work. If they're not in the AVISynth plugins folder (ffavisynth.avsi and ffavisynth.dll) then re-installing ffdshow while selecting the option to install them should fix that.

ffavisynth.avsi and ffavisynth.dll are not required in order to use the Avisynth filter inside ffdshow.
They are for a different purpose, allowing you to use ffdshow's own filters inside Avisynth.

http://forum.doom9.org/showthread.php?t=85447

[qyot27]

Seems that r686 breaks C-plugin compilation. r684 compiles without a hitch.

gcc -Wall -march=pentium3 -mtune=pentium3 -std=gnu99 -s -fomit-frame-pointer -I/home/Stephen/win32_build/include  -I. -Iinclude -D_FILE_OFFSET_BITS=64 -DFFMS_USE_FFMPEG_COMPAT  -c -o src/avisynth_c/avisynth.o src/avisynth_c/avisynth.c
In file included from src/avisynth_c/avisynth.c:21:0:
include/ffms.h:333:1: warning: type defaults to 'int' in declaration of 'FFMS_IndexErrorHandling' [enabled by default]
include/ffms.h:333:1: warning: '__stdcall__' attribute only applies to function types [-Wattributes]
include/ffms.h:333:35: error: expected ',' or ';' before 'FFMS_GetErrorHandling'

make: *** [src/avisynth_c/avisynth.o] Error 1

Full build log on pastebin


or the slightly more verbose output from gcc 4.8.0:

i686-w64-mingw32-gcc -Wall -march=pentium3 -mtune=pentium3 -std=gnu99 -s -fomit-frame-pointer -I/home/qyot27/win32_build/include  -I. -Iinclude -D_FILE_OFFSET_BITS=64 -DFFMS_USE_FFMPEG_COMPAT  -c -o src/avisynth_c/avisynth.o src/avisynth_c/avisynth.c
In file included from src/avisynth_c/avisynth.c:21:0:
include/ffms.h:333:10: warning: type defaults to 'int' in declaration of 'FFMS_IndexErrorHandling' [enabled by default]
 FFMS_API(FFMS_IndexErrorHandling) FFMS_GetErrorHandling(FFMS_Index *Index);
          ^
include/ffms.h:78:77: note: in definition of macro 'FFMS_API'
 # define FFMS_API(ret) FFMS_EXTERN_C __attribute__((visibility("default"))) ret FFMS_CC
                                                                             ^
In file included from src/avisynth_c/avisynth.c:21:0:
include/ffms.h:333:1: warning: '__stdcall__' attribute only applies to function types [-Wattributes]
 FFMS_API(FFMS_IndexErrorHandling) FFMS_GetErrorHandling(FFMS_Index *Index);
 ^
include/ffms.h:333:35: error: expected ',' or ';' before 'FFMS_GetErrorHandling'
 FFMS_API(FFMS_IndexErrorHandling) FFMS_GetErrorHandling(FFMS_Index *Index);
                                   ^
make: *** [src/avisynth_c/avisynth.o] Error 1

Full build log on pastebin

[sl1pkn07]

try gcc 4.7. on my linux build fine

[Plorkyeran]

r688 should fix compilation in C stuff.

[qyot27]

Originally Posted by Plorkyeran

r688 should fix compilation in C stuff.

Confirmed. It compiles without issues again now.

Originally Posted by sl1pkn07

try gcc 4.7. on my linux build fine

It wasn't tied to the version of GCC. And beyond that, I'm guessing that either:
A) That's the trunk, not the C branch. The trunk doesn't exhibit the problem.
B) If it was the C branch, you didn't do a HEAD catchup. An un-caught-up C branch is still back at like, r643.

[qyot27]

Due to request,

FFMS2 C-plugin r688

FFmpeg r41540 (git-2a622c2)
Both FFmpeg and FFMS2 optimized for Pentium III
MinGW-w64 GCC 4.8.0 20120610 (experimental)

EDIT: Updated, here

[burfadel]

Originally Posted by qyot27

Due to request,

FFMS2 C-plugin r688

FFmpeg r41540 (git-2a622c2)
Both FFmpeg and FFMS2 optimized for Pentium III
MinGW-w64 GCC 4.8.0 20120610 (experimental)

Wouldn't compiling for such an old processor be detrimental for newer processors?

What about SSEx etc instruction sets?

[sl1pkn07]

qyot27:

http://pastebin.com/pjj0XfHN

c-branch r.686 with gcc 4.7

gcc 4.8 is extreme experimental

[qyot27]

Originally Posted by sl1pkn07

qyot27:

http://pastebin.com/pjj0XfHN

c-branch r.686 with gcc 4.7

gcc 4.8 is extreme experimental

I know that gcc 4.8 is experimental, and that pastebin isn't working so I can't see the result. But it doesn't change the point that something that 4.6.2 and 4.8.0 both error out on leaves little room for 4.7 to fix. Not that it matters now, since r688 resolves the problem.

It's also not being compiled natively for Linux, if that's what was happening. It's very specifically a MinGW-w64 build, because IMO there's very little point in compiling the C plugin on Linux. It has to have the AviSynth module enabled (as it's meant as the AviSynth plugin .dll, hence MinGW), since it's avisynth_c.o where the error is tripped.

Originally Posted by burfadel

Wouldn't compiling for such an old processor be detrimental for newer processors?

What about SSEx etc instruction sets?

I don't know, and without trying to sound callous, I'm not concerned about it. I optimize for the processor I actually have and use 99% of the time. I've never run a definitive test of whether - or how much - it affects the performance of newer processors.

[sl1pkn07]

oks. thanks

[LigH]

Probably as mentioned before for the ffdshow decoders: Most of their optimization is already done in Assembler. The little bit of C++ compiler optimization potential left to the sources is only related to the API.

[qyot27]

Slightly updated version since there were two more commits made while I was busy compiling everything the other day, and stupidly did not save the FFmpeg dev files.

FFMS2 C-plugin r690

FFmpeg r41586 (git-ddece75)
Still PIII and MinGW-w64 GCC 4.8.0



EDIT: New build here.

[Abs62]

r694 don't compile.

..\src\core\haalivideo.cpp(157): error C2094: label 'Error' was undefined

[JEEB]

Originally Posted by sneaker_ger

The following interlaced H.264 sample will not work correctly in ffms2 (tested 2.17, r644, r666):
http://www.mediafire.com/?ubxfydr4owr2rmo

Multi-threaded: insanity, decoder delivers empty frame after first(?) frame
1 thread: jumping back and forth

This sample seems to have mostly been fixed with the recent multithreading-fixing commits

After a brief test with Aegisub the only problem I was getting was that every frame came out twice, which could be sample-related (I would like to have someone with more knowledge on the matter comment on how broken this matroska remux is, as most things seem to fail to mux or deal with the H.264 stream included to begin with). Otherwise it seems like frame order was correct, and all frames seem to be output correctly. With Avisynth I did also try with threads=1 and that for some reason brought back the jerkiness in a bit different way.

A build is available for testing here.

ffms2: r695, libav: git-d77f4af

libav configuration:
--prefix=/ffms --disable-network --disable-encoders --disable-muxers --disable-hwaccels --disable-indevs --disable-outdevs --extra-cflags='-U__STRICT_ANSI__ -D_SYSCRT' --disable-debug --enable-runtime-cpudetect