PDA

View Full Version : YV12: mpeg2dec, mpeg2dec2 and mpeg3dec developers


Wilbert
30th October 2002, 10:23
@Dividee, tbarry and MarcFD,

Could anyone of you make a mpeg2dec version which outputs to YV12 by default (or by option)? (I understood that MarcFD stopped developing for a while ...) So that we can make some speed tests (YV12 versus YV12->YUY2->YV12), for dvd to DivX/Xvid. That would be really great ...

sh0dan
30th October 2002, 10:43
Though a YV12 decoder would be a good thing for testing, there is no real speed increase to be expected yet, since VDub doesn't support YV12 data yet.

So instead of:

YV12 (MPEG2) -> YUY2 (decoder) -> YUY2 (avisynth) -> YUY2 (vdub) -> YV12 (Xvid).

we still have:

YV12 (MPEG2) -> YV12 (avisynth) -> YUY2 (vdub) -> YV12 (Xvid).

Until this is resolved, you cannot expect a speed increase. Furthermore many YV12 filters still need optimizations to perform at their best.

I tried to find Marc FD's sources, but haven't been succesful yet.

Wilbert
30th October 2002, 10:51
Sh0dan, haven't you seen the modified version of pulco-citron (see for example in the thread in the development section). You responded to his message this morning, in which he says:
VirtualDubMod already passes YV12 unaltered to the decompressor if both the source and the output report to support this format (is this what you mean ?)
His version can be found in the second url of his first post in that thread.

sh0dan
30th October 2002, 11:21
I get a lot of crashes in DivX, when using YV12, but it does work (Xvid DOES recieve data as YV12 - I tested this on a debug build).
Maybe AviSynth is giving DivX wrong information, or DivX is simply buggy.

trbarry
30th October 2002, 13:35
The sources to my version of DVD2AVI and MPEG2DEC are in the Sourceforge save-oe project, and also at:

www.trbarry.com/DVD2AVIT3.zip and
www.trbarry.com/MPEG2DEC2.zip

I think Store.cpp converts from YV12 to YUY2.

Also, I'm working on a version of TomsMoComp for ffdshow (if I can ever build the darn thing) that works in YV12. After that I'll probably make a YV12 SimpleResize version which I expect to go a bit faster than YUY2. I'm not sure after that.

- Tom

sh0dan
30th October 2002, 14:24
Yes, it seems like the conversion in store.cpp should be altered. I'll see if I get the time for it.

Marc FD
31st October 2002, 01:56
Argh XD i thought you'ld need more time to get to serious YV12 stuff :)

Hey, no pb, i'm pretty familiar with the source now, i'll do it.
just wait for 10 hours (to sleep) + 2 to 6 hours (to eat & code), okay ;)

I have not started to test YV12 in Avisynth, because i thought VDub couldn't handle it before a while, but you're so fast.

You know, developpement is like a drug. you've tasted it, and after you can't stop it ^^

who would refuse a more than 20% faster MPEG-2 decoder ?
not me.

back in 12 to 16 hours,
MarcFD

PS : maybe less, but i need to test it, and my beta 7 version introduce some new features, like custom PP... so it would be a testing version first.

Marc FD
31st October 2002, 11:55
10 hours ^^

okay i've done it. here you have MPEG2Dec3 pre-beta 7 with YV12 support.
everything should work, but i've only tested PP.

Crop works ! (croping is a very good test to check a filter)
Avisynth's resampler works ! (great job sh0dan)

Frameserving tests : (script is LoadPlug()/MPEG2Source() only)

Vdub decode using the DivX 5.02 codec (as expected)
WMP 8 crash.
BSPlayer crash.
Zoomplayer works.

VDub with "Direct Stream Copy" Preview :
YUY2 version : ~60 fps
YV12 version : ~75 fps
(Athlon XP 1600+, 256 Mo DDR)

so it's about 25% faster, as expected.
but the DivX decoder is slow and/or is converting in RGB32, because it's slower than MPEG2Dec3 internal convertions :

VDub with "Fast Recompress" Preview :
YUY2 version : ~50 fps (raw YUY2)
YV12 version : ~40 fps (decoded by DivX5.02)

that's what i've noticed so far.

BTW, ConvertToYUY2/ConvertToRGB doesn't work. i guess there's no implemented YV12 support in colorspace convertions yet. what about using XviD's ones ??

I hope the VDub Mod will have YV12 ultrafast-compress soon, i'd really like to see that working ^^

(attached : "MPEG2Dec3 YV12.zip")

Wilbert
31st October 2002, 12:14
MarcFD, try this modified version: alpha0.31 (http://sourceforge.net/projects/virtualdubmpg2/). Some info (http://forum.doom9.org/showthread.php?s=&threadid=33586&pagenumber=2).

There's one thing I forgot. Dvd2avi outputs to YUY2 or RGB only, isn't it (there's no option in dvd2avi for saving in YV12)? So the last thing we need is a modified version of dvd2avi?

sh0dan
31st October 2002, 12:49
@Wilbert:

DVD2AVI shouldn't matter, if you import the d2v file into AviSynth. The decoder should be the only thing that should be modified. DVD2AVI doesn't touch the video material when the d2v is created.

(unless I'm mistaking?)

sh0dan
31st October 2002, 13:02
@MarcFD: Great work man!!! Hope it gets approved soon!

When using Avery's Vdub, the image information is converted to YUY2 before it is sent to the DivX (or Xvid) compressor, when using "Fast recompress".
The VdubMod attampts to pass YV12, which only works partially. At least on my machine, I'm getting crashes in DIVX.DLL, when I use YV12 passing. I don't know if I'm passing the wrong data to DivX or if DivX is buggy. Both are equally possible.

ConvertToYUY2 _should_ work, when the source is YV12. I've been using it a lot for tests.
ConvertToYV12 _should_ work with all colorspaces. It is not optimized by any means though (and RGB sources are converted to YUY2 first).
Yes, the XVID routines seem very obvious to use - fast, very well tested. Only problem is that they have to be converted from NASM -> MASM.

Oh - and the current ConvertToYV12 has broken interlaced chroma conversion, so you don't have to mention that - I'm aware of it!

Nic
31st October 2002, 13:15
sh0dan is correct about d2a. :) YV12 support is great for MPEGDecoder.dll (at present I have to split the YV12 frame into its y,u&v components and then convert it to YUY2. Going straight out with YV12 makes things lots easier & v.quick.

The modification to VDub should only be tiny (?) Ill check out the source & have a look.

-Nic

sh0dan
31st October 2002, 14:26
The Vdub mod does it now, but the real issue is to make Vdub(mod) open YV12 without asking for a decompressor. That way there is no need for DivX anymore.
Vdub will not be able to preview or apply filters, but I think that would be an ok solution until it can properly decompress YV12.

Wilbert
31st October 2002, 14:26
sh0dan is correct about d2a.
Can I ask something about this ... What is the purpose of that colorspace setting in d2a? What is the difference if you set it to YUY2 or RGB? What happens if you leave it at YUY2 and try to open the d2v file in VFAPI for example?

trbarry
31st October 2002, 16:48
10 hours ^^

okay i've done it. here you have MPEG2Dec3 pre-beta 7 with YV12 support.
everything should work, but i've only tested PP.

Excellent! ;)

Let me see if I know where we stand then on YV12 support. Currently we can:

- Pass YV12 directly to Avisynth with no conversion using MPEG2DEC3

- Do ConvertToxxx in Avisynth as needed (except ConvertToRGB).

- Use Avisynth Crop and various resize (except my SimpleResize)

- Pass YV21 to vdub only if we are using fast recompress and going to Divx 5, not Xvid.

Is that pretty much correct and current?


Wilbert -

The RGB/YUY2 setting is honored by VFAPI but ignored by MPEG2DECx.

- Tom

Wilbert
31st October 2002, 16:59
The RGB/YUY2 setting is honored by VFAPI but ignored by MPEG2DECx.
Ok, thanks.
Currently we can: (...)
Yes, except the last one:
Pass YV12 to vdub only if we are using fast recompress and going to Divx 5, not Xvid.
As I understand it, this is also true when encoding to Xvid or DivX3/4. But DivX5 is needed to decompress the avi when opening it in Virtual Dub modified (DivX4 and Xvid are not capable of doing this).

@MarcFD,

Did you actually attach the file?

trbarry
31st October 2002, 18:01
As I understand it, this is also true when encoding to Xvid or DivX3/4. But DivX5 is needed to decompress the avi when opening it in Virtual Dub modified (DivX4 and Xvid are not capable of doing this).

Not sure I understood this. Are you saying I could already set vdub to fast recompress and pass the YV12 clip to Xvid? (without any colorspace conversion?)

- Tom

Wilbert
31st October 2002, 18:06
Yes, but you need to install DivX5 for that. Maybe Sh0dan can explain it better :)

Alestrix
31st October 2002, 18:24
Now that everyone is hot on YV12 it's time we somehow can get our hands on Marc's mpeg2dec3b7.... Is the Mod busy or did the upload not work?
@Marc: Can you upload the file to your web page?

Can't wait trying it,
Alex

Guest
31st October 2002, 19:49
Mod was out of town and when he got home found out about a death in the family. Attachments have now been approved.

trbarry
31st October 2002, 20:00
Donald -

Very sorry to hear that.

- Tom

trbarry
31st October 2002, 20:06
Can anyone point out a very small simple example source of a standalone Avisynth filter that works in YV12 mode.

I'd like to study one before modifying TomsMoComp if possible. As close as possible to something line Ben RG's original sample filter (http://math.berkeley.edu/~benrg/avisynth-extensions.html), but for YV12.

- Tom

Koepi
31st October 2002, 20:18
@Donald:
my "condolescence" (dunno the right word for that), I am sorry for your loss.

@All:
Hm, it doesn't work for me, my AVS looks like this:

SetMemoryMax(40)
LoadPlugin("D:\Video_TS\sbc-ripping\avisynth\mpeg2dec3 YV12.dll")
mpeg2source("D:\Video_TS\5thElement\5thElement.d2v")

Loading it in vdub-mp2 or mediaplayer just makes the program disappear without further notice.

Any idea what's happening? Isn't avisynth 2.06 supporting yv12? Which AVS version do I need? Maybe I need another iDCT-number?

Thanks and best regards,
Koepi

Marc FD
31st October 2002, 20:22
@Donald
mes condoleances.

>Isn't avisynth 2.06 supporting yv12? Which AVS version do I need?

no, as far as i know only the alpha 2.5 work with YV12.

i'm gonna try how fast i can transode with :

MPEG2dec3 (YV12) -> Avisynth resample to 640x480 (YV12) -> XviD (YV12)

sh0dan
31st October 2002, 20:57
ok - I did some heavy vdub/xvid debugging, and have good news!

I have HACKED (very bad hack even) an XVID version together, that claims it is capable of decoding YV12. It isn't! But the trick is, that this enables you to use "Fast Repack" in a modified VirtualDubMPG2 i also made.

This makes DivX5 unneeded for those who doesn't want it. I made this mostly for test purposes. In general I would still recommend using DivX5!

The most important change was a small change in VirtualDubMPG2, that enabled YV12. In the official version, all data is still converted back and forth between YV12 and YVYU, because of the way it opened the file. That why there was no speed gain!

Techinical explanation - you may skip this:When Virtual Dub attempts to do "Fast recompress", it tries different codecs on the source. If the AviSynth script has YV12 for input it will fail on these. What VFW then tries is to get any decompressor to accept YV12 and then return it it the format that vdub requests. This is what DivX5 (and the hacked Xvid) does. It'll decompress the YV12 data to something that Vdub requests.
The problem was that VirtualDubMPG2 requests YVUV _before_ requesting Yv12. Therefore DivX5 kicks in and decompresses the YV12 data to YVUV, which XVID (and of course DivX) also accepts as input formats, when compressing. The problem besides the slowdown is that DivX5 seems to have buggy YV12->YVYU conversion, causing crashes.
The modified VirtualDubMPG2 now requests YV12 before any formats, and the therefore DivX5 never touches the video when "Fast Recompress" is enabled.

If you're using DivX5: (recommended!)
- Use the VirtualDubMPG2 in the "Alpha Package" on the alpha site.
- Use fast recompress, and your data should be passed as YV12.
- You should be able to preview your data most places.

If you don't use DivX5
- Manually install the Xvid.dll hack from the "Alpha Package" (if you don't know how, don't bother, stick with DivX5)
- Open the YV12 file in the modified VirtualDubMPG2 (you probably cannot open it elsewhere).
- Don't mind you cannot see the images, when dragging.
- Use "Fast recompress"
- Hopefully your result is ok.

ARDA
31st October 2002, 20:58
@Donald
Mis más sinceras condolencias

Arda

sh0dan
31st October 2002, 21:08
Originally posted by trbarry
Can anyone point out a very small simple example source of a standalone Avisynth filter that works in YV12 mode.


I've converted some internal filters. Just download the source.

Small filter you could look at:

Levels (levels.cpp)
HSIAdjust (levels.cpp)
StackVertical (combine.cpp)

Usually you have three loops - one for each plane.
Many things become clear (hopefully) if you look at the new avisynth.h and the documentation on my alpha site. Many things are still the same, but with small adjustsments.

Just ask away.

[EDIT] Just converted Ben's Invert filter. I haven't tested it, but I probably only made typo's. You can find a link to it in the development section on the alpha page. A thing that may surprise you is, that it still works with YUY2 and RGB data!

Koepi
31st October 2002, 21:08
Ok, got it working with Avisynth2.5 (http://cultact-server.novi.dk/kpo/avisynth/avisynth_alpha.html) and opening the AVS with vdub_mp2 (after installing divx5 [%&$§&%]). Cropping [Crop(2,74,716,432)] after that still works.

EDIT:

Ok, I found out that only vertical resolution can get resized :-/
Is the downsampling/upsampling in horizontal direction really so much different?

Thanks a million again,

regards,
Koepi

sh0dan
31st October 2002, 21:33
@Koepi:
Please use mod4 resolutions. This will be a YV12 requirement, but isn't enforced yet!

Did you get the modified vdub_mp2 version? Otherwise it will not be clean YV12.

Horizontal resizing should work in the version you got (and yes, it is _very_ different) - Horizontal took many times longer to implement as vertical. Try a mod8 resolution (both before and after the resizer).

Rrrough
31st October 2002, 21:43
sh0dan,

thanx for your mod on VirtualDubMPG2, will try it right away with Avisynth 2.5. please excuse a probably stupid question : why isn't xvid capable of decoding yv12 as is ? isn't it also encoding in yv12 ?
Hopefully we'll find your modifications soon in VirtualDubMod !

cheers

sh0dan
31st October 2002, 21:46
Otherwise I'm off to bed. I'll probably be gone for a couple of days now. As you get on with the testing, remember this is alpha software. Most of it is unoptimized, so don't put too much into benchmarking. There are also still some bugs to be resolved, and some missing functions.

@Donald: I'm very sorry to hear that. I hope you take the time needed for such an event. Take care!

sh0dan
31st October 2002, 21:48
Originally posted by Rrrough
why isn't xvid capable of decoding yv12 as is ? isn't it also encoding in yv12 ?

It's capable of decoding Xvid. It just doesn't touch YV12 data, when it comes to XVid for decompression. Adding proper conversion is not a job for me, but most of the code is there.

Koepi
31st October 2002, 21:50
Ok, encoding is now running at ~14fps (WOW! that's speed increase... even if your xvid.dll spits out so much debug info, doesn't use EPZS, ... ;) )

Fetched the "Alpha package", modified the AVS to look like this:

SetMemoryMax(64)
LoadPlugin("D:\Video_TS\sbc-ripping\avisynth\mpeg2dec3 YV12.dll")
mpeg2source("D:\Video_TS\5thElement\5thElement-yv12.d2v")
Crop(4,74,712,432)
Trim(0,174846).BicubicResize(640,272,0,0.5)+Trim(174846,0).BilinearResize(640,272)

Set to fast recompress, usual xvid setup (at least for me ;) ), unfortunately no unfilter and avsmonitor filters available - but the speed is there. Let's see how this encoding will look like after the 2nd pass, but it looks promising at least from the debugview output...

Thanks for all your great work,

best regards,
Koepi

Rrrough
31st October 2002, 21:51
thanx for clarifying. sleep well. ;)

