FFmpegSource

[Myrsloik]

Your puny request was already partially implemented. The frame type is set on each time a new frame is requested and can be subtitled on to the frame using scriptclip (or used otherwise). Frame size is something I won't add. Pointless complexity since with b-frames there isn't a 1:1 relation really and size says nothing about quantizers (or any other quality measure) so adaptive filtering could be used.

REQUEST DENIED

[poisondeathray]

Vlada - I don't know if this will help you or if it even applies to your specific situation, but with .m2v elementary streams, I also noticed the weird scrubbing behaviour and found "seekmode=0" makes everything back in order

[ajp_anton]

The frame type is set on each time a new frame is requested and can be subtitled on to the frame using scriptclip (or used otherwise).Maybe it's just me but I can't see how this is done... it's nowhere in the documentation, the change log, and if it's in the source code I just don't understand it.

[Myrsloik]

The variable name is FFPICT_TYPE and I guess I missed to add it to the documentation...

[ajp_anton]

Thanks, that's why I missed it and had to ask again =)
Frame size isn't *that* important, just thought that if you did one of them, the other would pretty much come along.

[ajp_anton]

Problems I've encoutered with ffms2:
It seems to skip the 2nd frame. To get correct seeking, you have to seek back and forth a few times and then it will work until you reload the clip.
Indexing gives an "access violation" and ffmsindex.exe crashes on mkv files created by x264. x264-mp4 and mkvmerge-mkv works fine.
ffpict_type is one frame off (shows n-1'th frame instead of the n'th). This can be corrected with after_frame=true though.

[Myrsloik]

Problems I've encoutered with ffms2:
ffpict_type is one frame off (shows n-1'th frame instead of the n'th). This can be corrected with after_frame=true though.

This is by design in avisynth. You have to fetch a frame first, guessing which frame will be next is impossible. But it's good that you reported it and in the next version it should at least be documented properly. (next release is after a small change in ffmsindex is tested)

[Myrsloik]

FFMS2 beta 5 has been released. Some minor fixes but mostly released to have a fresher FFmpeg revision. I still haven't had time to go through the already reported bugs so no need to report them again.

[Myrsloik]

Finally had some time to look at a few bugs:
IK_-_WWW.flv: LAVF's seeking seems to be broken when you specify a timestamp in an audio track, so this one isn't my fault.
clipped-original.avi: Seems to have been fixed by updating ffmpeg.
sample-kemono.avi: XVID with n-vops. LAVC doesn't duplicate frames when encountering an n-vop and this one also triggers a bug with ffvfw. No idea how to solve it but a hack option could be added if there's a demand for it.

TS files are also known to still be weird in all ways possible.

Any other bugs should be reported again because now I've lost track.

[Myrsloik]

Another update. 2.00 beta 6 improves many things and having the haali splitter installed should now be seen as almost a requirement.

There is however one very big known issue remaining (exists in all versions) and that is mpeg4 videos with NVOPs which desync when they are encountered. I'm also getting tired of talking to myself so if others would consider talking to themselves in this thread it would also be appreciated.

[lobosrul]

I'm getting an AviSynth script error after upgrading to beta 6 "Evaluate: System Exception - Access Violation".

Beta 5 works as expected.

[LoRd_MuldeR]

I'm getting an AviSynth script error after upgrading to beta 6 "Evaluate: System Exception - Access Violation".

Beta 5 works as expected.

Yup, same problem here!

[Myrsloik]

