New experimental Lossless codec -- needs your help

[TheRealMoh]

Newest version is 004, download below

Note to moderators: I'm posting this here because the code is in need of your help. Although the current code works, it's not ready for wide release. If you feel this thread should be moved, please do so.

I've spent a bunch of time writing a new codec. It's based loosely on the LOCO-I algorithm.

Summary:
- Lossless file size if about 70% of Huffyuv
- lossy can decrease file size another 10-20% percent
- about 1/4 the speed of huffyuv :-<
- Stores YV12 natively
- GPL: (C) 2003 Mohammad Rezaei

TODO:
- Performance.
-- calcLoco can be vectorized. Part of comp_one_pel can be vectorized.
-- riceEncode can not be easily vectorized.
-- unlikely to be made more than 50% faster
- YV12:
-- conversion to YUY2 and RGB after decompression
- interlacing
-- is there a flag indicating interlacing in the incoming images? if so, store it.
-- a quick test showed that unless most of the video is highly combed, it does not make sense to compress fields separetely.

Essentially, I've hit a wall with the code as far as performance goes. You guys are the closest thing I can find to video related performance experts. I need your help in tuning this codec so it can be more useful. I'm not sure how much more time I can spend on this, so if someone wants to take this over, that's fine too.

The project was inspired by the YV12 codec thread in this forum. Feel free to test the codec, but please don't store anything important using this codec: the internals may change.

The code is based on huffyuv and is GPL, so please don't release binary only versions.

Your help is much appreciated.

Edit note: removed loco001.zip, added loco002.zip (small bug fix) down below.

[Dali Lama]

Hi Moh,

Edit: I guess you know about Marc FD's VBLE codec. Perhaps you can try to PM him or "-h"?

Take Care,

Dali

[TheRealMoh]

Here is a small bug fix.

[Guest]

Originally posted by TheRealMoh
Here is a small bug fix.

Please describe the bug when posting bug fixes.

[DDogg]

Your readme indicates this is installable without a compile, however you did not include the DLL. Was this your intention?

[TheRealMoh]

@neuron2:
sorry. Changes to 002:
- GUI was not accepting "0" for max loss.
- When in lossless mode, it's slightly faster.

@DDogg:

Here is a binary release of 002.

[sh0dan]

(Copy/Paste from an earlier posts I made regarding ffvfw)

Regarding colorspaces, it would of course be a good idea to support all output formats. Any input format would also be optimal. XviD provides most conversion routines.

YV12 -> YUY2 - use AviSynth routines (if possible). These routines have better chroma upsampling, and optional interlaced handling.
There _must_ be an option to select interlaced conversion. Sort of: Use interlaced upsampling, if more than 'n' lines, would be best.
There would have to be special adaption if width is not mod-16, since AviSynth has larger pitch in these cases. I would be glad to help out here.

YV12 -> RGB - use XviD conversion routines. Unfortunately they are not qualitywise optimal, but they are fast and has support down to mod-8 width.
Interlaced upsampling is also a problem here.
A solution could be to use AviSynth YV12 -> YUY2 and also use AviSynth YUY2 -> RGB. This will be slower, but on the other hand it would be possible to properly support interlacing and have optimal chroma upsampling.

It is also possible to modify the existing AviSynth assembler RGB24->YUY2 to support 24bits.

So to conclude, you can find most conversion routines needed in AviSynth - the only problem is interlaced YV12 -> RGB.

Link to the latest convert_yv12.cpp.
There are MMX and ISSE YUY2 -> YV12 (interlaced and noninterlaced) and YUY2 -> YV12 (interlaced/non-interlaced).


Lastest XviD conversion routines - adapted for MASM, if they are of any help. No interlaced handling, and sub-optimal chroma interpolation.

The best way for lococodec to handle this would probably to be able to pass through material, if possible, or use the simplest possible conversion - this does include much work though - but AviSynth has assembler routines for most of these.

|YUY2 -> RGB32| - |MMX RGB32 -> RGB24| - |MMX YUY2 -> RGB24/34|


IMO any VFW codec should be able to output in (interlaced/progresive) YV12, YUY2 and RGB24/32.

[ominte]

pardon my ignoranance TheRealMoh but i can't view any material encoded with loco002. Any help would be appreciated .

Otherwise nice job on the compression my tests show loco002 lossless reduces file size by 8% when compared to VBLE. Also I am getting encoding speeds of around 20 fps on an AMD +1600, nice.

[terwin]

The same problem here, I can't decode the Loco-movies. But the encoder works fine for me.

cu terwin

