Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - TheFluff

Pages: [1] 2 3
1
Avisynth Development / Re: AviSynth Plugin to drop undecodeable frames
« on: June 25, 2012, 02:24:24 PM »
what you're trying to do pretty much cannot be done in a filter that isn't the source filter itself, so have fun with that

Why not, you ask?
Pretty much all source filters just throw an exception when retrieving a frame fails, and once that happens it's game over and you can't do shit. You usually cannot restart decoding in a safe way once the exception is thrown, even if we presume that you actually manage to catch the exception in the first place (which in and of itself is decidedly nontrivial to do from inside a plugin, since most likely the script environment will catch the exception before you ever get to see it; you will need some serious C++ voodoo to catch it before someone else does, if it's even possible at all).

Assuming that you actually do manage to catch the exception, in many (most?) cases you'd either need to reinit the decoder and/or reopen the source file in order to restart decoding at the next frame in a safe way (since once the exception is thrown, all assumptions about the decoder state are completely useless), and you can't do that from inside another plugin.

Furthermore, you need to consider that most modern codecs use predictive or even bidirectionally predictive coding, which means that if decoding frame X fails, decoding all frames that depend on X (possibly the entire GOP, which is typically 2-300 frames) will also either fail completely, or succeed with serious artifacts.


edit: if you're actually trying to just drop frames that are green, and not detect actual decoding failures, then ignore the above. dropping green frames is relatively easy.

2
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: March 16, 2012, 05:54:13 PM »
As usual the VFR edge cases are always hilarious. FFMS2's current algorithm for conversion to CFR is to calculate the timestamp for each frame in the output and then, at each frame in the output, pick the source frame that starts closest to the destination timestamp. Hence, for all frames after 5.000 seconds, frame 1 is closer than frame 0 and so it gets chosen. I'm not sure if this is actually the "best" way of doing it though, nor if it's strictly correct. We'll take your report under consideration.

3
Avisynth Usage / Re: h264 (GBR) source filter?
« on: February 17, 2012, 05:18:23 AM »
That's a really interesting bug. Provide a sample and we will fix it in FFMS2.

4
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: January 22, 2012, 11:42:22 PM »
FFMS 2.17 has been released.
Again, this is mostly a bugfix and maintenance release; no major new features have been added. There are, however, two minor features that might be relevant to Avisynth users. First, you can now get the FFMS version by calling FFGetVersion(), which returns a string on the form "2.17.0.0", where the last two numbers are mostly relevant for API users. Second, all exported metadata variables can now have their names prefixed with a string of your choice, which prevents two or more subsequent calls to FFVideo/AudioSource from overwriting each other's variables. Oh, and for the three people who care (hello there, tebasuna51), the audio channel layout is now exported as a dwChannelMask-compatible integer, in the variable FFCHANNEL_LAYOUT.

Downloads
Full changelog since 2.16
  • Reworked color matrix and color range handling a bit, which fixed a bug that could cause FFMS2 to always output TV range even if the input was full range. (TheFluff)
  • The autotools build system can now create debug builds properly. (Daemon404)
  • Deprecated parts of the API will now cause compiler warnings when you use them. (TheFluff)
  • Added a FFMS_GetVersion function to the API (lets library users get the version number at runtime) and exposed it in Avisynth as FFGetVersion. (TheRyuu, TheFluff)
  • Added a variable prefix option to the Avisynth functions. Its primary purpose is to get subsequent calls to source functions from overwriting variables from earlier calls. (TheFluff)
  • Make it possible to open single-frame videos without explicitly setting seekmode to -1 for you weird people who want to open images with ffms (Plorkyeran)
  • Fixed bug where indices would sometimes be incorrectly considered valid (TheRyuu)
  • Add support for recent versions of Libav/FFmpeg built as shared libraries (Plorkyeran, TheRyuu, Kovensky)
  • When possible, non-API symbols are no longer exported (Daemon404, TheFluff)
  • Deprecate postprocessing support. Libav and FFmpeg are planning on removing it at some point in the near future and it's really not very useful.
  • Fix the pkg-config version on OS X (Plorkyeran).
  • Fixed a bug that could cause the FFmpegSource2() Avisynth function to not use UTF8 filenames even when told to do so. (pandv2)
  • Fixed a few minor memory leaks. (Plorkyeran)
  • Adjusting audio delay relative to the first video track should now work properly again (was broken in 2.16). (Plorkyeran)
  • General bitrot fixes to deal with changes in Libav/FFmpeg (everyone)
  • Corrected handling of codec private data when using a non-libavformat parser. Fixes decoding of FFV1 and UTVideo in MKV, among other things. (TheFluff)
  • Bump minimum required version of FFmpeg to 0.6.

Other notes
The VC-1 decoding issue is not fixed, but since it's been there since forever and is extremely mysterious and hard to debug, we've decided to release 2.17 anyway. We haven't given up on it, though.

We'd also like to again remind postprocessing users that postprocessing support is deprecated and will be removed in 2.18. The reason for this is that both libav and FFmpeg are planning on removing the library we use (libpostproc).

5
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: August 26, 2011, 12:56:11 PM »
FFMS 2.16 has been released. The following downloads are now available:

  • ffms-2.16.7z - the usual binary. Includes multithreaded decoding functionality; you no longer need a special -mt version.
  • ffms-2.16-src.tar.bz2 - source code.
  • ffms-2.16_SDK.7z - package for Windows developers who want to develop programs that use FFMS2 but don't want to deal with MinGW.

Full changelog since 2.15:
  • Reimplemented output colorspace selection, this should fix all issues with the avisynth plugin when opening yuv420p10 or yuv444 material plus several other less common cases. (Myrsloik)
  • Added FFMS_SetOutputFormatV2 to the API. This function allows you to specify PixelFormats >= 64 for use as output. (Myrsloik)
  • Fixed a serious bug that could cause crashes and completely useless index files with h264 in matroska. (Myrsloik)
  • Automatically detect number of decoding threads. The avisynth video source funtion already did this, now moved so the api can use it as well. (TheRyuu)
  • Re-add the ability to target x64 with msvc since it's a bit more sane now. (TheRyuu)
  • Fixed a bug that could cause crashes when reading audio if FFMS2 was compiled with GCC. (Myrsloik)
  • ffmsindex will no longer crash if it cannot open the file given to it for indexing. (TheFluff)
  • FFMS2 will no longer crash if the video decoder feeds it an empty frame (can sometimes happen when using lots of decoder threads); you'll get a nice error message instead. (TheFluff)
  • The C-plugin can now act as both an Avisynth 2.6 plugin (including support for new colorspaces) as well as an Avisynth 2.5 one, in the same binary. (kemuri_-9)
  • Fixed an issue that could cause opening Vorbis audio to fail because FFMS2 couldn't find an initial valid PTS. (TheFluff)
  • FFMS2 will no longer crash if forced or tricked into using an index file generated by a FFMS2 version compiled for a different architecture. (TheRyuu)
  • Fixed a crash when the last frame was requested using the Avisynth plugin's forced CFR mode. (Plorkyeran)
  • Fixed various issues with decoding audio from the Ogg container without Haali's splitter. (Myrsloik, TheFluff)
  • Fixed the "invalid postprocessing settings"; they were caused by a parsing bug in libpostproc, and a workaround has been added. (Myrsloik)
  • Tinkered a bit with the non-MSVS build system. (Daemon404, Kovensky)

Important notice for postprocessing users:
Support for postprocessing in FFMS2 will be dropped in the next release. The reason is that both libav and FFmpeg are dropping this library from their own releases, and so we cannot continue supporting it.

6
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: August 25, 2011, 02:23:20 PM »
New test build: ffms2-r532.7z
Includes pthreads.

We're slowly working on trying to fix enough bugs to motivate a release of 2.16, so test everything, submit all your weirdest sample files and win a prize if it causes a reproducible crash. Test audio in particular since we've been fucking around with that a lot lately.

Full changelog (maybe) since 2.15:
  • Reimplemented output colorspace selection, this should fix all issues with the avisynth plugin when opening yuv420p10 or yuv444 material plus several other less common cases. (Myrsloik)
  • Added FFMS_SetOutputFormatV2 to the API. This function allows you to specify PixelFormats >= 64 for use as output. (Myrsloik)
  • Fixed a serious bug that could cause crashes and completely useless index files with h264 in matroska. (Myrsloik)
  • Automatically detect number of decoding threads. The avisynth video source funtion already did this, now moved so the api can use it as well. (TheRyuu)
  • Re-add the ability to target x64 with msvc since it's a bit more sane now. (TheRyuu)
  • Fixed a bug that could cause crashes when reading audio if FFMS2 was compiled with GCC. (Myrsloik)
  • ffmsindex will no longer crash if it cannot open the file given to it for indexing. (TheFluff)
  • FFMS2 will no longer crash if the video decoder feeds it an empty frame (can sometimes happen when using lots of decoder threads); you'll get a nice error message instead. (TheFluff)
  • The C-plugin can now act as both an Avisynth 2.6 plugin (including support for new colorspaces) as well as an Avisynth 2.5 one, in the same binary. (kemuri_-9)
  • Fixed an issue that could cause opening Vorbis audio to fail because FFMS2 couldn't find an initial valid PTS. (TheFluff)
  • FFMS2 will no longer crash if forced or tricked into using an index file generated by a FFMS2 version compiled for a different architecture. (TheRyuu)
  • Fixed a crash when the last frame was requested using the Avisynth plugin's forced CFR mode. (Plorkyeran)
  • Fixed various issues with decoding audio from the Ogg container without Haali's splitter. (Myrsloik, TheFluff)

7
H.264/AVC / Re: x264 streaming playback issues
« on: August 24, 2011, 12:18:11 PM »
You're outputting a h264 elementary stream. That's not a streaming-friendly format. Try changing -f h264 to -f mpegts at the end and see if that works better.

8
H.264/AVC / Re: x264 version 0.116.2057 0ba8a9c released!
« on: August 20, 2011, 06:53:12 AM »
Quote from: ophiuchus18 on August 19, 2011, 05:03:30 AM
I am still amazed how the x264's compiling team or other developers know how to trick the mingw's gcc "--enable-shared" preset to remove all this bunch of dll's
I don't think it's us using something specific trick, I think it's you Doing It Wrong.

9
H.264/AVC / Re: Linking x264 against static ffms2 libs problem
« on: August 09, 2011, 04:30:08 AM »
Reminder: nobody can actually reproduce the problems you're having. I'd say that drawing the conclusion that everyone else must be wrong is a bit odd in your situation.

If you want a non-broken MinGW, compiling your own GCC is a Very Bad Idea. The chances of you actually getting shit right are slim to none. Just download someone else's confirmed-to-be-working package, like for example this one.

10
H.264/AVC / Re: Linking x264 against static ffms2 libs problem
« on: August 07, 2011, 01:08:27 PM »
Quote from: ophiuchus18 on August 07, 2011, 03:57:29 AM
1) When starting the ffms2 build process with autogen.sh for rebuilding the configure file,
the package version is computed correctly (2.15.0.1). Starting directly with ./configure
applied to the provided configure script, will determine an outdated package version (2.13.1)
and configure will be performed again with make. The resulted outdated (v2.13.1) static lib
will fail to link against x264.