Alestrix
1st November 2002, 01:31
@Donald
Sorry to hear that, I know what it's like. Hope you were not offended by my "call for the mod"...

sh0dan,
outstanding work! Did a simple avs:

LoadPlugin("C:\PROGRA~1\SOUNDV~1\GORDIA~1\mpeg2dec3 YV12.dll")
mpeg2source("D:\Eigene Dateien\Video\DVD\intermediate\shrek\shrek.d2v")
Crop(5,5,712,566)
LanczosResize(704,384)

and I can even watch it in MPC (I think I had to set ffdshow to handle raw video first). Also thanks to Marc!!! for his quick adaptation of Mpeg2Dec3!
Encoding to xvid works fine in the modified VirtualDubMpeg2 - I only found a tiny bug in Avisynth's handling of YV12 in crop/resize. When substitutung the Crop and Resize statement to LanczosResize(704,384,5,5,712,566) (which works fine in YUY2), the chrominance information is shifted up by a few pixels (my guess is 4). (in the latter case I also tried mod4 values with the same effect)
Could it also be that B-frame support (I know, I'm, overdoing things ;)) is gone in your modified xvid.dll? 'cause even when working in YUY2 the B-frame options are grayed out in XviD config. Maybe I should install DX50 (lite should do the job) again and use the standard xvid.dll with your modified VDub? Would that still pass YV12 directly to the XviD-encoder?

...maybe a few things I should test in the morning...

Again, thanks for the great work!

- Alex

Rrrough
1st November 2002, 09:08
@Alestrix

I think it's made of the stable branch (no bframes, no qpel...). take a look at the about box.

@Koepi

if it's not done already, could you please propose sh0dan's mods to CVS and/or use them for your builds ? that way we could also test dev-builds without having to deal with DivX5...

thanx alot, sh0dan, it's working real fine here, ~9 fps instead of ~6-7 fps (...slooow machine...)

cheers

hakko504
1st November 2002, 10:44
Unfortunately it doesn't look like YV12 is enabled, at least the release notes (http://sourceforge.net/project/shownotes.php?release_id=119822) don't mention it.

Alestrix
1st November 2002, 11:02
Originally posted by Rrrough
@Koepi

if it's not done already, could you please propose sh0dan's mods to CVS and/or use them for your builds ? that way we could also test dev-builds without having to deal with DivX5...

I got it to work with Koepi's latest XviD in GraphEdit (with B-frames):
Filesource (the avs) -> Xvid Compressor -> OggMuxer -> FileWriter
I used trombetworks' FilterConfigurator in the graph to configure the XviD compressor.

A little bit OT:
EDIT:decided to move this here (http://forum.doom9.org/showthread.php?s=&threadid=37096).

- Alex

Koepi
1st November 2002, 11:03
Originally posted by Rrrough
@Koepi
if it's not done already, could you please propose sh0dan's mods to CVS and/or use them for your builds ? that way we could also test dev-builds without having to deal with DivX5...


I'd love to add that to my builds but unfortunately I don't know what sh0dan changed, he has to send me the modifications so I can apply them... :)

But I'd prefer that as well, since his build is giving me worse compression than my actual dev-api-3 build+qpel,... :) Still I'm looking forward to see the results of the plain YV12 chain in ~2hrs.

Regards
Koepi

Rrrough
1st November 2002, 11:47
@Alestrix
I got it to work with Koepi's latest XviD in GraphEdit (with B-frames): gonna try it ! I didn't notice Trombettwork's FilterConfigurator yet, only seen the ChannelDownmixer. thanx for the hint. still it would be more comfortable modding xvid in general, but I guess that will take a while.

@Koepi
I'd love to add that to my builds but unfortunately I don't know what sh0dan changed, he has to send me the modifications so I can apply them... I hope sh0dan is listening (when he returns).
Still I'm looking forward to see the results of the plain YV12 chain in ~2hrs. let us know about your results.

cheers

Koepi
1st November 2002, 13:03
Jesus, it makes a difference.
It's faster. One pro.
The colours stay more "natural" due to "no unnecessary interpolations"! Another pro.

It's "very" ;) complicated and we can just use a special xvid build. That's a con ;)

Great work! This really is amazing. If I can get it to work with usual xvid builds it will be even more interesting. I hope this modification makes it in all our tools.

Best regards
Koepi

int 21h
1st November 2002, 14:36
I'm sort of lost as to why we need a special XviD build, if XviD accepts YV12, why do we need to make it appear like it is capable of decoding YV12? Only for the VirtualDub preview correct? Why not just disable to preview? I guess its related to Vdub requesting an appropriate decompressor?

Anyway, you should all chime in here:

http://virtualdub.everwicked.com/index.php?act=ST&f=11&t=449

To let Mr. Lee know how much people want this idea implemented 'properly'.

sh0dan
1st November 2002, 15:33
Originally posted by Koepi
I'd love to add that to my builds but unfortunately I don't know what sh0dan changed, he has to send me the modifications so I can apply them... :)


I included the modified codec.cpp in the alpha package. Basicly, the changes are:
decompress_query():
if (inhdr->biCompression == FOURCC_YV12) {
DEBUG("\n***** Was asked for YV12 decompression.\n");
return ICERR_OK;
}

Which basicly means: If a program asks if YV12 input is ok, return ok.

decompress_get_format():
if (lpbiInput->bmiHeader.biCompression == FOURCC_YV12) {
memcpy(outhdr, inhdr, sizeof(BITMAPINFOHEADER));
DEBUG("\n***** returned YV12 decompression.\n");
return ICERR_OK;
}

Which translates into: If a program asks for a decompression destination format, and input is YV12, ALWAYS return the same format (YV12). This may be ignored!

decompress():
{ char tmp[120]; wsprintf(tmp, "\ninput colorspace:0x%08x %s\n", (icd->lpbiInput->biCompression),&icd->lpbiInput->biCompression); OutputDebugString(tmp); }
{ char tmp[120]; wsprintf(tmp, "output colorspace:0x%08x %s\n", (icd->lpbiOutput->biCompression),&icd->lpbiOutput->biCompression); OutputDebugString(tmp); }

if (icd->lpbiInput->biCompression == FOURCC_YV12) {
DEBUG("input=yv12\n");
if (icd->lpbiOutput->biCompression == FOURCC_YV12) {
DEBUG("copying\n");
memcpy(frame.image,codec->dhandle,icd->lpbiInput->biSizeImage);
}
return ICERR_OK;
}

This is the hacky part! Basicly: If input is YV12 and output is YV12 the source frame is copied directly to the destination frame. If it isn't, nothing is done to the destination (ie. uninialized data)

This should be: If input==output==yv12, then copy as it is doing now. Otherwise do a colorspace conversion to the destination format and return that.

sh0dan
1st November 2002, 15:49
Originally posted by Alestrix
I only found a tiny bug in Avisynth's handling of YV12 in crop/resize. When substitutung the Crop and Resize statement to LanczosResize(704,384,5,5,712,566) (which works fine in YUY2), the chrominance information is shifted up by a few pixels (my guess is 4).

I have seen the same result myself (and a green pixel topleft).
Besides that, the crop functions in resize will probably be removed, since it is slower and doesn't work as well as crop().

Could it also be that B-frame support (I know, I'm, overdoing things ;)) is gone in your modified xvid.dll? 'cause even when working in YUY2 the B-frame options are grayed out in XviD config. Maybe I should install DX50 (lite should do the job) again and use the standard xvid.dll with your modified VDub? Would that still pass YV12 directly to the XviD-encoder?

Yes, it'll still work.
You should probably install DivX for testing - it'll enable preview, and you still get the speed - then you can use your own favorite xvid distributor.
The xvid hack is only temporary, and since I have no idea of which compile-defines to enable. I hope someone else will do this job, or vdubmod will take up the challenge to open yv12 data raw.

Nic
1st November 2002, 15:56
Got no idea if I have added the hack properly, because im trying to do about 100 things at work right now:
http://nic.dnsalias.com/XviD_Install_Hack.exe
Same as my build from today but with the hack installed...hope I did it right.

-Nic

sh0dan
1st November 2002, 18:05
OK - new alpha up for you speed freaks.

I rewrote the YV12 horizontal resizer, and it is MUCH faster now - even faster than YUY2.

This also seems to have solved the green pixel (chroma offset) bug - on my computer at least.

Edit: Oh - forgot - YV12 horizontal resizing requires ISSE - I'll do an MMX version soon.

Edit2: Finished the MMX-version. People with old machines can redownload todays alpha.

Marc FD
1st November 2002, 18:27
wow. 30 fps with a BicubicResize. and you say it could be even faster ?
just need to wait that vlad finish c3d YV12 (he's working on it right now) and i could speed up by more than 50% my XviD encodes ^^

BTW, if s.o. want to try a real encode, and need filtering, the PP in MPEG2Dec3 is working (it's YV12 based ^^). and you can use custom PP using cpu2. ex : chroma only filtering : cpu2="oxoxox"

iago
1st November 2002, 20:06
Hello everyone,

All I can say is that's really striking!

MPEG2Dec3 YV12
Avs 2.5 today's latest alpha
VirtualDubMpg2 modified

Averaging ~12 fps on my poor machine with BicubicResize :). Thanks everyone putting effort on this great work!

kindest regards,
iago


@Tom,

I hope we'll also have the YV12 version of your great UnFilter soon! ;)

ErMaC
2nd November 2002, 02:50
Guys, I'd really love to try some of this stuff out, but I don't want to put my normal AVS stuff in jeopardy, so here's a question.
What exactly do I need to start testing this stuff and using it and keep it in an isolated environment?
Can I have a separate VDub directory with the hacked VDub, the new v2.5 AVISynth DLL, the new MPEG2DEC DLL, and the hacked Xvid DLL, and will everything work when I use that VDub from that directory without interfering with my other stuff?

Emp3r0r
2nd November 2002, 08:55
Ermac, you need two computers to reliably have something to fall back on. Have one computer with beta stuff (2.5 YV12 is super fast on a XEON) and one with avisynth 2. I don't think Avisynth 2.5 alpha autoloads filters most likely because of alpha status so you should wait on mission critical machines.

jarthel
2nd November 2002, 09:47
isn't this thread more suitable to the "developer's section"? :)

jayel

iago
2nd November 2002, 11:19
Originally posted by Marc FD
...BTW, if s.o. want to try a real encode, and need filtering, the PP in MPEG2Dec3 is working (it's YV12 based ^^)... @Marc and all,

I can confirm that PP (cpu=x) is working great in mpeg2dec3 YV12. (edited/deleted)

BTW, I'm really sorry to hear that Marc announced he stopped development for an uncertain period...


@Donald,

I'm deeply sorry to hear about that. Condolences.


@everyone,

The result of my full two pass encode is great. Speed is amazing and colours are really much more natural, as Koepi mentioned too. I just wanted to share that. The only problem is there is a very thin green line at the bottom edge of the image (decoded with Nic's latest xvid.ax). My crop and resize values were as below:

crop(4,4,-4,-8)
BilinearResize(576,320)

best regards,
iago

Koepi
2nd November 2002, 11:25
I did a full 2pass with th Element Second Edition again, I hacked my latest development snapshot to "support" YV12 like sh0dan mentioned.
Unfortunately, I get plenty of colour errors/mismatches/smearing effects.

But the quantizer distribution is much more like I can accept it, compared to sh0dans stable-hack ;)

I'll look into this, I just wanted to mention why I didn't put up a YV12-hacked build of my binary yet.

Regards
Koepi

EDIT:

Oopsi. I just used a "fresh copy" of the xvidcore and the dshow filter, compiled it, and now playback is fine again. Ffdshow has it's problems with xvid qpel again though :-/ Still, if you're interested, I could put up an "YV12-hacked build", just need some votes for that ;)

Gaia
2nd November 2002, 11:42
Yes very nice work. It's very fast. Only problem is that this small green line is still there. It's not gone.

iago
2nd November 2002, 11:56
@Koepi

Vote 1 from me, "dostum"! ;)

regards,
iago

Rrrough
2nd November 2002, 12:34
@ErMaC
What exactly do I need to start testing this stuff and using it and keep it in an isolated environment? 2 different windows partitions work as well, supposed your HD is large enough... dividing your system into a "stable" and a "dev" part ;)
EDIT : xvid-mod in the VDMPG2-mod directory is working as a separate solution (see below), but I think avisynth 2.5 needs to be installed properly.

