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. |
|
|
Thread Tools | Search this Thread | Display Modes |
25th April 2018, 18:43 | #621 | Link |
Big Bit Savings Now !
Join Date: Feb 2007
Location: close to the wall
Posts: 1,545
|
10 Years ! Congratulations & many thanks !
Time for a donation ! Done.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain) "Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..." |
26th April 2018, 04:13 | #622 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
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 04:27. |
4th June 2018, 17:04 | #623 | Link |
Unregistered User
Join Date: Feb 2015
Location: Tokyo, Japan
Posts: 86
|
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
|
21st July 2018, 20:03 | #624 | Link |
Unregistered User
Join Date: Feb 2015
Location: Tokyo, Japan
Posts: 86
|
Version 20.1.0 is released
Version 20.1.0 is released.
New features
License (GPLv2) / readme / Windows (exe) / source code / GitHub Last edited by umezawa_takeshi; 24th September 2018 at 14:15. Reason: fix typo |
13th January 2019, 17:02 | #625 | Link |
Unregistered User
Join Date: Feb 2015
Location: Tokyo, Japan
Posts: 86
|
Version 20.2.0 is released
Version 20.2.0 is released.
Performance Improvements
License (GPLv2) / readme / Windows (exe) / source code / GitHub |
11th March 2019, 20:00 | #626 | Link |
Registered User
Join Date: Oct 2009
Posts: 930
|
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. |
11th March 2019, 23:52 | #627 | Link |
Registered User
Join Date: Oct 2009
Posts: 930
|
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% |
12th March 2019, 00:36 | #629 | Link |
Registered User
Join Date: Oct 2009
Posts: 930
|
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. |
12th March 2019, 15:41 | #631 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
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 ? |
12th March 2019, 16:08 | #632 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
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 |
|
12th March 2019, 19:20 | #633 | Link | ||
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
Quote:
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. |
||
12th March 2019, 20:24 | #634 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
Another person in another forum reported the slow VFW speeds too, that's why I'm double checking this Quote:
And if I pipe gbrp directly I get ~200fps , since ffmpeg doesn't packed rgb to planar rgb conversion |
||
13th March 2019, 01:29 | #635 | Link | ||
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
VFW I could only check by looking at the CPU usage graph, but wasn't as impaired as ffmpeg in RGB. 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. 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...) |
||
13th March 2019, 02:20 | #636 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
Quote:
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. |
||
15th March 2019, 15:04 | #637 | Link |
Unregistered User
Join Date: Feb 2015
Location: Tokyo, Japan
Posts: 86
|
Version 20.3.0 is released
Version 20.3.0 is released.
Performance Improvements
License (GPLv2) / readme / Windows (exe) / source code / GitHub |
15th March 2019, 15:21 | #638 | Link | |
Unregistered User
Join Date: Feb 2015
Location: Tokyo, Japan
Posts: 86
|
Currently, no.
Quote:
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. "Pro" variants support higher bit depth and less functionality. Recent FFmpeg/Libav use their own implementation. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|