I think I've said this like ten times now but that version number has nothing to do with anything and is completely irrelevant to any and all issues you're having.

Quote from: ophiuchus18 on August 07, 2011, 03:57:29 AM
2) After building, ffmsindex.exe can't run without libgcc_s_dw2-1.dll and
libstdc++-6.dll in the same folder or without these libs path set in the system's
environment variables. In the MinGW manuals they say they included both type o
gcc/g++ libs, the shared libs (libgcc_s_dw2-1.dll and libstdc++-6.dll) and the static
libs (libgcc.a and libstdc++.a) and in certain situations mingw/gcc will link against
the executables the shared libs instead of the static libs. My minGW is ok, I succesfully
built many other packages but only with ffms2 I experimented this behaviour.
Probably some settings about sharing and/or debugging in ffms configure/MakeFile scripts
determined MinGW to select the gcc/g++ shared libraries instead of the static items.

3) The x264.exe built with libffms2.a from the ffms2.r518: The r518's libffms2.a
output hundreds of errors in x264 ./configure process, but finally it could still
be linked in x264.exe. I think it's a serious bug inside this libffms2.a because when
I tested the x264.exe, the ffms indexing crashed at 0.6%
------------------------------------------
[info]: indexing input file [0.6%]
ffms [info]: 864x486p 1:1 @ 30/1 fps (vfr)
------------------------------------------
Due to the linked libffms2.a, x264.exe can run now only with libgcc_s_dw2-1.dll and
libstdc++-6.dll inside the folder or with path set in the system's environment variables.