@iago
And a question: In Nic's XviD hack, B-frames are inactive. Did/do you use B-frames and/or QPel in your hack? make sure, sh0dan's xvid.dll isn't still in the same directory as the modded VirtualDubMPG2, otherwise it seems to use this XVID-version !

@all
that's a real boost in development, I also want to thank all involved people for working together on a great project ! thank you all.

cheers

iago
2nd November 2002, 13:01
Originally posted by Rrrough
make sure, sh0dan's xvid.dll isn't still in the same directory as the modded VirtualDubMPG2, otherwise it seems to use this XVID-version !@Rrrough

:confused: Thanks for mentioning this!

iago

Rrrough
2nd November 2002, 13:05
@iago

does it work now for you ? I asked the same question myself yesterday, until I tried to move the xvid.dll from the directory.
EDIT: errm, maybe I didn't make it clear, if you have an xvid.dll in the virtualdub directory, virtualdub uses this version, no matter what build you have installed. Nic's hack is a dev-build. if b-frames are grayed out for you, you probably have sh0dans or another xvid.dll in the virtualdub directory.

cheers

iago
2nd November 2002, 13:35
@Rrrough

Yes, you're right. So my previous encode was with Shodan's build ;). I removed the xvid.dll from modified VirtualDubMpg2 directory and now I'm using Nic's build with B-frames enabled. It's also clearly visible from the debugview output, which I overlooked in my previous encode. Thanks for clarifying this.

regards,
iago

edit: my previous posts are edited accordingly, to avoid possible misguidance on the part of other users.

Alestrix
2nd November 2002, 17:38
@koepi:
One more vote from me!
(wanna be able to uninstall DivX again :-) )

- Alex

trbarry
2nd November 2002, 19:33
Koepi -

Vote from me too.

- Tom

int 21h
2nd November 2002, 19:41
Hmm, no matter what I try, with MPEGDecoder I always get 'failed to open' for my vob...


SetMemoryMax(96)
LoadPlugin("C:\ENCODI~1\MPEGDecoder.dll")
MPEGSource("D:\VIDEO_TS\VTS_03_1.vob",-2,"decss")
BicubicResize(576,256,0,0.65)


or


SetMemoryMax(96)
LoadPlugin("C:\ENCODI~1\MPEGDecoder.dll")
MPEGSource("C:\vobs\VTS_03_1.vob")
BicubicResize(576,256,0,0.65)


Both places are valid paths and the vobs do rest at those locations (D: being the DVD Drive). This is with the newest alpha of Avisynth, and the newest download of MPEGDecoder from nic's homepage and I tried both VirtualdubMPG2 and the supplied version from this thread... The exception is being thrown from Line 3...

I know I tested this before and it worked fine, any ideas?

Rrrough
2nd November 2002, 20:28
hmmm, I guess MPEGDecoder doesn't output to YV12 yet :confused: did you try MPEG2DEC3 yet ?
EDIT: sorry, stupid thinking, of course it should work with YUV2 as well...

Nic, do you plan to support it with your next ("rebirth") version ?
that will probably give the next speed boost ! I'm really looking forward to it.

cheers

ARDA
2nd November 2002, 20:52
@int 21h
I couldn't open a vob either.
I've been able to encode a short clip with the following:
Avisynth 2.5 from shodan, xvid.dll and Virtualdubmpg2 modified
from this page http://cultact-server.novi.dk/kpo/avisynth/avisynth_alpha.html
+dlls in virtualdubmod projects page http://sourceforge.net/projects/virtualdubmod,
mpeg2dec3 yv12.zip,from Marc FD first page of this thread and this avs.script

LoadPlugin("C:\Avisynthplugins\mpeg2dec3 YV12.dll")
MPEG2Source("D:\LaPutaVida\laputavidapista1.d2v",CPU=0,IDCT=5).
\crop(8,8,704,536).LanczosResize(640,336)

I hope than can be usefull
Arda

@Koepi -
Vote from me too.
Arda

And I've almost forget to say THANKS EVERYBODY for this new revolution.
_______________________________________________
Lo único absoluto es el cambio permanente

vlad59
2nd November 2002, 21:05
IIRC avisynth 2.5 (alpha) use a brand new avisynth.h so all existing filter must get recompiled to be used with v2.5

iago
2nd November 2002, 21:10
@vlad59

I hope one of the first of those will be your "Convolution3d YV12.dll"! ;)

regards,
iago

MaTTeR
2nd November 2002, 21:13
It seems even basic scripts fail with v2.5 on one of my machines. With some trickery I've managed to encode a 2pass movie with XviD though and all seems to be working fine on the dualie PIII.

Following script causes instant VirtualDubMpg2 crashes upon opening-

LoadPlugin("C:\Program Files\AviSynth2\plugins\MPEG2DEC3 YV12.dll")
mpeg2source("D:\DivX RIPs\Romeo is Bleeding\romeo.d2v")
crop(8,4,708,468)
BicubicResize(624,348,0.4,0.4)

I tried no less than 20 different MOD-4 and MOD-8 resolutions and still no luck:rolleyes: So it seems my Win2k/Dual AMD system doesn't have much hope for YV12 for the moment.

Edit- I hope one of the first of those will be your "Convolution3d YV12.dll Yes, that will be great indeed.

vlad59
2nd November 2002, 23:01
@iago & MaTTer
Don't worry it's almost done. I just have to take care of first and last line who need a special work and that's it.

@MaTTer
You should be happier too : due to the rewrite it will be easier to add SMP support.

Koepi
2nd November 2002, 23:57
XviD-02112002-1:
- Fresh CVS checkout. GMC support (search precision ultra).
- New mod. HQ quant type reimplemented.
- Hacked in YV12 decoding support for new YV12 testings at forum.doom9.org.


GMC! Yay!

No improvement on first pass size for a test on "shanghai noon" yet, but let's see the result in a few hours (well, i most likely will sleep when it's finished), it even grew bigger - it seems minimum framesize isn't always used with GMC as is now, but at least we have something to play with...

Regards,
Koepi

MaTTeR
3rd November 2002, 00:02
@vlad

I'm already drooling for that rewrite;) I'm sure it will be worth the wait.

@Koepi,
Wow! GMC is now implemented as well. I can't keep up with all these new features. Thx for the new build!

Edit- Koepi,
So I gather that using MotionSearch 6 is also going to use Qpel along with GMC? I wish we had a way to turn each of the features on/off.

Rrrough
3rd November 2002, 00:08
@Koepi

thank you for granting our wishes so fast ! :)
not does only the speed of conversion grow, but also the speed of development. AMAZING

@vlad59

well, drooling here, too !

cheers

Koepi
3rd November 2002, 01:02
Yes, search precision 6 throws everything in we have, so qpel as well ;)

Regards,
Koepi

MaTTeR
3rd November 2002, 03:10
I'm sure it's too soon for this but just curious if anyone knew of a softening/blur filter that works in the YV12 space right now. If not, I'll wait patiently like everyone else:D

I managed to finally get a script to open an encode on my dual AMD box now, the trick is to not have any resizing line for some reason. As soon as I try to resize with any resolution it causes the immediate VdubMPG2 crash. Seems very stable on the dual PIII 850 box though, have done several 2 pass movies already today.

Just wanted to say thx to all the ppl who are contributing to make YV12 happen.

vlad59
3rd November 2002, 12:12
@all

while testing Convolution3D for YV12 I had some stange results :

I wanted to compare a simple avs script in YUV2 and YV12 colorspace to test the compressibility / speed of filters

My avs script is simple mpeg2source, crop & that's all.
I used DivX5 to decode YV12, all encode are done with a very old Xvid.


in YUV2 :
without C3D :
speed : 8.6 fps
first pass size : 69839 Ko

with C3D (v1.01) :
speed : 4.9 fps
first pass size : 48548

in YV12
without C3D :
speed : 8.34 fps ???????
first pass size : 74138 ???????

with C3D (new YV12) :
speed : 5.8 fps
first pass size : 49983


Strange, isn't it !
I'll make a test with the latest Koepi Xvid which can decode YV12 without Divx5 but I don't understand fully.


The good news is that C3D is faster with YV12.

Rrrough
3rd November 2002, 12:39
@vlad59

that's definetly strange :confused: but I'm glad C3D gets sped up !!! YAY

@all

I was reporting this XVID+VD YV12 decoding "problem" to xvid-user list, and guess what, sh0dans hack is already in CVS now, and it's being discussed now if+how xvid color conversion can/should be used by other programs, so maybe we'll get the preview function working purrfectly with XVID and ... bye bye DivX5 ...

cheers

ErMaC
3rd November 2002, 13:45
Update:

It does indeed appear that if I stick all the pertinent files in a single directory and open everything manually using the file->open dialog boxes, I can use the new DLLs in an isolated environment. I downloaded the VDubMOD DLLs, the AVISynth package and the binary DLL, and MarcFD's mpeg2dec yv12 and placed them all in a folder and Version is reporting back v2.5 - I'll do tests with some DVD encodes shortly.

@Vlad
I'm also waiting for the Conv3d so I can do REAL encodes (since now I only do DVD rips using it).
I also have an SMP system so if you need someone to test your SMP code please let me know and I would be happy to help. I'm running dual P3 700MHz on an Abit VP6.

sh0dan
3rd November 2002, 14:38
Originally posted by vlad59
@
My avs script is simple mpeg2source, crop & that's all.
I used DivX5 to decode YV12, all encode are done with a very old Xvid.
[...]
Strange, isn't it !
I'll make a test with the latest Koepi Xvid which can decode YV12 without Divx5 but I don't understand fully.

Are you using the modded VDub MPG2? Otherwise your YV12 will be converted to another format before it is handed to XVID. With the XVID hack, you don't risk that (you'll just get black frames).

The good news is that C3D is faster with YV12.

Well, that's just great news! Seems like we're getting some fairly good speeds for 2.5 - nice!

sh0dan
3rd November 2002, 14:42
Originally posted by Rrrough
I was reporting this XVID+VD YV12 decoding "problem" to xvid-user list, and guess what, sh0dans hack is already in CVS now, and it's being discussed now if+how xvid color conversion can/should be used by other programs, so maybe we'll get the preview function working purrfectly with XVID and ... bye bye DivX5 ...

I hope I have not laid it out that way - it's not a bug in Xvid, that it doesn't decode YV12 - it's just another feature of DivX5. I'm not to judge if this should be a feature of Xvid, or if there should be written a seperate codec for this (without XVID).
I do however see a good point in Xvid supporting YV12, since it'll probably broaden the use of Xvid even further. But please remember - it's not an Xvid bug!

sh0dan
3rd November 2002, 14:46
Originally posted by MaTTeR
Following script causes instant VirtualDubMpg2 crashes upon opening-
[...]
So it seems my Win2k/Dual AMD system doesn't have much hope for YV12 for the moment.

I'll try it out to see if I can reproduce!

Rrrough
3rd November 2002, 15:14
I hope I have not laid it out that way - it's not a bug in Xvid, that it doesn't decode YV12 - it's just another feature of DivX5. I'm not to judge if this should be a feature of Xvid, or if there should be written a seperate codec for this (without XVID). no, I didn't regard it as a bug and didn't describe it as one in the mailing-list, that's why I wrote "problem" here.
The term of "feature-addition" would be more suitable, I guess. :)
It is proposed now (and concerning your hack, it's already accepted) and the judges (=xvid-devels) have to decide whether it should be done or not.

cheers

sh0dan
3rd November 2002, 15:34
@Rrrough: ok :)

/me looks up from, and relaxes a bit to see that there are no angry Xvid-devel's after me. :cool:

[Toff]
3rd November 2002, 15:45
@sh0dan

RGB support in 2.5alpha (avisynth_a_011102.zip) seems broken.
Here is a test clip (650ko) :
http://christophe.paris.free.fr/temp/bug_AVS25_RGB24.avi

And the avs script:
AVISource("bug_AVS25_RGB24.avi")
ConvertToRGB24()

MaTTeR
3rd November 2002, 15:52
Originally posted by sh0dan
I'll try it out to see if I can reproduce!

Well after hours of trying to get it working I finally managed to do so by cropping in multiples of 8 instead of 4. Of course I also I had to use a MOD-4 resolution. It seems to be working great and very stable.

At 640 resolution I was encoding at 63FPS, I'd say that's a nice speed boost; not to mention the colors staying slightly cleaner. Thx anyways shOdan!

sh0dan
3rd November 2002, 16:26
Originally posted by [Toff]

AVISource("bug_AVS25_RGB24.avi")
ConvertToRGB24()

ConverttoRGB doesn't support YV12 (as stated on the alpha page).
UseAVISource("bug_AVS25_RGB24.avi")
ConvertToYUY2()
ConvertToRGB24()

sh0dan
3rd November 2002, 16:32
Originally posted by MaTTeR
Well after hours of trying to get it working I finally managed to do so by cropping in multiples of 8 instead of 4. Of course I also I had to use a MOD-4 resolution. It seems to be working great and very stable.


@MarcFD: Are you using AlignPlanar in Mpeg2dec3?

Edit: It seems more like an unintentional "feature" in the horzontal resizer.
Edit2: Which leads back to a bug, where avisynth.h not returned aligned row-widths.

sh0dan
3rd November 2002, 18:49
New version. Fixing mod 4/8 problems. Complete changelist:

* Resizer now works with MOD4 resolutions.
* MergeLuma/MergeChroma now supports YV12
* Fixed bug in YV12 greyscale.
* Fixed general bug on resolutions that are not mod16.
* NewVideoFrame() now throws an error, if a filter attempts to create an YV12 image that isn't mod4.
* Separatefields() should now split chroma correctly (according to the YV12 spec.)
* Mod4 checks in Resize, crop, addborders.

Enjoy

Bug? - I get some chroma noise on the last line when resizing vertically.
Edit: There seems to be stability issues with this release. I'll test further, but beware!
Edit3: Hopefully fixed it.

New feature:

* Added Limiter(clip,min_luma, max_luma, min_chroma, max_chroma) (inspired by Sansgrip)

MaTTeR
3rd November 2002, 18:54
Thx for the confirmation sh0dan. New build changelist looks great!

