FFmpegSource - Page 50

Chikuzen · 6th December 2010, 22:49

@kypic
FFMS use libavcodec for decoding. so, it is possible if libavcodec supports UtVideo.
but AFAIK, there is no person who is working at present for that.

If you don’t want to use AVISource or if your source is not RGB, then you should use not UtVideo but ffvhuff.
The compressibility of ffvhuff is almost equal to UtVideo. and, it may be as fast as UtVideo on decoding if you use mt version of ffms.
Alexander Strange (developper of ffmpeg-mt) enabled MultiThread decoding of ffvhuff.

If you don't believe this, then you should try Komisar's x264 build.
his x264 binary uses ffmpeg-mt for lavf/ffms input.

lintran · 7th December 2010, 09:12

Hi,
Can i use FFMS2 to index mov file (h264/aac like apple trailers) with script like that
LoadPlugin("path\ffms2.dll")
FFVideoSource("path\xxx.mov",colorspace="YV12")
Or I'll have to remux mov to mp4 or mkv then use FFMS2?
Thank you so much.

kypec · 7th December 2010, 12:04

@ TheFluff: I see, thanks for clarification.
@ Chikuzen: Well, I just wanted to avoid the necessary step of creating AVS (though the most simple one like you proposed) and feed my source file directly into x264. However, I just experimented with Lossless mode of x264 (--qp 0) and as it seems I won't be needing UtVideo after all. It certainly is good and fast codec but compressibility-wise it just can't compete with Lossless AVC which x264 is offering. I've posted my observations in separate thread.

TheFluff · 7th December 2010, 13:43

Quote:

Originally Posted by lintran

Hi,
Can i use FFMS2 to index mov file (h264/aac like apple trailers) with script like that
LoadPlugin("path\ffms2.dll")
FFVideoSource("path\xxx.mov",colorspace="YV12")
Or I'll have to remux mov to mp4 or mkv then use FFMS2?
Thank you so much.

Newer .mov files with h264/aac are just MP4 in disguise so it should work just fine. Older .mov is a mystery.

lintran · 7th December 2010, 14:17

Quote:

Originally Posted by TheFluff

Newer .mov files with h264/aac are just MP4 in disguise so it should work just fine. Older .mov is a mystery.

Thank you TheFluff!
Did you mean if mov files with h264/aac are "newer" mov and are just MP4 in disguise so i can use ffms2 to index them without any problem?
Otherwise, all mov files (not h264) are called "older" .mov?

TheFluff · 7th December 2010, 16:29

There's no trivial way to tell the two apart, as far as I know. FFMS2 should work with both, and as long as they're h264/aac it should be just as reliable as with MP4. If they contain anything else it's anyone's guess as to how well it works. Most likely it'll open them but I have no idea if you can get frameaccurate seeking. In theory it should work but it depends on libavformat quirks.

lintran · 7th December 2010, 17:33

Quote:

Originally Posted by TheFluff

There's no trivial way to tell the two apart, as far as I know. FFMS2 should work with both, and as long as they're h264/aac it should be just as reliable as with MP4. If they contain anything else it's anyone's guess as to how well it works. Most likely it'll open them but I have no idea if you can get frameaccurate seeking. In theory it should work but it depends on libavformat quirks.

Thank you. But when i use MEGUI File Indexer to index mov (h264/aac), i've got script like that

Code:

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("path/xxx.mov",colorspace="YV12")

Then enqueue it, i got msg Incorrect Colorspace from megui:
Name: 1.jpg
Views: 1643
Size: 23.0 KB

I click Yes, and still got this msg:
Name: 2.jpg
Views: 1562
Size: 28.7 KB

I've checked my .avs file with info() and it showed my video colourspace is YV12.
So i dont know how to fix this problem. I found some ppl got this error like me, but didnt see any solution to fix it.
Could you please tell me how to fix this problem?
Thanks very much
--------------------------------
PROBLEM SOLVED, i've update Megui to lastest build and everything is OK now.
Thank you all

lintran · 7th December 2010, 20:39

Quote:

Originally Posted by TheFluff

Newer .mov files with h264/aac are just MP4 in disguise so it should work just fine.

Dear TheFluff!
How do i know it should work fine?
I mean: what does "work fine" mean? Does it mean when index by FFMS2 then load into avisynth, after that video and audio are in synchronous? If yes, so I just have to check video and audio are out of sync or not to know it "work fine" or not?
Thank you.

TheRyuu · 8th December 2010, 10:55

ffms2-mt-r375.7z

Fixes a bug which would cause the index to be recreated every time (introduced r372), ffmpeg-mt flavor.

WILLIS · 8th December 2010, 18:14

Quote:

Originally Posted by TheRyuu

ffms2-mt-r375.7z

Fixes a bug which would cause the index to be recreated every time (introduced r372), ffmpeg-mt flavor.

Having some trouble reaching that dl link...is there an alternate link I can snatch the file from? thx

LoRd_MuldeR · 9th December 2010, 01:20

Quote:

Originally Posted by WILLIS

Having some trouble reaching that dl link...is there an alternate link I can snatch the file from? thx

