FFmpegSource

[the_weirdo]

The same happens when I let x264 convert range from PC to TV with FRAPS I420 videos.
The range conversion of AviSynth/ffms 2.16 is the only thing that works.

Range of the output file has to be TV because most decoders can't deal right with non-RGB video with PC range.

Maybe there're flaws from your workflow. How about replace ConvertTo... line with ColorYUV(level="PC->TV")? What is your x264 command line? Which method you're using to take those screenshots?

[TheFluff]

I think FFMS 2.16 actually had another bug too that made it output RGB32. ConvertToYV12(matrix="foo") on YV12 material throws an error, so if that worked in your 2.16 script then FFMS2 definitely wasn't outputting YV12. Try this:
FFVideoSource("derp.avi", colorspace="RGB32")
ConvertToYV12(matrix="Rec709")

When I open that in VirtualDub, I get an image that matches your 2.16 screenshot on the reds, but on the other hand it looks less greenish overall. What did you screenshot with?

But yes, in the end I think Fraps does use its own color matrix that doesn't match Rec 709 perfectly.

[aufkrawall]

I think FFMS 2.16 actually had another bug too that made it output RGB32. ConvertToYV12(matrix="foo") on YV12 material throws an error, so if that worked in your 2.16 script then FFMS2 definitely wasn't outputting YV12. Try this:
FFVideoSource("derp.avi", colorspace="RGB32")
ConvertToYV12(matrix="Rec709")

Your script works perfectly, thank you very much. :goodpost:
It also works great with little adjustment when converting FRAPS RGB source to I444.
Original FRAPS video and FRAPS decoder:
http://www.ld-host.de/uploads/thumbnails/e42ca54250a8da426c52d5ce178b4429.png (http://www.ld-host.de/show/e42ca54250a8da426c52d5ce178b4429.png)

LAV x264:
http://www.ld-host.de/uploads/thumbnails/9a9135b11432c3d8b90bacea7f844f0e.png (http://www.ld-host.de/show/9a9135b11432c3d8b90bacea7f844f0e.png)

Windows Media Player x264:
http://www.ld-host.de/uploads/thumbnails/83d14533886a71ca7d204eeaec081d72.png (http://www.ld-host.de/show/83d14533886a71ca7d204eeaec081d72.png)

All three look almost identical (I guess WMP has some sharpening filter active *sigh*).


When I open that in VirtualDub, I get an image that matches your 2.16 screenshot on the reds, but on the other hand it looks less greenish overall. What did you screenshot with?

I also got some weird results with VirtualDub, hence I used the save picture function of MPC HC (it extracts the source's frame).
Another advantage is that the screenshot matches the real picture drawed by the renderer to 100% in any case. :)
For WMP I had to make a capture of the whole screen. :D

[Pat357]

It would be really, really very nice if we could have the C version of this plugin soon : something like FFMS2-2.17-avs-cplugin.7z :D
Any idea when it will be available on the download area ?

Not that I'm looking for it, but why has there not been a 64bit version from the C plugin ? Was the "avisynth-interface" never made for x64 use ? Just curious...

Keep up the great work guys ! :thanks:

[TheRyuu]

It would be really, really very nice if we could have the C version of this plugin soon : something like FFMS2-2.17-avs-cplugin.7z :D
Any idea when it will be available on the download area ?

Not that I'm looking for it, but why has there not been a 64bit version from the C plugin ? Was the "avisynth-interface" never made for x64 use ? Just curious...

Keep up the great work guys ! :thanks:

ffms-2.17-cplugin.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17-cplugin.7z)

Archive contains both 32-bit and 64-bit versions.
Primary use of the cplugin version is for those who want access to the extra colorspaces provided in Avisynth 2.6 (it is backward compatible with 2.5).

[bencahill]

This is really awesome, except that I'm getting artifacts on my Canon T2i footage in moving areas. (H.264 MOV)

