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

[cjplay]

Forgive my ignorance. I see it now in the 4CC list as ULH2 in FFMPEG. Now I just need a command to force it. My input is still a UYVY and FFMPEG is defaulting the encoder to the other 4:2:2 for UT video. Any thoughts?

Chris.

[filler56789]

Do you know of any way to force FFMPEG to output the 709, 4:2:2 colorspace version of UTVideo?

Oooops :o , I deleted my previous post, because I had misunderstood your problem :o Anyway, not really a solution, but if you're on a Windows machine, you might use Mencoder.EXE together with the UT VfW codec. Maybe you can use this combination on Linux through WINE, but I don't know whether it works or doesn't work. :confused:

[cjplay]

Thanks for the reply. I'm on Windows, so I will give it a shot. I'm especially interested in the VFW2Menc if it supports an AVI output and an STDIn.

[raffriff42]

@rean,
>hard clipping out of range
use " -pix_fmt yuv420p"

>incorrect matrix
I didn't see this, using a Fraps video as a test source
-vcodec utvideo -pix_fmt yuv420p

Opening with FFMS yielded perfect results: #avisynth
return FFmpegSource2("path to video", atrack=1).ConvertToRGB32(matrix="Rec709")
https://www.dropbox.com/s/q7izf3ewqv45u09/codec-test-2-ut420%2Bffms%2Bm709.jpg?raw=1