The beta 6 archive has now been updated. For some reason vs2008 miscompiled the dll in release mode or so it seems. This time it has less optimizations enabled and should work. (unless it's really something bad ffmpeg does in which case you will now get a more random error)

[LoRd_MuldeR]

The beta 6 archive has now been updated. For some reason vs2008 miscompiled the dll in release mode or so it seems. This time it has less optimizations enabled and should work. (unless it's really something bad ffmpeg does in which case you will now get a more random error)

Thanks. I'll give it a try :)

[TheFluff]

By the way ffmsindex now has a -v flag. By default it suppresses all ffmpeg logging/warning output, use -v if you want to see it (will probably lead to spamming lots of "invalid and inefficient packed b-frames detected" with mpeg4 in avi).

[b66pak]

beta 6 and 5 generates invalid timecodes:

999832
999874
999916
999957
999999
1.00004e+006
1.00008e+006
1.00012e+006
1.00017e+006
1.00021e+006


it should be (beta 4):

999832
999874
999916
999957
999999
1000041
1000082
1000124
1000166
1000208
_

[TheFluff]

I believe I've fixed that one problem just now. Try this (very unofficial and not approved by Myrsloik) build and see if that fixes it: http://renji.se/files/fluff/aegisub/ffms2-20090417.7z

[b66pak]

it is ok now...thanks a lot...

this is for a 29.97 fps file...

999865.533333
999898.900000
999932.266667
999965.633333
999999.000000
1000032.366667
1000065.733333
1000099.100000
1000132.466667
1000165.833333
_

[Myrsloik]

A few bugs (enough to make it almost useless) were in the latest two releases and because of this I'll start doing a bit more structured testing... in the next version. Use beta 4 for now if you encounter any issues, a new version should be done within a week.

[Myrsloik]

FFMS2 beta 7. This one can actually request all frames in a clip with b-frames without crashing. Isn't it amazing what computers can do nowadays? It's also been inspected by the COM police (Haali).

There's also an application called ffms2rt.exe which takes a media file as its only argument. It then tries to create a full index with all audio tracks and sequentially requests all frames. Finally it outputs the md5 sum of all decoded frames if successful or the error returned by ffms2. Not sure how useful it is if you're not testing things.

[LoRd_MuldeR]

Thanks. Seems to work fine for me :)

[ajp_anton]

Why do I need to go back to 1.21 to be able to open .mkv files made by x264?

[TheFluff]

Because there was a bug that was recently fixed that made the matroska parser crash on MKV files that it couldn't determine the filesize of simply by reading their headers. I guess I could upload a new build for you if you wanted to, or you can just wait for the next beta release.

[unranger]

Problems I've encoutered with ffms2:
It seems to skip the 2nd frame. To get correct seeking, you have to seek back and forth a few times and then it will work until you reload the clip.


until FFMS2 b8 is officially released, you may want to check this page (http://www.mod16.org/hurfdurf/?page_id=19) and the document (http://svn.aegisub.net/trunk/aegisub/FFmpegSource2/ffms2.html) on the source page

[Myrsloik]

Beta 8. Yes. We. Like. Beta. Since unranger already spoiled the fun I had to go and do something else. There's also an experimental compile against ffmpeg-mt linked in the first post. I tried it on almost one file and won't have time to test it with more. Feel free to post your own experiences with it.

[LoRd_MuldeR]

Thanks. The new version seems to work, even with x264-encoded MKV files :)

[Mottodj]

Using FFVideoSource on x264-mkv MeGUI reports I420 colourspace, converting isn't option so how make yv12 output, or it's depend by source?

[Myrsloik]

Using FFVideoSource on x264-mkv MeGUI reports I420 colourspace, converting isn't option so how make yv12 output, or it's depend by source?

That is a bug in MeGUI. It hates things such as mpeg2source and similar for the same reason. I've never figured out why it has that useless restriction. And yes, in the case of ffvideosource the output format depends on what type the input is.

[LoRd_MuldeR]

x264 as wll as Xvid are exclusively limited to the YV12 colorspace. So unless your source is in that format, a colorspace conversion is unavoidable...

[Myrsloik]

You can't really distinguish between a compressed format being YV12 or I420 in my opinion. When so much rearranging is involved whoever writes the decoder will be deciding. The only difference is whether the U or V plane comes first when decoded and is stored in memory. Nothing else, so there is no conversion necessary and supporting both is trivial. Hence the big MeGUI mystery. All avisynth filters support both automatically.

[LoRd_MuldeR]

Well, MeGUI is nothing but a front-end that will call x264 with your Avisynth script. So if x264 expects the data in YV12 memory order, there's not much MeGUI can do about that.

But couldn't the problem be avoided easily by appending ConvertToYV12() to end of the script? From you explanation this should be a "lossless" conversion. Just some memory reordering...

[Myrsloik]

Yes and no, internally avisynth considers both formats to be the same (only avisynth really needs to know the difference since it handles actual frame allocation and final output). So IsYV12() will return true for both (confused yet?) and ConvertToYV12() will pass through the video unchanged since it already IsYV12(). As it is FFVideoSource will always return YV12-ish formats as I420 (forgot that until I looked at the source again). It should be trivial to flip it to "real" YV12 but I don't see why it's my problem.

[LoRd_MuldeR]

So internally Avisynth hides the difference between I420 and YV12. But doesn't I420 -vs- YV12 matter as soon as the data is passed to the host application, e.g. x264?

If the application expects the YV12 data to be in "real" YV12 memory order, but the data is actually delivered in I420 memory order, problems will occur...

[TheFluff]

So if x264 expects the data in YV12 memory order, there's not much MeGUI can do about that.

x264 itself has no problem with I420, neither does xvid_encraw or anything else really.

[LoRd_MuldeR]

x264 itself has no problem with I420, neither does xvid_encraw or anything else really.

Then now I see the problem. MeGUI complains about I420 although x264 would actually handle it just fine...

[TheFluff]

Yes, if you actually ever tried MeGUI (I never did) you can apparently just ignore that warning completely and it'll work just fine anyway so I have no idea why it's still there, people have been complaining about it for years.

It's probably because the MeGUI people don't understand what I420 is, because the warning offers to add ConvertToYV12() for you, and if you do that it just pops up again. If you just ignore the warning on the other hand it'll Just Work(tm). (of course it works with the ConvertToYV12() too since it's just a no-op)