Edit- I just wanted to confirm with you that TemporalSoften still isn't YV12 supported. Correct?

Marc FD
3rd November 2002, 19:06
>Are you using AlignPlanar in Mpeg2dec3?

no. the internal buffers are all 128-bit aligned, but i just added a very simple memcpy from these buffers in each plane.

sh0dan
3rd November 2002, 19:20
@Matter: Correct. It hasn't been implemented yet. I hope dividee will get back to assist us.

@MarcFD: OK. If you use NewVideoFrame that isn't a problem. Just wanted to make sure :)

Koepi
3rd November 2002, 21:45
XviD-03112002-1:
- Fresh CVS checkout. GMC decoding support added.
- New mod. HQ quant type reimplemented.
- Added checkboxes for qpel/gmc for better control.

Well, now even YV12 support is "official", maybe you like this build more.

Regards,
Koepi

iago
3rd November 2002, 23:08
@shOdan,

Any ideas and/or hope ;) about the "green-line-at-the-bottom-edge" problem?

@Tom,

Sorry for asking this one more time but any plans on making a YV12 release of UnFilter? ;) (I got addicted and can't live without it! :p)


Best regards and many thanks again to everyone putting effort on this great work.

iago

MaTTeR
3rd November 2002, 23:22
Originally posted by iago
@shOdan,

Any ideas and/or hope ;) about the "green-line-at-the-bottom-edge" problem? I noticed it on my encodes today also.

MOD-8 resolutions does seem to work now with the new AVS build from shOdan and I haven't experiences any instabilities yet.

trbarry
4th November 2002, 05:38
Sorry for asking this one more time but any plans on making a YV12 release of UnFilter? (I got addicted and can't live without it! )

iago -

Yep, Unfilter should be an easy port. But my YV12 plans for the moment are:

- UnDot (fast deringing dot remover), new and simple, mostly done

- TomsMoComp, about half done

- SimpleResize, harder, but I want it

- UnFilter, not hard, but not first ;)

- MPEG2DEC2 HDTV support, others?

As I posted elsewhere, I'm actually having more trouble with YUY2 in the 2.5 alpha.

- Tom

ookzDVD
4th November 2002, 06:02
@forum,
Can someone please post an example of your working .avs script
(complete) for this YV12 ?
How many percent improvement use the YV12 over the "regular" one ?

@sh0dan,
Is all the build resize filter : Bilinear, Bicubic, Lanczos support
the YV12 ?

Thank you.

MaTTeR
4th November 2002, 06:58
Originally posted by trbarry
UnDot (fast deringing dot remover), new and simple, mostly done
Tom,
That's great news, glad to hear your working on them already. When you say "dot remover", are you speaking about the so called "mosquito noise" we see on DVD sources? I know your mostly into HDTV so maybe I'm off base here.

Koepi
4th November 2002, 07:01
@Ookz,

please read the whole thread, all the 50 posts (you'll see which posts you can jump over as they're more-or-less chit-chat).

E.g. I posted a nice working script some pages ago, some other people as well. It's all already there. Even the answer to your question that all resizers are.... well. Now go back to start, and READ for yourself.

Thanks for your attention ;)

Koepi

sh0dan
4th November 2002, 07:33
Originally posted by iago
Any ideas and/or hope ;) about the "green-line-at-the-bottom-edge" problem?
It should be gone in the latest (04-11) build - at least on my machine.

Gaia
4th November 2002, 09:14
Originally posted by sh0dan
It should be gone in the latest (04-11) build - at least on my machine. Sorry sh0dan but the green line is still sadly there :( Tried your latest build...

Rrrough
4th November 2002, 12:12
@iago & gaia,

I haven't come across the green line problem yet, could you please post your AVS-scripts ? wanna try to reproduce it.

cheers

Gaia
4th November 2002, 12:48
Here's my very simple test script:

LoadPlugin("C:\OHJELM~1\GORDIA~1\mpeg2dec3 YV12.dll")
mpeg2source("C:\THREE_KINGS\3kings.d2v",cpu=0)
crop(0,74,720,428)
BicubicResize(640,264)

It's there but sometimes it's bit hard to see. Turn all the lights off. I also noticed that there's somenthing in the left border.

Marc FD
4th November 2002, 13:11
> I also noticed that there's somenthing in the left border.

yellow dots, right ? might be the know bug of XviD old colorconv.

Gaia
4th November 2002, 13:36
Originally posted by Marc FD
> I also noticed that there's somenthing in the left border.

yellow dots, right ? might be the know bug of XviD old colorconv. Not quite sure how to descripe it. Maybe dots maybe somekind of line too...

Rrrough
4th November 2002, 13:37
do they also appear when using another compressor (e.g. DivX) ?

Marc FD
4th November 2002, 13:42
>Not quite sure how to descripe it. Maybe dots maybe somekind of line too...

a bit this way :

-- normal pixels
xx yellow dots

------
xx----
------
xx----
------

on the left side only.

>do they also appear when using another compressor (e.g. DivX) ?

if i remember well, it's only on decoding, so it's not in the bitstream.
and i think the new color convertions fixed it. but i'm not sure it's been commited to CVS now.

Rrrough
4th November 2002, 13:45
f i remember well, it's only on decoding, so it's not in the bitstream. maybe gaia could change the 4cc to divx and use divx decompression or try ffdshow and see if it's still there...

cheers

Gaia
4th November 2002, 13:46
Originally posted by Marc FD
>Not quite sure how to descripe it. Maybe dots maybe somekind of line too...

a bit this way :

-- normal pixels
xx yellow dots

------
xx----
------
xx----
------

on the left side only.

>do they also appear when using another compressor (e.g. DivX) ?

if i remember well, it's only on decoding, so it's not in the bitstream.
and i think the new color convertions fixed it. but i'm not sure it's been commited to CVS now. I have to try Divx but yes i quess it's like you descriped them.

Koepi
4th November 2002, 13:49
Your description looks exactly like the xvid decoder bug. If isibaar finds some time and is bored (means: has no other interesting features to play with), he'll fix that MMX code. Go to XviD configuration and there to the CPU tab and disable all mmx/sse stuff and you'll see the yellow spots are gone.

Regards,
Koepi

Marc FD
4th November 2002, 13:49
if you see it in VDub, i'm pretty sure it's the YV12->RGB32 convertion.
try with DX50 fourcc and see.

@Koepi

could you commit the checkbox in vfw to CVS, i'd like to test it, and i'm a noob to change the interface. thanks.

Koepi
4th November 2002, 13:53
Marc,

I'll send you the sources. They are for current CVS, thus already supporting chroma me :) The first test run here looks very promising, but since gruel's a little angry with me I fear I won't release a binary until it proved to work alright here.

Regards,
Koepi

Marc FD
4th November 2002, 13:56
just send vfw, i've a 5 min old xvidcore, i guess it's okay (i've the last ME)

but i don't have checkboxes ^^

BTW, i'll apply the patch to test the new color convertions

Gaia
4th November 2002, 13:57
Thanks for help. Now only problem is that green line at the bottom.

Marc FD
4th November 2002, 14:01
@Koepi

thx.

@Gaia

i think Sh0dan will fix that very fast as always.

Koepi
4th November 2002, 14:59
XviD-04112002-1:
- Fresh CVS checkout. GMC improvements.
- New mod. HQ quant type reimplemented.
- Added checkbox for chroma motion estimation (slow but better PSNR).

So now everyone can test it...

Regards,
Koepi

Rrrough
4th November 2002, 16:15
@all,

as you can see that there's a lot of changes going on on the XVID-development branch, please make sure when reporting possible avisynth problems/bugs that you test with another codec as well, as there might be some problems/bugs related with these _unstable_ xvid dev builds.
just an idea to make avisynth debugging easier.

cheers

iago
4th November 2002, 18:00
@Rrrough and all,

Regarding the green line problem, With all my XviD encodes (including Koepi's 04112002-1 build) and today's AviSynth 2.5 binary too, the green (or sometimes pinkish) line is still there at the bottom. Changing the FourCC to Divx, decoding with ffdshow or DivX 5.02 decoder or using Nic's latest DSF, or disabling XviD optimizations (though I don't know if the green line is the same issue as the yellow dots mentioned) doesn't change a thing.

To make sure I did a test encode with DivX 5.02 as well, and the green line problem persists with DivX 5.02 too (decoded with DivX Decoder - 5.02).

Below is my avs script:

--------------------------------------------------------
LoadPlugin("C:\FILTERS\mpeg2dec3 YV12.dll")
mpeg2source("D:\RIP\RIP.d2v",blend=true,cpu=4,lumoff=-2)
crop(12,8,-12,-8)
BicubicResize(512,288,0,0.75)
--------------------------------------------------------

regards,
iago


edit1: Windows XP - Celeron 900 - ZoomPlayer and MPC

edit2: Tom, it's really nice to hear that you're gonna release UnFilter YV12, though you say it's not in your utmost-priority list! ;)

edit3: Koepi, many thanks for the new toy to play with, which has a lot of new features as well! ;)

edit4: Rewriting the crop parameters in the above script as crop(16,8,-16,-8) and encoding with it doesn't make a difference either.

edit5: I tried with mpeg2source("D:\RIP\RIP.d2v") as well, to check if the problem is related with mpeg2dec3 YV12 parameters, but it does not seem to be related with mpeg2dec3 YV12 either.

sh0dan
4th November 2002, 18:52
The thin green line is probably an AviSynth resizer bug I haven't found yet. I'm working on it however :)

Edit: (and it isn't an easy one to find) :angry:

iago
4th November 2002, 19:21
@shOdan

Many thanks for your time and effort regarding the "green line" issue. I'm almost sure it will be resolved very soon, since it's under your very investigation! ;)

best regards,
iago

HarryM
4th November 2002, 19:33
Originally posted by iago
@shOdan

Many thanks for your time and effort regarding the "green line" issue. I'm almost sure it will be resolved very soon, since it's under your very investigation! ;)

best regards,
iago

You can crop this green line away... :D :D :D

sh0dan
4th November 2002, 19:48
Originally posted by iago
Many thanks for your time and effort regarding the "green line" issue. I'm almost sure it will be resolved very soon, since it's under your very investigation! ;)

Got it (almost sure) - One of the more stange bugs I've had. What you can learn from this is: Never use the same variable name for a private class variable and a local function variable. (This bug is a very old one, but it just never showed up until multiple planes were added ;)

You can expect a speedup from this too (wow - a bugfix with a speedup!)

iago
4th November 2002, 23:33
@shOdan

Great news that you have pinpointed and solved the problem! And the solution comes with even more speed gain! What can I say?! ;)

thanks a lot for all your great work,
iago

Edit: Tested and confirmed! Green line is history now! ;)

iago
5th November 2002, 01:03
@Marc,

I guess lumoff parameter does not work in your "mpeg2dec3 YV12.dll", right? I really would like to be able to use it with YV12 ;).

regards,
iago

trbarry
5th November 2002, 03:23
Tom,
That's great news, glad to hear your working on them already. When you say "dot remover", are you speaking about the so called "mosquito noise" we see on DVD sources? I know your mostly into HDTV so maybe I'm off base here.

MaTTeR -

Not off base at all. It is a fairly fast simple deringing median filter designed to remove stray dots. It should somewhat handle ringing and mosquito noise. It may not have as strong an effect as the one I did for Xvid/ffdshow but should be maybe twice as fast.

Some really superficial testing shows it gives maybe a 5-10% compression improvement at Xvid quant=2 for clean (superbit) source without any obvious loss of detail. But this is brand new, experimental, and only for the Avisynth 2.5 alpha testing (SSEMMX only).

I intended this somewhat to be a simple example of a mixed YUY2 and YV12 (no RGB) filter. Anyway, see:

www.trbarry.com/Readme_UnDot.txt and
www.trbarry.com/UnDot.zip (source & dll)

And FWIW, after demuxing HDTV caps are basically just Vobs, YV12/mpeg2 video with ac3 sound except lots more pixels. They can have the same blocking and ringing problems as a DVD and can be IVTC'd and deinterlaced the same. But many of the same tools work and Avisynth/Virtualdub/Xvid is still the way to go. I recommend everybody get a HDTV card for captures if there are any stations where you live. It's like they are broadcasting free 1920x1080i DVD's (but cut for prime time audiences, the "airplane versions").

But because of the huge resolution they are pig slow to process which makes Sh0dans new YV12 support the neatest thing since sliced bread.

Thanks, Sh0dan. ;)

- Tom

MaTTeR
5th November 2002, 15:08
Tom,

Thx for the speedy filter. I ran a full 2pass encode last night using latest AVS 2.5 alpha along with Koepi's latest 11-04 dev build. No problems at all and I did gain about 7% in compression. Visually I don't see any loss of detail. While the source isn't SuperBit, it's still one of the cleanest DVD transfers you'll see for an older movie(Romeo is Bleeding). So I guess it's safe to change your readme to indicate it has been tested on AMD Athlons:)

Dual AMD XP 1600s
Win2k w/ SP3
512MB PC2700 DDR

BTW- Many thx for that HDTV info, I had never really paid much attention to it until this weekend I seen a beautiful Fuji HDTV at my local AV store. Unfortunately it was almost $10K but certainly had the best picture I've ever seen. It would be worth me buying HDTV just for the National Geo. HDTV channel thats broadcasted here.

int 21h
5th November 2002, 16:34
You all may be interested in checking out:

http://forum.doom9.org/showthread.php?threadid=36768

Its a commandline encoding application specifically for Avisynth written by [Toff], and today I added two pass functionality to it (with XviD in mind). Give it a whirl (It supports YV12).

Marc FD
5th November 2002, 17:05
>I guess lumoff parameter does not work in your "mpeg2dec3 YV12.dll",
>right? I really would like to be able to use it with YV12 .

It works, and all other features too, because everything is working in YV12 colorspace.

iago
5th November 2002, 21:05
@Marc

The results I get when using lumoff=-96 and no lumoff parameter are the same, which is impossible, since a value of lumoff=-96 should darken out the encode considerably! ;)

To make sure, can you or someone else check that on another machine please?

(mpeg2dec3 YV12.dll - Avs2.5 (4-11-02) - XviD 04112002-1)

regards,
iago

unplugged
6th November 2002, 02:34
Originally posted by int 21h
You all may be interested in checking out:

