Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th April 2018, 19:43   #621  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 687
10 Years ! Congratulations & many thanks !
Time for a donation !
Done.
__________________
Die toten Augen von Friedrichshain: "Data reduction ? Yep, Sir. We're working on that issue. Synce invntoin uf lingöage..."
"To bypass shortcuts and find suffering"...no, it was somehow different...
Emulgator is offline   Reply With Quote
Old 26th April 2018, 05:13   #622  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,134
Quote:
Originally Posted by Emulgator View Post
10 Years !
Suddenly I feel old.

Yep, UTVideo has come a long way from those humble beginnings. Thanks for all of your work and dedication.
__________________
Nostalgia's not what it used to be

Last edited by WorBry; 26th April 2018 at 05:27.
WorBry is offline   Reply With Quote
Old 4th June 2018, 18:04   #623  |  Link
umezawa_takeshi
Unregistered User
 
Join Date: Feb 2015
Location: Tokyo, Japan
Posts: 59
Lossless Video Codec Benchmark 2018-06

I did benchmarking about one and a half years ago. Since UtVideo is enhanced in this period, I do benchmarking again.

Please see
umezawa_takeshi is offline   Reply With Quote
Old 21st July 2018, 21:03   #624  |  Link
umezawa_takeshi
Unregistered User
 
Join Date: Feb 2015
Location: Tokyo, Japan
Posts: 59
Version 20.1.0 is released

Version 20.1.0 is released.

New features
  • UQRG: Add suppport of r210 input/output.
Bug fixes
  • all: Wrong behavior in encoder configuration resetting process.
  • UQxx: May crashed if video width is not multiple of 8.
  • UQRG: Alpha value is wrong in b64a output.

License (GPLv2) / readme / Windows (exe) / source code / GitHub

Last edited by umezawa_takeshi; 24th September 2018 at 15:15. Reason: fix typo
umezawa_takeshi is offline   Reply With Quote
Old 13th January 2019, 17:02   #625  |  Link
umezawa_takeshi
Unregistered User
 
Join Date: Feb 2015
Location: Tokyo, Japan
Posts: 59
Version 20.2.0 is released

Version 20.2.0 is released.

Performance Improvements
  • ULxx: Speed up encoding on x64.

License (GPLv2) / readme / Windows (exe) / source code / GitHub
umezawa_takeshi is offline   Reply With Quote
Old 11th March 2019, 20:00   #626  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 834
Hi!

Is there an ecoding guide around? There are so many variants now... Should I use RGB or YUV444? Does the latter entail quality loss?
How is the T2 variant different? Is the "pro" codec only different in encoding in higher bit depth?

PS:
By the way, does ffmpeg have it's own implementation or uses original codec?

Last edited by mzso; 11th March 2019 at 23:39.
mzso is offline   Reply With Quote
Old 11th March 2019, 23:52   #627  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 834
I've been testing with ffmpeg. Is it normal for 444 to be so much faster with much better multi-processing utilization? It's close to five times faster.
YUV444:
Code:
Output #0, matroska, to 'ut-444.mkv':
  Metadata:
    encoder         : Lavf58.25.100
    Stream #0:0: Video: utvideo (ULH4 / 0x34484C55), yuv444p(pc, bt709/bt709/unknown), 1600x1200, q=2-31, 200 kb/s, 50 fps, 1k tbn, 50 tbc (
default)
    Metadata:
      DURATION        : 00:01:44.980000000
      encoder         : Lavc58.43.101 utvideo
frame= 1815 fps=169 q=-0.0 Lsize= 2247617kB time=00:01:44.96 bitrate=175422.1kbits/s speed=9.75x
video:2247527kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.004034%

RGB:
Code:
Output #0, matroska, to 'ut-rgb.mkv':
  Metadata:
    encoder         : Lavf58.25.100
    Stream #0:0: Video: utvideo (ULRG / 0x47524C55), gbrp, 1600x1200, q=2-31, 200 kb/s, 50 fps, 1k tbn, 50 tbc (default)
    Metadata:
      DURATION        : 00:01:44.980000000
      encoder         : Lavc58.43.101 utvideo
frame= 1815 fps= 37 q=-0.0 Lsize= 2427476kB time=00:01:44.96 bitrate=189459.8kbits/s speed=2.16x
video:2427386kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.003734%

mzso is offline   Reply With Quote
Old 12th March 2019, 00:02   #628  |  Link
richardpl
Registered User
 
Join Date: Jan 2012
Posts: 75
That may be because of on which compiler it was build. Looks like auto-vectorizations are not enabled when using gbrp conversion within swscale is slow.
richardpl is offline   Reply With Quote
Old 12th March 2019, 00:36   #629  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 834
I also noticed a problem. I couldn't play back the 444 file with MPC or PotPlayer. I only got a black screen with the loaded ULH4 Decoder DMO filter.
Apparently LAV doesn't support this format. Because for RGB LAV loads and the video plays fine.
mzso is offline   Reply With Quote
Old 12th March 2019, 00:38   #630  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 834
Quote:
Originally Posted by richardpl View Post
That may be because of on which compiler it was build. Looks like auto-vectorizations are not enabled when using gbrp conversion within swscale is slow.
Huh. Oh well. Not much I can do about that. I don't compile builds myself.
mzso is offline   Reply With Quote
Old 12th March 2019, 15:41   #631  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,722
Actual encode speeds for the VFW/VCM version seem slower than they should be (compared to say, ffmpeg)