(EDIT viewing in Vdub with UT Video's VfW decoder +Alias Rec709 filter had a problem though - green channel clipped at around 220)
https://www.dropbox.com/s/r3heb2n70tqgunm/codec-test-2-ut420%2BVfW%2Ba709.jpg?raw=1

[raffriff42]

yuv420p will destroy chroma. I want to convert true YUV 4:4:4YUV 4:4:4 is not supported by UT Video; the choices are RGB ('ULRG'), RGBA ('ULRA'), 4:2:0/BT.601 ('ULY0') 4:2:0/BT.709 ('ULH0'), 4:2:2/BT.601 ('ULY2') and 4:2:2/BT.709 ('ULH2'). If using 4:2:0 or 4:2:2, you must choose the correct encoding matrix. (EDIT if your source is 444, you are converting to RGB, one way or the other - it's best to do so explicitly and specify the correct conversion matrix)

PS. Your images may give a sense of control, but you cannot see clipping. See the result using a histogram (YUV) or a special source (i.e. with a cloudy sky and deep blacks with details in these areas (RGB).Compare the green ridge line on the pyramid - the second one is visibly flattened. In my opinion, an image like this, with full range color ramps, is superior to Histogram for clipping detection. (EDIT it's not an image file, but a generated test pattern ('http://sourceforge.net/projects/frafstestpatt/') using DirectX9, and captured with Fraps)

I created a new RGB test video; encoded with ffmpeg (-vcodec utvideo -pix_fmt rgb24) - and the result is perfect as viewed in VirtualDub with UT's VfW decoder. No color shift, no level shift, no clipping. Also perfect as viewed in Premiere with UT's DirectShow codec.

Note I always specify my playback signal chain - you can't say, "this video looks wrong," you have to say, "this video looks wrong using decoder X and renderer Y." See for example: BT.601 and BT.709 compatibility benchmark ('http://forum.doom9.org/showthread.php?t=164378') (doom9)

[cjplay]

Bad news. A member of Zeranoe's forum updated me that the support I read about was for decoding only. Encoding is not supported yet. Bummer.

Trying Mencoder tomorrow AM.

Chris.

[raffriff42]

Source: H264 4:4:4 file with 0..255 luma

Conversion string: ffmpeg.exe -i 20121010_16425.mkv -vcodec utvideo -pix_fmt rgb24 out.avi

Resulted avi played in VirtualDub, Avisynth: FFMpegSource or Haali dss2, the same result in all cases.

Also I point you to read something about YUV->RGB conversion. It is not possible without an information about source and destination color profile knowledge.

Try -vcodec utvideo -pix_fmt yuvj444p, it works for me.

[Keiyakusha]

ffmpeg.exe -i uncompressed.avi -vcodec utvideo -pix_fmt rgb24 out.avi
(where uncompressed.avi is a YUV 4:4:4 fullrange 1080p raw video)

For me the result converted with right matrix but with clipped levels.
However as it is not possible to know what range source uses, I expect we should somehow tell ffmpeg that the source uses full range.
EDIT: h264 High 4:4:4 fullrange converted to utvideo rgb without issues!
If you have clipping, most likely fullrange flag is missing in your h264 stream. If you haven't set it during encoding, it is impossible to tell that the source is fullrange as in case of raw video.

[poisondeathray]

ffmpeg.exe -i uncompressed.avi -vcodec utvideo -pix_fmt rgb24 out.avi
(where uncompressed.avi is a YUV 4:4:4 fullrange 1080p raw video)

For me the result converted with right matrix but with clipped levels.
However as it is not possible to know what range source uses, I expect we should somehow tell ffmpeg that the source uses full range.
EDIT: h264 High 4:4:4 fullrange converted to utvideo rgb without issues!
If you have clipping, most likely fullrange flag is missing in your h264 stream. If you haven't set it during encoding, it is impossible to tell that the source is fullrange as in case of raw video.




Confirmed .

If the h.264 source file was flagged full range, ffmpeg takes that into account in the rgb conversion

-vf colormatrix=bt709:bt601 will fix the other 709/601 problem - BUT, the conversion is low quality compared to if the manipulations were done in avisynth (there is chroma aliasing and looks like it's not done at full chroma resolution maybe YUV 4:2:2) - I mentioned this ffmpeg colormatrix issue in the various other fraps threads

[poisondeathray]

ffmpeg's colormatrix was ported from avisynth - I think that's where the quality loss is occuring since colormatrix() only works with YV12/YUY2. If someone could update the avisynth colormatrix() plugin to work with yv24, I suspect it could be updated in ffmpeg .

(but it would be better if the avisynth ConvertToXX(matrix="X") functions could be implemented in ffmpeg)

[poisondeathray]

I have added option "--range pc" to x264 and reencoded the source to check. Again, in this case, I still have the same results. Anyway, this flag is not needed, because x264 automatically set it if found out of tv range values in the source stream (auto by default).

:D:D:D

In my tests, when the yv24 h.264 file encoded with x264 used "auto" it didn't work (the data was full range, but ffmpeg didn't do the RGB conversion correctly - rec601 and limited range)

But when I specified --input-range pc --range pc, it worked

x264 --crf 0 --input-csp i444 --output-csp i444 --input-range pc --range pc -o output.mp4 input.avs

[Keiyakusha]

rean
--range sets output range. To set input range you need to use --input-range. Also if they don't match - levels will be converted.
Anyway. If you think you did everything right and it still doesn't work for you, perhaps your ffmpeg revision is broken or old.

[Keiyakusha]

-vf colormatrix=bt709:bt601 will fix the other 709/601 problem
Not sure that I understand this. What problem? There is no problems not with levels, not with matrix during conversion h264 4:4:4 PC to UT RGB...

Source: h264 4:4:4 PC bt709
ffmpeg.exe -i source -vcodec utvideo -pix_fmt rgb24 out.avi
Result is right for me.

Besides why exactly utvideo? Isn't ffmpeg is the one doing conversion and then supplies uncompressed RGB to UT video? If there is a problem isn't it should be with other output formats too?

[poisondeathray]

Not sure that I understand this. What problem? There is no problems not with levels, not with matrix during conversion h264 4:4:4 PC to UT RGB...

There are 2 problems; levels (pc vs. tv) , and Rec 601 vs 709

The levels issue you addressed, but ffmpeg will always convert YUV to RGB using Rec 601 (not correct for most HD sources) instead of Rec 709

The colormatrix is a "hack"; as rean described above, you are converting in yuv 709 to yuv 601 (ie. as if the source file had been converted to YUV from a previous RGB=>YUV conversion using 601 in the first place instead of 709) - and this is done in 4:2:2, not 4:4:4. After that, ffmpeg is converting to RGB using Rec 601 (so colors match in RGB)

[Keiyakusha]

ffmpeg will always convert YUV to RGB using Rec 601 (not correct for most HD sources) instead of Rec 709

This is not true for me. Maybe I need to re-check it though but I'm pretty sure I did checked for that too.

[poisondeathray]

This is not true for me.

Well maybe something has changed in the last 2 weeks ? My binary is 2 weeks old . Are you aware of any recent changes ? I can retest it and report my observations

There are a few notable exceptions when going from RGB to YUV (normally ffmpeg uses Rec601 for everthing) , when you use v210 (10bit 4:2:2 YUV), it will use Rec709 instead of Rec601 .

[poisondeathray]

But now is a question, how to get it working directly from an avs2yuv stream...


If you're using avs /avisynth somewhere in the workflow, why not do all the manipulations in avisynth ? or am I missing something ?

[Keiyakusha]

Well maybe something has changed in the last 2 weeks ? My binary is 2 weeks old . Are you aware of any recent changes ? I can retest it and report my observations

There are a few notable exceptions when going from RGB to YUV (normally ffmpeg uses Rec601 for everthing) , when you use v210 (10bit 4:2:2 YUV), it will use Rec709 instead of Rec601 .

I don't follow ffmpeg and my build is a bit older than 2 weeks, maybe 3 or 4
1) I just made rgb fullrange 1080p reference with gradients that allow me to spot matrix conversion issues easily
2) converted it to fullrange YV24 bt709 in avisynth
3) encoded to h264 with all proper flags for matrix and levels
4) used this command: ffmpeg.exe -i source.mkv -vcodec utvideo -pix_fmt rgb24 out.avi
resulting h264 stream is confirmed to have all flags set an tested with LAV+madvr -> madvr's output matches reference video.
resulting out.avi is a perfect match to the reference minus little quality loss due to conversions