http://forum.doom9.org/showthread.php?threadid=36768

Its a commandline encoding application specifically for Avisynth written by [Toff], and today I added two pass functionality to it (with XviD in mind). Give it a whirl (It supports YV12).
Maybe?

YV12@#]/@€£$"òç!!!

Boys, this AVS2AVI utility really ROCKS !!!

It takes almost NO TIME to setup!!! :D
Very easy to insert in batch files toghether with other stuff + shutdown command ;) and goes up to 40fps with my Athlon 2100+ even with B-Frames at hi-res!!

Love infinitely command-line tools... :p

Thanx TOFF!

Waiting Suiryc for OGG mod ;)

MaTTeR
6th November 2002, 04:13
Originally posted by iago
The results I get when using lumoff=-96 and no lumoff parameter are the same, which is impossible, since a value of lumoff=-96 should darken out the encode considerably! ;)

Iago is correct of course, changing the value either direction gives no effect to the encode whatsoever. However, I can confirm that various PP/CPU modes are working. I still never understood what blend=xxxx did so I never play with it:confused:

ookzDVD
6th November 2002, 04:14
Hmmm....

I have the same speed of encoding even the "default" or the tricky
"yv12" mode both the same speed with the same script and xvid settings, both about ~17-19fps on my Athlon XP +1700.

I think I'm missing something or it's my bad machine :(

MaTTeR
6th November 2002, 04:56
I think I've just ran across a nasty bug but I'm not sure who the culprit is at this time. For whatever reason, encoding with a resolution of 612x332 almost doubles or triples my file size compared to a resolution of 608x332.

Koepi's Dev Xvid build- 04112002 using Chroma motion option with MPEG fixed quantizer of 2. Also using latest AVS 2.5 alpha build dated as 11-04-2002 along with shOdan's hacked VdubMPG2 app.

Sample Script- LoadPlugin("C:\Program Files\AviSynth2\plugins\MPEG2DEC3 YV12.dll")
mpeg2source("D:\test\romeo.d2v")
crop(8,4,704,464)
LanczosResize(604,328)
Limiter()

Replacing the resizer line above with LanczosResize(608,332) gives expected results. Please forgive me if I'm overlooking something very obvious here, it was a very long day at work. Can anyone else reproduce the results though?

Edit-
@ookzDVD,
Can you post your script and XviD build?

Edit2-
@all,
Uhgg...guess I'll try reproducing my file size problem with Divx5 quants now to make sure this isn't an XviD issue.

Update: Moderator, please merge this post with the following Xvid thread. (http://forum.doom9.org/showthread.php?s=&postid=205847#post205847) In fact I was unable to reproduce the problem using Divx 5.02

ookzDVD
6th November 2002, 05:36
@MaTTeR,

Here is my script :

LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec3 yv12.dll")
mpeg2source("C:\Documents and Settings\Administrator\My Documents\murder.d2v",lumoff=-2)
crop(0,0,-2,-2)
LanczosResize(640,352)

Wilbert
6th November 2002, 10:02
Last evening I tried Vobsub (which is supposed to work in YV12), but it doesn't work at all in AviSynth 2.5 alpha. I will contact Gabest.

Chibi Jasmin
6th November 2002, 13:57
Originally posted by unplugged
Boys, this AVS2AVI utility really ROCKS !!!


And girls? :)

Well, you're right, I also played with it and I love it...avs2.5 + mpeg2dec3 yv12 + avs2avi is fine for yv12... :D

Marc FD
6th November 2002, 14:33
>The results I get when using lumoff=-96 and no lumoff parameter are the
>same, which is impossible, since a value of lumoff=-96 should darken out
> the encode considerably!

oups ^^
maybe i've commented the luma filtering with the YV12->YUY2 stuff.
because it's just before.

i'll try to release MPEG2Dec3 beta 7 with YUY2/YV12 choice and cleanded settings.

@Sh0dan :
are filters compiled for avisynth 2.5 compatible with 2.06 if i keep YUY2 colorspace ?

maybe i should wait until YV12 is stable. it's why i said i would stop to code.

BTW, is it possible to try to improve DirectShowSource in avisynth 2.5 ??
*.grf files support and/or sound support would be great. i hate dshow, but i admit it's sometimes a very usefull tool.

Cheers,
MarcFD

sh0dan
6th November 2002, 15:41
are filters compiled for avisynth 2.5 compatible with 2.06 if i keep YUY2 colorspace ?

No - and they never will. The internal structures have changed, and some have been added, so a 2.5 filter cannot work with earlier versions.
However a minor set of #ifdefs should make it possible to keep the two versions side by side.

[EDIT!] I've been talking to Gabest regarding VobSub, and he suggested that we should replace "AvisynthPluginInit" for plugins with "AvisynthPluginInit2" for 2.5 plugins. That way there will not be any conflicts at least. I still think you would need to compile two seperate dll's, since it refers directly to the structures of avisynth.h.


maybe i should wait until YV12 is stable. it's why i said i would stop to code.

You're free to wait. YV12 will probably not change much more, since it seems to be working very nice internally, both performancewise and codewise (easy/good enough to use for plugin writers).

There will probably be added a few helper functions to Environmnet Settings in avisynth.h, but nothing major.

BTW, is it possible to try to improve DirectShowSource in avisynth 2.5??
*.grf files support and/or sound support would be great. i hate dshow, but i admit it's sometimes a very usefull tool.

If you know how - yes! VFW and DirectShow was a dark hole for me until recently. I've learned some basics about VFW, but Directshow is still trial and error. I would love to add sound support, and GRF-support, but I have no idea where to start, and I would rather spend the time on finishing up 2.5 instead of beginning on a new project.

trbarry
6th November 2002, 16:27
I still also have Divx5 installed which means that even when I send Vdubmpg2 YV12 data I can still see the preview, etc.

But when I set vdub to Fast recompress then it still should be passing the data directly to Xvid as YV12 without conversions, right?

I don't know how I would be able to test that except for speed and I don't know enough about how vdub works to be sure.

And, is that Divx YV12 decompressor even included in the free (non-adware) version of Divx 5?

- Tom

sh0dan
6th November 2002, 16:44
Originally posted by trbarry
But when I set vdub to Fast recompress then it still should be passing the data directly to Xvid as YV12 without conversions, right?

Yes

I don't know how I would be able to test that except for speed and I don't know enough about how vdub works to be sure.

The only way I know. You could try the new great "AVS2AVI" - it reports the colorspace used! But it's command-line based, so there is no preview there either.

And, is that Divx YV12 decompressor even included in the free (non-adware) version of Divx 5?

Don't know - anyone?

HarryM
6th November 2002, 18:59
Where can I find AVS2AVI utility?

I find on google, I can't find it!

hakko504
6th November 2002, 19:06
Originally posted by HarryM
Where can I find AVS2AVI utility? In a threaed in the developers forum here, called Command Line Compressor (http://forum.doom9.org/showthread.php?s=&threadid=36768)

Rrrough
6th November 2002, 19:40
And, is that Divx YV12 decompressor even included in the free (non-adware) version of Divx 5? yep. (what an elaborate and thoughtful answer, I know ;) )

iago
6th November 2002, 23:19
i'll try to release MPEG2Dec3 beta 7 with YUY2/YV12 choice and cleanded settings.

Marc,

Nice to hear that! I'm really looking forward to it and getting the lumoff parameter back again! ;)

regards,
iago

ookzDVD
7th November 2002, 04:30
Yes, I finally could notice some YV12 speed improvement over the
YUY2... it's about 10-15% on my machine... not bad :)

Koepi
8th November 2002, 10:50
@MarcFD:

Any progress with mpeg2dec3+yv12 choice / beta7? ;)

@all:

How's vdub-mod coming along? :)=

Best regards,
Koepi

vlad59
8th November 2002, 11:02
As it seems there is two thread about Avisynth 2.5, I also post here.

The first beta of Convolution3DYV12 is out you can find it here (http://forum.doom9.org/showthread.php?s=&threadid=36279)

Thnaks in advance for the feedback

MaTTeR
8th November 2002, 12:53
Originally posted by vlad59
The first beta of Convolution3DYV12 is out Very cool Vlad. My testing begins in about 9hrs from now:)

BTW- The readme is showing all presets using the same values of- (0, 32, 128, 32, 128, 10, 0).

Edit- First impressions of the speed seem to be pretty good.

LoadPlugin("C:\Program Files\AviSynth2\plugins\MPEG2DEC3_YV12.dll")
mpeg2source("D:\Lost\lost.d2v",iDCT=2,cpu=1,moderate_h=45,moderate_v=65)
crop(8,58,704,368)
UnDot()
Convolution3D(0,2,3,2,3,2.8,0)
LanczosResize(624,264)

Averaging 29FPS with XviD and Chroma motion at Motion Search 6, latest dev build from Koepi. Thx Vlad

vlad59
8th November 2002, 14:00
Originally posted by MaTTeR
Very cool Vlad. My testing begins in about 9hrs from now:)

BTW- The readme is showing all presets using the same values of- (0, 32, 128, 32, 128, 10, 0).


Do you mean that the presets don't work anymore ?????

Rrrough
8th November 2002, 14:52
@vlad59

thank you very much for your yv12 implementation of convolution3d. will try it asap.

@all

suxen_drol from the xvid-development team developed external colorspace api support, so there is YV12 preview with vdub(mod) and XVID support already committed to CVS. it's supposed to be faster than divx5 too.

cheers

iago
8th November 2002, 15:56
@vlas59

Thanks for convolution3d YV12! Gonna try it asap! ;)

@Marc

Any good news on the mpeg2dec3 beta7 side? ;)

regards,
iago

Marc FD
8th November 2002, 17:10
>Any progress with mpeg2dec3+yv12 choice / beta7?

it's WE, so i'm gonna work on it.
I've a problem. maintain compatibility with avisynth 2.06 will be a source of bugs and would cost me to much time for packaging,ect..

and you all know i prefer the coding part ^^

so i'm gonna make MPEG2Dec3 beta7 compatible ONLY with Avisynth 2.5. It's beta now, and more users would help to improve stability.

It'll ONLY output in YV12, but i'll add the internal YV12->YUY2 convertion (for debugging, and to keep compatibility with MPEG2Dec. MPEG2Dec3 would still be able to give the same results than MPEG2Dec. (maybe not exactly, because of the ssemmx Motion Compentation)

i need to find a _very_ accurate way of detecting combing on MPEG-2 streams. i think i'll add a pratical-check : search for combing on the frames. if auto-combing check detection work, it would output a field based clip.

so i've some ideas for next versions. i'll try to release MPEG2Dec3 beta7, with bugfixes, and minor changes first. new features would wait for beta 8.

@vlad59

cool ! bravo.

trbarry
8th November 2002, 18:31
Marc -

Is source available anywhere for your MPEG2DEC3 YV12?

I guess yours does not handle HDTV streams so I'm going to have to do MPEG2DEC2, but I'm lazy. ;)

- Tom

Marc FD
8th November 2002, 18:50
>I guess yours does not handle HDTV streams so I'm going to have to do MPEG2DEC2, but I'm lazy.

it's based on save-oe (MPEG2Dec2) and there's pid stuff in it. i guess it should be able to handle HDTV streams. if not, just say what you need, i'll add it ^_^

MaTTeR
8th November 2002, 19:35
Originally posted by vlad59
Do you mean that the presets don't work anymore ?????

No, sorry that's not what I meant. Presets appear to work fine for me so far. In your readme(documentation) file it shows that all presets use the same parameters;) Copied and pasted here- 2 - Parameters sample

I build the following presets to make things easier :
Convolution3d (preset="movieHQ") // Movie Hi Quality (good DVD source)
is an alias for Convolution3D (0, 32, 128, 32, 128, 10, 0)
Convolution3d (preset="movieLQ") // Movie Low Quality (noisy DVD source)
is an alias for Convolution3D (0, 32, 128, 32, 128, 10, 0)
Convolution3d (preset="animeHQ") // Anime Hi Quality (good DVD source)
is an alias for Convolution3D (0, 32, 128, 32, 128, 10, 0)
Convolution3d (preset="animeLQ") // Anime Low Quality (noisy DVD source)
is an alias for Convolution3D (0, 32, 128, 32, 128, 10, 0)
Convolution3d (preset="animeBQ") // Anime Bad Quality (???)
is an alias for Convolution3D (0, 32, 128, 32, 128, 10, 0)

trbarry
8th November 2002, 19:47
>"I guess yours does not handle HDTV streams so I'm going to have to do MPEG2DEC2, but I'm lazy."

it's based on save-oe (MPEG2Dec2) and there's pid stuff in it. i guess it should be able to handle HDTV streams. if not, just say what you need, i'll add it ^_^

Marc -

Okay, I guess that means the source isn't available. I really hate to lose my SSE2 speed advantage. :(

But I only tried it a couple times with ATSC streams but got an error on both files so I switched my YV12 testing to DVD material. Since I didn't have source I didn't try to debug it much. I'll go test some more and check and see if it is just something simple in the d2v file and let you know.

Does your code read the PID numbers in the d2v file? Or is that part of the code the same also? In doubt, my version source is still at:

www.trbarry.com/MPEG2DEC2.zip

- Tom

Marc FD
8th November 2002, 20:09
>Okay, I guess that means the source isn't available. I really hate to
>lose my SSE2 speed advantage.

i removed the sse2 stuff, because it crashed for P4 owners. i'm not sure your sse2 MC is working. BTW, sse2 iDCT works, and it's more important than MC (speed-wise)

>But I only tried it a couple times with ATSC streams but got an error on
>both files so I switched my YV12 testing to DVD material. Since I
>didn't have source I didn't try to debug it much.

It's transport packet stream compatible.

>I'll go test some more
>and check and see if it is just something simple in the d2v file and
>let you know.

>Does your code read the PID numbers in the d2v file?

yes, with Stream_Type=2,[..],[..] and MPEG2_Transport_PID=VideoPID,[..] is recognised. i think it should work. i hope i didn't broke something.

int 21h
8th November 2002, 21:18
Why isn't the source to mpeg2dec3 available?

