FFmpegSource

[Zhelkus]

@Zhelkus: You cannot get support for your illegally obtained material here. Read the rules.
Aw, you deleted my entire post. :scared:

What's illegal about working with ripped DVD content? I'm familiar with the rules, especially the one you're accusing me of, since I had to make sure that I was complying with it. My brother got me the first 3 volumes from amazon, he ripped it to mkv and now I want to re-encode it to watch it in our iPods for when he comes back. Then I saw this plugin that wouldn't have the audio delay directshowsource() seems to have when reading from the matroska container. That's all.

Could you restore my post please? I would really want this to work out nicely without any trouble.

[mikeytown2]

@Zhelkus Simple solution is to re-rip (http://www.doom9.org/guides.htm) your dvd's and encode it for ipod playback. Probably get a better encoded file since there will be less lossy steps. This forum (http://forum.doom9.org/forumdisplay.php?f=9) should be able to help you with the DVD if you encounter any issues with it.

[Adub]

No, your brother did not rip them for you. If you looked at the file name, "[a4e]..." then you would know that it was from an anime ripping group. Probably Anime 4 Ever. So, unless your brother is from that group, your lying.

It seems the suspicious flag was [DVDrip]. This is standard practice in pirate circles which is what flagged you in the first place. That was my mistake. I apologize. But the use of bracketed file names is rarely if ever used in home backups.

[martino]

Maybe he did? Who knows lol...

[Zhelkus]

Well now I'm made to look like a bad guy. That's swell. I'm saying he gave me the MKVs and I was simply going to get them to work on our iPods. Simple re-encode. I don't understand why he would download them if he showed me the boxes he got. I just wanted to work with the mkvs because they were already on the computer and the quality on them is really good.

@merlin: I didn't see any bracketed group name on the filenames, just "[DVDrip]". But if I can't convince you that I'm not lying, then there's not much reason to ask for assistance since I'm not welcome to.

I'll just work with the vobs. Sorry for the misunderstandings.

[Adub]

The [a4e] was more of an example. I thought I saw it in your old post, but it must have been the [DVDrip], which is standard practice in the pirate circles. However, the naming scheme is usually much more elaborate, so I am willing to believe that maybe your brother did rip them, and just decided to add that suspicious flag.

Honestly, I would recommend working directly with the Vobs, as they will produce higher quality output, vs an encode --> encode.

[Guest]

@Zhelkus

You would not have said you "obtained" (your quotes) an MKV if your brother had given it to you. Next time, don't get cute, say where you got it. Also, the "[DVDRip]" in the file name is highly suspicious and tends to corroborate the first point. Finally, first you say your brother "got you" the DVDs, then you say later "he showed me the boxes he got". Why would he need to show you the boxes if he got the DVD set for you?

So just drop it. A moderator examined your post and ruled on it. Do not discuss it further in this thread. Use a PM to sh0dan if you feel wronged. If you don't get satisfaction, then appeal to Doom9.

[ajp_anton]

What can be easily done is to set a variable in every getframe call so you can write it on the clip/use it in scripting. I haven't looked that closely yet but I think that should would very well for the frame type.

Frame size? dimensions? bytes? explain what and why you want it.

The frame number is already possible to add using one scriptclip line so that will never be added.Can't remember what I meant with frame number so forget that one =)
With frame size I mean in bytes.

I use ffmpegsource to compare an encode with the source since directshowsource sometimes fails to be frame-perfect. What's missing is something telling me what frame type and size I'm comparing, something like the OSD options in ffdshow.

[TheFluff]

Public service announcement: the Aegisub SVN server has moved to http://svn.aegisub.net/. Hence, the ffmpegsource source code has been relocated to there as well and can now be found at http://svn.aegisub.net/trunk/FFmpegSource/. It is also available through HTTPS but the SSL certificate is bogus so you'll have to press a button or two if you do it that way.

[Myrsloik]

I've now gotten around to cleaning up FFmpegSource quite a bit. The reason for this is to finally turn it into a useful library that can relatively easily be used from other programs. What will be possible is to call indexing separately from a another program and have it report on the progress. The indexing process itself is also greatly improved since all tracks are indexed at once so only one index file will be needed.

What I'm not sure what to do about is the audio support. As it is now FFAudioSource() (no decoded cache) appears to be too buggy for anyone to actually use. So I intend to remove it at least temporarily unless someone complains.

FFmpegSource() will probably be split into FFVideoSource() and FFIndex(). Or at least that's what I think it will be called. FFIndex() will (hopefully) be able to do indexing and write the selected audio tracks as wave files in one pass.

Maybe I'll even add some of that elusive framerate conversion I hate so much...

Are there any comments on this structure and the changes? Other resonable feature requests?

A final version or two based on the old code with a newer FFmpeg library will also be released until the new stuff works.

And if anyone missed it the unrelated discussion moved to here (http://forum.doom9.org/showthread.php?t=140117).

[vlada]

Myrsloik
I think this is a very good idea. Splitting the indexing into a standalone CLI application would be a big improvement for me.

I personally use FFAudioSource without much problems. But for me the only advantage using it is the possibility to avoid decoding of audio track(s). But with splitting indexing and audio decoding to separate CLI application, I probably wouldn't miss it.

[IanB]

@Myrsloik,

Being able to pre-index the sources with a free standing application will be a great boon for the advanced user. Many speed optimisations are possible if only parsing the structure and not actually decoding it. Done well you should be able to read through most files at close to maximum disk speeds i.e. 80 to 100+ MB/s.

Still having indexing be done at startup, like now, would make it simple to use for the novice user. And maintain version usage compatibility.

Indexing the audio so it can be directly accessed and decoded on the fly is superior to decoding it to a wave file. The size of the uncompressed audio can easily exceed the size of the input A/V file, doing this much writing can significantly slow the indexing process down. Compare DGDecode speed when just writing a .D2V file and when also demuxing/decoding the audio.

The current problems with audio seeking can probably be cured by doing 1 frame of pre-roll. i.e. Seeking to sample 10000. Look in index, find block 150 has samples 9975 to 10240. So access block 149 (samples 9709 to 9974) and then pre-roll 291 samples. If a format has dependencies that span more than 1 block just increase the pre-roll to suit.

[Myrsloik]

New version. Just another FFmpeg refresh which hopefully works properly for avi files and everything else this time.

@Ian

The idea is to automatically index a video file when opened and an index doesn't exist OR allow it to be created in advance. That should be the best compromise for most users. I will however not bother with previous version compatibility because it's just too different. Maybe a wrapper function or something as a separate script but things will be moved around too much.

And are there any plans to extend WAVSource() in avisynth to handle wave64 files? As it is now I'll probably have to include a simple reader for them as well (using libsndfile?) to make audio handling easier.

[IanB]

... automatically index a video file when opened and an index doesn't exist OR allow it to be created in advance.Yes that will be a friendly implementation. :D

I will however not bother with previous version compatibility because it's just too different. Maybe a wrapper function or ...:( Don Graft seems to share your unfortunate attitude. I recently enhanced the parser to handle overloaded function definitions based on the named argument, previously it only used the argument type pattern (ignored the arg names). This should make it easier to keep script compatibility between versions. At the least try to keep the order of the first few arguments the same so minimal scripts keep working without change. If you need a massive arg list change then you probably should change the name of the function.

And are there any plans to extend WAVSource() in avisynth to handle wave64 files?Somewhere down the track I want to update the import of all the VDub code for AVISource/OpenDMLSource/AVIFileSource/WAVSource. The current is from circa 1.4.8 and there have been many bugs fixed and features added since then that we are missing out on, hugh AVI/Wave64 being just one.

[tebasuna51]

...

And are there any plans to extend WAVSource() in avisynth to handle wave64 files? As it is now I'll probably have to include a simple reader for them as well (using libsndfile?) to make audio handling easier.

Can help RaWavSource() from NicAudio.dll v2?

Open w64, rf64, WAVE_FORMAT_EXTENSIBLE, and wav files >4GB (with 'data' last subchunk)

[acrespo]

When I open a MPG file with AC3 audio, I can't open the audio part because avisynth crash. I need to put atrack=-2. Can anybody help me?

EDIT:
I can't open audio with ffmpegsource("file.mpg", atrack=-1) but I can open with ffaudiosource("file.mpg"). This resolve my problem.

[Myrsloik]

With all of that information, no. Things you could try and report the results of:
Try to play the file using a recent ffplay.exe
Demux the ac3 audio and see if it works separately
Post a small part of the file so others can try

[acrespo]

here is the link to a piece of file:
http://rapidshare.com/files/138995487/dbz193__02_.mpg

And here is the script:

SetMTMode(2,2)
LoadPlugin("c:\encodes\filtros\fft3dgpu.dll")
LoadPlugin("c:\encodes\filtros\ffmpegsource.dll")
LoadPlugin("c:\encodes\filtros\dgdecode.dll")
LoadPlugin("c:\encodes\filtros\ffmpegsource.dll")
LoadPlugin("c:\encodes\filtros\tivtc.dll")
LoadPlugin("c:\encodes\filtros\mt_masktools.dll")
LoadPlugin("c:\encodes\filtros\awarpsharp.dll")
LoadPlugin("c:\encodes\filtros\Toon-v1.0.dll")
LoadPlugin("c:\encodes\filtros\nicaudio.dll")


FFmpegSource("g:\dbz193.mpg",atrack=-1)
amplify(1.5)

AssumeTFF()
TFM(order=1,mode=6,PP=7)
TDecimate(mode=1)

Crop(8,8,-16,-8,align=true)

SetMTMode(5,2)
FFT3DGPU(sigma=6.0, bt=2)
SetMTMode(2,2)

Spline36Resize(720,480)

Toon(Strength=0.5)



And the error is: Evaluate: System Exception - Access Violation (on line 13)

[check]

Is it possible your system is running out of RAM or VRAM?

[Revgen]

@acrespo

Have you tried using DGMPGDec instead of FFMPEGSource?

[Myrsloik]

@acrespo

Your file will work in the next version (2.0 most likely). I'm however far too busy with other things right now to fix the last memory leaks so I can't say exactly when it will be released. Send me a pm if you want to try the unfinished version.

I've also realized that I have no idea how to make nice import libraries and header files in c++ so that will take even longer...

[smok3]

i somebody has done a nice/correct avisynth script for xdcam ex, i would appreaciate if you could post it here?

(btw, The footage will be 1920x1080 50i and i need 1280x720 50p)

so far:

LoadCPlugin("t:\utility\avisynth\yadif\yadif.dll")
LoadPlugin("t:\utility\avisynth\ffmpegsource\FFMpegSource.dll")

ffmpegsource("g:\tmp\406_0693_01.MP4")
yadif(mode=0, order=1)
resize(1280,720)
# Levels(16, 1, 235, 0, 255, coring=false)

i don't think the colors are ok, some colormatrix fix i need?

[Adub]

You don't think the colors are ok, or you know the colors are wrong? Do they look different if the file is played alone in a media player? Meaning, just drag and drop into MPC.

[Myrsloik]

It is finally done. Or close enough to done. Actually I'm waiting for TheFluff to learn how to program so I don't have to write more stuff myself...

The most important changes:

2.00 beta 1
Can now be used as a stand alone library for making indices and retrieving frames
Rewrote most things
Updated FFmpeg to rev 15301


FFmpegSource 2.00 beta 1 (http://ivtc.org/new/beta/FFmpegSource-2.00b1.rar)

Source: http://svn.aegisub.net/trunk/FFmpegSource2/

Next I'll probably try to add audio decoding again in a similar way to how FFAudioSource worked. If someone wants to write a simple CLI (or otherwise) program to create indices from outside avisynth look at ffms.h and ffavsfilters.cpp (or wait for TheFluff).

[flywitness]

Can you tell me how to access the audio using this.

I can do this to get my section of video:

mycut=trim(clip, 50, 100)

but how do i get the corresponding audio section?

[Myrsloik]

No, I can't. You didn't mention which version of ffmpegsource you used or provide the script line you use to initialize your clip variable.

[SpAwN_gUy]

Can you tell me how to access the audio using this.

I can do this to get my section of video:

mycut=trim(clip, 50, 100)

but how do i get the corresponding audio section?

u have to replace "clip" with corresponding input-audio-load function.
i.e. (this is just a sample.. functions may be wrong)
for video:
clip=FFmpegsource("some.avi")
for audio:
clip=FFaudiosource("some.avi")
and then
mycut=trim(clip, 50, 100)

read the AviSynth guide. it is provided with installation.

[flywitness]

Sorry. I should have made it more clear. With V1.21 I can do this:

v1.21
-----
c=FFmpegSource(source, vtrack=-1, atrack=-1)
c.trim(50, 100)
SoundOut(c, output, blah...)
c

I can then open and add my soundout track as the audio in avidemux. Great.


However, In V2, I cannot find any way to access the audio that corresponds to my video trim. FFAudioSource has vanished along with FFmpegSource. Instead we have FFVideoSource which only deals with video it seems, and FFIndex which as far as I can see, only writes the entire original source clips audio to disk.

Unless I'm overlooking something, it would appear that V2, in it's current form, is missing some important functionality (important to me anyway :) ).

Have I missed something?

[Myrsloik]

You missed the sentence right below the link you downloaded v2 from. It says: "Next I'll probably try to add audio decoding again in a similar way to how FFAudioSource worked."

The only way to currently get audio from the v2 beta is to open the .w64 files with RaWavSource and use audiodub or whatever the filter was called. There's also a good chance I'll one day write my own wave64 source filter and include it to make the process easier. If I ever get that far it should be easy to write a function that wraps everything to work in a similar way to v1.

[flywitness]

ok. thanks.

i'll stick with 1.21 for now then.

[tebasuna51]

The only way to currently get audio from the v2 beta is to open the .w64 files with RaWavSource and use audiodub or whatever the filter was called.

Now RawavSource don't support .w64 files than FFIndex wrote.

The problem is the 'fmt ' chunk length. The field is filled with 0x2C when the offset to 'data' chunk is 0x30 like other software like SoundOut and sndfile-convert (libsndfile-1.dll) put.

BTW, after this correction, I remember the needed channel remap (for ac3 input):
GetChannel(1,3,2,6,4,5)

[Myrsloik]

The offset will be fixed in the next beta.

[tebasuna51]

The offset will be fixed in the next beta.
Thanks, I think is better use exact chunk sizes.

BTW your value is also valid because in w64 specs say:
6. All chunks are byte-aligned on 8-byte boundaries,
but their chunk size fields do not include any padding if it is necessary.
Standard RIFF/WAV files use 2-byte alignment of chunks.

The next NicAudio plugin version will support also this issue.

[IanB]

When writing these files it is best to obey all the restrictions in concert, i.e. make sure all chunks are actual multiples of 8 bytes! even if you have to invent up to 7 bytes of nulls at the end. Thus the padding issue never comes up.

When reading if possible cope with all the likely stuff ups people make when writing these files, i.e. expect bad 2 bytes alignment, roll in clover and throw a party if it is correctly 8 byte aligned. Of course sometimes you cannot, so you must follow the letter of the spec or provide a user option to override a common bad case.

[Myrsloik]

Released a much improved beta. See the front page for the changes.

[buzzqw]

in latest beta package is missing "ffmpegsource2.dll"

BHH

[Myrsloik]

Rename the included dll then. They are supposed to be the same.

[Myrsloik]

Because of a certain other thread with certain other people I have now ordered a gf8400gs (at 2 AM in the night because I'm so generally displeased with the state of the world). I don't know if I'll have time to actually do something with it but I WILL TRY. (financing already secured so no donations (http://pastebin.ca/1211083) will ever be necessary) That is almost all.

The official short way to refer to this project is also from now on FFMS2. It stands for Fabulous FM Source 2 (never was a 1 but who cares?).

[Keiyakusha]

I get an error "Access Violation" when trying open uncompressed RGB in avi. This is probably a bug...

[Myrsloik]

There are two things I like. Sample files and complete bug reports. This means you include the version since there are two likely versions you could be using right now.

[Keiyakusha]

Myrsloik
Sorry. Sample files (http://jtsknw.blu.livefilestore.com/y1pfofnNLWqQRQ2zHCfjUUhNWFWVzobNc4Cu3CfGh6JAmgf_ySvt4U0M0kUKWg9Q6z69_ziWJ0IR9G8mRNb_74o-g/FFtest.7z) has been generated in VirtualDub.
The version is 2.00 beta 2, but I think 1.21 also don't work.

Non uncompressed formats works fine.

[chriszxl]

the v2.0 beta2 ,the source file path can not contain special characters, like Chinese,but 1.21 no problem with that.

[Myrsloik]

These are two very odd bugs. The uncompressed files almost seem like they corrupt the stack somewhere and that is no fun to debug. I'll add it to my todo list but this will take time to investigate...

The special character issue I have no idea what to do about. Nothing was changed in the handling of input or compilation of ffmpeg. I suspect it's somehow caused by changes in ffmpeg since other odd things have happened with support for large files appearing and disappearing in my builds. Try your luck with the next beta and report your findings.

[Myrsloik]

Behold the glorious third beta. It brings a VFR to CFR mode for all you matroska haters (ironically it was debugged by TheFluff). An indexing program linked against the right dll name and a much improved FFAudioSource which can fail in completely new ways WITHOUT an extra cache file.

The summary: FFMS2 can now do everything 1.x could

But it's still beta because I have two (http://forum.doom9.org/showthread.php?t=80762) more (http://forum.doom9.org/showthread.php?t=141104) things I want to try to add...

[nurbs]

Hello. I have a problem with ffmpegsource (2.0b3) and vc-1 encoded files in mkv container. The indexing works, but when I try to open the files in an avisynth script I get:
Evaluate: System Exception - Access Violation

Happens with every vc-1 file I got from HD-DVD and Blu-Ray disks. The files play fine using MPC-HCs internal (non-DXVA) vc-1 decoder.
I uploded a sample of the clip: http://www.megaupload.com/?d=FD07G9U3

[Atak_Snajpera]

Hello. I have a problem with ffmpegsource (2.0b3) and vc-1 encoded files in mkv container. The indexing works, but when I try to open the files in an avisynth script I get:
I had similar problem with older version so I was forced to switch to DirectShowSource(ffdshow)

[Myrsloik]

I found a bug so now it says it can't open the codec (unsupported) instead of causing an access violation. It doesn't work in a recent mplayer either so I don't think ffmpeg can decode that file yet. Remuxing it to avi also produces exactly the same results.

[Atak_Snajpera]

It doesn't work in a recent mplayer either so I don't think ffmpeg can decode that file yet.
FFDshow is based on ffmpeg project so why libavcodec has no problems with that mkv?

ffmpeg.exe is able to detect that mkv
http://img186.imageshack.us/img186/1716/new1ok1.th.png (http://img186.imageshack.us/my.php?image=new1ok1.png)http://img186.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

[nurbs]

MPC-HCs internal decoder is also based of ffmpeg and plays the file, which is why I mentioned it in my post.

[vlada]

Hi,

I have a problem with the ffmsindex.exe program. I want to use it because unlike FFVideoSource it can show it's process. Unfortunately once I use it from my program it doesn't show the progress anymore. Unfortunately my programming knowledge is quite poor, so I'm just guessing what the problem could be.

I'm periodically reading from stdout of the ffmsindex.exe process. Unfortunately I don't get anything before the process finishes. Then it writes "Indexing, please wait... 100%". So I can't display any progress. I'm using the same approach for many other CLI programs like xvid_encraw, ffmpeg, lame etc. Do you have any idea what could be the problem?

I have two more questions/feature requests:

1) There is no documentation on the new FFAudioSource. Could you please tell me what are the usable parameters?

2) Is it possible to add an option to index only a part of a video file? So in the output would be only the selected part of the video...

3) I would like to have an option to suppress all warnings and errors (like the one regarding VfW AVI B-frames).