[poisondeathray]

Besides why exactly utvideo? Isn't ffmpeg is the one doing conversion and then supplies uncompressed RGB to UT video? If there is a problem isn't it should be with other output formats too?

Yes, this discussion sort of moved away from UT video strictly , the last few comments deal with ffmpeg (it's more a fffmpeg problem)




I don't follow ffmpeg and my build is a bit older than 2 weeks, maybe 3 or 4
1) I just made rgb fullrange 1080p reference with gradients that allow me to spot matrix conversion issues easily
2) converted it to fullrange YV24 in avisynth
3) encoded to h264 with all proper flags for matrix and levels
4) used this command: ffmpeg.exe -i source.mkv -vcodec utvideo -pix_fmt rgb24 out.avi
resulting h264 stream is confirmed to have all flags set an tested with LAV+madvr -> madvr's output matches reference video.
resulting out.avi is a perfect match to the reference minus little quality loss due to conversions

OK, I'll double check it .

But how did you do step 2? What matrix?

ConvertToYV24(matrix="PC.709") ?

I didn't include the --colorprim --transfer --colormatrix flags , that might be the difference...

Can you post your full command lines please ?

[Keiyakusha]

But how did you do step 2? What matrix?

ConvertToYV24(matrix="PC.709") ?

I didn't include the --colorprim --transfer --colormatrix flags , that might be the difference...

Can you post your full command lines please ?

Yes ConvertToYV24(matrix="PC.709")

--crf 0 --preset veryslow --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --input-range "PC" --range "PC"

BTW why you didn't included flags? they must be set every time regardless of what you encode for what purposes. unless you don't care about output at all...

[poisondeathray]

Yes ConvertToYV24(matrix="PC.709")

--crf 0 --preset veryslow --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --input-range "PC" --range "PC"



Thanks. Yes, out.avi is still using wrong matrix with those flags