Used lavf folders from:
C:\>ffmpeg.exe --version
ffmpeg version N-31762-g6e19cfb, Copyright (c) 2000-2011 the FFmpeg developers
  built on Aug  5 2011 21:52:51 with gcc 4.5.2
  configuration: --enable-gpl --enable-postproc --enable-libxvid --enable-libx264 --enable-avisynth
  libavutil    51. 11. 1 / 51. 11. 1
  libavcodec   53.  9. 1 / 53.  9. 1
  libavformat  53.  6. 0 / 53.  6. 0
  libavdevice  53.  2. 0 / 53.  2. 0
  libavfilter   2. 27. 5 /  2. 27. 5
  libswscale    2.  0. 0 /  2.  0. 0
  libpostproc  51.  2. 0 / 51.  2. 0

So put the crap out on tests and share later with us your experiences  ;D
It's not a bug in ffms, YOUR SHIT IS MISCOMPILED. That is why it crashes and that is why you get a billion undefined references to various C++ standard library functions. Fix your broken compilation environment. Using vanilla MinGW stuff is probably a very bad idea.

11
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: August 01, 2011, 02:13:48 AM »
Quote from: ophiuchus18 on July 31, 2011, 05:45:42 PM
My mingw is OK, I successfully build executables and libraries (.a and .dll) from ffmpeg, libav, x264, zlib, bzip2, pkg-config, GLib, lame, etc. from their sources and the built applications don't have unexpected dependencies like ffms application and its libraries.