Here you go:
http://www.mediafire.com/file/ft6ek4...ms2-mt-r375.7z

lintran · 9th December 2010, 18:26

Quote:

Originally Posted by TheRyuu

ffms2-mt-r375.7z

Fixes a bug which would cause the index to be recreated every time (introduced r372), ffmpeg-mt flavor.

Is ffms2-mt-r375 newer or older than ffmpegsource-2.14-mt? Should I use r375 or 2.14?
Thank you.

9th December 2010, 23:30

2.14 = release version, r375 designates SVN version ...

2.14 is a "stable" release, r375 is the most recent, but developmental build (so use with caution, noting any bugs you may find here) ...

When an SVN ("r" designation) version is determined to be "stable", then it will be released as 2.15 in due course (but of course the SVN builds can continue) ...

It's the way most OSS works (release version are stable, but lagging behind "SVN" version for trial features/updates/bug fixes) ....

So back to the question of which to use:
It's your choice!
Do you need something stable that works with almost everything, or do you need the featureset of the SVN, but are happy to risk crashing, macroblocking, bugs, etc (that you are happy to report to the devs) ...

7ek
PS just to clarify, not all SVN builds are tempermental, keep in mind the goal is to better the OSS code via "trial and error", so some SVN builds work flawlessly, some have issues

lintran · 10th December 2010, 09:23

Quote:

Originally Posted by 7ekno

2.14 = release version, r375 designates SVN version ...

2.14 is a "stable" release, r375 is the most recent, but developmental build (so use with caution, noting any bugs you may find here) ...

When an SVN ("r" designation) version is determined to be "stable", then it will be released as 2.15 in due course (but of course the SVN builds can continue) ...

It's the way most OSS works (release version are stable, but lagging behind "SVN" version for trial features/updates/bug fixes) ....

So back to the question of which to use:
It's your choice!
Do you need something stable that works with almost everything, or do you need the featureset of the SVN, but are happy to risk crashing, macroblocking, bugs, etc (that you are happy to report to the devs) ...

7ek
PS just to clarify, not all SVN builds are tempermental, keep in mind the goal is to better the OSS code via "trial and error", so some SVN builds work flawlessly, some have issues

Thank you ^^, I've got it

TheRyuu · 11th December 2010, 21:36

Quote:

Originally Posted by 7ekno

2.14 = release version, r375 designates SVN version ...

2.14 is a "stable" release, r375 is the most recent, but developmental build (so use with caution, noting any bugs you may find here) ...

When an SVN ("r" designation) version is determined to be "stable", then it will be released as 2.15 in due course (but of course the SVN builds can continue) ...

It's the way most OSS works (release version are stable, but lagging behind "SVN" version for trial features/updates/bug fixes) ....

So back to the question of which to use:
It's your choice!
Do you need something stable that works with almost everything, or do you need the featureset of the SVN, but are happy to risk crashing, macroblocking, bugs, etc (that you are happy to report to the devs) ...

7ek
PS just to clarify, not all SVN builds are tempermental, keep in mind the goal is to better the OSS code via "trial and error", so some SVN builds work flawlessly, some have issues

I didn't want to make a build for 374 because it was 'unstable' in a sense there was regression introduced at r372. Generally I'll make builds that are probably 'stable'.

TheRyuu · 12th December 2010, 02:18

ffms2-mt-r375-avs64-2.7z

No idea if it works, I don't use avs64.

Actually have the indexing fix. Forgot that avs64 was it's own branch.
Anyone who got the previous version please re-download this version.

TheRyuu · 15th December 2010, 12:48

ffms2-mt-r376-x64.7z