To "view" the avs script that generated the source file, I used ConvertToRGB(matrix="PC.709") => that is what the out RGB UT Video should look like (ie. it should look like the original RGB image, minus the colorspace conversions damage)

I used a source image belle nuit test chart (One reason why it's useful, is it has 709/601 patches that can be verified in a waveform monitor, and full/std range patches)
http://www.belle-nuit.com/test-chart

ImageSource()
ConvertToYV24(matrix="PC.709")

# to view what the RGB UT video should look like
#ConvertToRGB(matrix="PC.709")



EDIT: just to clarify, I'm viewing out.avi (the RGB UT Video) in avspmod, using AVISource() , using UT Video VFW decoder. I verifed that it is indeed RGB output (not some other YUV format and some inadvertent colorspace conversion, since it's already RGB)

[Keiyakusha]

I repeated test with 1920*1080 testchart.tif (396 KB) and matrix is fine.
Note that you do see some loses especially where it shows [1] but that's not a matrix issue its a loss due to ffmpeg's conversion being low quality and in normal video you shouldn't notice it.

[poisondeathray]

I repeated test with 1920*1080 testchart.tif (396 KB) and matrix is fine.
Note that you do see some loses especially where it shows [1] but that's not a matrix issue its a loss due to ffmpeg's conversion being low quality and in normal video you shouldn't notice it.

I'm not talking about the mild losses, I'm talking about different matrix, different colors .

In fact , if I use for previewing

ImageSource()
ConvertToYV24(matrix="PC.709")
ConvertToRGB(matrix="PC.601")

It looks exactly like the UT RGB "out.avi" in terms of colors . This confirms it's the wrong matrix (601)

I'm using komisar's x264 build, and zeranoe's ffmpeg build , might that account for the difference ?

[Keiyakusha]

I'm using both private builds but I'm not aware of any patches related to this stuff...
Well, I don't know... here is my h264 file (https://dl.dropboxusercontent.com/u/110558786/Samples/matrix_test.mkv), and final UTvideo file (https://dl.dropboxusercontent.com/u/110558786/Samples/matrix_test_out.avi). You can see some differences compared to source. Mostly near [1] block, also somewhat at green color. but this is minor loses, wrong matrix will be far more visible.
I use UTvideo decoder to decode avi file, not ffmpeg or whatever.

[poisondeathray]

hmm your files look correct, correct matrix. We are getting different results

I'll check again and download new binaries, and repeat the tests, but I think it might a difference in your private build

[poisondeathray]

The difference is definitely in ffmpeg, not x264 (even using your input h.264 , I get different results)

Can you confirm ffmpeg commandline was only something like (no other ffmpeg switches ?)

ffmpeg.exe -i input.mkv -vcodec utvideo -pix_fmt rgb24 output.avi

[Keiyakusha]

The difference is definitely in ffmpeg, not x264 (even using your input h.264 , I get different results)

Can you confirm ffmpeg commandline was only something like (no other ffmpeg switches ?)

ffmpeg.exe -i input.mkv -vcodec utvideo -pix_fmt rgb24 output.avi

Yes it is. But I can confirm better. zeranoe build gives me wrong results. :devil:
ffmpeg-20130706-git-63d7684-win64-static.7z

Is there any other builds out there?

[poisondeathray]

Yes it is. But I can confirm better. zeranoe build gives me wrong results. :devil:
ffmpeg-20130706-git-63d7684-win64-static.7z

Is there any other builds out there?



Hahahaha . Ok thanks for clarifcation

Can you provide more info on the "secret sauce" that goes into your private build :)

(what patch might be the difference) ?

There is ffmbc as well , but IIRC it's the same issue (I tested these things several months ago)

[Keiyakusha]

Can you provide more info on the "secret sauce" that goes into your private build :)

(what patch might be the difference) ?

I don't know, sorry. I'm not aware of any patches at all, but you never know... It was built from ffmpeg version N-53758-g5711e4f. Maybe this is just lucky revision? ^__^

[poisondeathray]

Ok thanks. I hope it gets sorted out in zeranoe builds eventually