In your release packages there are only ffmsindex.exe, ffms2.dll, FFMS2.avsi, ffms.h, ffms2.lib, ffms2.pdb, ffmsindex.pdb. I can use ffms2.dll, ffms.h and ffms2.lib form these packages to enable the EXTERNAL ffms support in x264.exe, but then x264.exe will run only together with ffms2.dll and it's annoying.

All I need from ffms2 site are the regularly up-to-date files: ffms.h, ffmscompat.h, libffms2.a, libffms2.la and ffms2.pc, to enable the STATIC ffms support in x264 when I build the executable. This is the only reason because I compile and build from your source.

Why don't you put all your libraries (.a and .la inclusive, not only .dll and .lib) and the matching headers in the dev folder of your regular releases ? it's a great mistery. This is not chinese, is just a simple way to simplify the access of third party to ffms libs.

We are actually planning on releasing an SDK package with pretty much what you're asking for (include files, library and debugging symbols), but we haven't gotten around to it yet.

As for your funny dependencies, I have no idea what you're doing wrong but something is clearly broken on your end. You're the first to report similar issues, and there is nothing special about how FFMS2 is built in MinGW.

12
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: July 31, 2011, 04:42:27 PM »
Quote from: ophiuchus18 on July 29, 2011, 06:13:57 PM
I built ffmpeg.v0.7.1. The /libavutil/sha1.h is mandatory required to build the svn.ffms2.15.Revision509.src and sha1.h is missing in the latest months's ffmpeg releases.
2.15 was released in February. If you want to build it, you should use a FFmpeg at least that old, as it is hard to be forwards-compatible.

Quote from: ophiuchus18 on July 29, 2011, 06:13:57 PM
Q: Why the src version is named 2.15 and the created package version is 2.13.1 ?
A: ...
As I already told you, 2.13.1 is not the package version. It's the API version, which is a completely different thing.

