Ut Video Codec Suite - a new lossless video codec for Windows!

[the_weirdo]

Please explain to me why MeGUI opens its lossless Huffyuv created by itself with ffms2?

Because it doesn't know if you have Huffyuv VfW decoder installed or not, so it uses FFMS2 which doesn't depend on that factor.

[WorBry]

..... Can't imagine it's a question of speed as the vfw UT-Video decompressor is darn fast (Left prediction especially)

Qualification on that. The UT-Video vfw decompressor is intrinsically very fast; in my tests, UT-Video YV12 (Left Pred) decompresses around 6 x faster than Huffyuv YV12 (vfw FFDShow) in 32-bit mode and faster still (7 x) in 64-bit. But of course, 'in-use', other influential factors (limiting and accelerating) come into play.

Here's a quick comparison of AVS output rates (AVISource vs ffms2) using AVSMeter(v174 AVS2.6_x86)

Test AVISource: Uncompressed YV12 clip (1440 x 1080, 25p, 2000 frames) encoded to UT-Video (v 13.3.1) YUV420 BT.709 with Left Prediction (Frame Divide Count 6). Compression ratio: 2.02

AVS scripts prepared with MeGUI AVS Script Creator; MeGUI v2418, AVISynth 2.6 MT (SEt’s, in non-MT mode...so as not to complicate matters). No other filters in script.

PC: Hex-core CPU (AMD-FX-6300), 8GB RAM, Win7 64-bit

AVSMeter Results:

AVISource.avs :
Average fps: 107.42
Av cpu use: 28%
Threads 7
Physical memory peak: 13MB

ffms2.avs: (FFVideoSource int threads: 1 - as set by AVS Script Creator)
Average fps: 45.32
Av cpu use: 16%
Threads 6
Physical memory peak: 14MB

BUT..........