Source:
http://ompldr.org/tY2lldA (http://ompldr.org/vY2lldA)
FFMS:
http://ompldr.org/tY2lldg (http://ompldr.org/vY2lldg)

I'd love to use this because it's fast and doesn't take up space (e.g. demuxing the h.264 stream), but because of this I'm using MPEGAutoIndexSource() for the time being (which is slower and takes space).

Any idea as to why this is happening? If you need me to test more, just let me know.

Thanks!

P.S. I searched, but couldn't find anything on this issue. If it's already been discussed, my apologies.

[TheFluff]

H.264 in MOV should work, AFAIK. Post sample (it doesn't need to be big, ~50MB is more than enough) and I'll take a look.

[Yellow_]

No problems with 2.17 32bit from #1438 http://forum.doom9.org/showthread.php?p=1553391#post1553391 with Canon 550D/T2i MOVs, well at least not 1920x1088 25p.

[bencahill]

Oh yes, I forgot to mention: that clip was obtained here (http://movies.dpreview.com.s3.amazonaws.com/canon_eos550d/Bus.MOV), so you can test it also.

It's 720p25, but I was getting the same with my 1080p30, and also with H.264 video from a Kodak Zi8. I'm guessing it's something with my setup?

I've used Avisynth 2.5.8 ST, and 2.6 MT (http://forum.doom9.org/showthread.php?t=148782). Using latest FFMS (2.17 with no suffix) on WinXP Home SP3 32-bit.

Thanks for your time. :)

[TheFluff]

File breaks ffmpeg/avconv too so it's not our fault this time. Remuxing with mkvmerge gives this warning:
Warning: 'E:\ffms2testclips\Bus h264 canon t2i.MOV' track 0: The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.
Resulting file has the same issue.

I think you should open a bugreport with ffmpeg.

[Yellow_]

MKVMerge has said that for as long as I remember whenever I've used it, however remuxing to mkv via ffmpeg on the CLI gives no such warning, so might be a MKVMerge thing possibly.

In the years I've had a Canon video shooting DSLR and last three major releases of ffmpeg I've never seen artifacts like that nor from numerous h264 shooting compacts.

What are you opening the avs files with? AVSPmod for example I see no problems with my sources or the bus.MOV off the dpreview site in the link above, it's fine.

I think it's your setup.

[TheFluff]

MKVMerge has said that for as long as I remember whenever I've used it, however remuxing to mkv via ffmpeg on the CLI gives no such warning, so might be a MKVMerge thing possibly.

In the years I've had a Canon video shooting DSLR and last three major releases of ffmpeg I've never seen artifacts like that nor from numerous h264 shooting compacts.

What are you opening the avs files with? AVSPmod for example I see no problems with my sources or the bus.MOV off the dpreview site in the link above, it's fine.

I think it's your setup.

I could reproduce the issue with FFMS2 in debug mode yesterday; it's interesting that you can't. Are you using 2.17?

[Yellow_]

Yes, 2.17 for a few days, 2.15 before that. Just checked with 2.15 and no problem there either with the bus.MOV source.

**EDIT**

Another test, some h264AVC at 1920x1080 29.971 fps off a Samsung Compact in a mp4 no problem, even jumping about the stream no decoding errors.

[bencahill]

What are you opening the avs files with? AVSPmod for example I see no problems with my sources or the bus.MOV off the dpreview site in the link above, it's fine.

I'm using VirtualDub 1.8.8 (portable version from portableapps.com).

[Yellow_]

Portable version? I guess you have good reason to use it from there but Virtualdub's portable anyway, no install necessary, can just download from the authors site put it on a memory stick and run the .exe from anywhere?

Same with Gimp, VLC, mplayer, etc have them all on a memory stick.

I'd try it out from there but I don't understand why I have to install Virtualdub to use it, in fact refuse to, never done that in 10yrs of using it :-)

Have you tried AVSPmod or Virtualdub from the authors site as an alternative?

[StainlessS]