But we should move disucssion back to UT Video Codec (this thread), since those were ffmpeg related issues

[HulkHoganRules]

I have been using Ut video for recording from the Blackmagic cards due to HDYC color space.

I will be doing 4-5 hour recording sessions from a 720p source so lossless UT video is no longer a valid solution due to space issues.

Does anyone know of a good "lossy" codec I can use to handle the HDYC color space? It must be compatible with FFMpeg.

[HulkHoganRules]

Nevermind. Did some AVISynth wizadry and was able to losslessly capture HDYC to RGB with less bit rate than Ut. Perfect captures now. :)

[kolak]

Edited post - incorrect results before

I have just checked the resulted matrix by compare source yuv444 and result rgb one with one. Also tried to emulate matrix conversion 709->601 or 601->709 to check an idea about incorrect matrix.
The result is wrong: ffmpeg uses incorrect matrix to convert from H.264 4:4:4 to ut RGB.



It's famous ffmpeg bug and has not been fixed for ages!
It's real pain in the xxx :)

[kolak]

Nevermind. Did some AVISynth wizadry and was able to losslessly capture HDYC to RGB with less bit rate than Ut. Perfect captures now. :)

HDYC to RGB with less bitrate than Ut? It had to be really something magical :)

[acesea]

I am capturing some analog hi8 and vhs footage using ATI usb 600 svideo input into vdub and compressing with UtVideo. The work will later involve processing in avisynth, editing in premiere pro or vegas and then encoding with x264 for pc and web viewing.

There are audio sync issues depending on the lossless codec used and to get closest audio sync with UtVideo I set vdub capture timing options to sync audio to video by resampling the audio to a faster or slower rate and check correct video timing for fewer frame drops/inserts and audio latency determination automatic with 300 audio blocks to use at start.

Should I set vdub custom video format to YUY2 YUV 4:2:2 interleaved and then select video compression UtVideo YUV422 BT.601 (ULY2) VCM and check assume interlace video?

Anything else recommended for good UtVideo captures that will process and edit well without any unnecessary yuv to rgb to yuv conversions along the way? Should I keep with 601 since its SD or any reason to capture in 709 color space?

[TheSkiller]

Should I set vdub custom video format to YUY2 YUV 4:2:2 interleaved and then select video compression UtVideo YUV422 BT.601 (ULY2) VCM and check assume interlace video?
Yes.
Albeit the "assume interlace video" option in Ut Video is only for resampling color spaces which you should avoid and therefore the option is more or less irrelevant – same applies to the 601/709 variants, as long as you don't request any conversion it doesn't matter which option you choose.
For example, you feed YUY2 to the 4:2:2 601 Ut video Codec, and if you request YUY2 from the captured file later, there's no conversion.
If you need anything other than YUY2 later, you're better off using AviSynth for the conversion, in other words don't request Ut video to do any color space conversions. Ut video does it but from what I've seen it's resampling qualities are not quite ideal. It's a great lossless codec after all, it doesn't need to be good at converting color spaces, just keep that in mind. :)