eg. 1920x1080 4:2:0 to ULH0 (709), blankclip in avisynth to prevent source decoding bottleneck (check with avsmeter, ffmpeg, ssd to reduce any I/O bottleneck . Tried with vdub, vdub2 , or avs2avi CLI . Tried older UT Video codec versions . Tried other fourcc (ULY0, 601) .

Looks like a threading issue in task manager . Maybe ~60-65fps . But magicyuv VFW/VCM same setup might get 3x the speed (and -c:v utvideo in ffmpeg about 3x the speed) both look to make use of threading more efficiently

Any ideas ? or what is the proper way to use VCM/VFW version ?
poisondeathray is offline   Reply With Quote
Old 12th March 2019, 16:08   #632  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,722
Quote:
Originally Posted by mzso View Post


RGB:
Code:
Output #0, matroska, to 'ut-rgb.mkv':
  Metadata:
    encoder         : Lavf58.25.100
    Stream #0:0: Video: utvideo (ULRG / 0x47524C55), gbrp, 1600x1200, q=2-31, 200 kb/s, 50 fps, 1k tbn, 50 tbc (default)
    Metadata:
      DURATION        : 00:01:44.980000000
      encoder         : Lavc58.43.101 utvideo
frame= 1815 fps= 37 q=-0.0 Lsize= 2427476kB time=00:01:44.96 bitrate=189459.8kbits/s speed=2.16x
video:2427386kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.003734%
maybe other bottleneck like decoding bottleneck ? What is your RGB source format ? What is the source decoding speed only ?

eg.
ffmpeg -i rgbsource.ext -an -f null NUL


I get about 5-6x faster for 1920x1080 RGB for actual encoding ULRG in absence of source decoding bottleneck
poisondeathray is offline   Reply With Quote
Old 12th March 2019, 19:20   #633  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 834
Quote:
Originally Posted by poisondeathray View Post
Actual encode speeds for the VFW/VCM version seem slower than they should be (compared to say, ffmpeg)
Huh? My experience is the polar opposite. FFmpeg is a lot slower. Not just with UT but with x264vfw as well.

Quote:
Originally Posted by poisondeathray View Post
maybe other bottleneck like decoding bottleneck ? What is your RGB source format ? What is the source decoding speed only ?

eg.
ffmpeg -i rgbsource.ext -an -f null NUL


I get about 5-6x faster for 1920x1080 RGB for actual encoding ULRG in absence of source decoding bottleneck
It's highly unlikely that the decoding source is relevant. CPU utilization wasn't near full. As you can see the core utilization is pretty poor also.
I deleted the files since then but the source was either an ultrafast preset AVC or another ut-video file. (from an SSD) Both decode really fast.

I guess richardpl may be right that ffmpeg is slow. (for whatever reason)

Last edited by mzso; 12th March 2019 at 20:03.
mzso is offline   Reply With Quote
Old 12th March 2019, 20:24   #634  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,722
Quote:
Originally Posted by mzso View Post
Huh? My experience is the polar opposite. FFmpeg is a lot slower. Not just with UT but with x264vfw as well.
What kind of speeds with UT VFW ? for 4:2:0 and RGB ?

Another person in another forum reported the slow VFW speeds too, that's why I'm double checking this


Quote:
Originally Posted by mzso View Post

I guess richardpl may be right that ffmpeg is slow. (for whatever reason)
Not for me. ~180fps for 1920x1080 rgb source encoding to UT RGB (ULRG)

And if I pipe gbrp directly I get ~200fps , since ffmpeg doesn't packed rgb to planar rgb conversion
poisondeathray is offline   Reply With Quote
Old 13th March 2019, 01:29   #635  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 834
Quote:
Originally Posted by poisondeathray View Post
What kind of speeds with UT VFW ? for 4:2:0 and RGB ?

Another person in another forum reported the slow VFW speeds too, that's why I'm double checking this




Not for me. ~180fps for 1920x1080 rgb source encoding to UT RGB (ULRG)

And if I pipe gbrp directly I get ~200fps , since ffmpeg doesn't packed rgb to planar rgb conversion
I didn't test everything only what I shared. Where RGB was a lot slower.
VFW I could only check by looking at the CPU usage graph, but wasn't as impaired as ffmpeg in RGB.

Quote:
Originally Posted by poisondeathray View Post
Not for me. ~180fps for 1920x1080 rgb source encoding to UT RGB (ULRG)

And if I pipe gbrp directly I get ~200fps , since ffmpeg doesn't packed rgb to planar rgb conversion
What sort of ffmpeg build are you using? Your own? I only ever use the zeranoe builds.

Do you check the resulting file? Without using out_color_matrix and out_range=pc the files are borked. appear with the wrong color and become limited ranged...
I made quick test.
With your cli I got: speed= 14x for the source file

ffmpeg -i D:\Felvétel\ePSXe_2019_03_12_13_02_25_790.mkv -an -vcodec utvideo UT-rgb.mkv:
frame= 1181 fps=131 q=-0.0 Lsize= 1817113kB time=00:00:59.68 bitrate=249401.7kbits/s speed= 6.6x

ffmpeg -i D:\Felvétel\ePSXe_2019_03_12_13_02_25_790.mkv -an -pix_fmt yuv444p -vcodec utvideo UT-444-borked.mkv:
frame= 1181 fps= 54 q=-0.0 Lsize= 1609549kB time=00:00:59.68 bitrate=220913.2kbits/s speed=2.71x

ffmpeg -i D:\Felvétel\ePSXe_2019_03_12_13_02_25_790.mkv -pix_fmt yuv444p -vf scale=out_color_matrix=bt709:out_range=pc -color_range pc -colorspace bt709 -color_primaries bt709 -vcodec utvideo UT-444-proper.mkv

frame= 1181 fps= 38 q=-0.0 Lsize= 1671630kB time=00:00:59.68 bitrate=229433.9kbits/s speed=1.94x

I guess I mixed up the results before. YUV is slower. And a lot slower still when using the scale options. I don't know what ffmpeg is exactly doing, but I think it scales pointlessly for me to get a proper result. Which seems superfluous since the source is already in a proper full range RGB format...
(Someone suggested using -vf scale for this when I was unable to encode proper full range video. I know of no other fix...)
mzso is offline   Reply With Quote
Old 13th March 2019, 02:20   #636  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,722
Quote:
Originally Posted by mzso View Post

What sort of ffmpeg build are you using? Your own? I only ever use the zeranoe builds.
I used zeranoe for those tests too

Quote:
Do you check the resulting file? Without using out_color_matrix and out_range=pc the files are borked. appear with the wrong color and become limited ranged...
I made quick test.
Yes. I removed those extraneous variables for the testing. You're confusing the test results, because of colorspace conversions and swscale. (ie. you're not just testing the utvideo encoding speed, but a bunch of other operations too - you have other bottlenecks)

