View Full Version : mpegable AVC
flower1209
16th June 2004, 11:36
I just found mpegable's AVC codec. Does anybody made any experiences? More information on www.mpegable.com (http://www.mpegable.com)
Flower
Thanks for the tip,
It has a VFW decoder interface which means you can play/encode H264 AVI Files in VDUB :)
Also has VFW Encoder...I'll give it a try :)
-Nic
UPDATE:
Ok, Im quite impressed....Just did a 78second clip at 781kbps. Was encoding at 8fps on my 2.4Ghz P4 so slow and very slightly oversized. But the quality is pretty darned good seeing it's a 720x576 video.
@all: If you haven't tested this, give it a go. Oh and it doesn't seem to like fast recompress in VDUB, (it moans about frame size), so use Full Compression if you get that error.
bond
16th June 2004, 12:14
great news!!!
does the encoder include b-frames?
also is it limited somehow? 30days, number of encodes or so?
did anyone test the dshow decoder, whether its able to decode avc?
i give up, vfw will never die :D
1) Nope it doesn't use B-Frames (I checked :) )
2) Doesn't seem limited (ive put my computer into 2005, still decodes/encodes)
3) Strangely it doesn't seem to use a DirectShow filter to decode the video. It uses the VFW Wrapper. Which seems to work fine (no logo on screen or anything)
-Nic
Doom9
16th June 2004, 12:48
previous mpegable products had a logo if I remember correctly... and their bitrate control was horrible (and the company wasn't very cooperative.. when I asked for a full version without limits and restrictions they went into mute mode).
I know, and their codecs were cr*p anyway. Hence when I went to try this I expected the same heavy branding and bad quality. But I was quite surprised....I'm really surprised they've just given it away.
-Nic
bond
16th June 2004, 13:26
hm doesnt seem to show up in virtualdub/vfw codecs list :(
maybe it doesnt work in win98/me and only in xp and 2000? can anyone confirm this/the contrary?
chilledoutuk
17th June 2004, 01:59
if you change the fourcc from DAVC to H264 you can play it back with the ffdshow H264 playback filter.
I am testing it now I am impressed so far with the quality will report back with more findings later.
and maybe a sample clip.
:D
skal
17th June 2004, 13:10
Hi,
JFYI, we (Bobololo and I) tested this codec yesterday
on the 'tempete' sequence, 2Mb/s. It's 2dB+ under
jm81a reference software, set up to use same features
(p-frame only, filtering, 16x16->8x8 modes, qp=25, cavlc).
More tests on referenced sequences would be great.
Someone?
Skal
@skal:
Why test with such a high bitrate on such a low-res file? The perceptible differences must have been miniscule....
I'll try some of the sequences from here and put results:
http://www.stewe.org/vceg.org/sequences.htm
-Nic
ps
And how did you're own code score on that test? ;)
skal
17th June 2004, 14:21
@Nic:
well, feature-wise, mpegable codec is just a little
above mpeg4-v2, you know (the bonuses being: filtering
and 16x8 + 8x16 modes). 2Mb/s is what you then get from
jm81a with qp=25, which i expect to be the equivalent
of mpeg4's q=4 for a good rip. Don't forget we're
talking about constant-quant encoding here, not CBR (which
jm81 doesn't support very well, if at all).
Moreover, 'tempete' is a very difficult sequence, especially
if you don't use b-frames: it's a zoom-out with lot of
erratic/fast motion.
Now, this being said, it was only a first test. Given
the result, it should be better to try another working
zone. Something like 1Mb/s, QP=30 (mpeg4's q=10), PSNR ~= 34/35dB.
Skal
Thanks for the info :) I know what you mean about the reference source not supporting CBR. It doesn't seem to do it at all well.
I'll try some tests too. Thanks again :)
-Nic
mpegable
17th June 2004, 14:49
Hi,
we at dicas already made a lot of test, also against the reference software.
The results obviously depend on the encoding speed set in the codec's configuration dialog. For best quality we recommend to always use the slowest mode ;-).
How do you use the reference software? With CABAC, B-frames, ..?
For common bitrates, mpegable AVC (slowest mode) is usually around 0.5db below reference sofware (using Base profile tools) due to our tests, but looks better or equal than any of the exisiting MPEG-4 codecs at the same bitrate. As you know PSNR does not always correspond 1:1 to subjective visual quality. Especially, the in-loop filtering of AVC enhances the subjective quality compared to MPEG-1/2/4.
This version of mpegable AVC does not include a scene cut detection, pre-processing, ... There is still a lot of work - and potential.
I am already curious about your test results ..
bond: The installer of the current version only supports NT, 2000, XP but we will try to fix this asap.
Nic: When I checked the the fast recompress in Virtualdub it worked. Can you give me some info about the actual color format of your input?
Thank,
mpegable
@mpegable: Welcome to the forum :) You've got the start of a good and promising codec there. When I tried it on a PAL 720x576 Aviscript Script from MPEG2Dec3.dll I got an error about the input size being incorrect. The actual error was: "Output compressor error: The source image is not acceptable. (error code -2)". The same occurs with both an old and most recent version of VirtualDub.
When I check the "File Information" in VDub the Decompressor for the YV12 is listed as DivX 5.1.1 Codec. Maybe you have a different decompressor acting on yours?
Hope that's some use. :)
-Nic
mpegable
17th June 2004, 15:38
Thanks Nic, we'll check this.
bond
17th June 2004, 16:08
Originally posted by mpegable
bond: The installer of the current version only supports NT, 2000, XP but we will try to fix this asap.thanks!
bobololo
17th June 2004, 16:08
Originally posted by mpegable
we at dicas already made a lot of test, also against the reference software.
The results obviously depend on the encoding speed set in the codec's configuration dialog. For best quality we recommend to always use the slowest mode ;-).
How do you use the reference software? With CABAC, B-frames, ..?
For common bitrates, mpegable AVC (slowest mode) is usually around 0.5db below reference sofware (using Base profile tools) due to our tests, but looks better or equal than any of the exisiting MPEG-4 codecs at the same bitrate. As you know PSNR does not always correspond 1:1 to subjective visual quality. Especially, the in-loop filtering of AVC enhances the subjective quality compared to MPEG-1/2/4.
Obviously we tested with the same tools and conditions to be fair (baseline tools : cavlc, p slice only, 16x16 -> 8x8 MB partitions, no scene-cut detection, same gop, etc). We used the slowest encoding mode with MPEGABLE. The results on the sequence we tried (tempete_cif) were the following :
MPEGABLE
PSNR: Y/U/V 35.232 35.527 37.317 (2034 kb/s) (target 2000 kb/s)
JM81a
PSNR: Y/U/V 37.28 38.83 40.25 (2160 kb/s) (Qp 25)
As you can see the difference is already huge with the same tools. When enabling all the main profile tools of the JM (cabac, bframe, multi-ref, etc) we had more than 3 dB of difference.
Anyway this test is not very significant, it was only on 1 single sequence and for one (PSNR,RATE) point. The complete R-D curve on several sequence would be more interesting.
btw: the inloop deblocking filter gets higher PSNR in most cases. till now I've never seen any sequences where the deblocking doesn't increase the PSNR. However it tends to smooth the picture in a way that sharpness lovers could consider as a subjective annoyance ;)
Originally posted by mpegable
This version of mpegable AVC does not include a scene cut detection, pre-processing, ... There is still a lot of work - and potential.
I am already curious about your test results ..
Nic: When I checked the the fast recompress in Virtualdub it worked. Can you give me some info about the actual color format of your input?
I got the same problem here, the input was YV12.
-- bobololo
Sagittaire
17th June 2004, 16:46
As you know PSNR does not always correspond 1:1 to subjective visual quality
Perhaps with 0.3 dB but not with 3 dB.
kilg0r3
17th June 2004, 18:37
for me it only works with rgb input (full processing mode) :)
mpegable
17th June 2004, 19:15
Indeed, the version 0.7 only works with RGB input. An internal version already works with different YUV formats (YUY2, IYUV, YV12, UYVY). Does anybody has an idea what other formats might be important? thanks. Probably there will be a minor update next week. :)
We are still surprised about the large PSNR difference to JM but color conversion might be another cause - certainly not 2db. If somebody has more results with different sequences please let me know that we can compare it.
CruNcher
18th June 2004, 07:43
Especially, the in-loop filtering of AVC enhances the subjective quality compared to MPEG-1/2/4.
wahh Inloop the evilness ;) what i saw so far in a H264 codec with a Rate Controll (Videosoft) is that they lose vs XviDs RC especialy with inloop on and high motion scenes, you can see how the backgrounds and all the details washing out and for me that looks more disgusting then any blocking in a fast sequence wich you wont really realize at all.
mpegable
18th June 2004, 14:54
There is a little patch for mpegable AVC on Win98 machines. You can download it from http://www.mpegable.com/download.
In addition to the actual installation file, you must download the file 'davc.inf' and install it (click right on file and chose 'Install'). This script does the neccessary entries in system.ini.
unmei
18th June 2004, 20:57
An internal version already works with different YUV formats (YUY2, IYUV, YV12, UYVY). Does anybody has an idea what other formats might be important?
For me as "normal avisynth user", it seems YV12 is all i need.
What i would check back in your situation is who uses I420, i always thought this were simply a "re-packed YV12" (different storing order) and i have never explicitely seen a file using it, but it could be it were used on Real or Quicktime based systems in which case it were quite important ..but i really don't know, this is just a feeling this colorspace could be used somewhere i do not usually go :)
bond
19th June 2004, 11:42
mpegable, can you plz give us some more information on the used settings in your avc codec, like loopfiltering is enabled always, what is the exact difference between very slow, medium, fast encoding speed (only motion search?), what is rection time aso...
also it never harms if you give the user the possibility to configure your codec, like en/disabling loopfiltering aso...
thanks :)
Originally posted by unmei
For me as "normal avisynth user", it seems YV12 is all i need.
yes, most people here will use yv12 streams (from dvd) as input, which avisynth is able to pass as yv12 too
Originally posted by kilg0r3
for me it only works with rgb input (full processing mode) :) with rgb input (add converttorgb at the end of the avs script) it also works in fast recompress
Originally posted by mpegable
There is a little patch for mpegable AVC on Win98 machines. You can download it from http://www.mpegable.com/download.thanks a lot!
edit: i did some first tests with it and noticed the same behaviour as with mainconcepts implementation:
the first few frames are totally blurred and ugly, only after a while they seem to look ok
Tommy Carrot
19th June 2004, 12:52
Perhaps i'm alone with this, but i would find a constant quantizer option very useful.
Teegedeck
19th June 2004, 13:55
I'm afraid you're wrong; it wouldn't be useful, it would make it usable. ;)
mpegable
21st June 2004, 14:26
Thank you all for the input. There is an updated version of mpegable AVC available from www.mpegable.com. The new version supports different YUV formats including YV12, IYUV, YUY2 and UYVY.
There will be some more updates in the near future before we release a 1.0. They will include automatic I-frame insertion, more options for the codec configuration as well as quality and performance improvements. :-)
One more remark also to the first results of PSNR measurements. Since the reference software does not support bitrate control (at least nobody knows if and when it really works) it is difficult to ensure equal test conditions. To make a fair comparison you can either make a longer test with full PSNR curves, or - to test only at a certain bitrate - you should first encode the sequence with the reference software configuring a certain quant step. Then determine the bitrate needed by the reference sofware, and configure the mpegable AVC accordingly.
Using the tempete sequence, the difference between mpegable AVC (slowest mode) and the reference software (base profile) should be around 0.5db. This is at least true with the version 0.8 of mpegable AVC when the input color format is YV12 (no RGB).
chilledoutuk
22nd June 2004, 00:01
I have tried encoding with fast recompress video mode in Vdubmod but all i get is a garbled picture with yv12 sources. If i connvert the video in avisynth to YUY2 then fast recompress works fine however as you know this is not ideal.
Shinobu
23rd June 2004, 12:33
Just an idea, could you add a smp implementation in your codec ? I'm running on dual cpu only ^^.
i've tried this codec, it's a good base for future good codec.
i think it need:
+1-pass quantitzer mode
+2-pass mode
+inloop configuration (and desactivation)
+...
++
mpegable
23rd June 2004, 13:45
hi shinobu, thanks for your input.
We plan to add multi-processor support to the codec but this will probaly take until end of the year.
+ constant quantizer mode: will be part of the next release
+ work in progress: not yet sure when it is finished
+ inloop configuration: it seems that a optional inloop filter is what some people like...
In general we do not want to make a codec only for video coding experts but for all users. To many configuration settings may be puzzleing. We need good mixture ...
bond
23rd June 2004, 14:27
Originally posted by mpegable
In general we do not want to make a codec only for video coding experts but for all users. To many configuration settings may be puzzleing. We need good mixture ...provide an option called "experts mode", if someone activates it all the advanced options get displayed
if not activated (the default setting) your "for all users" gui gets displayed
Shinobu
23rd June 2004, 15:11
"provide an option called "experts mode", if someone activates it all the advanced options get displayed
if not activated (the default setting) your "for all users" gui gets displayed"
+1
++
unmei
23rd June 2004, 18:05
well this is not actually a poll, but i'd also vote for the advanced settings panel as i like to play with this kind of things.
Maybe you should do it in a way that as soon as you use the normal panel again it restores the default values because else you will have people who tried something in the advanced part only once and forget about, then only use the nomal part and have special settings without knowing for a long time - i'm thinking about xvid here where people sometimes still have overflow and curve compression settings they set a year ago (=completely outdated).
bond
20th September 2004, 23:04
seems version 0.10 of the mpegable mpeg-4 avc/h.264 encoder has been released some days ago
hopefully they have considered our "experts mode" request :D
enjoy
Shinobu
21st September 2004, 21:13
Quality based mode is aivable ^^, i'm gona test (this week end if i got some time).
++
bond
26th December 2004, 19:51
is anyone able to decode h.264 .avi files created with x264 (mencoder/ffdshow) in vfw with the mpegable avc vfw implementation?
i tried it with files created with mencoder in vdm with no success (the DAVC fourcc is needed for the mpegable vfw decoder)
the dicas vfw decoder even crashes when the stream doesnt use b-vops, cabac, loop and 4x4mv
i always get the message:
Error decompressing video frame 2:
a codec specific error occurred. (error code 1)
DeathTheSheep
27th December 2004, 18:28
Ah, indeed, the x264 seems to have added some efficiency/compression code that renders it non-decodeable with older implementations of AVC decoding software. I have the same problem, but in VDUB mod. Just get the ffdshow vfw decoder set up, and it doesn't matter whether or not the DAVC decoder functions.
Cheers, baa
bond
27th December 2004, 19:59
ffdshow now also offers vfw decoders? seems i missed something :D
just to put emphasis on it again: i tested _very_ basic x264 streams (no cabac, aso, as described above) in .avi with mpegable (to be sure that not advanced technologies cause the problems), still it didnt handle it
DeathTheSheep
27th December 2004, 23:58
Woah. Wierd. Happens here too. I wonder if DAVC vfw looks for a "fingerprint" of its native encoding? I've heard about some sort of vfw protection for a while now, just never saw it happen. Perhaps this is an example of "vfw fingerprint checking." Perhaps mpegable only wanted its decoder to decode its own stream for testing purposes (in version .10). However, I've only noticed this after the installation of Nero...
'Spose I'll look into it.
Cheers, baa
DeathTheSheep
28th December 2004, 00:02
bond, oh yeah, I forgot to say... Um, yeah, vfw decoders. Ain't I the observant little snake? Or should I say... SHEEP? BWAHAHAHAHA BAAAAHAHAHAHAA baaa. (Or maybe I'm just stupid and out of it) Ok, here goes:
http://img134.exs.cx/img134/9610/ffdshow0bn.jpg
stephanV
28th December 2004, 01:20
Originally posted by bond
ffdshow now also offers vfw decoders? seems i missed something :D
eeeeeeeeeeeerrrr... those have been there for like ages... :p
bond
12th February 2005, 13:59
mpegable, i now tested your encoder more extensively and it seems that it doesnt set the incremental frame numbers in the slices!
thats also the reason why i am not able to remux your streams to .mp4 with mp4creator
older encoder versions (0.8 and 0.7) did set the framenumbers and mux fine into .mp4
hope you can fix that soon and give us a new version to play with ;)
anyone having version 0.9 to test whether it works correctly?
daveidmx
14th February 2005, 22:56
As long as this thread has been revived, I'll add:
A few months back I used the mpegable dshow filters for a while. At the time, I'm pretty sure the channel mapping was wrong on 6ch AAC decoding. That led me to stop using it. Anyone know if this has been or will be fixed?
DeathTheSheep
17th February 2005, 22:15
After I tried uninstalling mpegable AVC VFW, it uninstalled some needed system .dlls with it, most notably msvcr71.dll. This stops many programs from working (including ffdshow).
Anyone else have this problem?
vBulletin® v3.8.11, Copyright ©2000-2024, vBulletin Solutions Inc.