One of the main ideas behind PortableApps is that the app should leave no trace of ever
being used on a machine and not interfere with the owners settings in the
registry if that app is already installed on that system.
EDIT: In reality, the apps do not always conform to the ideal.

[TheFluff]

It's not related to the VDub version, it's a lavc decoding error. It prints a ton of junk to the console, like
[h264 @ 042117A0]missing picture in access unit
[h264 @ 04814BC0]concealing 8160 DC, 8160 AC, 8160 MV errors
[h264 @ 04813AA0]concealing 8160 DC, 8160 AC, 8160 MV errors
[h264 @ 00999C80]negative number of zero coeffs at 119 67
[h264 @ 00999C80]error while decoding MB 119 67
[h264 @ 00999C80]concealing 50 DC, 50 AC, 50 MV errors
[h264 @ 04814BC0]Invalid level prefix
[h264 @ 04814BC0]error while decoding MB 119 67
[h264 @ 04814BC0]concealing 50 DC, 50 AC, 50 MV errors

etc etc.

But I figured out why it works for Yellow_ but not for me or bencahill; it turns out it's lavc's multithreaded decoding that's broken on this file (what a surprise). ffvideosource("derp.mov",threads=1) works fine.

[the_weirdo]

It seems that decoding error has been fixed in latest FFmpeg git master (don't know about Libav). I tested that clip with my own FFMS2 build (compile against ffmpeg's libs) and didn't get any broken frames.

[Yellow_]

StainlesS thanks for explanation.

re. lavc yes I'm running all Windows apps on Linux through Wine and don't use multithreading although I'm sure others may be doing so via Wine. I kinda keep things simple out of ignorance rather than try getting more out of performance. If it works simple then I stick with it. :-)

[Chikuzen]

File breaks ffmpeg/avconv too so it's not our fault this time. Remuxing with mkvmerge gives this warning:


Using CTTS with Baseline profile is a spec violation.
I think you should open a bugreport with MKVToolNix :p

[Snowknight26]

