FFmpegSource

[hwti]

Hi,

I'm trying to open a TS file (recorded from DVB-T, H264 1440x1080i50 MBAFF) with FFVideoSource.
I tried with both the TS and remuxed to MKV, and the number of frames is not correct.
The loaded video is strange : the odd field only changes every two frames, and the even field often jumps forward and backward by several frames.
If I force the fps (fpsnum=25, fpsden=1) it loads correctly.

[TheFluff]

That's a known bug. FFMS2 hates TS; writing our own TS parsing library and supporting that format properly is on the todo list but nobody I know including myself has time to work on it right now.

[hwti]

That's a known bug. FFMS2 hates TS; writing our own TS parsing library and supporting that format properly is on the todo list but nobody I know including myself has time to work on it right now.

But it is the same when converted to MKV (which plays correctly in MHC-HC and WMP12 with Haali Media Splitter, and MPC-HC internal source).

[TheFluff]

The field duplication issue is because of a libavcodec quirk with interlaced h264; it decodes each field into its own frame.

[ganymede]

http://mod16.org/ffms2/ffms2-r408.7zI tried this version under linux/wine. It works well with H.264 and mpeg2 video, but cannot decode ffvhuff codec (tried avi and mov containers). It returns an error message : "No video stream found". Current stable version of ffms2 (2.14 vanilla) can decode the same files without problem.

[torwart]

I have one question about ffmpegsource2. Which is the best wrapper for it. I want to make a fake avi using this ffmpeg2.
sorry for my bad english. :thanks:

[LoRd_MuldeR]

I have one question about ffmpegsource2. Which is the best wrapper for it. I want to make a fake avi using this ffmpeg2.
sorry for my bad english. :thanks:

What exactly do you mean? FFmpegSource2 already is a wrapper to make libavcodec/libavformat available as source filter in Avisynth.

(Actually the Avisynth plug-in is yet another wrapper around the FFmpegSource2 core library. Applications, like x264, can use the FFmpegSource2 library directly)

[torwart]

for example: I have an avi file(divx) and I want to open it in Edius, Vegas or Premiere Pro in uncompressed. I write a script for avisinth(ffvideosource("C:\avifile")). now I can import this script in virtual dub, but how can I make a fake avi to open it in this big programms like Premiere Pro. I tried makeavis and vfapi , but it didn't work.

[LoRd_MuldeR]

So your question is NOT specific to FFmpegSource2. You want to know how you can open Avisynth scripts in the aformentioned applications.

I think this can not be answered in general, but at least for Premiere Pro a plug-in exists:
http://urchin.earth.li/~tomford/avisynth/

See also:
http://forum.doom9.org/showthread.php?t=47194

[cretindesalpes]

but how can I make a fake avi to open it in this big programms like Premiere Pro. I tried makeavis and vfapi , but it didn't work.

Do you mean this (http://forum.doom9.org/showthread.php?t=133313)?

[torwart]

Thank you gyes for you answers. I think I'll find the information that I need in links,that you gave me.

[torwart]

AVFS is wrapper number 1 !!!!! Thank you once more!!!!!!!!!! :thanks:

[TheRyuu]

ffms2-mt-r411.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r411.7z)
ffms2-mt-r412-avs64-2.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r412-avs64-2.7z)

For avs64 (for use with 64bit avisynth) be sure to load with LoadCPlugin.

Edit: Uploaded fixed avs64 version.

[burfadel]

The 411 build from the link about doesn't seem to work properly for xvid AVI's, whereas the 408 build and earlier has no issues. I tried 411 with a mkv x264 file I did earlier and it worked fine, so it seems its only 411. The encoding crashed pretty quickly, and if I quickly jump quickly back and forth through staxrip's preview with 411 it ends up crashing too...

[Maccara]

I tried this version under linux/wine. It works well with H.264 and mpeg2 video, but cannot decode ffvhuff codec (tried avi and mov containers). It returns an error message : "No video stream found". Current stable version of ffms2 (2.14 vanilla) can decode the same files without problem.