edit: yep, the megui people definitely have no clue.
18:10:42 < Dark_Shikari> what everyone calls "YV12" is actually i420
18:11:05 < Dark_Shikari> x264 doesn't support the reverse chroma plane order because there's no f*ing point, i.e. it can be trivially switched in whatever input app you're using
18:11:10 < Dark_Shikari> and because practically nobody uses the alternate order

[LoRd_MuldeR]

Hopefully they read this and kill the unnecessary warning :)

[Kurtnoise]

yep, the megui people definitely have no clue.
why not pointing to the right direction instead of bashing people here ?

You think you are superior to the others ? come on...:rolleyes:

[Blimblim]

Hi everyone.

First of all thank you to Myrsloik for his wonderful work with ffmpegsource. It really simplified my life a lot.

I just wanted to mention that sorenson 3 mov files seem to be broken with the main ffvideosource since at least beta 6 (I was using 1.0 before that, and couldn't find beta 5 anymore). The interesting thing though is that it actually works with the new beta8-mt build. I guess this is a ffmpeg thing, but if I can help find this issue I'll be more than happy to help :)

[Myrsloik]

With that description it definitely sounds like some kind of ffmpeg issue. Could you provide a clip so I can use it in my (future) automated tests?

[Blimblim]

Of course :)
One of many : http://media.gamersyde.com/madworld_trailer2mov.mov
I get a Evaluate: System exception - Access Violation when I try opening it.

[StifflerStealth]

I am using the new Beta 8, but MPC crashes with this error:
Problem signature:
Problem Event Name: APPCRASH
Application Name: mplayerc.exe
Application Version: 1.2.1008.0
Application Timestamp: 49bfb5f5
Fault Module Name: FFMS2.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4a05fbdc
Exception Code: c0000005
Exception Offset: 00001000
OS Version: 6.1.7100.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


My avs script is:
FFmpegSource2("My.mkv", -1, -1)
#Version()
Info()

It's rather simple. I manually index it and it creates the Wave64 file for the audio, but that crashes as well. I delete all the index and wave files and let the script create it and it just creates the index file. Also, I tried using just the ffaudiosource part on the raw AAC files and that crashes. It doesn't crash when I use just the video, ie. setting -2 for audio track. Oh, it also crashes in giving it the actual track number for the audio as well, so there is something weird with the audio.

[Myrsloik]

Oh, it also crashes in giving it the actual track number for the audio as well, so there is something weird with the audio.

It's AAC audio. Just that simple fact can make FFmpeg puke very quickly. I've considered going back to compiling it with FAAD2 for AAC decoding instead but that would take at least 5 minutes of effort.

[StifflerStealth]

Okay. But, when the file is manually indexed, it makes a Wave64 file. Isn't that used instead of the Audio in the mkv file? :S If not, why is it created? Can it be used? That would stop the crashing, I guess.

[Myrsloik]

No, FFIndex treats dumping the audio linearly and indexing as two different things. Use something like RaWavSource (I think, consult the manual) to open the w64 file you get instead.

[StifflerStealth]

Will try that. But, will a future version support AAC in MKV files? That would be nice to have. :)

Thanks for your help!

[TheFluff]

Will try that. But, will a future version support AAC in MKV files? That would be nice to have. :)

Here (http://www.mod16.org/aegisub/ffms2-20090512.7z) is a compile from today (ffmpeg from last week sometime) with libfaad compiled in and ffmpeg's internal AAC decoder disabled. Should support all not terribly broken AAC. When it gets outdated, remember to yell at me and not at Myrsloik (unless he has started to build with libfaad again by then).

edit: it won't work with your existing ffmsindex.exe unfortunately, hope that isn't a problem because I'm too lazy to build and upload that too right now

[StifflerStealth]

Brilliant. Thanks. :) And I don't yell. ;) :P Now I'm off to try to deinterlace a film that seems to have random interlacing so a simple pulldown doesn't work ... :S Oh, the strange projects I choose to do.

[StifflerStealth]

edit: it won't work with your existing ffmsindex.exe unfortunately, hope that isn't a problem because I'm too lazy to build and upload that too right now How does one go about getting a ffmindex.exe that is compatible with this new build? :o

[TheFluff]

One compiles it from source and links to the ffms2.lib on SVN. Or one could get it here (http://www.mod16.org/aegisub/ffmsindex-20090513.7z) I guess.