ffvfw

[BoNz1]

Originally posted by Animaniac
what's ff_libmad?

It is the mpeg audio decoder http://www.underbit.com/products/mad/ that works with ffmpeg, AFAIK.

[Animaniac]

Originally posted by BoNz1
It is the mpeg audio decoder http://www.underbit.com/products/mad/ that works with ffmpeg, AFAIK.

I assumed it was a MAD implementation, but what I meant was is ff_libmad an encoding implmentation or a DirectShow decoding implementation? Is this going to be integrated into ffdshow? The MAD decoder supposedly produces better results than the FhG decoder.

[S_O]

Milan is already programing a ffdshow audio decoder, MAD will be the decoding engine for mpeg-audio.

[superdump]

Has there been any progress on the libavcodec? or any of the other video codecs?

And is there any chance of a new compile from athos anytime soon? :D

[Tommy Carrot]

Originally posted by superdump
Has there been any progress on the libavcodec? or any of the other video codecs?

And is there any chance of a new compile from athos anytime soon? :D

It contains now FFV1 lossless codec, which supposed to be much more efficient than Huffyuv (although i don't know if it is better than VBLE). It would be great to try it.

[superdump]

Athos: Can you pleeeease please please compile a new version for us all to try out? I think I speak for us all when I say we'd be very grateful.

Thanks.

[Animaniac]

In AviUtl, when ffvfw is selected, it causes AviUtl to crash.

[IvS]

Originally posted by superdump
Athos: Can you pleeeease please please compile a new version for us all to try out? I think I speak for us all when I say we'd be very grateful.

Thanks.

Ahm...allow me to endorse this request :)...

[superdump]

I have spoken with Milan since that post and it appears there is very little going on with ffvfw for a new compile to be worth it.... We'll see though. NeroDigital's directshow codec should be out sometime this month. :) There's something to play with.

[superdump]

Actually... after running a few tests just recently, ffvfw's mpeg4 implementation STILL performs very well. And this is without b-frames working with chroma motion estimation!

Athos, could you please compile us a new version to play with? :) I have noticed new features such as 3ivX (blech :P), FVF1 (which we have already talked about), sklmp4 (Skal's mpeg4 implementation) entering into ffmpeg and hope that these will be ported across to ffvfw by Milan soon. (Though he seems to be on holiday or something. :))

Have fun, people.

[athos]

theres not much going on with ffvfw right now, I dont think a new compile would do much difference.

[superdump]

Have they fixed b-frames with chroma motion estimation?

[MarkCoolio]

@athos...
anyways would love to see a new compile even without big changes :)
keep up the work!

[athos]

For those who dare, you might want to take a new look in http://athos.leffe.dnsalias.com/
...

[Sagittaire]

It's an excellent news ... And does the development of Theora progress?

[Sagittaire]

Theora 2 pass mode bug. The second pass has the same size than first pass. The select final size for Theora has no influence ...

[Tommy Carrot]

The FFV1 lossless codec inside of ffvfw seems to be VERY promising! It easily beats LOCO and VBLE codecs (sometimes 20-30% shorter than them), not to mention huffyuv. The performance is poor yet, and it's a little bit buggy, but very promising.

[Animaniac]

2 pass MPEG-4 encoding produces garbage for the 1st 6 [sic: edit] frames for the 2nd pass.

[IvS]

Thank you athos!
I don't consider this ffvfw build a minor improvement over the previous, because this one has support for b-frames with chroma motion! It produces very nice results! (the help files are outdated)

edit: as superdump just informed me, and i checked, 2-pass with chroma and b-frames ist death :\.. oh well :). on to test ffv1.

[RadicalEd]

ffv1 ROCKS

Huffyuv (yuy2): 373 mb
Huffyuv theoretical yv12: 290 mb
FFV1 (yv12) VLC: 227 mb
FFV1 AC: 207 mb
FFV1 AC context 2: 199 mb

I dunno what context or VLC/AC do, but they're great. Playback isn't realtime on a 1ghz tbird, but I'm more interested in using lossless for storage.

[Tommy Carrot]

Originally posted by RadicalEd
ffv1 ROCKS