Hmm. I got this same issue with x264 ffms decoding mkv (muxed with ffmpeg) containing vmw streams (x264 --demuxer lavf was fine). Indexing seemed to start ok but failed with that "no video stream found" immediately after encoding was supposed to start.

Versions were ffmpegsource svn trunk + ffmpeg svn trunk + x264 git trunk built on Jan 11.

I need to try if I can still replicate this.

[burfadel]

Neither the FFmpegsouce build 411 and the new 423 build work correctly, once indexed and the video loads, it crashes. I'm using Staxrip, and yes I did do everything correctly!!! This is with multiple source files, with no exisiting index files etc.

Sticking with 408 for now.

[TheFluff]

I tried this version under linux/wine. It works well with H.264 and mpeg2 video, but cannot decode ffvhuff codec (tried avi and mov containers). It returns an error message : "No video stream found". Current stable version of ffms2 (2.14 vanilla) can decode the same files without problem.

I'll take a look.

Neither the FFmpegsouce build 411 and the new 423 build work correctly, once indexed and the video loads, it crashes. I'm using Staxrip, and yes I did do everything correctly!!! This is with multiple source files, with no exisiting index files etc.

Sticking with 408 for now.

A lot of users (well, like three or four) are reporting crashing issues with TheRyuu's -mt builds, so I think he needs to fix his shit.

[burfadel]

Ah ok! Are they the builds on code.google.com/p/ffmpegsource ? They're the ones I were having issues with.

Are there other sites that keep the builds up to date? I was thinlking a weekly build wouldn't be a bad thing... i realise ffmpegsource2.14 is technically the latest release version, but that is quite old. At least with the weekly version, if anyone encounters an unknown problem it can be reported and listed quicker, and they can go back to using the previous weeks build (which isn't several months old)...

[TheFluff]

I tried this version under linux/wine. It works well with H.264 and mpeg2 video, but cannot decode ffvhuff codec (tried avi and mov containers). It returns an error message : "No video stream found". Current stable version of ffms2 (2.14 vanilla) can decode the same files without problem.

I can't reproduce this with my current build on some of my own ffvhuff files, so I guess it's been fixed (possibly in r410). If it still doesn't work for you, give me a small (10-20mb or so is enough) sample that fails for you.

Ah ok! Are they the builds on code.google.com/p/ffmpegsource ? They're the ones I were having issues with.

Are there other sites that keep the builds up to date? I was thinlking a weekly build wouldn't be a bad thing... i realise ffmpegsource2.14 is technically the latest release version, but that is quite old. At least with the weekly version, if anyone encounters an unknown problem it can be reported and listed quicker, and they can go back to using the previous weeks build (which isn't several months old)...

All -mt builds, and also all non-release builds on the googlecode page are TheRyuu's.

I'm actually 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.

[TheRyuu]

I've poked the ffmpeg-mt dev about the issue, apparently there may have also been some talk in #ffmpeg-devel about it although I don't know the details.

So I'm trying to figure out what the issue is with my ffmpeg-mt builds, vanilla builds (even mine) do not seem affected so they should be safe for the time being albeit a little slower on things like h264. :p

[burfadel]

Thanks, 426 works well :)

[ganymede]

I tried this version under linux/wine. It works well with H.264 and mpeg2 video, but cannot decode ffvhuff codec (tried avi and mov containers). It returns an error message : "No video stream found". Current stable version of ffms2 (2.14 vanilla) can decode the same files without problem.
I can't reproduce this with my current build on some of my own ffvhuff files, so I guess it's been fixed (possibly in r410). If it still doesn't work for you, give me a small (10-20mb or so is enough) sample that fails for you.
The problem is now fixed with your latest revision (r426). Thank you very much.

[sneaker_ger]

