FFmpegSource

[qyot27]

The threading issue that was present back then with empty frames was resolved in the 690s revision range. Whether it also covers interlaced is another story, but r704 does seem to have some pertinence to interlaced H.264.

C-plugin r706

[burfadel]

Originally Posted by qyot27

The threading issue that was present back then with empty frames was resolved in the 690s revision range. Whether it also covers interlaced is another story, but r704 does seem to have some pertinence to interlaced H.264.

C-plugin r706

This build doesn't work for me, and neither does ffdshow build 4484 or 4486. I'm guessing it has something to do with LibAV... If it's instruction set related, I'm using a Core 2 Q9400 (has SSE 4.1 not 4.2), SSE4.1 was added with the E8xxx, Q8xxx, Q9xxx etc processors.

[abyss616]

Originally Posted by Gser

FFVideoSource doesn't really support .ts or .m2ts, so try muxing the file into a mkv. Some broadcasts work like this and some need to use DSS2.

Yeah, I go the demux>mkv route but I still experience routine crashes with VirtualDub and MeGUI when the source is VHS.

I also get the insanity error when working with 720p HD .ts material also, but it doesn't seem to affect the encoding/generate errors. Should I use 'threads=1' or leave it alone?

[Plorkyeran]

Originally Posted by qyot27

The threading issue that was present back then with empty frames was resolved in the 690s revision range. Whether it also covers interlaced is another story, but r704 does seem to have some pertinence to interlaced H.264.

With r704 interlaced H264 is no longer completely broken, but I still would not particularly recommend using FFMS2 for it without spending some time verifying that it's giving sane results.

[qyot27]

Originally Posted by Plorkyeran

With r704 interlaced H264 is no longer completely broken, but I still would not particularly recommend using FFMS2 for it without spending some time verifying that it's giving sane results.

I could gather as much, considering the wording of the commit message.

Originally Posted by burfadel

This build doesn't work for me, and neither does ffdshow build 4484 or 4486. I'm guessing it has something to do with LibAV... If it's instruction set related, I'm using a Core 2 Q9400 (has SSE 4.1 not 4.2), SSE4.1 was added with the E8xxx, Q8xxx, Q9xxx etc processors.

Without knowing the exact error, there's not much to go on.

As it's a C-plugin, it requires LoadCPlugin to make sure it loads, since it will not autoload. I've taken care of this in the .avsi, but in my own packaging I enforce an absolute path to C:\Program Files\AviSynth 2.5\plugins\ffms2.dll. If this is used on a 64-bit version of Windows, it will break since it expects 32-bit AviSynth to be installed to Program Files (x86). If that's what's going on here, just add the ' (x86)' part to the LoadCPlugin call in FFMS2.avsi.

Making it completely relative (as in, just the name of the .dll) also resolves the issue, but has the potential to break applications unexpectedly. It shouldn't, and doesn't in most applications I've tried, but I have seen it happen. Read: mencoder completely flips out when you do this and refuses to load anything through AviSynth (which is yet one more reason to avoid using mencoder if you can keep from it). But I figure if one app can freak out like that, chances are there are others that exist out there.

IMO, the most reliable solution uses GetSystemEnv to load the current directory as a variable and this abstracts the path enough for mencoder to work as well as the others. The downside to this approach is that GetSystemEnv is an external plugin and there's no guaranteeing that the end-user has it in AviSynth's plugins library.

[burfadel]

Originally Posted by qyot27

Without knowing the exact error, there's not much to go on.

As it's a C-plugin, it requires LoadCPlugin to make sure it loads, since it will not autoload. I've taken care of this in the .avsi, but in my own packaging I enforce an absolute path to C:\Program Files\AviSynth 2.5\plugins\ffms2.dll. If this is used on a 64-bit version of Windows, it will break since it expects 32-bit AviSynth to be installed to Program Files (x86). If that's what's going on here, just add the ' (x86)' part to the LoadCPlugin call in FFMS2.avsi.

Making it completely relative (as in, just the name of the .dll) also resolves the issue, but has the potential to break applications unexpectedly. It shouldn't, and doesn't in most applications I've tried, but I have seen it happen. Read: mencoder completely flips out when you do this and refuses to load anything through AviSynth (which is yet one more reason to avoid using mencoder if you can keep from it). But I figure if one app can freak out like that, chances are there are others that exist out there.