Should I keep with 601 since its SD or any reason to capture in 709 color space?
Unless you choose RGB in VirtualDub and then 4:2:2 709 Ut Video, you cannot capture in anything other than 601 colorimetry anyway because there would have to be a 601->709 conversion somewhere (which there isn't), hence you always get 601. It is important to realize this: if you feed YUY2 from your capture device to Ut video you will always get 601 and choosing the 709 Ut variant over the 601 one does *not* change this.

[ChiDragon]

I am capturing some analog hi8 and vhs footage using ATI usb 600 svideo input into vdub and compressing with UtVideo.

There are audio sync issues depending on the lossless codec used and to get closest audio sync with UtVideo I set vdub capture timing options to sync audio to video by resampling the audio to a faster or slower rate and check correct video timing for fewer frame drops/inserts and audio latency determination automatic with 300 audio blocks to use at start.

Don't do that. The ATI 600 USB device captures audio internally; that option should be disabled. There is something else wrong with your setup (like capturing without a TBC, leading to frame drops).

Albeit the "assume interlace video" option in Ut Video is only for resampling color spaces which you should avoid and therefore the option is more or less irrelevant

Really? I assumed it optimized compression for interlaced sources, like the Huffyuv option.

http://wiki.multimedia.cx/index.php?title=HuffYUV#Interlaced_images

[juGGaKNot]

When i open a ut video in vegas and render it without change ( vegas preview screen says "no recompression" ) the output is bad :

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/th_bug_zps0cdb652b.png (http://s286.photobucket.com/user/juGGaKNot4cs/media/bug_zps0cdb652b.png.html)

If i edit it ( i usually crop 2 pixels on all videos ) the output is ok.

mkv > FFVideoSource avs > vdub > utvideo-13.2.1-win ( "predict left" ) > sony vegas > utvideo

77 videos, any unedited one output = same as the picture up there.
If i apply a crop = all videos ok

Problem at my end ?

[Atak_Snajpera]

what is resolution reported in vdub? most likely it is not mod4.

[juGGaKNot]

what is resolution reported in vdub? most likely it is not mod4.

Codec ID : ULRG
Codec ID/Info : Ut Video Lossless Codec
Codec ID/Hint : Ut Video
Duration : 35s 744ms
Bit rate : 118 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps

Original and output are the same resolution, 720p

Looks ok in vdub, if i open it in vegas and render as ut again looks bugged. If i crop in vegas before rendering it looks ok. I crop all the sides ( aspect ratio locked ) not just vertical crop ( and this is just for that 1 pixel border ).

[Lenchik]

Does anyone have contact of developer of these codecs? Can we ask him to add support for YV24, please? Maybe he is planning it already?

[zerowalker]

You can try ask in his blogg.
Sadly i don´t think you know automatically if he answers.
But i believe his has answered me when i checked, though it took awhile, and i think he answered in Japanese.
At least i think he did answer;S

[Keiyakusha]

There's no need for YV24 when there is RGB(A)
Any source you produce yourself is RGB(A) so keep it this way. Every source you get from bluray, dvd and such is 4:2:0 or 4:2:2.

[Lenchik]

Even if the source is MJPEG screencapture with 4:4:4 color preservation? AFAIK YUV > RGB > YUV is not lossless.
However i don't know if there is difference for UTVideo RGB(a) in YV24 and RGB source.

[nevcairiel]

Your screen is already RGB, so you should keep it RGB and encode it like that. :)

[poisondeathray]

Yes for screen captures you should use RGB

But if you still need a lossless YV24 codec for your previous capture, ffmpeg's implementation of FFV1 supports YV24 now . But it's seek/decoding performance is sluggish compared to UT Video

[Keiyakusha]

Even if the source is MJPEG screencapture with 4:4:4 color preservation? AFAIK YUV > RGB > YUV is not lossless.
However i don't know if there is difference for UTVideo RGB(a) in YV24 and RGB source.

I really don't see why would you want to convert mjpeg into UTvideo. If your goal is to use utvideo as an intermediate format for editing (which is one of its main goals) then mjpeg isn't any worse and you can just keep it as is. It should be super fast too! Otherwise converting it to UTvideo will only result in increased filesize and nothing else.
Of course going YUV4:4:4>RGB will result in some loses. But seeing how you used mjpeg to begin with, loses from this conversion will be so small, you can assume there is none. So if you still need utvideo fir some reason, you can still go with RGB.

[Atlantis]

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?

[WorBry]

Looks like you have done it !

Probably others could explain the jerkiness, but why would you want to use ffms2 anyway, since you clearly have the vfw UT-Video codec suite installed and you don't have any problems with the AVISource to x264 transcode. Can't imagine it's a question of speed as the vfw UT-Video decompressor is darn fast (Left prediction especially). And if you've generated the avs script with the MeGUI AVS Script Creator tool why even bother with the extra (ffms2) indexing step if it loads directly as an AVISource?

[Atlantis]

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?