Quote from: ophiuchus18 on July 29, 2011, 06:13:57 PM
Q: Why don't you add in your release ffmscompat.h and libffms2.a to avoid all this mess (ffms2.dll and ffms2.lib don't fit with the "--enable-static" option and people don't want a bunch of files around to run eg. x264.exe)?
A:...
If you actually look at the current source code instead of at outdated shit, you will notice we did this a long time ago.

Quote from: ophiuchus18 on July 29, 2011, 06:13:57 PM
Q: Why it's easy to build x264, ffmpeg, libav, Glib, pkconfig,...  but with ffms2 only problems?
A:...
Because you are doing it wrong.

Quote from: ophiuchus18 on July 31, 2011, 11:20:29 AM
I didn't knew before about this link with the most updated source. The site architecture is confuse. A newcomer arrived at ffms2 page to search for ffms.h, ffmscompat.h and libffms2.a (necessary to include the static ffms support in x264.exe) is going to DOWNLOAD button and there is only the outdated ffmpegsource-2.15_src.7z and some .exe releases.
We assumed that if you wanted to compile from source you'd at least know how to do a SVN checkout. This debacle tells me it's probably a good idea to remove the source archives completely and tell people to check out the SVN tags instead.

Quote from: ophiuchus18 on July 29, 2011, 06:13:57 PM
But now there is another problem: ffmsindex.exe and x264.exe can't run without the presence of the next files:
libgcc_s_dw2-1.dll
libstdc++-6.dll
This never happend before and I successfully compiled and built many diff. source packs.
I tried to enable the -static-libgcc and -static-libstdc++ in my gcc 4.5.2 but doesn't work. It's something wrong in the source code of r512 or what?
I have no idea what you've done to your MinGW libraries but apparently they're shared now for some reason. Don't do that.

13
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: July 29, 2011, 10:42:52 AM »
Oh boy, so much dumb.

Quote from: ophiuchus18 on July 28, 2011, 04:34:53 PM
The so called ffmpegsource-2.15_src.7z from dev site is outdated trash (v2.13.1?)
The API version is not the same as the user-friendly release version.

Quote from: ophiuchus18 on July 28, 2011, 04:34:53 PM
It's impossible to compile and build this source pack because
the actual ffmpeg pack don't have such file as libavutil/sha1.h
(there is only libavutil/sha.h in the actual ffmpeg pack)
Your FFmpeg is too new. If you want to build an old FFMS2 you should use an old FFmpeg too.

Quote from: ophiuchus18 on July 28, 2011, 04:34:53 PM
I tried also to compile the svn.ffms2.15.Revision509.src. The same problem:
compilation conflict between:
\src\core\indexing.cpp (svn.ffms2.15.Revision509.src)
and
\libavutil\sha.h (Version: 51.11.0)
You're doing it wrong. There is no such conflict. If you're getting compilation errors anyway, post the compilation log if you want assistance.

Quote from: ophiuchus18 on July 28, 2011, 04:34:53 PM
What outdated ffmpeg libavutil use this "Fabulous" site (with the toilet paper logo  ;D) to compile ffms2.15.Revision509.src?
If you want to compile FFMS2 trunk you can use any version of FFmpeg or libav, as long as it's not too old.

Quote from: ophiuchus18 on July 29, 2011, 04:27:22 AM
Let's presume I'll build ffms2.v15.Revision509, tricked with an older version of ffmpeg libav libs and everything is ok. But there are conflicts with many other actual libav libs headers not only with "sha.h/sha1.h" change. It seems like ffmpeg and ffms are going now in different directions. I think ffms must update its code to the actual ffmpeg libav libs.
You're dumb and you're probably doing it wrong. There are no such conflicts. The current version of FFMS2 is backwards compatibile with all FFmpeg/libav versions at the very least six months back.