vlad59
8th November 2002, 21:35
Originally posted by Marc FD
It'll ONLY output in YV12, but i'll add the internal YV12->YUY2 convertion (for debugging, and to keep compatibility with MPEG2Dec. MPEG2Dec3 would still be able to give the same results than MPEG2Dec. (maybe not exactly, because of the ssemmx Motion Compentation)


If I remember well (it's been a long time) the ssemmx MC code I send to you has the same accuracy as the original MMX code. I had also written some Fast&dirty one (a little faster less than 1% but not accurate at all). So If you kept my code there shouldn't be not problem.


@MaTTer

That's the problem when you make the tests on the laptop and make the release on the _normal_ computer -> some copy/paste are not automatical ;) ;) ;)
I'll fix that soon.

Marc FD
8th November 2002, 22:46
>If I remember well (it's been a long time) the ssemmx MC code I send to
>you has the same accuracy as the original MMX code. I had also written
>some Fast&dirty one (a little faster less than 1% but not accurate at
>all). So If you kept my code there shouldn't be not problem.

yes you're right. i've even made tests between MPEG2Dec and MPEG2Dec3 and the results were 100% the same (and the speed almost the same too, maybe about 5-10% speedup ^^)

>Why isn't the source to mpeg2dec3 available?

no fear. i know it's GPL code, if you WANT it, you'll get it. but if i don't give it, it's because i'll need a _lot_ of time to clean what i've done and i think it's a waste of time. i prefer concentrate on usefull coding. if someone complain, no problem, i would stop to release it ^_^.

BTW, i've finished Focus2 - YV12. i'm gonna release it soon.

int 21h
8th November 2002, 22:58
Originally posted by Marc FD
no fear. i know it's GPL code, if you WANT it, you'll get it. but if i don't give it, it's because i'll need a _lot_ of time to clean what i've done and i think it's a waste of time. i prefer concentrate on usefull coding. if someone complain, no problem, i would stop to release it ^_^.


I'd prefer you just obey the GPL like everyone else does (trbarry, neuron2, sh0dan, etc.) No one around here cares how messy your code is, and in fact, some might even help you clean it up a bit.

Not like I'm asking for an entirely documented project, pseudo-code, algorithms, and incode comments, just that you obey the original intent of the code (So that if Tom indeed wanted to investigate the issues with transport streams in the code, he could).

trbarry
9th November 2002, 00:26
Marc -

I don't mean to be pushy but probably the only reason there IS an MPEG2DEC3 with all these nifty features is because there was open source to MPEG2DEC2, which wasn't cleaned up either.

And the ony reason there was an MPEG2DEC2 was because there was available source to DVD2AVI and MPEG2DEC that a whole bunch of people contributed to, making this sort of thing possible.

I'm not the original author of either of them but I'd like to see them continue to evolve. You are doing a quite admirable job in this area, but there is still only one of you. If you made it available then, like me, you would probably find that open source is a bit like karma ... what goes around, comes around. You'll find that other people add useful functions to it also.

And I don't think you are in a position to easily test and debug either ATSC/HDTV or SSE2 support but it would still be a shame if this caused those functions to disappear.

And frankly, I'm still too lazy to go code YV12 MPEG2DEC2 output routines if I know there are already functional ones based upon that code. ;)

How about if you post those output source functions and leave the rest 'til it's cleaned up and convenient? Possible? No demands, just a suggestion.

- Tom

Marc FD
9th November 2002, 11:28
>I don't mean to be pushy but probably the only reason there IS an
[...]
>And I don't think you are in a position to easily test and debug
>either ATSC/HDTV or SSE2 support but it would still be a shame if this
>caused those functions to disappear.

i think i wasn't clear. i'm addicted to opensource devellopement. no problem with that. if you want the source, just email me, i'll give it to you ASAP. my problem is packaging.

>And frankly, I'm still too lazy to go code YV12 MPEG2DEC2 output
>routines if I know there are already functional ones based upon that code.

you're are overestimating me. YV12 support is a 10 min hack.

>How about if you post those output source functions and leave the rest
>'til it's cleaned up and convenient? Possible? No demands, just a
>suggestion.

i think the best way is :
you email me, i send you the code, you test all sse2 parts of the code, make a sse2 version of the new MC, HDTV support, ect...
and you (please ^^) say me what's changed, so i can update it, and every user could benefit from it.

my only fear is to have 2 differents versions.
but i think opensource devellopement can be very productive.
i know well MPEG2Dec's code, you too, i think we can easily work together on the same project.

Regards,
MarcFD

PS : if someone want the code, just e-mail me. i don't think it's really interessing. BTW, when it would be stable, i'ld clean the code and package the source code. i just don't like too lose 50% of my time in code packaging of beta versions.

wanton
9th November 2002, 12:35
I just want to end this stupid YV12 mpeg2dec.dll thing because it's not possible to do. Only format that would work would be frame encoded mpeg2 file like svcds if you use force film option. Because most atleast anime dvd's have field/frame encoded frames meaning chroma is halved in field and frame mode diffrently in field mode it's halved field based and in frame frame based. and YV12 in avisynth is frame based. Then another problem is pulldown if you do normal output from mpeg2dec from material with pulldown added with flags mpeg2dec makes virtual frames using flags so if you do it in YV12 you would get quality loss because you would have to blend chroma and it would look shitty. Same thing with IVTC when you combine frame by field basis YV12 is shitty format. So only format YV12 would be any good for would be progressive frame based encodes without pulldown. Even progressive looking material could have been encoded in field format Looks progressive but have been encoded with field based.

Koepi
9th November 2002, 14:40
wanton:

you might want to do some background checks before posting such an misleading, wrong crap. Sorry pal, but the info you're "relying" on is wrong.

If your assumptions were right then mpeg2 couldn't be YV12 colour space internally - but it is.

Now please do some research, let us non-anime encoders our progressive YV12 fun and stop rumbling around. Read the forum rules, you sure broke no. 4.

*scratching head*

Koepi

trbarry
9th November 2002, 19:29
wanton -

Be aware that Avisynth already maintains flags for each clip saying whether it is frame-based or field based. And it is mostly only the deinterlace, IVTC, and conversion functions that will care.

It is true that Avisynth considers the entire clip to be either one or the other but if that becomes a problem for mixed clips we can pass along additional flags from any YV12 supporting versions of MPEG2DECx. Frankly I would like to have them anyway because of the guidance they could provide to IVTC type functions.

You might also consider that it is the job of a deinterlace or IVTC function to convert a clip to all progressive frames. Since these functions should invariably be run first before other filters you can figure that most Avisynth functions can then be operating on frame based material. And as I mentioned above (I think this thread) those IVTC/deinterlaced functions should be sure to always set the AssumeFrameBased flag for clips they process.

We've probably glossed over other details also but nothing that I do not believe is solvable. And I still believe that handling things in their native YV12 format will give both faster and more precise results. For instance I think there can be much greater chroma precision if deinterlace/IVTC is done before any YUY2 color conversion since frame based clips can be created. And we've already seen that many operations may be written to be faster.

So sure there are issues to be dealt with but with much of our input material now coming from MPEG2/YV12 in the form of DVD's, Tivo's, and (increasingly) HDTV it would be silly not to explore this.

I think at worst it will turn out that some clips can not be processed optimally using both YV12 and DirectShowSource, but I don't consider DirectShowSource all that reliable anyway. But I'm pretty confident that at least the DVD2AVIx/MPEG2DECx YV12 path can be made quite functional and eventually better for many purposes than either YUY2 or RGB.

- Tom

scmccarthy
9th November 2002, 20:38
WOW Tom, that makes a lot of sense.

I think it is intuitively obvious that if we want to reencode mpeg-2 into mpeg-4, becuase it compresses better, since they both use the same color space it is better to stay in that color space because color space conversions are lossy. You also point out that some filters are actually easier to write in YV12 than YUY2. And I think that filter writers who have already made the transition from RGB to YUY2 will have no problem learning YV12 provided the benefits are worth it and they are. Meanwhile it is important to have the best conversion filters possible so filter writers can write in the color space of their choice with minimal impact on quality.

I am trying to write a filter in c++ using just cl.exe and link.exe that converts from YV12 to YUY2 by resizing the luma rather than interpolating the chroma. I'll post the code in a new thread later, but meanwhile, since you mentioned flags, I wonder if you know whether Avisynth 2.5 has some flag or structure member that needs to be set saying color space is now YUY2 instead of YV12? Or to change the size, since the vertical resolution gets reduced by a factor of 2?

The new YV12 Invert and my code compiled properly, so my primative development environment does work. Don't accuse me of going off topic, this question is about Avisynth 2.5 flags and structures as it relates to YV12. I'll ask about my code in a new thread.

Marc FD
9th November 2002, 23:04
Hi ^^

i'm dead. i've coded 5 hours to get MPEG2Dec3 v0.9 ready (but not clean enough code-wise :( )
and i've spend 2 hours on the documentation, because my filter always lack of it, and i hope my efforts would be appreciated.

i'm gonna open a new thread for MPEG2Dec3 v0.9 it's avisynth 2.5 ONLY compatible, able ouput native YV12, and to convert to YUY2/RGB24 (interlaced or progressive) , to Separate YV12 Fields (only topfirst yet), and some other stuff.

@tom

i'll give you the code ASAP. but i think it couldn't today : i really need to sleep ^^.

Wilbert
11th November 2002, 10:17
@tbarry,

If you are going to modify mpeg2dec3 you modify it (and dvd2avi) such that the AC3 stream is passed through (if it is present of course, since there's no mp2 support yet).

int 21h
11th November 2002, 13:53
Originally posted by Wilbert
@tbarry,

If you are going to modify mpeg2dec3 you modify it (and dvd2avi) such that the AC3 stream is passed through (if it is present of course, since there's no mp2 support yet).

I thought AVISynth had no compressed audio support yet anyways?

hakko504
11th November 2002, 13:55
Compressed audio support was introduced in v2.04. List of changes and latest CVS release
is here (http://cultact-server.novi.dk/kpo/avisynth/avs_cvs.html)

Wilbert
11th November 2002, 13:58
I thought AVISynth had no compressed audio support yet anyways?

You need to be more around on this forum! Since v2.04 there is compressed audio support (DivX/Xvid with mp3 audio VBR/CBR).

In v2.5 there is multichannel support (DivX/Xvid with AC3 audio VBR/CBR).

and there are more plans ...

sh0dan
11th November 2002, 14:11
AviSynth doesn't have INTERNAL compressed sound, and probably will never have - I think this is what int 21h is talking about.

All audio still needs to be decompressed, just as images have to.

int 21h
11th November 2002, 15:17
Originally posted by Wilbert
You need to be more around on this forum! Since v2.04 there is compressed audio support (DivX/Xvid with mp3 audio VBR/CBR).

In v2.5 there is multichannel support (DivX/Xvid with AC3 audio VBR/CBR).

and there are more plans ...

I get around quite enough thank you.

And as sh0dan confirms, I meant passing through audio similar to WavSource() functionality. Instead of crutching mpeg2dec to pass AC3, work should be done on an AC3Source() filter, or maybe a general AudioSource() filter.

sh0dan
11th November 2002, 15:56
Originally posted by int 21h
Instead of crutching mpeg2dec to pass AC3, work should be done on an AC3Source() filter, or maybe a general AudioSource() filter.

The most obvious way (IMO) would be for someone to create a link to besweet.dll. It offers decoding of all important standards.
A besweet input/output plugin would be VERY helpful for all cases, and should be much easier with the 2.5 API.
I would love to help anyone up to the task, if they get problems with the AviSynth part.

int 21h
11th November 2002, 16:40
a BeSweet I/O plugin would more or less be something like..

BeSweet("audiosource.wav/ac3/etc",500 parameters here)

or are you talking about trying to encode the stream of an input given, like the soundtrack of an avi file or MPEG file. In its current incarnation, its impossible to use BeSweet.dll as a simple decoding tool because it always outputs its encoded result into a file (so you couldn't just pass a sample of PCM to it and get back a sample of MP3 and pass that through Avisynth to the destination environment)

It seems like it would be so much more useful to have the functionality inside of Avisynth so that you could compress/process outside of Avisynth, and the support of the input of compressed audio but lack of support for the output of compressed audio seems .. :confused:

sh0dan
11th November 2002, 17:18
OK, let's just start all over then - this is why I would like something like besweet:

I would very much like for people to be able to do advanced editing, even if their source is from a DVD. That also means that audio has to be put alongside video. For example:

Mpeg2dec2("poelle.d2v")
audiodub(AudioSource("poelle.ac3"))
trim(505,-10000)
l_ch = getchannel(1)
r_ch = getchannel(2)
mergechannels(l_ch,r_ch).normalize().ssrc(rate=44100)


So the user gets out two-channel, completely in-sync audio. As MP3 or just WAV for starters.

What would be the best solution in your opinion?

I'd really wish I has the time to get in some great audio functionality, like ssrc, SuperEQ, Boost (sound compression). But I cannot do the code for it until 2.5 is out.

Nic
11th November 2002, 17:37
I started it & then got completely sidetracked. At present, as far as I know, besweet.dll doesn't let you have access to the output frames (i.e. it gets you to specify an output file then you use *_Burst to send the input packets).

That would need to be changed before a besweet plugin can be made....

-Nic

int 21h
11th November 2002, 17:41
Originally posted by sh0dan
OK, let's just start all over then - this is why I would like something like besweet:

I would very much like for people to be able to do advanced editing, even if their source is from a DVD. That also means that audio has to be put alongside video. For example:

Mpeg2dec2("poelle.d2v")
audiodub(AudioSource("poelle.ac3"))
trim(505,-10000)
l_ch = getchannel(1)
r_ch = getchannel(2)
mergechannels(l_ch,r_ch).normalize().ssrc(rate=44100)


So the user gets out two-channel, completely in-sync audio. As MP3 or just WAV for starters.

What would be the best solution in your opinion?

I'd really wish I has the time to get in some great audio functionality, like ssrc, SuperEQ, Boost (sound compression). But I cannot do the code for it until 2.5 is out.

I am of the same general opinion, except I believe the output format and encoding process should be left up to the user. Decoding AC3 to Wav is a good idea, but in my mind encoding to mp3 just seems like a bad idea, also offering the pass through of AC3 would be convenient.

In my mind, Avisynth is an editing framework, and as such it should not be reliant on any specific encoding technologies because of the pace at which those technlogies evolve. (Consider 2 years ago what we encoded MP3s with)

All of this really became relevant to me when I started helping out with AVS2AVI because only having a WavSource() input filter for audio severely limits any program that relies on the Avisynth interface. In my mind AudioSource would have arguments, allowing you turn decoding on/off, and AudioSource ideally would not be reliant on third-party .dlls (using internal decoding like AC3Dec, which could probably use some work), however, you could use the straight azid.dll because its calls work as follows:

//
// Decode one frame of ac3
//
// Decode the ac3-frame in 'ac3data' into pcm samples in 'pcm'. The output
// samples are interleaved according to the setting 'speaker_sequence'.
// E.g for stereo the first sample (pcm[0]) is left channel, sample 0, and
// the second (pcm[1]) is sample 0, right channel, etc. The float value
// range of the pcm samples are -1.0 to 1.0.
//
// Returns: The result of the operation. Use the following macroes to check
// if the operation is successful or not:
// AC3_OK() The operation was successful
// AC3_FAILED() Some serious error has occurred and the
// decoder program should quit.
// AC3_PRODUCEDOUTPUT() The decoder has produced data, i.e. the
// data in 'pcm' is updated and contains
// valid data.
//
int ac3_decode(u32 *ac3data,f32 *pcm);


and you could still deliver a single sample of pcm for the final encoding application.

sh0dan
11th November 2002, 18:04
IMO all import/export of compressed audio formats should never be an internal AviSynth functionality - just as MPEG2 decoding also shouldn't be.

All of my suggestions were for plugins. I don't think any of these belong inside AviSynth, but they should be separate plugins. Therefore depending on external dll's is not that big a problem, IMO.

int 21h
11th November 2002, 18:13
I admit that makes more sense, I'm not familiar enough with Avisynth framework to know how to make a plugin like AC3Source(), but maybe if I get some time I'll look... it can't be all that different from the principles in Mpeg2dec except that you're working with audio.

sh0dan
11th November 2002, 18:42
Basicly, the only difference is that you extend GetAudio instead of GetFrame.

You can see how to handle audio in audio.cpp/audio.h in the AviSynth sources - it's really easy, if you have worked with samples before.

int 21h
11th November 2002, 20:55
I'm somewhat confused on how you need to offer seeking capabilities. I'm expected to provide a GetAudio(void* buf, __int64 start, __int64 count, IScriptEnvironment* env), Azid only provides a function to read 1 frame into memory, and it appears to be sequential access only (i.e. I can't specify what frame or sample I'd like to retrieve, but if I built my own reading function I suppose I could supply it the frame to decode via the Decoding function), even if I do supply my own reading function, there will still be times that you have to loop forward to seek in the file right?

sh0dan
11th November 2002, 22:16
Yes, assuming that you get sequencial reads isn't very safe.
You will probably have to include your own buffering, so that it can handle requests that split an AC3 frame (which is very likely).
So you have to buffer the remaining samples, until the next read request, where they are needed.
Another way would of course be to decode the same frame again - probably easier, since it is the typical case, and probably nothing worth noticing performancewise.

As a side note, EnsureVBRMp3Sync() gives the preceding filter 100% assurance that it is read sequencially. If the user rewinds, ALL audio is decoded from frame 0 = very slow.

DSPguru
11th November 2002, 22:49
Originally posted by Nic
I started it & then got completely sidetracked. At present, as far as I know, besweet.dll doesn't let you have access to the output frames (i.e. it gets you to specify an output file then you use *_Burst to send the input packets).

That would need to be changed before a besweet plugin can be made....

-Nic i might find the time on weekend to supply this.

Nic
11th November 2002, 23:54
No rush Dg, im far too busy, ill and very irritable :)

@int21:
When I started writing to think about writing the BeSweet audio plugin
(which I think I aptly called BeSynth in the VC6 workspace ;) ) I wrote a little skeletal plugin that does the same as WavSource (but reads the data in raw from the Wav file, rather than use the AVI API).
Might be a starting point if your short on time, if you want?

-Nic

int 21h
12th November 2002, 00:29
Sure, PM me the details :D

wanton
12th November 2002, 10:11
koepi - Sorry that calling mpeg2dec yv12 conversation stupid got on yer nerves but it wasn't offending anyone except it seems probably you. I didn't mean to do that. mpeg2 is yv12 but every frame can be in diffrent format meaning way chroma is handled like i said. Reason example why DVD2AVI author did DVD2AVI was because flaskmpeg decoded interlaced frames wrong http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/interlace/
Here in that page you probably better explanation about what i mean.

But because avisynth only has interlace flag per clip not frame and i'm not even sure avisynth supports interlaced YV12 currently. Interlaced chroma would mean first line in chroma would have chroma for line 0 and line 2 if it is progressive it's for line 0 and line 1 and so on. trbarry was right about tivo stuff because it doesn't have pulldown flags so it doesn't have to comb frames so it should work and ivtc it would work because it's probably field encoded but there are adaptive frame/field encoders (field for high motion and frame for low motion scenes) so it could mean for some frames you would still have to blend chroma. It's just that doing all this doesn't speedup so much and causes probably lot of problems because you would have to know what you can or can't decode properly with mpeg2dec to yv12 and ivtc would only work without quality loss in chroma for field encoded frames since chroma is divided per field. So doing YUY2 to YV12 after ivtc + deinterlace then running filters in YV12 should be good since final encode is gonna be encoded progressive mpeg2/4 anyway so there should be any quality loss doing this.

int 21h
12th November 2002, 14:16
Again you're not researching anything before talking your talk. From the Avisynth 2.5 alpha page (developer's notes)
From http://cultact-server.novi.dk/kpo/avisynth/avisynth_alpha.html
YV12 interlaced chroma
YV12 handles interlaced chroma differently than compared to YUY2, since YV12 only contains chroma information for every second line. To enable interlacing, chroma is stretched across two luma lines in the same field! That means that luma and chroma isn't directly mappable to lumaline/2 and lumaline/2+1 as framebased images.


line 0: Chroma for interlaced luma lines 0+2 line 1: Chroma for interlaced luma lines 1+3 line 2: Chroma for interlaced luma lines 4+6 line 3: Chroma for interlaced luma lines 5+7...etc!

This is something that deinterlacers and similar programs need to take into consideration.Other filters might rely on the use of Separatefields() and Weave(), to produce framebased images. You can use the VideoInfo.IsFieldBased() to check your source, and maybe decide to throw an error, or shift to another processing mode.

If your video is fieldbased your vertical resolution (height) must be divideable with 4, otherwise AviSynth will not create a new VideoFrame, but will throw an error.

Marc FD
12th November 2002, 17:19
you should take a look at MPEG2Dec3. it's outputting YV12.
try SeparateFieldsYV12 or YV12toYUY2(interlaced=true) on interlaced MPEG2 sources.

Avisynth is the more powerfull existing video framework. don't compare it to FlaskMPEG please.

Thx.

scmccarthy
12th November 2002, 18:11
If the YV12 to YUY2 conversion only works for frame based clips, then SeparateFields of SelectEven/Odd then stacking them, doing the conversion, then Weaving, would allow you to use the frame based version of the conversion. Soon, if not already, it will work for fields. Maybe this is already clear to everybody; but I like to state the obvious once.

trbarry
12th November 2002, 19:47
Wanton -

Maybe there is some confusion here about how YV12 works in MPEG2. Possibly that confusion is mine, but if so then if I write it down here someone else can point it out.

Please pardon my oversimplifying here. I'm thinking out loud.

I'm using the "Video Demystified" descriptions here. In my pictures I'll call the top line line 1. Be aware that many/most video folks tend to number them from one, except in maybe in DScaler where we've usually called it 0.

In MPEG2 4:2:0 there are values representing Y, U, and V, where Y is the luma (brightness) and U,V represent chroma (color) values. I'll just call the U and V components C for chroma, since in MPEG2 they will represent 2 different values at exactly the same sample points on a screen.

But there are 4 times as many Y components as C components, twice as many in both the horizontal and vertical directions. Each Y component represents the Luma value at some sample point on the screen. And each C component represents chroma value at some point on the screen. Much of the confusion in MPEG2 4:2:0 color space results from the fact that the Y and C components result from values (originally measurements) at different points on that screen, no 2 at the same point.

If the luma represents sample points on screen lines 1,2,3, ... then the MPEG2 chroma will represent sample points on lines 1.5, 3.5, 5.5, etc. None of these are real screen raster lines. The sample points occur between the real screen lines and when displaying things you eventually have to interpolate to get the correct values. And only half of those possible half-lines are actually represented with chroma values.

For instance, ignore how YV12 is stored in planes and let's just think about which points on the screen are represented by the data. For a progressive frame the following sample points might be represented:


Line 1 : YYYYYYYY ...
Line 1.5: C C C C ...
Line 2 : YYYYYYYY ...
Line 2.5: <- not present
Line 3 : YYYYYYYY ...
Line 3.5: C C C C ...
Line 4 : YYYYYYYY ...
Line 4.5: <- not present
Line 5: : YYYYYYYY ...
Line 5.5: C C C C ...
Line 6: : YYYYYYYY ...
...


So even in progressive, if you want to find all values of chroma for all the pixels you want to display you have to interpolate between the various chroma sampling points you have been given. For instance to calculate the croma values for line 4 you will need to use ratios of chroma values from (at least) lines 3.5 and line 5.5.

Okay, cool, we have code to do this. Now what happens if we have an interlaced clip? Then even though we are given a single frame it may contain data from two fields which represent 2 different points in time. So if we were to combine chroma data from lines 1.5 and lines 3.5 we would be blending chroma from 2 fields. And we know this is a bad thing, possibly causing artifacts since those fields change over time.

So it looks like MPEG2 4:2:0 for interlaced frames ("Field Based") is stored like the following (assumes top field first):


First Field Second Field
Line 1 : YYYYYYYY ...
Line 1.5: C C C C ...
Line 2 : YYYYYYYY ...
Line 2.5: <- not present
Line 3 : YYYYYYYY ...
Line 3.5: C C C C ...
Line 4 : YYYYYYY ...
Line 4.5: <- not present
Line 5: : YYYYYYYY ...
Line 5.5: C C C C ...
Line 6: : YYYYYYY ...
Line 6.5: <- not present
Line 7 : YYYYYYYY ...
Line 7.5: C C C C ...
...


So now look what happens. If we need to calculate the chroma value for pixels on line 4 we can no longer use the values from line 5.5 because they come from the wrong field and possibly represent the wrong point in time. So we would have to use a ratio of chroma values from line 3.5 and line 7.5. This keeps us using only the correct field but now we are vertically much further apart and the calculation will be much less accurate, losing color detail. However that is the way it is currently done as long as MPEG2DEC2 just returns YUY2 data for field based frames.

But here is the point where I may be wrong and someone can jump on me for it.

I believe that for both the progressive and interlaced cases above the croma sample point values represent EXACTLY THE SAME points in space, just not necessarily from the correct fields, or points in time. But if this is true then, to the extent we can IVTC or deinterlace the frames first, we can then do the more precise color conversion that can be used with progressive frames.

Now it remains to be seen in real life whether we can do this, and for which real life clips we will need the MPEG2 flag data from MPEG2DECx.dll in order to do it. But, again, I'll wager that it is doable and that we will see an advantage from it.

So, what did I overlook? ;)

- Tom

vispgraedde
12th November 2002, 19:56
Originally posted by int 21h
Again you're not researching anything before talking your talk. From the Avisynth 2.5 alpha page (developer's notes)

Hmm... Your own quoted post would be more interesting if you could relate the information you posted to the information in the link that Wanton posted.
If the information can be shown to be equal, then all is good.
But if not, I'd personally trust what the dvd2avi author says more than what the avisynth developer says.

scmccarthy
12th November 2002, 20:07
@trbarry

Please check out my one and only filter ConvertYV12ToYUY2VerticalRecuceBy2() for Avisynth 2.5 alpha. It is great as an example code that demonstrates the inner workings of YV12 that you are talking about. I do remember a while back you asked for a a YV12 version of Invert. This is like that execept in uses a little more of the new YV12 functionality.

Try it and I think you will be satisfied that it demonstrates the difference between YUY2 and YV12. The output certainly looks right.

It is not meant to work with interlaced material. I have not even tried it with interlaced material yet.

trbarry
12th November 2002, 21:29
But if not, I'd personally trust what the dvd2avi author says more than what the avisynth developer says.

I guess that depends upon which application you are talking about.

But it may not matter how you prefer to convert YV12 if you can avoid doing so. And to the extent we can pass only progressive (or all field based) YV12 frames to Xvid we can do just that.

- Tom

vispgraedde
13th November 2002, 00:48
For clean progressive stuff, it should mean a speedup if you can use only YV12 throughout the whole process, but since almost no dvd I have is progressive, it's more important to me to have something that is garanteed to work than something that might work (if it works out in the end, all is good, but until then...)

trbarry
13th November 2002, 06:13
Well, it seems it should work whenever you have progressive material.

And it seems it should work whenever you can use DVD2AVI/MPEG2DECx force film.

And it seems it should work with all interlaced video when you intend to keep it that way.

And it seems it should work whenever you are going to deinterlace video source with TomsMoComp, even if there are some progressive frames in it.

And offhand I think we can probably make it work with things like DeComb and GreedyHMA for most material but there are still some issues I haven't tried to work out yet.

And we can already predict that at least some Japenese anime will find a way to break it somehow. ;)

But it looks like it should work at least some of the time. :)

- Tom

Marc FD
13th November 2002, 14:35
(for all the suspicious guys about YV12 and interlacing)

> And we can already predict that at least some Japenese anime will find a
> way to break it somehow.

guess what : i encode ONLY japanese anime.
and better : often after NTSC->PAL convertion.
a real nightmare. (a sort of worst-case encoding ^^)

i don't see what is the problem with YV12 ?
i've programmed a bob filter in YV12, and it works very well.

you can trust a guy who worked a lot on MPEG2Dec and who's encoding only interlaced streams, when he says that YV12 is a pleasure to code, and has only advantages.

BTW, YUY2 is not forbidden in Avisynth 2.5 ^__^

SansGrip
13th November 2002, 15:15
you can trust a guy who worked a lot on MPEG2Dec and who's encoding only interlaced streams, when he says that YV12 is a pleasure to code, and has only advantages.

I disagree. This may be true if all you need to do is iterate over each component individually while applying some processing to them. But as soon as you get interdependence between the components I find a packed format much nicer.

It's a question of speed of execution/speed of development. YV12 is undeniably faster at runtime, but I find it to be at least twice as much typing, which means twice as many typo bugs. It also means three times the pointers and at least two times the constants, three times the "helper variables" to hold results of calculations etc..

And since most filter writers are now going to feel compelled to produce both YV12 and YUY2 versions for speed reasons, that means two algorithms to maintain and bugfix.

Apart from that I love it, and can see no reason whatsoever to move to an internal 4:4:4 format :p :D.

Marc FD
13th November 2002, 15:41
> I disagree. This may be true if all you need to do is iterate over each
> component individually while applying some processing to them. But as
> soon as you get interdependence between the components I find a packed
> format much nicer.

no. as soon as you use complex algorithms, even with interdependance, the packing is an overhead. you need to deinterleave it.

in fact, using pseudo planar YUY2 can be faster and easier to code when you MMX optimise something more complex than cnr2 for exemple.

> It's a question of speed of execution/speed of development. YV12 is
> undeniably faster at runtime, but I find it to be at least twice as
> much typing, which means twice as many typo bugs. It also means three
> times the pointers and at least two times the constants, three times
> the "helper variables" to hold results of calculations etc..

for me, YV12 is much easier to code, and MMX optimisations are a real pleasure.
i'll port Cnr2 to YV12 today, there's interdependency in it, i'll report if it's really that hard ^^

> And since most filter writers are now going to feel compelled to
> produce both YV12 and YUY2 versions for speed reasons, that means two
> algorithms to maintain and bugfix.

YUY2->YV12 / YV12 filter / YV12->YUY2 is a very little overhead, if users don't have no YV12 input nor YV12 output.

SansGrip
13th November 2002, 16:48
in fact, using pseudo planar YUY2 can be faster and easier to code when you MMX optimise something more complex than cnr2 for exemple.

I have no idea which is preferable for MMX, since it's been about 10 years since I last looked at assembler ;), but my gut tells me that planar would be a lot more efficient.

for me, YV12 is much easier to code

Hmmm. Since you've written more YV12 code than me I'll take your word for it. Perhaps when I'm more au fait with planar I'll agree with you ;).