e.g. If I wanted to test RGB encoding, I fed it RGB. If I want to test 8bit 4:2:0 , I fed it 8bit 4:2:0.

EDIT: and for YUV 444 (ULH4 , 709) , it's even faster than RGB input/encoding in ffmpeg , I get about 210-220 fps . It's a valid file (VLC doesn't support it, but it decodes corrrectly with potplayer, mpv, ut official decoder, ffplay etc...)



Why is VFW so slow for encoding ? I made sure to use "fast recompress" in vdub , and avs2avi feeds same colorspace .

There used to be known DEcoding differences . The ffmpeg encoded variant was about 2/3 the speed for decoding a few years back using the same decoder

Last edited by poisondeathray; 13th March 2019 at 03:02.
poisondeathray is offline   Reply With Quote
Old 15th March 2019, 15:04   #637  |  Link
umezawa_takeshi
Unregistered User
 
Join Date: Feb 2015
Location: Tokyo, Japan
Posts: 59
Version 20.3.0 is released

Version 20.3.0 is released.

Performance Improvements
  • ULxx: Speed up encoding to / decoding from native packed formats.
Others
  • ULxx: "Assume interlace video" is now non-recommended feature.
  • Deleted information in readme about QuickTime components, which are already discontinued practically.

License (GPLv2) / readme / Windows (exe) / source code / GitHub
umezawa_takeshi is offline   Reply With Quote
Old 15th March 2019, 15:21   #638  |  Link
umezawa_takeshi
Unregistered User
 
Join Date: Feb 2015
Location: Tokyo, Japan
Posts: 59
Quote:
Originally Posted by mzso View Post
Is there an ecoding guide around?
Currently, no.

Quote:
Originally Posted by mzso View Post
There are so many variants now... Should I use RGB or YUV444? Does the latter entail quality loss?
They are completelty lossless if and only if the input/output formats are same as its internal format. If not, they are lossless except colorspace conversion noise.

Quote:
Originally Posted by mzso View Post
How is the T2 variant different?
Compared to non-T2 variant,
* T2 is faster in most cases.
* T2 has temporal compression mode.
* T2's compression ratio is lower for noisy images and higher for something like CGs.

Quote:
Originally Posted by mzso View Post
Is the "pro" codec only different in encoding in higher bit depth?
"Pro" variants support higher bit depth and less functionality.

Quote:
Originally Posted by mzso View Post
By the way, does ffmpeg have it's own implementation or uses original codec?
Recent FFmpeg/Libav use their own implementation.
umezawa_takeshi is offline   Reply With Quote
Old 16th March 2019, 22:19   #639  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 834
@umezawa_takeshi
Thanks for the info.
mzso is offline   Reply With Quote
Old 19th March 2019, 16:59   #640  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 834
What effect does the temporal compression option has? Does it improve compression ratio (at the cost of or without significantly affecting performance?), or will it improve performance(at what cost?) ?
mzso is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 20:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.