Huffyuv (yuy2): 373 mb
Huffyuv theoretical yv12: 290 mb
FFV1 (yv12) VLC: 227 mb
FFV1 AC: 207 mb
FFV1 AC context 2: 199 mb

I dunno what context or VLC/AC do, but they're great. Playback isn't realtime on a 1ghz tbird, but I'm more interested in using lossless for storage.

I think VLC and AC are the entropy coders for h.264. VLC is much faster, while AC (arithmetic coder) is more efficient.

I don't know exactly, but i suppose context other than 0 is lossy.

It's too slow right now for being useful, but hopefully it will be faster.

EDIT: i was wrong, 'context' setting other than 0 is still lossless, and can reduce the filesize even more. Anyone know what's this?

[gino25]

I have tries to encode a video qith ffvfw using h263+

Ma i can' t decode it.

What decoder must i use?

[haibane]

Originally posted by gino25
I have tries to encode a video qith ffvfw using h263+

Ma i can' t decode it.

What decoder must i use?

ffdshow can decode h.263+


I can't see xvid in there anymore.....
is it removed?

[BoNz1]

Milan is working on XviD dev-api-4 for ffvfw so stay tuned for more info. Looks like he hasn't completed it yet, thats all :).

[gino25]

But where i must set h263+ decoder?

In ffvfw last version i have (in the decoder dialog):
Xvid
div3
divx
dx50
mp43
mp42
mp41
hfyu
wmv1/7
wmv2/8
wmv9,mss2
raw video
other mpeg-4 codecs



But no h263

[IvS]

gino25, as haibane said, just use *ffdshow* to decode h263+.

[LigH]

:eek: They are allowed to use arithmetic coding? Wow - when I was in the college and studied computer science, I read that this algorithm is patented by IBM! :D

[Tommy Carrot]

Originally posted by LigH
:eek: They are allowed to use arithmetic coding? Wow - when I was in the college and studied computer science, I read that this algorithm is patented by IBM! :D

I guess they don't really care.

[cweb]

Could there be an option to write to a different file every 2GB or 1GB?
It would be useful for win98 users or anyone stuck with FAT32, doing video capturing.

I'm currently testing the MJPEG option - it seems to work well.

Great stuff - thanks to the author - keep it up..

Edit: I did a capture with ffvfw's mjpeg format and while I can play
it back with Zoom Player and read it in Virtualdubmod, it seems that
I cannot get it to open in an avs script with avisynth. It gives the error "There is no decompressor for MJPEG"... I'll see if I can get around that otherwise there should be some option in ffvfw itself, please...

Edit 2: I discovered a roundabout solution which works well - open the source file (ffvfw mjpeg) in Vdubmod (since it has the internal decompressor for mjpeg) and start the frameserver, creating a file with the .vdr suffix. Then reference this vdr file using avisource("file.vdr") in an avisynth script and hey voila' - the solution (you can then open the script as usual).

[superdump]

cweb: If avisource("something.avi") doesn't work try directshowsource("something.avi",fps=##). It may just be that there's only a ds decoder for it.

[BoNz1]

Originally posted by cweb
Could there be an option to write to a different file every 2GB or 1GB?
It would be useful for win98 users or anyone stuck with FAT32, doing video capturing.

Yup, virtualdubmod and vdub both have supported this for a very long time, save as a segmented avi and limit the size of the files to 2GB or 1GB or whatever you want.

[cweb]

I know but I need it to occur while I'm capturing with VirtualVCR as the latter's author won't implement the same type of segmentation. Vdubmod doesn't capture (when I try it bombs out) and in any case you need the wrapper which loses some frames. I know of vdub+vcr and have a copy, but I still prefer the results I get with VirtualVCR (a wdm application).

[cweb]

Originally posted by superdump
cweb: If avisource("something.avi") doesn't work try directshowsource("something.avi",fps=##). It may just be that there's only a ds decoder for it.

Precisely - but that's so slow... that frameserving from vdubmod was faster for me...

[cweb]

For the MJPEG file capture with ffvfw, I installed Morgan's MJPEG v3 for decoding within avisynth, but the colours are wrong from the middle of the picture down - the bottom half is all green!

Seems like I'll have to either keep frameserving as above, or I'll now try to see what happens with MPEG1 to a separate file.