YUY2->YV12 / YV12 filter / YV12->YUY2 is a very little overhead, if users don't have no YV12 input nor YV12 output.

I suppose, though I still think there should be One True Way (i.e. a canonical internal format, probably planar 4:4:4, either 8- or 16-bit).

trbarry
13th November 2002, 18:00
In much of the computer industry the cost of development and especially maintenance dominates. But there are some things that are CPU intensive enough that they are worth writing in assembler or doing other things that gain performance at the expense of complication.

I think video is still like that. This is actually is some of what attracted me to writing video programs in the first place. I'm mostly an assembler programmer and video make me feel more valuable.

Anyone can attempt to write video filters in any easier high level language with data structures optimized for human critters to understand.

But you only have to run it a couple times and you may be thinking about ordering an assembler manual and doing some strange optimizations.

I like it this way. ;)

- Tom

SansGrip
13th November 2002, 19:14
@Tom

At the risk of straying inexcusably far from the topic:

I'm mostly an assembler programmer and video make me feel more valuable.

Well given the popularity and utility of your various filters I'd say you're definitely valuable :).

Anyone can attempt to write video filters in any easier high level language with data structures optimized for human critters to understand.

And this is how I like to write them -- the first iteration, anyway. I like to code it out fast, testing each step until it works, then go back and tweak. I find by writing the algorithm out the first way that pops into my head, I often discover a better way of doing it afterwards. I favour "extreme programming" over "big plan up front".