This sample (http://www.mediafire.com/?v2benur48ewkor0) gets very jerky if I specify fpsnum=24000 and fpsden=1001 using r426.

[TheRyuu]

This sample (http://www.mediafire.com/?v2benur48ewkor0) gets very jerky if I specify fpsnum=24000 and fpsden=1001 using r426.

Although the behavior probably isn't what we want (and I guess should be fixed), specifying fpsnum/fpsden is meant for vfr->cfr conversions. As far as I can tell the sample is purely cfr and you don't get the jerkiness if you don't specify the fpsnum/fpsden.

Also made a few builds while doom9 was down for a bit. I rolled back ffmpeg-mt to a December version which fixes the two issues people were having with it (I believe the issues have been addressed in the ffmpeg-mt src).

ffms2-mt-r430.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r430.7z)
ffms2-mt-r430-avs64.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r430-avs64.7z)

Some vanilla ffmpeg builds if you want them (dunno why):
ffms2-r430.7z (http://ffmpegsource.googlecode.com/files/ffms2-r430.7z)
ffms2-r430-avs64.7z (http://ffmpegsource.googlecode.com/files/ffms2-r430-avs64.7z)

[sneaker_ger]

Although the behavior probably isn't what we want (and I guess should be fixed), specifying fpsnum/fpsden is meant for vfr->cfr conversions. As far as I can tell the sample is purely cfr and you don't get the jerkiness if you don't specify the fpsnum/fpsden.

But if it already fails on CFR content, why would it suddenly work fine on VFR content? Shouldn't both be affected in exactly the same way?

2.14 and r375 work fine, problem appears with 411 for the first time. (all mt)

[TheFluff]

But if it already fails on CFR content, why would it suddenly work fine on VFR content? Shouldn't both be affected in exactly the same way?

2.14 and r375 work fine, problem appears with 411 for the first time. (all mt)

You should've said it was a regression earlier. I was going to have a look at it anyway but now it suddenly became a lot more important.

e: pretty sure Plorkyeran broke it in r385 (http://code.google.com/p/ffmpegsource/source/detail?r=385).

[sneaker_ger]

Yes, my fault.

[TheRyuu]

But if it already fails on CFR content, why would it suddenly work fine on VFR content? Shouldn't both be affected in exactly the same way?

2.14 and r375 work fine, problem appears with 411 for the first time. (all mt)

Status update, it was indeed broken in r385 as fluff said (ffmpeg-mt had nothing to do with it).

[Plorkyeran]

Fixed in r432.

[TheFluff]

FFMS 2.15 is now released; you can grab it from the Google Code page (http://code.google.com/p/ffmpegsource/).

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 <tt>cachefile</tt> 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.

Edit: ATTN the three of you who downloaded this before 00:35 GMT: your version doesn't handle zlib compressed streams in MKV correctly. Redownload it to fix the issue.

[b66pak]

thanks a lot...
_

[Maccara]

Thanks for the update!

Edit: ATTN the three of you who downloaded this before 00:35 GMT: your version doesn't handle zlib compressed streams in MKV correctly. Redownload it to fix the issue.

FYI, from the "last minute" fixes (SVN 444), probably not intended: :)

src/core/utils.cpp: In function 'void safe_aligned_reallocz(T*&, size_t, size_t)':
src/core/utils.cpp:233: error: there are no arguments to 'min' that depend on a template parameter, so a declaration of 'min' must be available
src/core/utils.cpp:233: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
src/core/utils.cpp: In function 'void safe_aligned_reallocz(T*&, size_t, size_t) [with T = uint8_t]':
src/core/utils.cpp:262: instantiated from here
src/core/utils.cpp:233: error: 'min' was not declared in this scope

(on mingw gcc 4.4.5)

[burfadel]

What FFMPEG revision is FFMS 2.15 based on? for both the normal and MT version of FFMS?

Thanks

[TheRyuu]

What FFMPEG revision is FFMS 2.15 based on? for both the normal and MT version of FFMS?

Thanks

ffmpeg-mt uses the Dec. 15th update (http://gitorious.org/ffmpeg/ffmpeg-mt/commit/2bbb64dae018cbb09ea47a6bdcb184f551136c26) (basically the last one that nothing breaked on).

The vanilla ffmpeg builds I would imagine use whatever was the last revision before the files were posted.

[burfadel]

Ah ok! well, 2 months for FFMPEG = lots of changes, I think I'll use the standard one! Multithreaded ffms doesn't really affect me, I usually encode 2 videos at once which equals 100 percent CPU usage, speed wise its not noticeable since Staxrip defaults x264 etc to the lowest priority. Parallel encoding files seems more effective than multithreading, since there are still stages in the pipeline that are slowed down either by processing requirements or being unoptimised and/or single threaded.

[TheFluff]

Thanks for the update!



FYI, from the "last minute" fixes (SVN 444), probably not intended: :)

src/core/utils.cpp: In function 'void safe_aligned_reallocz(T*&, size_t, size_t)':
src/core/utils.cpp:233: error: there are no arguments to 'min' that depend on a template parameter, so a declaration of 'min' must be available
src/core/utils.cpp:233: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
src/core/utils.cpp: In function 'void safe_aligned_reallocz(T*&, size_t, size_t) [with T = uint8_t]':
src/core/utils.cpp:262: instantiated from here
src/core/utils.cpp:233: error: 'min' was not declared in this scope

(on mingw gcc 4.4.5)

Fixed, I think.

[sneaker_ger]

Setting fpsnum and fpsden seems to work correctly now.

[Maccara]

Fixed, I think.

Yeah, that works. Thanks!

[b66pak]

@TheFluff does this improvements go to x264's ffms too? (especially the timebase/timescale fix)...may be in the next release?
_

[TheFluff]

That depends on who compiles x264 and what version of FFMS they're linking against. JEEB usually uses the SVN HEAD so in his builds the changes should have been in for a long time, but I dunno about anyone else.

[b66pak]

it looks like everybody (JEEB, Komisar, X5-452) still use FFMS2 2.14.2 (svn-432)...x264.nl is using svn-431...
_

[b66pak]

@TheFluff x264.nl is using now "2011-02-19 00:59:01 SVN: ffmpegsource revision 448" but timescale/timebase is still returning HUGE values...can you investigate?

source:
Seems stream 0 codec frame rate differs from container frame rate: 47.95 (20000000/417083) -> 23.98 (20000000/834166)

x264 info:
[21:56:09.312] ffms [info]: 1280x720p 1:1 @ 24000/1001 fps (vfr)

resulting mp4 (x264 gpac muxer):
Track # 1 Info - TrackID 1 - TimeScale 1000000000

if i use ffmpegsource-2.15 for indexing i get the correct timescale/timebase 24000/1001...
_

[TheFluff]

@TheFluff x264.nl is using now "2011-02-19 00:59:01 SVN: ffmpegsource revision 448" but timescale/timebase is still returning HUGE values...can you investigate?

source:
Seems stream 0 codec frame rate differs from container frame rate: 47.95 (20000000/417083) -> 23.98 (20000000/834166)

x264 info:
[21:56:09.312] ffms [info]: 1280x720p 1:1 @ 24000/1001 fps (vfr)

resulting mp4 (x264 gpac muxer):
Track # 1 Info - TrackID 1 - TimeScale 1000000000

if i use ffmpegsource-2.15 for indexing i get the correct timescale/timebase 24000/1001...
_

I don't understand what you're saying at all nor what the problem is nor if it's likely that it's a problem in ffms2 or not. What is "source" and where is it printing that message? It looks like ffmpeg, but who knows? What do you mean by "if I use ffmpegsource-2.15 for indexing"?

Also, how about a sample file?

[b66pak]

"source" is the source file: a mkv with a near 24000/1001 fps encoded using directshowsource...see this (http://forum.doom9.org/showthread.php?p=1476069#post1476069) for more info...
the report is from ffmpeg: it outline the timescale/timebase of the "source"...

if i use your latest fmpegsource-2.15 to index the "source" and make an avs and feed it to the latest x264.nl build i get a corrected timescale/timebase witch is very good! (20000000/834166 > 24000/1001)...

the question is why can't x264 do the same if its using the latest ffms? can you investigate?
_

[TheFluff]

"source" is the source file: a mkv with a near 24000/1001 fps encoded using directshowsource...see this (http://forum.doom9.org/showthread.php?p=1476069#post1476069) for more info...
the report is from ffmpeg: it outline the timescale/timebase of the "source"...

if i use your latest fmpegsource-2.15 to index the "source" and make an avs and feed it to the latest x264.nl build i get a corrected timescale/timebase witch is very good! (20000000/834166 > 24000/1001)...

the question is why can't x264 do the same if its using the latest ffms? can you investigate?
_

I haven't looked at the file at all but judging from the description it seems pretty simple. There is no such thing as a CFR Matroska file; there is no real "timebase" in the container, and no container-level framerate either. All frames have timestamps in wallclock nanoseconds (by default; you can change the precision/timecode scale at mux-time if you want to). Hence FFMS2 reports the timebase for MKV's as 1/1000000 or something silly like that (assuming the default timecode scale) because pretty much what it is.

In order to get a "constant" framerate for MKV files that can be reported to things that aren't VFR-aware (like Avisynth), FFMS2 calculates a framerate based on the average frame duration, and then checks if it's "close enough" to a well-known NTSC fraction, and if it is, the otherwise huge fractional value gets corrected to the usual 24000/1001 or 30000/1001.

In this case, as you can see from what x264 says about the framerate, the behavior described above was triggered and the reported "constant" framerate is 24000/1001 (note how x264 says "vfr"; it knows the reported framerate may be complete bogus). The timebase is still 1000000/1, though, and apparently x264 decided to stick with that and pass it through to its MP4 muxer, since it cannot know if there are uneven frame durations or not.

The reason you get a timebase of 24000/1001 when doing it via Avisynth is that Avisynth doesn't store a separate timebase value at all; since it only supports CFR, all frames have the same duration and there's no reason to have a separate timebase. In other words, the framerate is the same as the timebase and the frame number is functionally equivalent with a PTS. x264 never sees the original timebase from the MKV at all when using Avisynth input.

If you know and can GUARANTEE that your source is CFR, you can always force a timebase in one way or another, but if you cannot, the only really correct way to handle it is to keep the original timebase. You could also write some more or less complex algorithm that inspects all frame durations, determines the smallest possible timebase and then converts all timestamps to that, but that will probably cause all sorts of other interesting issues later down the chain instead.


I hope you're sufficiently confused, since you did ask for it. What I'd really like to know though is what real-world problems this issue causes you.

[b66pak]

thank you for the explanation...the problem is that mp4 files with huge timescale/timebase can't be played on any device other than PCs (QTime excluded) and NMTs...
_

[b66pak]

here (http://www.mediafire.com/?dqr1ff7abcj8b8j) is a small sample...

on the same "source" mkv i forced the lavf demuxer (instead of ffms - default) and i get a more friendly timescale:
Track # 1 Info - TrackID 1 - TimeScale 1000

now i and really confused...ffms+x264 = big timescale in mp4...lavf+x264 = normal timescale in mp4...
_

[TheFluff]

I have no idea what x264 does or does not do with the lavf demuxer or what lavf might do internally with regards to the timebase of Matroska files. FFMS2 does not use lavf for Matroska.

[b66pak]

kenuri-_9 posted an explanation here (http://forum.doom9.org/showthread.php?p=1479790#post1479790):
_

[lintran]

I got problem with both 2.15 vanila and mt version when index this file (http://wdmp.rd.llnwd.net/wdsmp/IAN4/USExtLook/IANF_USExtLook_1080.mov).
My avs script
----------------------------------------------------------
LoadPlugin("D:\ffmpegsource-2.15\ffms2.dll")
FFVideoSource("D:\thisfile.mov",fpsnum=24000,fpsden=1001)
----------------------------------------------------------
When play .avs by MPC, it was broken when video nearly end.
But everything OK when using 2.14 version.
Could you please figure it out?
Thank you.