FFMS returns an error along the lines of "Insanity detected: decoder returned an empty frame" for this (http://stfcc.org/misc/ffmpegsource.empty.frame.mkv) sample. ffmpeg/ffplay/everything else based off ffmpeg/libav plays it fine.

On a related note, FFMS returns mangled timestamps for this (http://stfcc.org/misc/ffmpegsource.mangled.timestamps.ts) sample. The timecode file ffindex writes shows that multiple frames are displayed at the same time, which x264 doesn't seem to like.

[pandv2]

What's the correct method to deduce the display dimensions for a video?.

mplayer displays a video with 1280*720. MediaInfo reports it 960*720 with a Display ratio of 16:9.

FFMS (last stable version) returns (I get the frame 0):

FFMS_Frame.EncodedWidth = 960
FFMS_Frame.EncodedHeight = 720
FFMS_Frame.ScaledWidth = -1 (960 after the call to FFMS_SetOutputFormatV2)
FFMS_Frame.ScaledWidth = -1 (720 after the call to FFMS_SetOutputFormatV2)
FFMS_VideoProperties.SARDen = 691200
FFMS_VideoProperties.SARNum = 921600

I can't find the system to deduce 1280*720 (or another numbers with the same ratio) from the information obtained from FFMS.

[LigH]

Well, it was encoded with 960 pixels width; but it was given an SAR which is not 1:1, therefore the displayed dimensions won't match the encoded dimensions. 1280 pixels width is probably correct then.

[TheFluff]

SARNum and SARDen are the numerator and denominator of a fractional number that defines the Sample Aspect Ratio, i.e. the ratio between the width and the height of a single pixel.

Use the following relation to calculate the Display Aspect Ratio (DAR; the familiar 4:3 or 16:9 ratios) and/or the corresponding width/height:

SARNum DARNum * encoded_height
------ = -----------------------
SARDen DARDen * encoded_width


In your case, the SAR and encoded width/height are known but you want to know the DAR. We multiply both sides of the equation with the reciprocal of encoded_height/encoded_width:

SARNum * encoded_width DARNum
----------------------- = ------
SARDen * encoded_height DARDen

Fill in the numbers and we get:

921600 * 960 884736000
------------ = ---------
691200 * 720 497664000

884736000/497664000 is not a very nice-looking number, but simplify it (by getting rid of all the zeroes and then dividing both numerator and denominator by 55296) and you get the nice and friendly fraction 16:9. That's the Display Aspect Ratio, the width/height relation for the entire image. Multiply the encoded width (960) by 16/9 and you get 1280. 1280x720 is the intended display resolution.

[pandv2]

Thanks TheFluff for you explanation.

I learned this concepts in the DVD world and I confused SAR (Sample Aspect Ratio) in MPEG4, with SAR (Store Aspect Ratio, encoded width/encoded height) in MPEG2. In MPEG2 is PAR (Pixel Aspect Ratio) the equivalent to MPEG4 SAR.

Your explanation has a little typo. The last sentence has to be:

Multiply the encoded height (720) by 16/9 and you get 1280. 1280x720 is the intended display resolution.

[Chumbo]

...- 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. Remuxing to MKV will rid you of the need to use demuxer="lavf" and seekmode=-1 but will not solve the frame duplication and you're still likely to get random corruption issues, and apparently lavc likes crashing with threads > 1 now too.
...
Do you happen to know if the status on this changed at all in the last 7 months?

[mbcd]

I dont think so, I had an interlaced vc1 yesterday and stumpled over this problem. Even with actual 2.17 there are only corrupted frames (on vc1, not h264). I think that interlaced material has no high priority on ffmpegSource.

My workaround is: Convert to AVI (for vc1) and open with DirectShow, thats the only way I found. Maybee you get a workaround for h264 too.

[TheFluff]

FFmpeg's VC-1 decoder doesn't fully support interlaced material yet, there's nothing we can do about that. There are also some mysterious issues with progressive VC-1 that I'm not sure if they're our fault or not.

H.264 is an entirely different problem, but no, it still doesn't work reliably as far as I know. Haali's parser causes funny issues and lavf's is so terrible at seeking it's entirely useless. Reading linearly (seekmode 0 or -1) with lavf (ffindex(demuxer="lavf")) might "work" though.

[Chumbo]

I'm using directshowsource now with ffdshow decoder set to deinterlace so I don't have to it in the script, but DS is just so slow. Do you have any recommendations for faster method that doesn't use ffms2? Being on Win7 64bit can be such a pain with the limited filters. I can't even use DGAVCDecode since that version is not available for 64bit.

[TheRyuu]

I can't even use DGAVCDecode since that version is not available for 64bit.

You know not using 64-bit is an acceptable solution. What about DGDecodeDI or DGDecodeNV (the latter even supports vc1)? You do know that you can run 32-bit applications on a 64-bit copy of Windows right?

I also doubt that the ffdshow deinterlacers are any good (other than yadif which can be used from avisynth as well).

[LoRd_MuldeR]

@Chumbo:
Depending on what you are doing, running Avisynth in a 32-Bit process and processing the video in a separate 64-Bit process (e.g. x264) may be a feasible solution.

[LigH]

Is FFIndex (either in ffms2.dll or via ffmsindex.exe) able to support a list of VOB segments as source (like DGMPGDec does), if not even an IFO (ideally with a PGC/angle definition, or at least a PGC/angle VOB set stripped by the ripper in IFO/movie mode or PGCDemux), and an MPLS Blu-ray playlist?

If not yet ... where is the recommendable place to add such a feature request?
__

P.S.: Exists already... (http://code.google.com/p/ffmpegsource/issues/detail?id=78)

[Chumbo]

You know not using 64-bit is an acceptable solution. What about DGDecodeDI or DGDecodeNV (the latter even supports vc1)? You do know that you can run 32-bit applications on a 64-bit copy of Windows right?

I also doubt that the ffdshow deinterlacers are any good (other than yadif which can be used from avisynth as well).
Yep, I do know that. Unfortunately, when I run it that way, the components crash all the time, e.g., x264 successfully encodes pass1 and then crashes. This means I have to manually intervene constantly for every component that crashes. I'm an ATI shop so I can't use DGDecodeNV but did NOT know about DGDecodeDI so I'll definitely look that up. Thanks for the heads up. BTW, my source is AVC so I would need DGAVCDecode for 64bit.

I much prefer to use yadif which is what I was using in my scripts but with the problems with encoding these interlaced files with ffms2 I've been trying to find an alternative solution that is still free.

@Chumbo:
Depending on what you are doing, running Avisynth in a 32-Bit process and processing the video in a separate 64-Bit process (e.g. x264) may be a feasible solution.
Yep and per what I stated above, I actually started down that road initially but ran into the problems where the 32bit apps were essentially crashing at the end of their run which required constant manual intervention to my automated processes. Unless I'm missing something in how I'm running these? I have tried several different compatibility modes but got the same results.

The only way I was able to do this was to create a virtual machine running Windows 32bit but it's really slow to do this inside a VM.

[TheFluff]

Is FFIndex (either in ffms2.dll or via ffmsindex.exe) able to support a list of VOB segments as source (like DGMPGDec does), if not even an IFO (ideally with a PGC/angle definition, or at least a PGC/angle VOB set stripped by the ripper in IFO/movie mode or PGCDemux), and an MPLS Blu-ray playlist?

If not yet ... where is the recommendable place to add such a feature request?
__

P.S.: Exists already... (http://code.google.com/p/ffmpegsource/issues/detail?id=78)

It's been on the todo list for ages, issue #33 (http://code.google.com/p/ffmpegsource/issues/detail?id=33) is an even older feature request for the same thing.

[Chumbo]

...I can't even use DGAVCDecode since that version is not available for 64bit.
Let me clarify what I said here. I CAN use dgdecode to produce the dga file. What I CANNOT do is load the DLL and use AVCSource in the script.

[TheRyuu]

This is getting fairly off topic but it obviously shouldn't be crashing so you should probably look into why it is. Using 64-bit avisynth really is not an acceptable solution considering it's basically one giant hack.

[Chumbo]

I agree, so back on topic. I think I found a working solution using ffms2. I've encoded around 15 files so far and they all good. Here's my script:LoadPlugin("C:\megui64\tools\ffms\ffms2.dll")
FFVideoSource("file.ts", threads=1)
LoadPlugin("C:\megui64\tools\avisynth_plugin\TIVTC.dll")
telecide(guide=1,order=1,hints=true,post=1)
Load_Stdcall_Plugin("C:\megui64\tools\yadif\yadif.dll")
Yadif(mode=0, order=1)
converttoyv12()
My sources are all AVC interlaced at 30fps (30i and 60i) and 29.976fps. I am doing 2-pass and doing this linearly but did not specifically set seekmode nor using lavf for demuxer. So far so good.

[Atak_Snajpera]

Can I ask somebody to compile r644 for me?

[TheRyuu]

Can I ask somebody to compile r644 for me?

ffms2-r644.7z (http://ffmpegsource.googlecode.com/files/ffms2-r644.7z)

[Atak_Snajpera]

Thank you!

[burfadel]

Thanks + 1!

[Chumbo]

Thanks + 1!
me2...

[Atak_Snajpera]

sample -> http://forum.doom9.org/showthread.php?p=1551814#post1551814

keyframe locations detected by ffindex
# keyframe format v1
fps 0
0
14
15
28
42
56
70
84
98
112
126
140
154
168
182
196
210
224
238
252
266
280
294
308
322
336
350
364
378
392
406
420
434
448
462
476
490
504
518
532
546
560
574
588
602
616
630
644
658
672
686
700
714
728
742
756
770
784
798
812
826
840
854
868
882
896
910
924
938
952
966
980
994
1008
1022
1036
1050
1064
1078
1092
1106
1120
1134
1148
1162
1176
1190
1204
1218
1232
1246
1260
1274
1288
1302
1316
1330
1344
1358


However if I ask for key frame (let's say 238) video starts from corrupted frame
FFVideoSource("..\video.mkv",threads=1)
Trim(238,1358)


but if use Trim(237,...) everything is ok!

I suspect that ffmpeg has some bug that it adds one frame to requested frame
Example: In order to start from keyframe you always must use Trim(detected_keyframe - 1, ...)

I tested with many BD VC-1 sources and above rule is always valid!

Maybe this a reason why corruption occurs while random seeking in VC-1 .

For mpeg2 and AVC keyframe is always correctly returned.

[TheFluff]

FFMS returns an error along the lines of "Insanity detected: decoder returned an empty frame" for this (http://stfcc.org/misc/ffmpegsource.empty.frame.mkv) sample. ffmpeg/ffplay/everything else based off ffmpeg/libav plays it fine.

I don't get that message with threads=1, but the file exhibits the usual interlaced h264 shenanigans and also features significant corruption. MPC-HC plays it with some minor corruptions as well.

On a related note, FFMS returns mangled timestamps for this (http://stfcc.org/misc/ffmpegsource.mangled.timestamps.ts) sample. The timecode file ffindex writes shows that multiple frames are displayed at the same time, which x264 doesn't seem to like.

Haali's parser returns the same PTS twice or more in certain places in this stream. Not sure why, I haven't investigated deeper yet.

Edit: it seems to be because the stream is a mix of progressive and interlaced coded frames and Haali's parser returns one packet per field in some cases, and then both fields have the same PTS. While meditating on this I think I also might have discovered why we're getting those annoying frame duplication issues with interlaced h264. I'll return to this later.

[TheFluff]

If you desperately need to open H.264 files using the RGB-hidden-in-YUV444 trick, here's a patched build that might do what you want: http://mod16.org/ffms2/ffms2-r654-gbrphack.7z

This is needed because vanilla builds of FFMS2 currently suffer from a bug in SWScale that makes such files take a roundtrip via YUV and also clamps the output to TV range. It's really a pretty ugly hack though and will not be committed to SVN; the SWScale maintainer is aware of the issue and is going to fix it Soon(tm).

Patch is in the archive.

[LigH]

How can I avoid FFMS2 "going insane" and returning empty frames at tiny little video stream errors another VfW codec or DirectShow decoder survives?

[Gser]

How can I avoid FFMS2 "going insane" and returning empty frames at tiny little video stream errors another VfW codec or DirectShow decoder survives?

By not using FFMS2, not multithreading it also helps sometimes.

[LigH]

not multithreading it also helps sometimes.

:o That was the key I should have known already but forgot to remember.

Now I have a blue range there, that's indeed way better than a crash.

[TheFluff]

How can I avoid FFMS2 "going insane" and returning empty frames at tiny little video stream errors another VfW codec or DirectShow decoder survives?

A lot of the empty frame errors are probably caused by a bug in the frame delay calculation in FFMS2, in turn sorta caused by ffmpeg changing the definition of has_b_frames. We're working on it.

[horrormaster34]

Is it just me or do none of the FFIndex options work? I've tried to use "source", but it says that it can't open it. If I leave out "source" and call the file then it works. If I use "indexmask=-1" it uses that as the index file name. If I try to set the index file name using "cachefile" it again uses that as the index file name.

ex: ffmsindex64.exe D:\inputfile.mkv cachefile=D:\output.mkv.ffindex

that returns the index file as a literal cachefile=D:\output.mkv.ffindex instead of simply output.mkv.ffindex.

If I try to use any of the other options it just shows a message that it's unrecognized.