ffms2.avs: (FFVideoSource int threads: -1 (default) = # logical cores)
Average fps: 208.03
Av cpu use: 89%
Threads 11
Physical memory peak: 35MB

And just for comparison:

Test AVISource: same raw source encoded to Huffyuv (vfw FFDS*) YV12, Left Prediction (Huff tables) *FFDShow Tryouts rev4525
Compression ratio: 2.02 (same as UT-Video)

AVISource.avs: (vfw FFDShow decoder: # decoding threads: 6)
Average fps: 60.70
Av cpu use: 16%
Threads: 2
Phys memory peak: 20MB

ffms2.avs (FFVideoSource int threads: 1 - as set by AVS Script Creator)
Average fps: 50.75
Av cpu use: 16%
Threads: 6
Phys memory peak: 15MB

ffms2.avs (FFVideoSource int threads: -1 (default) = # logical cores)
Average fps: 206.62
Av cpu use: 82%
Threads: 11
Phys memory peak: 42MB

Clearly enabling full (default -1) internal MT support in FFVideoSource makes a huge difference for both UT-Video and Huffyuv. I see there is an option in the MeGUI Settings to set the FFMS thread count, and that it defaults to 1. I wonder why not -1 ? I can only assume that it is to give MT CPU priority to the encoder? Something to be aware of, as I often use the tool just to start an AVS script for purposes other than MeGUI mediated encoding.

[WorBry]

.... I see there is an option in the MeGUI Settings to set the FFMS thread count, and that it defaults to 1. I wonder why not -1 ? I can only assume that it is to give MT CPU priority to the encoder?

Doesn’t appear to affect the x264 encode rate much though:

Input: Same AVS scripts as above for UT-Video YV12 (Left)
x264 encode settings:
program --level 4.1 --preset slow --tune film --crf 18.0 --vbv-bufsize 78125 --vbv-maxrate 62500
--colorprim bt709 --transfer bt709 --colormatrix bt709 --output "output" "input"Output: RAWAVC
‘Normal’ priority

x264 encode rates (fps):
AVISource.avs : 11.25
ffms2.avs (int threads 1) : 11.06
ffms2.avs (int threads -1) : 11.15

Not much difference there, but possibly I/0 read/write rates are limiting anyway; I'm running with a single internal SATA-3 HDD atm.

All three x264 encodes (muxed to mp4) play back perfectly well (MPC-HC, VLC) BTW, so regarding:

I have a ut video created by myself. Wanted to encode it to h264 using MeGUI. How do you do it?
I used file indexer and ffms2. When I encode the created avs file, the resulting h264 file plays back jerky. I think ffms2 doesn't index correctly utvideo.
If I open the avi file directly with AVISource(), the encoded h264 file plays correctly. Any ideas? FFMSIndex has problems with utvideo?

......I don't know the reason why you got jerky playback with your ffms2 x264 encode.

[WorBry]

Because I tried to learn from MeGUI. When you add a pre-rendering job and MeGUI creates a lossless Huffyuv, it opens it with ffms2.

Please explain to me why MeGUI opens its lossless Huffyuv created by itself with ffms2?

Ah, realize now, likely reason is because you already have an ffindex file in the same folder as your Huffyuv file and with the same file name. So when you open the Huffyuv with AVS Script Creator, it picks up the ffindex file instead and loads the Huffyuv via ffms2. Delete the ffindex file and you'll find that you are again given the option to load the Huffyuv as an AVISource, assuming of course that you have have the appropriate vfw Huffyuv decompressor installed (or enabled, if using vfw FFDShow).

[Atlantis]

Yes but when I index my Ut Video with ffms2 I also have a ffindex file for my ut video and its still choppy when I encode.

[WorBry]

That's a separate issue and...


......I don't know the reason why you got jerky playback with your ffms2 x264 encode.

Well, if someone more knowledgeable than I doesn't pick up your query on this thread, I can only suggest addressing the issue on the FFMPEGSource thread:

http://forum.doom9.org/showthread.php?t=127037

or equally gigantic 'MeGUI: General Questions and Troubleshooting Thread'

http://forum.doom9.org/showthread.php?t=105920

But not both ;)

Only other thing I can suggest is testing your ffms2 avs script to encode to something else (HuffYuv or whatever in VDub) and see if you still get a jerky video, that might point to the indexing. And does your Huffyuv.avi (or another format.avi file) loaded with ffms2 also produce a 'jerky' x264 encode or is it just the UT-Video avi ? Such is my 'process of elimination' approach to troubleshooting. Like I said, others more knowledgeable would likely be able to better pinpoint the cause.

[WorBry]

I see FFMPEG also supports UT-Video encoding.

I’m very new to FFMPEG and have only run a few simple transcode commands. Taking this basic script for converting a RawYV12 avi clip (typically 1440x1080, 25p) to UT-Video:

ffmpeg -i C:\RawYV12FFDS.avi -vcodec utvideo -an UTVYV12.avi

Could someone please advise how I should amend the script to match the configuration options in the vfw version:

Left or Median prediction - I assume default would be Left, but how to set Median?

Interlaced - my sources are typically progressive, but how to set interlace support if required?

Multi-threading support - if indeed this is supported in the FFMPEG UT-Video implementation?

Also, assuming this is an implementation of the BT.709 version - how to specify YUV422 (ULH2) and YUV420 (ULH0) or is that just set by the pixel format -pix_fmts?

I’m using Zeranoe ffmpeg win64-static build (20140125-git-5554c6d).
PC has hex-core CPU (AMD FX-6300) running Win7 64-bit

Thanks a lot.

[WorBry]

Does the UT-Video developer (or his representative) not visit these pages anymore?

[raffriff42]

These are more ffmpeg questions than utvideo, but looking at the source code (https://ffmpeg.org/doxygen/trunk/utvideo_8h_source.html) and doing some experimentation, I can say: it appears left, gradient and median prediction are supported (-pred left|plane|median)
RGB, RGBA, 422 and 420 supported
-pix_fmt rgb24 => "ULRG"
-pix_fmt rgba => "ULRA"
-pix_fmt yuv420p => "ULY0" (4:2:0 BT.601)
-pix_fmt yuv422p => "ULY2" (4:2:2 BT.601)
the code contains an interlaced flag; don't know if it's functional
don't know about multithreading (but doubt it is supported)

[JEEB]

With regards to the libavcodec Ut Video encoder's capabilities I recommend taking a look at the initialization function utvideo_encode_init in utvideoenc.c (https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/utvideoenc.c).

Left and median prediction are indeed implemented. I think gradient prediction was really nowhere to be seen so it is not implemented, the encoder will throw up an error if you try to use it :) . There is also a prediction mode 'none', which is generally useless, but I guess it can be useful with pictures that contain absolutely nothing but a single value.

The specific interlaced coding mode is not supported as my mentor did not see much worth in it. Such content will get encoded the same way as progressive content will be currently (at least I do not either remember or see any errors being thrown at interlaced content as such.

Currently the libavcodec encoder is not threaded. Everyone wanted to have slice-based threading for the Ut Video encoder, which would have needed some new things to be added related to how the huffman coding is done, among other things. I have a patch from Daemon404 for the non-huffman parts of slice-based threading, but he said it was not really faster at all because of the huffman coder being at the end of it.

On the other hand, picture-based threading would be probably pretty simple to implement, and I think at this point it would probably be the better way to get at least some kind of threading to the encoder. Not to mention that while picture-based threading generally uses more memory (multiple pictures in memory being encoded at the same time), it is generally the threading model that ends up being faster.

The implementation was coded before the new FourCCs were added to Ut Video. And it seems like while the libavcodec decoder got patched by someone for the new FourCCs (see decode_init in utvideodec.c (https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/utvideodec.c)), the encoder did not (I am not sure of the whole hardcoding of things to AVCOL_SPC_BT470BG in case of the old YCbCr FourCCs in the decoder). This should probably be the simplest addition.

Additionally I guess there should be a setting to set the amount of slices used by the encoder. It is currently hardcoded to one, as that gives the best compression ratio (the actual encoder internals can handle more slices just fine). That said, the official Ut Video decoder is slice threaded, so it probably has a bit of a negative effect on that.

Edit: Posted a patch (http://patches.libav.org/patch/46933/) for the BT.709 FourCC on libav-devel, That way the feature will go into both FFmpeg and Libav, as FFmpeg merges libav commits almost daily.

[WorBry]

Thanks both. I'm afraid I have no understanding of source codes, but thanks for the advice and update.

So, just to be clear, with the BT.709 FourCC update, it will be:

-pix_fmt yuv420p => "ULH0" (4:2:0 BT.709)
-pix_fmt yuv422p => "ULH2" (4:2:2 BT.709)

Actually, I'm mostly using the vfw UT-Video codec which I've found to be easily fast enough for use as a lossless edit format in the NLE I use at present (Corel VideoStudio Pro x6). Although VSPro, as yet, only supports 32-bit vfw codecs, it has good MT support.

This in turn got me wondering whether the FFMPEG implementation of UT-Video might have similar application in a Linux - possibly as an alternative to 'Matroska Lossless' (Huffyuv/Flac) in KDenLive.

10-bit 4:2:2 support (in both vfw and FFMPEG implementations) would, of course, be the icing on the cake. Any movement on that? I know Windows has Cineform and Linux has DNxHD, but a fast lossless 10bit codec would be priceless.

[JEEB]

To be exact, it is like this:

if decoder has set colorimetry to BT.709 and the format is YCbCr?
-> Use the BT.709 FourCC
in other cases with YCbCr
-> Use the older FourCC

(or actually, encoder's context is what is read, but in ffmpeg and avconv the system sets the encoder's context's values according to the decoder's)

Now, the only problem that I notice is that initialization of the encoder is done quite early in the process (this is where the FourCC is set), and the decoder has not yet decoded anything. Thus in many cases the source's colorimetry is not yet set at that point, and even if the source is marked as BT.709 it might not get encoded as such. I will later see if FourCC settling could be moved to the actual encoding side of things. Rather unfortunate that Ut Video ended up taking the route of multiple FourCCs instead of bitstream/extradata flags. This can be of course overridden with -colorspace 1 (1 being the number of BT.709) on the encoder's side of settings (after -i).

As for high bit depth lossless coding, you might want to try ffvhuff or ffv1, I think both of them currently have >8bit lossless coding in FFmpeg.

Edit: Or heck, even libx264 with quantizer set to zero with a fast preset.

[WorBry]

Thanks again. So if I understand correctly, your advice is to force BT.709 colorimetry (using -colorspace 1), for the time being, to avoid any possibility of the encoder not picking up the source colorimetry flags? And for FFMPEG decoding of (FFMPEG-encoded) UT-Video - any issues or precautions to be taken there, or are the colorimetry flags set as they should be ?

As for high bit depth lossless coding, you might want to try ffvhuff or ffv1, I think both of them currently have >8bit lossless coding in FFmpeg......
Edit: Or heck, even libx264 with quantizer set to zero with a fast preset.

But, AFAIK, there are no 10-bit lossless vfw codecs out there, at least that are accessible as such. Canopus Lossless is 10-bit in Edius, but (as I recall reading) when accessed as a free-standing vfw codec (through the free Canopus codecs pack) it is only 8-bit ......and much slower. When I compared vfw codec decompression rates (32-bit and 64-bit) Canopus Lossless was essentially on par with ffhuff-YUY2-Left pred (FFDShow). UT-Video (left) decompressed 7 x faster in 32-bit mode and even faster (7.5 x) in 64-bit - twice that even of Cineform (Film Scan 1), which is judged to be pretty fast. Cineform (Film Scan 2) comes darn close to lossless (with SSIM scores consistently exceeding 98% in my tests; Canopus HQX Superfine also) - but it's a monster to edit and at the bitrates/file sizes generated one might as well be using a true lossless - and neither ffhuff nor FFV1 (vfw FFdshow) cut it - at least on my system (hence the possible interest of editing with FFMPEG in Linux).

Granted, one might question the benefit of a 10-bit lossless intermediate when editing 8-bit sources with (consumer level) 8-bit editing software. But having looked at a variety of 8-bit footage, I've observed a noticeable reduction in posterization artifacts (inherent in the source or otherwise generated) when using Cineform (Film Scan 1) as an edit intermediate....at least in Corel Video Studio Pro x6 which (despite the 'Pro' epiphet) still only edits in 24bit RGB colorspace. Part of that could well derive from the wavelet compression, but I'm seeing some improvements (albeit slight) also when comparing 10-bit and 8-bit (FFMPEG) DNxHD encodes.

So, it's not only the Professionals who would welcome a 10-bit incarnation of UT-Video.

If the reason is lack of adequate resources to develop and test 10-bit, surely someone could help out? Just seems a pity that having come all this way, with such phenomenal improvements in performance, that this presents such a hurdle. :(

[WorBry]

...... Canopus Lossless is 10-bit in Edius,
Correction: Only Canopus HQX is 10-bit in Edius. Canopus Lossless is 8-bit in and outside Edius:

http://forum.grassvalley.com/forum/showthread.php?t=24932

Also just came across this:

http://forums.adobe.com/thread/1252087

What's that all about - UT-Video maybe not really lossless?? :scared: I wonder if the guys original footage was 10-bit; might explain the banding on the 8-bit UT-Video gradient ? If so, yet another reason why UT-Video needs 10-bit support ;)

[raffriff42]

UT-Video maybe not really lossless?? :scared: 2nd image has been resized; the comparison is invalid for this and other reasons.

However...

Comparing Fraps source (YUV full-range 709) encoded with ffmpeg/utvideo, the result is clamped to 16-235.
(EDIT - I should say, the result is clamped in the U & V channels only!)
https://dl.dropboxusercontent.com/u/108089426/Screenshots/utvideo-compare-yuv-02a.jpg
https://dl.dropboxusercontent.com/u/108089426/Screenshots/utvideo-compare-yuv-02b.jpg

This applies to the ffmpeg version only, and only the YUV flavor. ffmpeg/utvideo in RGB mode is fine. The VfW version is fine.

Repeat, the result is clamped in the U & V channels only. In ffmpeg's defense here, full range YUV is not really legal in the first place! (but it's common in captured sources)

(also, ULH0 / BT.709 does not seem to be supported in ffmpeg, but this is not important IMHO.)

[JEEB]

Comparing Fraps source (YUV full-range 709) encoded with ffmpeg/utvideo, the result is clamped to 16-235.

This applies to the ffmpeg version only, and only the YUV flavor. ffmpeg/utvideo in RGB mode is fine. The VfW version is fine.

Repeat, the result is clamped in the U & V channels only. In ffmpeg's defense here, full range YUV is not really legal in the first place! (but it's common in captured sources)

This is not related at all to the Ut Video encoder itself, but to how ffmpeg works. There is no clamping in the encoder. Try to specify the range on either/both side(s). Also make sure that the data is actually clamped and not clamped by the YCbCr→RGB conversion that comes after that (full range YCbCr read as limited range because it has no full range flag).

But yes, Ut Video has no flag for limited/full range, so I really can't recommend using it for full range content. But the encoder itself should not and does not clamp anything. It just encodes whatever you pass to it as-is.

Edit: Because of how the swscale system works, the conversion from full range to limited range can't be skipped in command line ffmpeg. Welcome to swscale, although after some thought it's a damn brainfart to use a thing that can't signal stuff for full range content. Save this kind of stuff for formats that actually can convey the information down the goddamn chain. It only "works" in VfW because the framework is as dumb as a brick. That said, if the conversion is done incorrectly (I have not checked for it, just for the fact that the information actually changes), feel free to poke the related project to fix it.

(also, ULH0 / BT.709 does not seem to be supported in ffmpeg, but this is not important IMHO.)
The decoder has supported it for quite some time now as far as I can see (albeit I do not fully agree with how it works right now, where the old YCbCr FourCCs are interpreted as AVCOL_SPC_BT470BG -- after all, those FourCC have been used for all Ut Video YCbCr content before; it should instead not lead to anything, to be undefined).

The encoder has had support for the BT.709 FourCCs for four hours now in libav, and FFmpeg has just merged it. Now both libav and FFmpeg support it.

Do note, though, that the libutvideo encoder does not seem to use the BT.709 FourCC (decoder seems to have an ifdef and uses it), I am only speaking of the internal libavcodec implementation, which I coded during the summer of 2012.

[raffriff42]

Thanks, JEEB. I should mention, before someone else does, about the apparent residual color matrix error and slight chroma smearing: these are both due to the Fraps decoder's YUV to RGB conversion. The UTvideo screenshot is actually more correct in these areas. (Should've used FFmpeg input plugin for my tests)

[WorBry]

Well, like I said, part of my interest was in the potential use of Ut-Video as lossless edit intermediate in Linux, primarily KDenLive which, as far as I can tell, edits in RGB color-space (that assumption being based on there being no mention of an option to set the edit color space otherwise). In which case, proper recognition and respect of color-matrix flags would be important. That said, there appears, at this time, to be no option to configure a custom transcode format in KdenLive - (thinks ) I wonder though if modifying the script of one of the 'canned' transcode formats (Matroska Lossless maybe?) could be made to work with UT-Video - not at my home pc just now, but might try that. But that would, in turn, need the UT-Video Rec.709 update to be in the Ubuntu libav libraries that KDenLive uses. Not sure know how that works - would they be updated daily also?

This is not related at all to the Ut Video encoder itself, but to how ffmpeg works......
But yes, Ut Video has no flag for limited/full range, so I really can't recommend using it for full range content. But the encoder itself should not and does not clamp anything. It just encodes whatever you pass to it as-is.


Hmmm....didn't realize that. So does that mean that full-range content is going to get clamped in KDenLive with any of the transcode formats? Not sure I'd want that.

[JEEB]

Well, like I said, part of my interest was in the potential use of Ut-Video as lossless edit intermediate in Linux, primarily KDenLive which, as far as I can tell, edits in RGB color-space (that assumption being based on there being no mention of an option to set the edit color space otherwise). In which case, proper recognition and respect of color-matrix flags would be important.
Now, first of all, with video editors you have some stuff that you have to make sure before hand, if you even want to have them handle YCbCr content. And yes, in most cases editing itself is done in RGB space. Pictures are decoded and converted, and then filtered, and then thrown towards an encoder again, possibly converted back to YCbCr if the encoder is not set to RGB.

Your first problem is to check if the editor handles colorimetry at all. Encode some shade of, say, light blue, and stick different colorimetry metadata to it. Use a format that doesn't do hackjobs for this information, such as H.264. See if it makes any difference at all.

After that, if you really wanted to have full control on things, I'd still recommend a format that can signal this stuff properly.

But that would, in turn, need the UT-Video Rec.709 update to be in the Ubuntu libav libraries that KDenLive uses. Not sure know how that works - would they be updated daily also?
No, official repositories of distributions that actually have releases always stay on the major version that was in when the release was made (and usually a few months before that). Also with things like FFmpeg or Libav there is also a rather large amount of work to be done to update everything that depends on their libraries so that it all works with the new version. And the amount of things depending on these libraries is rather large.

Every current stable Ubuntu release to this date has Libav 0.8, released 21st of January, 2012. It has the decoder, no encoder. No idea how many Ut Video decoder fixes have since been backported into the 0.8 branch. 14.04 will either have Libav 9 or Libav 10, depending on if the Debian/Ubuntu maintainer will be able to update things.

Hmmm....didn't realize that. So does that mean that full-range content is going to get clamped in KDenLive with any of the transcode formats? Not sure I'd want that.
What was just talked about was looking at the content as if it was full range YCbCr. RGB is not related in any way or form (or actually it is, but pretty much no-one uses limited range RGB in such use cases).

ffmpeg (the command line app) saw that what the decoder would output was not what the encoder would take in (for swscale the full range and limited range 4:2:0 are separate "pixel formats"), and a conversion happened. In all theory this is correct. Your output format is not capable of distinguishing between limited or full range YCbCr, and thus your content is converted to limited range, so that it can be correctly handled by other things. Whether or not this conversion was done correctly is out of the scope of this post, and if it is incorrect then I strongly recommend reporting it at the given upstream project :P .

If the system in the command line ffmpeg was somewhat better, you could have forced it to not convert. That said, you really don't want it. You would lose all metadata about the range. It only "works" in VFW because VFW is dumb and has absolutely no idea about these things. It just passes one filter's output to another filter's input as long as the general pixel format is the same. After that passing has happened, no-one and nothing else but you can do anything to that content correctly. Manually, of course.

As for editors and full/limited range YCbCr? No idea. Up to the editor. If your input format is something that can actually signal the YCbCr range, it might get read in properly and converted correctly to RGB for editing. Of course, this depends on how intelligent the input module is as well. If your editor's input module has no idea of these things or how to push them further down the chain, you are just screwed. Like with VFW, for example (stuff like FRAPS can have its own special decoder that can output straight into RGB and do the conversion itself; a Ut Video decoder would not be able to do this because it has absolutely no way of knowing what range you have in there, so it would have to just handle it as limited range YCbCr or full range RGB).

As for export, no idea either. I would guess that unless you hack around hard your things would get converted to limited range YCbCr in case of YCbCr. And full range RGB in case of RGB.

Long story short, if I had to use something that I have no idea of how it does things, I would just convert to RGB in the exact way I would want to before editing, and then export in RGB, and then convert that into YCbCr again in the exact way I wanted.

[JEEB]

Additionally I guess there should be a setting to set the amount of slices used by the encoder. It is currently hardcoded to one, as that gives the best compression ratio (the actual encoder internals can handle more slices just fine). That said, the official Ut Video decoder is slice threaded, so it probably has a bit of a negative effect on that.
An update on this, I have posted a patch (http://patches.libav.org/patch/47263/) to make the lavc Ut Video encoder use multiple slices. If nothing is specified, slice count is set to <subsampled height> / 120 . So everything up until 239 samples of height will have one slice, and 240+ will have two, and so forth. This is calculated from the chroma subsampled height in case of 4:2:0 YCbCr for example, so less slices are used then :) (but you do get at least two with 4:2:0 480p).

Naturally, you can override this by using the -slices parameter as well :) .

[qyot27]

Do note, though, that the libutvideo encoder does not seem to use the BT.709 FourCC (decoder seems to have an ifdef and uses it)
It was mainly because I wasn't sure how to handle the decision in the encoder's switch case. The fix for the native encoder can be safely re-applied against libutvideoenc with little modification, though.

Although the discussion above concerning featureset led to more testing that uncovered the fact that libutvideoenc seems to be locked to median prediction. I'm also not sure if multithreading is used when libutvideo is selected, nor how much of an impact enabling the assembly really has (except that enabling both it and building as a shared library results in broken builds).

Really, the use case for libutvideo over the native implementation is as a reference.



(to be honest, I just use ffvhuff - the higher bit depths and extra colorspaces need -strict experimental, so using those seamlessly has to wait until it gets finalized; there's always FFV1 for those scenarios in the meanwhile)

[JEEB]

An update on this, I have posted a patch (http://patches.libav.org/patch/47263/) to make the lavc Ut Video encoder use multiple slices...
This feature is now in both Libav and FFmpeg. Now what's left is threading. Will have to look up a similar intra-only and frame/picture-basely threaded encoder as an example.

The fix for the native encoder can be safely re-applied against libutvideoenc with little modification, though.
Might poke Daemon404 for this at some point. After all, he is the maintainer for the libutvideo wrappers :) .

Although the discussion above concerning featureset led to more testing that uncovered the fact that libutvideoenc seems to be locked to median prediction. I'm also not sure if multithreading is used when libutvideo is selected, nor how much of an impact enabling the assembly really has (except that enabling both it and building as a shared library results in broken builds).
At least median is generally what people most probably want to have. Multithreading-wise in theory it should have it, and the asm probably has some effect on the result? Also lol at the broken build. Will poke youm on #utvideo@freenode later I guess.

(to be honest, I just use ffvhuff - the higher bit depths and extra colorspaces need -strict experimental, so using those seamlessly has to wait until it gets finalized; there's always FFV1 for those scenarios in the meanwhile)
Yeah, ffvhuff is a nice one. Had used it for a long time before Ut Video came around, and still use it at times. The main reason to use Ut Video is for intercompatibility, really. It has a decoder component in pretty much every major multimedia framework by now, in addition to the support in libavcodec (VFW, DShow, QuickTime, MF...).

[qyot27]

Might poke Daemon404 for this at some point. After all, he is the maintainer for the libutvideo wrappers :) .
I can just send a patch with all the original commit info intact. Maybe add a blurb in the commit message that it's been slightly modified for the lib wrapper.

At least median is generally what people most probably want to have. Multithreading-wise in theory it should have it, and the asm probably has some effect on the result? Also lol at the broken build. Will poke youm on #utvideo@freenode later I guess.
With the asm, what I meant is that when I tried enabling it, it didn't seem to speed anything up, and this was on a system that would have at least the SSE2 support available (CPU was an Athlon64 Orleans). Maybe the Orleans' SSE2 support just sucks - it wouldn't surprise me.

The situation with libutvideo is a bit...sticky. The ability to build libutvideo from the official source zip was removed a few versions back. The only reason newer versions of it can still be built is because I kept the GNUmakefile and the more fleshed-out buildsystem patches alive on Github (http://github.com/qyot27/libutvideo).

[RTW47]

Version 14.0.0
New features
•Add a codec whose internal format is YUV422 10bit. (FourCC: UQY2). Very slow.
Others
•Changed codec names.
•Changed minimum requirement OS: Windows Vista or later.
readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.0.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.0.0-win.exe) / Mac OS X (zip) (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.0.0-macosx.zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.0.0-src.zip)

[kolak]

10 bit support ☺
Great news.

[Sparktank]

Just saw that there was an update on VideoHelp.com

Version 14.1.1

New features
UQY2: Restriction of video width is relaxed.


http://www.videohelp.com/tools/Ut-Video-Codec-Suite

Official Site (sorted by Last Modified descending):
http://umezawa.dyndns.info/archive/utvideo/?C=M;O=D

[Selur]

Where do I find some documentation about the arguments accepted by ffmpeg for utvideo? (as a aside note: also looking for the same info in regard to ffvhuff)

[raffriff42]

Where do I find some documentation about the arguments accepted by ffmpeg for utvideo?Looking at the source code (http://www.ffmpeg.org/doxygen/2.0/utvideoenc_8c_source.html#l00057), to me it appears that there are only two user variables from AVCodecContext used in the encoding process:

Pixel format (-pix_fmt) options are rgb24, rgba, yuv420p and yuv422p.
(Note ffmpeg sets the default pixel format for you, based on your source format, so this argument is not needed unless you want to force a format conversion)
(BTW, for YUV, the Rec.601 (http://umezawa.dyndns.info/archive/utvideo/utvideo-13.1.0-readme.en.html) variants are used: yuv420p fourcc = ULY0, yuv422p fourcc = ULY2)

Prediction method options appear (http://www.ffmpeg.org/doxygen/2.0/utvideoenc_8c_source.html#l00120) to be left (-pred left, the default) or median (-pred median)
(left is supposed to be faster, median is supposed to give better compression)

EDIT okay, there's more than two; there is one more item of possible interest: Slices (for example, -slices 4)
There was no effect on encoding speed in my very short test video, but the binary output was slightly (0.02%) larger, so something happened. Needs more looking-into.

[Selur]

Thanks a lot raffriff42!! :)

[qyot27]

(BTW, for YUV, the Rec.601 (http://umezawa.dyndns.info/archive/utvideo/utvideo-13.1.0-readme.en.html) variants are used: yuv420p fourcc = ULY0, yuv422p fourcc = ULY2)
This can be changed with the -colorspace option.
ffmpeg -i input -vcodec utvideo -pix_fmt pixfmt -colorspace bt709 output.avi
automatically selects the ULH* variant of the pixfmt.


At the current time, neither the native utvideo codec nor libutvideo wrapper exposes the 10-bit form introduced in version 14. I tried to fiddle with it a while ago to see if I could do it, but it wasn't allocating the right side of the image.




And just because I mentioned it earlier, ffvhuff no longer requires -strict experimental to use the huge array of additional pix_fmts.

[raffriff42]

This can be changed with the -colorspace option.Thank you, that's good to know!

[BlockABoots]

Am about to try out the utvideo codec for the first time, but noticed there are 7 decoding options...

(ULH0)
(ULH2)
(ULRA)
(ULRG)
(ULY0)
(ULY2)
(UQY2)

Can some one explain what each one is please. If im wanting to used the codec to record xbox one game play and then retro stuff (NES, SNES) which ones should i be picking?

[raffriff42]

I assume you mean 'encoding options' ?

If your source is 720p or 1080p, start with 'ULH0' (YUV 420 BT.709), but I would test 'ULY0' (YUV 420 BT.601) as well, choosing whichever looks 'better' (least saturation shift in greens & reds) in your chosen editor program.

If you have fine color detail (thin lines, small fonts) and you want to upscale from (for example) 480p to 720p, you may want 'ULRG' (RGB). You will probably have to convert to YUV 420 for the final product anyway, but doing so after upscaling looks a bit better. The downside of RGB is larger file size.

For really retro stuff (360p or below) I would definitely capture in RGB mode and scale up to HD for the final video.

There are threads on doom9 about upscaling pixel games...EDIT here's the one I was thinking of:
http://forum.doom9.org/showthread.php?t=170661

[rikai]

Figured i'd point out the 14.2.0 release here from back in june since nobody else had. :)

Version 14.2.0

Performance Improvements
•UQY2: Add support for multithreading.

readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.2.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.2.0-win.exe) / Mac OS X (zip) (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.2.0-macosx.zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.2.0-src.zip)

[nhope]

Anyone having any luck rendering 10-bit? I'm choosing the "UtVideo Pro YUV422 10bit VCM" option and have tried a few resolutions and frame rates but rendering in Vegas Pro it always tells me "The selected codec does not support the current render settings." In VirtualDub it says "Couldn't find compatible format. Possible reasons: *Codec may only support YUV *Codec might be locked *Codec might be decompression-only".

[Ignus2]

Anyone having any luck rendering 10-bit? I'm choosing the "UtVideo Pro YUV422 10bit VCM" option and have tried a few resolutions and frame rates but rendering in Vegas Pro it always tells me "The selected codec does not support the current render settings." In VirtualDub it says "Couldn't find compatible format. Possible reasons: *Codec may only support YUV *Codec might be locked *Codec might be decompression-only".

As the reply would lead to very off-topic discussion, I answered here:
http://forum.doom9.org/showthread.php?p=1702245

Greets,
I.

[RTW47]

readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.0-readme.en.html) (EN) / Windows (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.0-win.exe) (exe) / Mac OS X (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.0-macosx.zip) (zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.0-src.zip) (zip)

New features:
• Add QuickTime components (both encode/decode) for Windows.
• ULY2, ULH2, ULY0, ULH0: Add support of YUV422 input/output on QuickTime components.
• UQY2: Add QuickTime components.

[kolak]

Interesting!:thanks:

[cez4r]

Version 15.0.1 (http://umezawa.dyndns.info/archive/utvideo/)

"For some reasons, rebuilt and re-packaged." — 15.0.1 readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.1-readme.en.html)

[kolak]

Qt 10bit was badly crashing QT player for me.

Next step is 16bit with RGB support.

[kolak]

Version 15.0.1 (http://umezawa.dyndns.info/archive/utvideo/)

"For some reasons, rebuilt and re-packaged." — 15.0.1 readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.1-readme.en.html)

Installer was infected.

[cez4r]

Thanks.

And the author totally removed 15.0 versions for Windows from his site...

[LigH]

Infection seems to be not so certain, only suspicious as generic backdoor, but by almost half the engines used by VirusTotal.

VirusTotal reports: utvideo-15.0.0-win.exe (https://www.virustotal.com/de/file/9fceb488fcb4d5a50a961d7d58bc7140b80985d5a52e1cdc1902a72fffa5fed1/analysis/1422015743/) / utvideo-15.0.1-win.exe (https://www.virustotal.com/de/file/86a84bd3876a72f000649249b7190d768e8a836ef683646ce2ef03e5b161ed07/analysis/1422015928/)

Ongoing discussion (http://umezawa.dyndns.info/wordpress/?p=5292) on the japanese author's blog...

[LigH]

Version 15.0.2 appears to be clean (https://www.virustotal.com/en/file/1a6115abf5e8efb252f4a9652109a6e480354d43d3c09398133c263cf283bc4e/analysis/1422101384/).

[zerowalker]

Been reading and looking around how to Encode UTVideo with FFmpeg to Rec.709.

From my understanding this has been implemented in the Decoding, but not in the Encoding, or has that changed?

Cause i need to encode to Rec.709 via UT Video (not through color space conversions to "hack" through it).

[kolak]

Add -colorspace bt709 to your command.

[zerowalker]

Ah ok. Thanks

[zerowalker]

Is UT Video supposed to be slower than Lagarith at 60fps 1920x1200?
Cause it doesn't make sense, it's lagging on playback (i use Set for Decoding Speed),
compared to Lagarith which uses about 20% less CPU for the same clip.

Talking only decoding here, Encoding is different.

[Ignus2]

Is UT Video supposed to be slower than Lagarith at 60fps 1920x1200?
Cause it doesn't make sense, it's lagging on playback (i use Set for Decoding Speed),
compared to Lagarith which uses about 20% less CPU for the same clip.

Talking only decoding here, Encoding is different.

You are probably using the decoder from ffmpeg (either in Lav or MPC or something) and not the original UT decoders.
The ffmpeg variant is vastly inferior.

Greets,
I.

[zerowalker]

I am actually not doing that cause i thought the same.
I tried ffmpeg just in case, but it was so slow it's pretty much slideshow.

MagicYUV worked fined btw, huge difference in CPU Utilization.

EDIT:

UT Video used 50% (which is 100% as it only used 2 Threads).
MagicYUV uses about 15%.

Not sure if everything is as it should.
UT Video when i did tests before was fairly close go MagicYUV, but then again that wasn't at this resolution and fps.