IMO, the most reliable solution uses GetSystemEnv to load the current directory as a variable and this abstracts the path enough for mencoder to work as well as the others. The downside to this approach is that GetSystemEnv is an external plugin and there's no guaranteeing that the end-user has it in AviSynth's plugins library.

I tried it either way, both seemed to work with the same error, (AVIGetStreamfail or something), but without that line, it says there isn't any filter named FFvideosource, so it is definitely loading. I believe on x64 systems, because it is a 32-bit program it automatically redirects the call to C:\Program Files (x86).

In any case, neither this, nor the latest FFDshow (4484, 4486) work for me, so I'm assuming it's LibAV related.

[TheRyuu]

ffms2-r706.7z

Because of various herping and derping libav can now be built with msvc (experimental and not completely finished).

Appears to be a slight code size reduction as well as a result of using msvc (6.3MB -> 4.6MB for ffms2.dll).

Built with libav ~20120825 w/msvc stuffs.
No postproc.
No opencore.
32-bit only.

[burfadel]

Originally Posted by TheRyuu

ffms2-r706.7z

Because of various herping and derping libav can now be built with msvc (experimental and not completely finished).

Appears to be a slight code size reduction as well as a result of using msvc (6.3MB -> 4.6MB for ffms2.dll).

Built with libav ~20120825 w/msvc stuffs.
No postproc.
No opencore.
32-bit only.

Thanks! This build works fine

Don't know what the differences is between it and the earlier posted r706.

What version of MSVC did you use, out of curiosity?

[TheRyuu]

Originally Posted by burfadel

Thanks! This build works fine

Don't know what the differences is between it and the earlier posted r706.

What version of MSVC did you use, out of curiosity?

Visual Studio 2010 (VC10). It also requires other tools such as a compile wrapper and a c99 -> c89 converter (clang based). Still very much a work in progress but it makes building ffms2 a lot easier.

Building a 64-bit version of libav in msvc is still a work in progress I believe but it should be in the works once 32-bit support is finished and working the way they want (there's still a bit of inline asm I think that needs to get ported to yasm, among other things I'm probably not aware of).

[burfadel]

Ah ok Once they get MSVC2010 completed, MSVC2012 will be officially available. It's finalised and available now, just not 'officially', same as Windows 8.

I'm guessing that MSVC2012 would be compatible too?

[TheRyuu]

Originally Posted by burfadel

Ah ok Once they get MSVC2010 completed, MSVC2012 will be officially available. It's finalised and available now, just not 'officially', same as Windows 8.

I'm guessing that MSVC2012 would be compatible too?

I don't see why not.

I'm not sure if they're specifically targeting 2010, I think at this point the idea is to just make it work and move on from there.

Apparently the CABAC inline asm isn't going to be ported since it's not feasible. Fortunately a msvc compiled binary is as fast as a gcc one (which has that inline asm) although low bitrate files may be affected. There isn't a lot of execution time spent there anyway so it's not a big deal.

[qyot27]

Previously I mentioned that some MP4 files suddenly break with builds of FFMS2 (trunk and C-plugin) using newer versions of FFmpeg/libav (specifically after the beginning of July). I've traced the issue back to this commit:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6
http://git.libav.org/?p=libav.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6

Which has to do with reading iTunes cover art.

The commit immediately prior works, this one and all the ones after it cause affected files to fail indexing. The failure only occurs in FFMS2, as ffmpeg.exe/avconv.exe can deal with the files correctly. I also confirmed that that single commit is the only problem, as reversing those changes against HEAD results in FFMS2 being able to read such files again.

[TheRyuu]

Originally Posted by qyot27

Previously I mentioned that some MP4 files suddenly break with builds of FFMS2 (trunk and C-plugin) using newer versions of FFmpeg/libav (specifically after the beginning of July). I've traced the issue back to this commit:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6
http://git.libav.org/?p=libav.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6

Which has to do with reading iTunes cover art.

The commit immediately prior works, this one and all the ones after it cause affected files to fail indexing. The failure only occurs in FFMS2, as ffmpeg.exe/avconv.exe can deal with the files correctly. I also confirmed that that single commit is the only problem, as reversing those changes against HEAD results in FFMS2 being able to read such files again.