Quote from: ophiuchus18 on July 29, 2011, 04:27:22 AM
Now it's become clear why x264 built with ffmpeg support from the actual stable v0.8.1 and with ffms support from ffms2.v15.Revision509 (built with some older ffmpeg libav libs) crash unexpectedly in some situations: maybe because the ffms/libav libs conflicts, I don't have a detailed view about this.
We're interested in any and all crash reports, but no, they're not caused by "libs conflicts".

Quote from: ophiuchus18 on July 29, 2011, 04:27:22 AM
Another x264 external support problem: ffmpeg dropped the libpostproc from its v.0.8.1 and x264 need libpostproc/postprocess.h and libpostproc.a for build the executable with lavf support. I see there are developers which work on both projects, ffmpeg and x264. What's their opinion?
If you want libpostproc I suggest you compile it yourself.


If you want actual help or meaningful answers rather than just flaming, I suggest you start posting some compilation logs.

14
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: June 09, 2011, 08:18:16 AM »
Quote from: Chumbo on June 08, 2011, 12:46:29 PM
For my issue above, TheRyuu made some suggestions of which one worked.  That being to use threads=1 with FFVideoSource.  It works but is extremely slow.  On a first pass with x264 (via megui) I get around ~18fps where the 32bit version using dss2 I get ~65fps.  Hopefully a fix soon?

hahaha you want to load an interlaced h264 ts with ffms2
you might as well go throw your cpu cycles at playing conway's game of life or something, that'd be more productive

Status of TS support in FFMS2 is as follows:
- progressive mpeg2: should work with Haali's splitter; frame accuracy is doubtful, however. Seeking most likely extremely broken with lavf unless you use seekmode=0 or -1 (that is to say, you never seek).
- interlaced mpeg2: same as above.
- progressive h264: only safe way to get this to work is demuxer="lavf" and seekmode=0 or -1 (-1 prevents wasting cpu cycles on pointless shit).
- interlaced h264: bat country. will most likely not work properly at all no matter what you do. If you're feeling particularly adventurous you can try demuxer="lavf", seekmode=-1, threads=1 and then use the correct fpsnum/fpsden for your source, but you're still likely to get random corruption issues.
- any type of vc1: it is a mystery

MPEG PS is probably mostly the same, but nobody uses PS these days except on DVD's, and there are better tools for handling those.

15
Avisynth Usage / Re: ffms2 gives green video on 12 core mac pro
« on: June 08, 2011, 10:25:47 AM »
The FFMS2 Avisynth plugin defaults to using as many threads as you have physical CPU cores on your system. However, libavcodec's multithreading isn't exactly stable, so for system with a lot of cores this may sometimes cause problems. If it worked on the 6-core machine, setting threads=6 (as Chikuzen suggested) should solve the problem.