New experimental version of 64bit ffms2. This one is compiled with msvc instead of the avisynth c plugin way via mingw (so load it via normal LoadPlugin("ffms2.dll").

Note: Only works with vista+ (vista or greater) machines.

Edit: Build in above post is still recommended over this one, but feel free to test it if you want to.

kemuri-_9 · 16th December 2010, 01:20

apparently the above is using ramiro's fake pthreads wrapping the windows api,
and i already noticed several issues with it, so if there's weird crashes in this binary, it's not my problem.

TheRyuu · 16th December 2010, 01:33

Quote:

Originally Posted by kemuri-_9

apparently the above is using ramiro's fake pthreads wrapping the windows api,
and i already noticed several issues with it, so if there's weird crashes in this binary, it's not my problem.

Indeed, one issue is it apparently doesn't release handles for threads.
Suppose it's more proof of concept then anything.

One that that would work correctly would be a vanilla ffmpeg build using w32threads (would have no pthreads issues since it doesn't use that). Wouldn't be as fast though

.

Edit: The avs64 build which uses the avisynth c interface is still recommended over the build I posted two posts up due to some issues, but feel free to test it out if you want too.

TheFluff · 8th January 2011, 21:50

http://mod16.org/ffms2/ffms2-r408.7z

Go test this. Plorkyeran rewrote most of the audio code from scratch, so it should actually be sample-accurate like it claims to be now, at least with most containers and codecs. Notable exceptions are AC3 and MP3 since their libavcodec decoders seem to be, well, broken. Some other changes as well.

7th December 2010, 12:04	#983 \| Link
kypec User of free A/V tools Join Date: Jul 2006 Location: SK Posts: 826	@ TheFluff: I see, thanks for clarification. @ Chikuzen: Well, I just wanted to avoid the necessary step of creating AVS (though the most simple one like you proposed) and feed my source file directly into x264. However, I just experimented with Lossless mode of x264 (--qp 0) and as it seems I won't be needing UtVideo after all. It certainly is good and fast codec but compressibility-wise it just can't compete with Lossless AVC which x264 is offering. I've posted my observations in separate thread. Last edited by kypec; 7th December 2010 at 13:46.

9th December 2010, 23:30	#993 \| Link
7ekno Guest Posts: n/a	2.14 = release version, r375 designates SVN version ... 2.14 is a "stable" release, r375 is the most recent, but developmental build (so use with caution, noting any bugs you may find here) ... When an SVN ("r" designation) version is determined to be "stable", then it will be released as 2.15 in due course (but of course the SVN builds can continue) ... It's the way most OSS works (release version are stable, but lagging behind "SVN" version for trial features/updates/bug fixes) .... So back to the question of which to use: It's your choice! Do you need something stable that works with almost everything, or do you need the featureset of the SVN, but are happy to risk crashing, macroblocking, bugs, etc (that you are happy to report to the devs) ... 7ek PS just to clarify, not all SVN builds are tempermental, keep in mind the goal is to better the OSS code via "trial and error", so some SVN builds work flawlessly, some have issues Last edited by 7ekno; 9th December 2010 at 23:37.

12th December 2010, 02:18	#996 \| Link
TheRyuu warpsharpened Join Date: Feb 2007 Posts: 787	ffms2-mt-r375-avs64-2.7z No idea if it works, I don't use avs64. Actually have the indexing fix. Forgot that avs64 was it's own branch. Anyone who got the previous version please re-download this version. Last edited by TheRyuu; 12th December 2010 at 02:50.

15th December 2010, 12:48	#997 \| Link
TheRyuu warpsharpened Join Date: Feb 2007 Posts: 787	ffms2-mt-r376-x64.7z New experimental version of 64bit ffms2. This one is compiled with msvc instead of the avisynth c plugin way via mingw (so load it via normal LoadPlugin("ffms2.dll"). Note: Only works with vista+ (vista or greater) machines. Edit: Build in above post is still recommended over this one, but feel free to test it if you want to. Last edited by TheRyuu; 18th December 2010 at 23:09.

16th December 2010, 01:20	#998 \| Link
kemuri-_9 Compiling Encoder Join Date: Jan 2007 Posts: 1,348	apparently the above is using ramiro's fake pthreads wrapping the windows api, and i already noticed several issues with it, so if there's weird crashes in this binary, it's not my problem. __________________ custom x264 builds & patches \| F@H \| My Specs

6th December 2010, 22:49	#981 \| Link
Chikuzen typo lover Join Date: May 2009 Posts: 595	@kypic FFMS use libavcodec for decoding. so, it is possible if libavcodec supports UtVideo. but AFAIK, there is no person who is working at present for that. If you don’t want to use AVISource or if your source is not RGB, then you should use not UtVideo but ffvhuff. The compressibility of ffvhuff is almost equal to UtVideo. and, it may be as fast as UtVideo on decoding if you use mt version of ffms. Alexander Strange (developper of ffmpeg-mt) enabled MultiThread decoding of ffvhuff. If you don't believe this, then you should try Komisar's x264 build. his x264 binary uses ffmpeg-mt for lavf/ffms input.

7th December 2010, 09:12	#982 \| Link
lintran Registered User Join Date: Aug 2008 Posts: 65	Hi, Can i use FFMS2 to index mov file (h264/aac like apple trailers) with script like that LoadPlugin("path\ffms2.dll") FFVideoSource("path\xxx.mov",colorspace="YV12") Or I'll have to remux mov to mp4 or mkv then use FFMS2? Thank you so much.

7th December 2010, 16:29	#986 \| Link
TheFluff Excessively jovial fellow Join Date: Jun 2004 Location: rude Posts: 1,100	There's no trivial way to tell the two apart, as far as I know. FFMS2 should work with both, and as long as they're h264/aac it should be just as reliable as with MP4. If they contain anything else it's anyone's guess as to how well it works. Most likely it'll open them but I have no idea if you can get frameaccurate seeking. In theory it should work but it depends on libavformat quirks.

8th December 2010, 10:55	#989 \| Link
TheRyuu warpsharpened Join Date: Feb 2007 Posts: 787	ffms2-mt-r375.7z Fixes a bug which would cause the index to be recreated every time (introduced r372), ffmpeg-mt flavor.

8th January 2011, 21:50	#1000 \| Link
TheFluff Excessively jovial fellow Join Date: Jun 2004 Location: rude Posts: 1,100	http://mod16.org/ffms2/ffms2-r408.7z Go test this. Plorkyeran rewrote most of the audio code from scratch, so it should actually be sample-accurate like it claims to be now, at least with most containers and codecs. Notable exceptions are AC3 and MP3 since their libavcodec decoders seem to be, well, broken. Some other changes as well.