Did you post a sample? I can't find anything in previous posts mentioning it but I may not have gone back far enough.

Err I found the post saying basically anything muxed with mp4box will cause it so going to go try that now, not sure how I missed that looking back the first time.

[TheRyuu]

Originally Posted by qyot27

Previously I mentioned that some MP4 files suddenly break with builds of FFMS2 (trunk and C-plugin) using newer versions of FFmpeg/libav (specifically after the beginning of July). I've traced the issue back to this commit:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6
http://git.libav.org/?p=libav.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6

Which has to do with reading iTunes cover art.

The commit immediately prior works, this one and all the ones after it cause affected files to fail indexing. The failure only occurs in FFMS2, as ffmpeg.exe/avconv.exe can deal with the files correctly. I also confirmed that that single commit is the only problem, as reversing those changes against HEAD results in FFMS2 being able to read such files again.

I can't reproduce it with my latest build.

I downloaded a trailer from itunes, remuxed it into mp4 with mp4box (via yamb) and it worked. I'm not sure if I'm doing something wrong to attempt to reproduce it?

[Yellow_]

Hi I'm using ffmpegsource2 to decompress h264 is there anyway to tell via ffmpeg whether the source has been encoded with full range chroma, ie App0() JFIF rather than 16 - 240

Mediainfo just gives me BT709 prims and transfer with BT601 luma coeffs matrix.

[qyot27]

Originally Posted by TheRyuu

I can't reproduce it with my latest build.

I downloaded a trailer from itunes, remuxed it into mp4 with mp4box (via yamb) and it worked. I'm not sure if I'm doing something wrong to attempt to reproduce it?

I'm seeing the issue when using your build too.

The files I saw exhibiting it had cover art (although I only fully realized this after seeing which commit seemed to be the source of the problem). For instance, Music Video or TV Episode purchases, but even self-created stuff with covers can manage to set it off. It doesn't actually only affect mp4box, as I also saw it happening to other audio-only files I'd muxed with mp4creator or that had been muxed by Quicktime (I would suppose, as I'd think that would be the obvious one used for iTunes purchases), but the only detail that seems to matter is the presence of an embedded image.

Re-ran some tests,
mp4creator v1.6.1d
mp4box 0.4.6-DEV (internal rev. 7)
L-SMASH rev.669 / git-3280f261

Quicktime (I guess; the original purchase) w/ cover: fail
mp4creator w/ cover: fail
mp4box w/ cover: fail
L-SMASH w/ cover: fail

mp4creator w/o cover: success
mp4box w/o cover: success
L-SMASH w/o cover: success

In all cases of failure except Quicktime, the cover was injected with Mp3tag 2.52. I can't seem to find options to insert covers in any of the three non-Quicktime muxers (and I can't verify anything with Quicktime itself because I think only Pro can do this stuff outside of iTunes' audio encoding ability), so I had to resort to an external app to do it. Files with metadata set this way used to work just fine, though, and since the original files exhibit the issue too I think it just has to do with the covers being present, rather than a problem with the way they've been inserted.

A couple of samples (normally ffmsindex fails in the < 10% range, but these are so small that it reports 100% but still fails and therefore still doesn't write the .ffindex files)
http://www.mediafire.com/?k7ti7s4izz47a8h

[Pat357]

Originally Posted by TheRyuu

ffms2-r706.7z

Because of various herping and derping libav can now be built with msvc

Any chance for the C build with full color-spaces support ?

[the_weirdo]

Originally Posted by Pat357

Any chance for the C build with full color-spaces support ?

You can try qyot27's build here:
http://forum.doom9.org/showthread.php?p=1588762#post1588762

[TheRyuu]

ffms2-r712.7z

Contains vapoursynth support.

I reproduced that cover art in mp4 bug, it's trying to index the cover art but fails. On a side note it's nice to be able to not look at libav and see a black box when debugging in msvc.

[active1]

Originally Posted by TheRyuu

ffms2-r712.7z

Contains vapoursynth support.

I reproduced that cover art in mp4 bug, it's trying to index the cover art but fails. On a side note it's nice to be able to not look at libav and see a black box when debugging in msvc.

isn't ffms2 already support vapoursynth?