[TheRealMoh]

@terwin & ominte

How you view the output depends on the color space (right now). If you compress YUY2 or RGB, you should be able to play it (but you need a very fast computer). Better yet, you should open it in virtualdub.

If you compress YV12, the only way to view the video is to create a small avs script:

video=avisource("C:\temp\yv12test.avi")
video.ConvertToYUY2()

You can then load the avs as normal.

The automatic conversion of YV12 is on the todo list, but I'm concentrating on performance right now.

[terwin]

Ok, thanks for the quick answer. The problem was YV12.

cu terwin

[ominte]

Thanks for your help, everything is working fine now . Any planned support for YV12 in the future?

[sh0dan]

@TheRealMoh: YV12 support is quite important, as all YV12 <-> YUY2 is lossy. Also YV12 should give additional compression, due to the chroma information.

[TheRealMoh]

@omnite

I'll code YV12 -> YUY2 conversion during decoding right after I'm done with performance stuff. I'm leaving on vacation soon for about 10 days, so probably 3 weeks.

@sh0dan

I'm not sure YUY2->YV12 is necessary. This is a lossless codec afterall. It would be nice, but I don't think anyone would use it. The way I see it, a lossless codec has two uses:

1) Capture. This requires real time encoding. That's why I'm concentrating on performance right now. I'm not sure conversion to YV12 would slow things down or speed things up. All captures cards I know are YUY2 natively.
2) Intermediate step where quality is important. In this situation, I doubt people would choose to lose 1/2 of UV planes.

Again, I'm not saying it's a bad idea, just not one high on the priority list.

Maybe you know the answer to this question: is there anything in the avi api's that deals with interlacing? I need to know if the source is interlaced so I can do the YUY2->YV12 conversion correctly.

[ErMaC]

Unfortunately there is nothing in the AVI standard to flag interlaced or non interlaced. The way Huffyuv deals with this is it assumes anything over a certain verical resolution is interlaced (288 vertical resolution by default). Then what it does is splits the frame into the two fields and encodes them separately for supposedly better compression.
Doing this in YV12 colorspace causes a problem because the chroma sampling varies between interlaced and progressive footage. The only way you could properly handle this, in my opinion, is to add a checkbox in your codec's configuration screen for interlaced encoding.

[MrTibs]

Personally, I appreciate the work. I'd like to get an addional 30% compression over Huffy during capture if possible. With the CPU's increasing at present rate, we could even use "slow" codecs for live capture. For now, however, sometimes I run my Huffy captures through Avisysnth with filtering and resizing and save back into huffy. This technique allows me to reduce my Huffy files by 80-90% before I convert to Mpeg1 (KVCD). I do this for three reasons:

1) Lossy (Mpeg] conversion requires much fiddling to get it perfect.
2) Lossy encoding is MUCH faster since Avisynth filters are not invovled.
3) Filtering through Avisynth is much faster then Mpeg conversion so I can make room on my HD for another TV capture very quickly.

[TheRealMoh]

I spent some time optimizing (vectorizing) the code for P4's. This requires a P4, so there are now two binaries P4 and non-P4.

It seems the vector operations on a P4 are not alot faster than the interger ones (probably because of the dual, dual-speed ALUs). The P4 code is about 10% faster now.

I'm going on a vacation for about 10 days, so this the last release for a while. Next on the todo list is the color space conversions.

The attachment has the source plus 2 binaries.

[mf]

Originally posted by TheRealMoh
2) Intermediate step where quality is important. In this situation, I doubt people would choose to lose 1/2 of UV planes.

That intermediate step is most likely to be converted to MPEG1/2/4 or other YV12 codecs. So why not convert to YV12 directly (or, in the case of an MPEG source and AVS 2.5 processing, don't convert it at all) and save the space.

[cweb]

Perhaps updating it to use YV12 would also speed it up.

I experimented with both Marc's new yv12 huffy codec and with yours.
Marc's seems faster and has no frame drops, unlike yours.

I found your codec interesting, I hope you will continue developing it.

[TheRealMoh]

I'm back from vacation and here is a new version:

Changes:

- Lossy compression is improved (compression wise).
- YV12->YUY2->RGB is implemented during decompression.
- replaced the field threshold with a simple check box: check it if the source is interlaced. The setting is only used during compression.

If you have a YV12 interlaced avi that was encoded prior to this release, it won't be properly decoded to YUY2/RGB. You can re-encode the clip with the "source interlaced" checkbox checked.

@cweb & mf
Thanks for the comments. I still haven't decided if/how I'll implement YUY2->YV12 during compression.