Edit: Writing to an external mpeg1 file with ffvfw gives me a 0 length file. Perhaps that doesn't work yet.

Edit2: Just for fun as an aside, I tried a capture of a few seconds with Morgan's MJPEG. When I read it within avisynth using avisource, the colours become all bluish. Weird... So, the ffvfw solution with frameserving is the only one which works for me (and I can capture 30mins with it before the file becomes too large for FAT32) so far.

Edit3: The morgan mjpeg blue bug, as I found by searching these forums, is remedied with SwapUV().... that's ok now.

[haibane]

I was playing around with the mpeg1 option(not the mpeg2ecn mpeg1). The quality was very good consider that it requires very little power to decode.
When I enable b-frame, during the play back, it just shows blended frame. Is there someting wrong with the encoder or it's the decoder's fault? I'm using ffdshow 8/16.

[superdump]

athos: It's been over a month since the last compiles you made. Do you feel like compiling unpdated versions of ffdshow and ffvfw again? :)

I haven't had any problems with either of the 2003/08/16 builds aside from 2-pass b-frames when using chroma not working. (I can't remember if I tried without...)

Thanks

[Rober2D2]

This thread has become a bit too long to search in, so could anyone post which are the most recent links to ffvfw binaries and sources, please?.

I have seen a few at the beginning of the thread, but I suppose they are a bit outdated.

[superdump]

Athos' binaries (http://athos.leffe.dnsalias.com) for ffdshow and ffvfw.
The sources can all be obtained from the CVS of the FFMPEG project on sourceforge if I am not mistaken.

[Rober2D2]

Thank you, Superdump

[easyfab]

Originally posted by superdump
Athos' binaries (http://athos.leffe.dnsalias.com) for ffdshow and ffvfw.
The sources can all be obtained from [B] the CVS of the FFMPEG [/project on sourceforge if I am not mistaken.

No not the FFMPEG project but a CVS branch of the FFDSHOW project.
FFDSHOW and FFVFW are milan's projects which include ffmpeg codec .
And now if i make no mistake the ffvfw branch is include directly in ffdshow.

[athos]

sorry, i have a lot of things going on right now with work, but i will try to compile new binaries soon.

[superdump]

easyfab: Thank you for the correction. :)

athos: Cool.

[athos]

new build is up @ http://athos.leffe.dnsalias.com/
Please note: this is an unofficial build, milan has not authorized it.

[Tommy Carrot]

ffv1 (the lossless codec) seems to really use delta frames, because when i set keyframes distance to 125, the output is smaller compared to when every frame is keyframe. The gain is not large (688M to 703M), but here was a long discussion about the uselessness of delta frames in lossless codecs. Can anyone explain how is it works in ffv1?

[Vash]

Just testet FFVFW for the first time using the latest version. Extremely useful! Especially in my XVID encodes. Great Work!
There is only one thing: I can´t find an option that enables a custom quantization matrix like HVSgood (which I prefer). Has this option been impleted jet?

[LigH]

Update: My mirror of ffdshow, ffvfw and some XviD builds (up from 2003); now dynamically created via PHP:

http://www.ligh.de/software/mirrors.phtml

[unixfs]

Hi,
I noticed that mpeg2enc-mpeg1/2 doesn't realize what the input
colorspace is: if I have a YV12 source I have to force it in the input section, otherwise the output has diagonal green lines.
In the other case the encoding proceeds well, but at half the speed (13-16 fps).
Why? Maybe mpeg2enc makes its own color color conversion? In this
case it would be redundant.
And what default colorspace does it expect?

Thanks.

[cweb]

Latest ffdshow (september version) from athos' site gives me a divide by zero error.
I use zoom player, but I get the same error using WMP.

edit: I found the solution - uninstall ffdshow, then reinstall.
I had as usual just installed over the old version (august).

[Die*wrek*show]

I was planning to install ffdshow 4-24 and ffvfw 4-15(currently i only have xvid root installed). Then athos came out with new builds of both. I'm not considering ffdshow 10-28 but I might go with ffvfw 10-28, anyone want to comment on its stability?

[athos]

I can tell you right now that the october version is most likely slower because i was not able to compile using assembly optimized code.