16
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: June 08, 2011, 01:20:25 AM »
Lagarith support in ffmpeg is still experimental and it doesn't work very well at all, really. Don't use ffms2 for Lagarith, at least not yet.
(ps: don't use Lagarith at all)

17
H.264/AVC / Re: Debugging x264 source - MSVS?
« on: May 18, 2011, 07:51:37 AM »
Using gdb on the command line to do interactive debugging is extremely annoying and inconvenient (it's mostly useful to get stack traces and disassemblies); a lot of gcc users I know just resort to using printf's sprinkled in strategical places most of the time. On the other hand Visual Studio's source code editor is REALLY BAD (in addition to the above-mentioned intellisense fun, try changing some #ifdef blocks and watch visual studio gray out the entire file for about ten minutes until it randomly decides to notice the new ifdefs and update the syntax hilighting) and more than offsets the convenience of having a real interactive debugger.

Compiling C with Visual C++ is also a Really Bad Idea since it's really a C++ compiler, and if you sick it on C code it strictly enforces C89, which means (among other things) that you have to declare all local variables at the top of each block, etc etc.

18
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: March 06, 2011, 11:02:12 PM »
Quote from: Gweilo on March 04, 2011, 09:35:23 PM
In the docs it says :
What does "good enough" mean here? Within a few hundredths of a second?
Something like that. It's probably safe to use FFMS2 unless you actually do need exact sample-accuracy.

19
Avisynth Usage / Re: loading WMV, with WMA2 audio
« on: March 03, 2011, 12:32:04 PM »
Quote from: Gweilo on March 02, 2011, 08:20:23 AM
"Now"? Has it been updated recently?

2.15 was released a few weeks ago, and it contains a substantial rewrite of the audio reading code.

20
Avisynth Usage / Re: loading WMV, with WMA2 audio
« on: March 01, 2011, 11:43:39 PM »
FFMS2 should support WMA audio a lot better now; if it still doesn't work there's probably a bug somewhere.

21
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: February 12, 2011, 04:55:35 AM »
Doubtful. That error comes from within Haali's matroska parser itself, so chances are you are actually looking at a damaged stream there. Does it happen in the small sample you uploaded for me too? If so, where in the sample?

22
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: February 11, 2011, 04:45:47 PM »
All of those are fixed in 2.15, which is out now. You can grab it from the Google Code page.

Changes since 2.14:
  • FFVideoSource and FFAudioSource will now automatically reindex and overwrite the index file if it doesn't match the file being opened and the cachefile argument is left as the default. (Plorkyeran)
  • FFMS2 can now be used to decode Lagarith, but note that libavcodec's decoder is very experimental at the moment. (Plorkyeran)
  • SWScale can now use SSE2 optimizations for certain operations if your CPU supports it. (kemuri_-9)
  • Fixed a bug that could cause SWScale initialization to fail. (kemuri_-9)
  • Fixed a bug that could cause index files to never be considered valid, forcing a reindexing every time a script was loaded. (TheRyuu)
  • Trying to use postprocessing on a fullrange YUV clip will no longer cause errors. (TheFluff)
  • Fixed a few random decoding bugs related to unaligned memory or buffers that were not initialized properly. (TheFluff)
  • It is now possible to force FFMS2 to use a specific demuxer instead of letting it pick one automatically. (TheFluff)
  • When converting YUV to RGB, FFMS2 will now try to actually use the correct color coefficients rather than assuming everything is bt470bg. (Plorkyeran)
  • Moved support for container-level audio delay from the Avisynth plugin to the core and exposed it in the API (Plorkyeran)
  • Audio decoding has been substantially reworked. Linearly decoding audio now almost always works correctly and seeking is now actually sample-accurate for many formats. (Plorkyeran)
  • It is now possible to build 64bit versions of the plugin for use with Avisynth (and whatever else) from MSVC by means of black magic (this probably only works when the planets are aligned, also 64bit builds might require msvcr90.dll). (TheRyuu)
  • The Avisynth plugin now supports UTF8 filenames; ffmsindex.exe also supports Unicode filenames. FFMS_USE_UTF8_PATHS is now a runtime option instead of a compile-time one. (TheFluff)
  • The FFInfo() function (supplied by ffms2.avsi) will now round timestamps to nearest millisecond instead of truncating them. It's also been cleaned up in general and no longer relies on global variables. (Gavino)
  • Containers opened with libavformat will now report a framerate based on the average frame duration instead of the duration of the first frame, just like Matroska files and files opened with Haali's splitter does. Should fix CFR framerates being reported incorrectly in dumb containers like FLV. (TheFluff)
  • PC/TV luma range (16-235 versus 0-255) detection should now be a bit more reliable. (TheFluff)
  • Fixed a crash when opening files with Unicode filename support enabled. (Plorkyeran)

I've updated the Avisynth plugin documentation a bit; it should be easier to read and understand now. I've also updated the known issues part of it, so all actual known issues are listed there now. If you find a problem that isn't listed there, please report it, regardless of what I or other people have said or claimed about it in the past.

23
H.264/AVC / Re: Constant I-Frame Insertion + SC detection
« on: February 08, 2011, 08:54:41 AM »
I think he wants an IDR every two seconds in a strict pattern, PLUS extra IDR's where warranted by scenechange detection. No idea why you'd want that, but qpfile is probably the way to go if you do.

24
H.264/AVC / Re: Tips to improve backwards single frame stepping performance
« on: February 07, 2011, 11:58:57 AM »
Well, baseline doesn't allow CABAC, and that alone is pretty CPU-intensive on decoding (on the other hand it also compresses a lot better than CAVLC).

25
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: February 02, 2011, 05:11:54 AM »
I guess I can add an overwrite parameter to ffvideosource/ffaudiosource so they behave just like ffindex does.

26
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: January 31, 2011, 04:16:14 AM »
I think it does that (complain that the source does not match the index instead of automatically replace it) if you explicitly specify an index filename, because by doing so you're telling FFMS that you have a very specific file that you would like to use, so instead of silently overwriting it, it errors out.

27
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: January 27, 2011, 04:36:35 PM »
I'm planning to release 2.15 quite soon. Have a test build (vanilla ffmpeg as usual): http://mod16.org/ffms2/ffms2-r426.7z

Changes since 2.14:
  • FFMS2 can now be used to decode Lagarith, but note that libavcodec's decoder is very experimental at the moment. (Plorkyeran)
  • SWScale can now use SSE2 optimizations for certain operations if your CPU supports it. (kemuri_-9)
  • Fixed a bug that could cause SWScale initialization to fail. (kemuri_-9)
  • Fixed a bug that could cause index files to never be considered valid, forcing a reindexing every time a script was loaded. (TheRyuu)
  • Trying to use postprocessing on a fullrange YUV clip will no longer cause errors. (TheFluff)
  • Fixed a few random decoding bugs related to unaligned memory or buffers that were not initialized properly. (TheFluff)
  • It is now possible to force FFMS2 to use a specific demuxer instead of letting it pick one automatically. (TheFluff)
  • When converting YUV to RGB, FFMS2 will now try to actually use the correct color coefficients rather than assuming everything is bt470bg. (Plorkyeran)
  • Moved support for container-level audio delay from the Avisynth plugin to the core and exposed it in the API (Plorkyeran)
  • Audio decoding has been substantially reworked. Linearly decoding audio now almost always works correctly and seeking is now actually sample-accurate for many formats. (Plorkyeran)
  • It is now possible to build 64bit versions of the plugin for use with Avisynth (and whatever else) from MSVC by means of black magic (this probably only works when the planets are aligned, also 64bit builds might require msvcr90.dll). (TheRyuu)
  • The Avisynth plugin now supports UTF8 filenames; ffmsindex.exe also supports Unicode filenames. FFMS_USE_UTF8_PATHS is now a runtime option instead of a compile-time one. (TheFluff)
  • The FFInfo() function (supplied by ffms2.avsi) will now round timestamps to nearest millisecond instead of truncating them. It's also been cleaned up in general and no longer relies on global variables. (Gavino)
  • Containers opened with libavformat will now report a framerate based on the average frame duration instead of the duration of the first frame, just like Matroska files and files opened with Haali's splitter does. Should fix CFR framerates being reported incorrectly in dumb containers like FLV. (TheFluff)
  • PC/TV luma range (16-235 versus 0-255) detection should now be a bit more reliable. (TheFluff)
  • Fixed a crash when opening files with Unicode filename support enabled. (Plorkyeran)

Quite a few regressions in earlier test builds have also been fixed.

To force a demuxer, use demuxer="lavf" as an argument to ffindex(). Possible choices are lavf, matroska, haalimpeg and haaliogg.

28
Avisynth Development / Re: FFMS2 (The Fabulous FM Source 2)
« on: January 27, 2011, 02:21:19 AM »
I'm here but I don't debug -mt builds. If you can reproduce it with a build using a vanilla ffmpeg I'm all ears but -mt is Somebody Else's Problem.

29
Avisynth Usage / Re: create 120 fps video -> dedup -> VFR
« on: January 22, 2011, 05:21:18 PM »
Quote from: OvejaNegra on January 21, 2011, 05:25:27 PM
How to convert all the sections to 120 fps video

no. don't.

30
H.264/AVC / Re: 4:2:2 input to x264?
« on: January 19, 2011, 02:54:59 PM »
You do not need ffms for your application. In fact it is completely useless for it since it requires a seekable input with a known number of frames.

If you want to tell x264 what the input is, use --demuxer and --input-csp.

Pages: [1] 2 3