I also like to use a lot of asserts etc., which really slow it down. So for me performance while debugging/pre-beta is secondary to maintainable, comprehensible code. Planar YUV (at least the "standard" multi-pointer implementation of it, as opposed to some kind of efficient class library such as I'm pondering now, any help appreciated :D) and multiple colourspace support are the antithesis of these two goals ;).

Edit: As you are doubtless aware, "comprehensible" and "fast" versions are often maintained side-by-side in critical areas of commercial products, such as a spreadsheet's calculation engine. In debug builds both are run on the same data and the output compared, which is an extremely effective way of tracking down bugs in the "fast" version. This is roughly what I hope to implement into my filters when I work out a way to do it with as few keystrokes as possible ;).

But you only have to run it a couple times and you may be thinking about ordering an assembler manual and doing some strange optimizations.

I'm already thinking that :). I've been meaning to learn i386 asm (I knew 680x0 way back when) for a very long time, and this gives me a good incentive.

I like it this way. ;)

I wouldn't still be here if I didn't ;). Anyway, back to mpeg2dec...

DSPguru
15th November 2002, 06:29
Originally posted by Nic
I started it & then got completely sidetracked. At present, as far as I know, besweet.dll doesn't let you have access to the output frames (i.e. it gets you to specify an output file then you use *_Burst to send the input packets).

That would need to be changed before a besweet plugin can be made....

-Nic latest beta dll has a new function "SetWriteRoutine", that gets a pointer for the callback function. callback function prototype :
int (*WriteRoutine) (const void*,size_t)

int 21h
15th November 2002, 17:15
where void* contains the processed data and size_t contains size of it in bytes?

DSPguru
15th November 2002, 17:23
Originally posted by int 21h
where void* contains the processed data and size_t contains size of it in bytes? exactly :D

int 21h
15th November 2002, 22:24
What and where do I need to declare to use this new function?

DSPguru
16th November 2002, 06:58
you just need to call this function once, at the very beginning, to set your callback (WriteRoutine).
if you won't do that, BeSweet's defualt WriteRoutine is fwrite ;)

int 21h
16th November 2002, 18:53
and what's the prototype for SetWriteRoutine?

DSPguru
16th November 2002, 20:27
it only gets one parameter. the callback function intself.
Originally posted by DSPguru
latest beta dll has a new function "SetWriteRoutine", that gets a pointer for the callback function. callback function prototype :
int (*WriteRoutine) (const void*,size_t)

int 21h
17th November 2002, 00:52
And no return type right?

DSPguru
17th November 2002, 05:58
right :)

int 21h
17th November 2002, 19:18
I must be dense because I cannot figure out how to get to the SetWriteRoutine function, I tried this:

HINSTANCE hDLL =NULL;
BESWEET BeSweet =NULL;
BURSTS AC3_Bursts =NULL;
BURSTS MPA_Bursts =NULL;
BURSTS PCM16S_Bursts =NULL;
VERSION BS_VERSION =NULL;
LPVOID SetWriteRoutine =NULL;


and later

SetWriteRoutine = (LPVOID) GetProcAddress(hDLL, "SetWriteRoutine");


then setting the routine with SetWriteRoutine(&WriteFunction);

but it won't compile and says:

error: expression must have (pointer-to-) function type
SetWriteRoutine(&WriteAudioData);

Any ideas? Also would it be possible for you to just make a .lib like Azid has? It would make this alot easier because we could just declare prototypes and then make the calls.

[Toff]
17th November 2002, 20:20
First I have not followed all the discussion ;)
Maybe you should define SetWriteRoutine this way :

// ------

int WriteRoutine(const void*,size_t);

// ------

int (__stdcall *SetWriteRoutinePtr)(void);
SetWriteRoutinePtr SetWriteRoutine;

// ------

SetWriteRoutine = (SetWriteRoutinePtr)GetProcAddress(hDLL, "SetWriteRoutine");

SetWriteRoutine(WriteRoutine);

// ------

int WriteRoutine(const void*,size_t)
{
...
}

(humm, aren't we offtopic here ???)

int 21h
17th November 2002, 20:51
Originally posted by [Toff]

(humm, aren't we offtopic here ???)

Yes, we are ;)

This code doesn't work either, I guess I need more guidance from DSPGuru.

DSPguru
18th November 2002, 18:17
here's how i would have write this code (if i only had the time :(!) :
typedef int (*WRITEROUTINE) (const void*,size_t);
typedef (*SETWRITEROUTINE) (WRITEROUTINE*);

SetWriteRoutine = (SETWRITEROUTINE) GetProcAddress(hDLL, "SetWriteRoutine");

SetWriteRoutine(&WriteFunction);


as for .lib -
that's a good idea :)

Wilbert
28th November 2002, 11:05
@int 21h,

Any progress?

@Sh0dan,

I've some questions about the audio in v2.5. Let's look at your script:
Mpeg2dec2("poelle.d2v")
audiodub(AudioSource("poelle.ac3"))
trim(505,-10000)
l_ch = getchannel(1)
r_ch = getchannel(2)
mergechannels(l_ch,r_ch).normalize().ssrc(rate=44100)

1) How are the channels numbered. I.e. is channel 1 the front left channel, channel 2 the front right channel, etc.?

2) If you want to merge all six channels (from different wav files), do you have to apply mergechannels five times? (Ok, problem is that VirtualDub still can't read them ...)

3) In AC3 to MP3 conversions they mix the front, rear, center and LFE channels. Can you do something like that in AviSynth?

4) When do you need the filter "ConvertAudioToFloat", and what is the purpose of this filter?

5) If the audiosamples are not 8,16,24,32 or float are they still converted to 16 bit (like in v2.0x)?

sh0dan
28th November 2002, 13:44
1) How the individual channels are numbered is up to the input source. In stereo, left is channel 0, right is channel 1.

2) For the moment, yes, but it would actually make sense to be able to give any number of clips. I'll put this on the todo-list.

3) Use GetChannel(int channel) and MixAudio(clip1,clip2 [,float clip1_volume, float clip2_volume]) to do this. MixAudio will mix channel 0 of clip 1 with channel 0 of clip two and so forth.

4) & 5) There is now 100% automatic sample conversion between filters. Filters may not support all sample types (typically 16bit and float), and if the sample type isn't this type, it will be converted to the filters prefered format (typically float).
You will never see this conversion, but the filters in general requests the best quality possible. But if the filter supports both 16bit and float input, and the input is 16bit, the samples are not converted to float!
"ConvertAudioToFloat" will forcibly convert to float.
If the sample type is float, when AviSynth has to output the data, it will be converted to 16bit, since float cannot be passed as valid AVI data.

Guest
30th November 2002, 04:27
I've just returned to this thread after long.

I wanted to say thank you to all who expressed sympathies and condolences to me, and to say of course the "call for the mod" was not out of line.

You're a great bunch of people.

Wilbert
4th December 2002, 10:46
1) How the individual channels are numbered is up to the input source. In stereo, left is channel 0, right is channel 1.
... left is channel 1, right is channel 2. But ok.

2) For the moment, yes, but it would actually make sense to be able to give any number of clips. I'll put this on the todo-list.
I saw that you already have done this. Thanks!

If the sample type is float, when AviSynth has to output the data, it will be converted to 16bit, since float cannot be passed as valid AVI data.
What if the output is 24 or 32 bit? (I saw that Virtualdub only can process 8 or 16 bit.)

I've done some tests with this multichannel stuff:

clip = AviSource("F:\test\red_ac3.avi")
# When opening in VdubMod/WMP6.4 it gives:
# ACM failed to suggest a compatible PCM format
# (F:\test\red.avs, line 1)

[The same message is shown if you use getchannel and mergechannels so that the output has only two channels instead of six. So AviSource can't open an avi+ac3 file. Note that VdubMod can open the avi itself.]

# ac3 --> (uncompressed) wav5.1 besweet --> muxed with VdubMod
clip = AviSource("F:\test\red_wav51.avi")
c1 = clip.GetChannel(1)
c2 = clip.GetChannel(2)
MergeChannels(c1, c2)
# When opening in VdubMod/WMP6.4 it gives:
# file info is correct;
# VdubMod just crashed when starting encoding

[So I converted the ac3 to an uncompressed six channel wav in Besweet and muxed it with the avi. Apperently AviSource can open the file since the file info. in Vdubmod is correct. But when you start encoding it just crashes. (I put the audio on encoding to "uncompressed wav" in VdubMod.)]

# ac3 --> (uncompressed) wav5.1 besweet --> muxed with VdubMod
clip = AviSource("F:\test\red_wav51.avi")
clip.GetChannel(1)
# When opening in VdubMod/WMP6.4 it gives:
# file info is correct;
# access violation at 0x065b4f64, attempting to write to 0x063ac000

[So I converted the ac3 to an uncompressed six channel wav in Besweet and muxed it with the avi, and I took the first channel. Apperently AviSource can open the file since the file info. in Vdubmod is correct. But when you start encoding it gives an access violation.]

# xvid+mp3
clip = AviSource("F:\test\test.avi")
clip.GetChannel(1)
# When opening in VdubMod/WMP6.4 it gives:
# file info is correct;
# access violation at 0x065b4f64, attempting to write to 0x0649c000

[Same problem as above.]

# xvid+mp3
clip = AviSource("F:\test\test.avi")
c1 = clip.GetChannel(1)
c2 = clip.GetChannel(2)
MergeChannels(c1, c2)
# When opening in VdubMod/WMP6.4 it gives:
# file info is correct;
# VdubMod just crashed when starting encoding

[Same problem as above.]

conclusions:

1) If the audio in uncompressed 6 channel wav, VdubMod will crash.
2) If the audio in 6 channel ac3, AviSource can't open it.
3) If you do something with getchannel/mergechannels (even if the input is a normal avi with mp3 or uncompressed two channel wav) VdubMod will crash.

other bugs:

1) VdubMod/WMP6.4 will crash if the path in AviSource doesn't exist (instead of giving an error message).
2) VdubMod/WMP6.4 will crash using a filter which doesn't exist (instead of given the error message "don't know what xxx means".

Let me know if you want me to do some other tests.

Wilbert
6th December 2002, 11:03
Oops. The arguments of mergechannels/getchannel must be wav files (I guess). Thus

# ac3 --> (uncompressed) wav5.1 besweet --> muxed with VdubMod
video = AviSource("F:\test\red_wav51.avi")
audio = WavSource("F:\test\red_wav51.avi").GetChannel(1,2)
AudioDub(video, audio)

Encoding goes fine in Vdubmod. Except that the sound was crippled, but that could be a problem of the source. The ac3 file plays fine but I can't play the 6 channel wav. Anyone know how to play them?