Have DV captured off VHS that I'm converting to HD dimensions. Below I've made screen caps of the stages of the process - the ratio is slightly different because of dimension changes using HuffYuv but that's not the issue. During the process the color changes - there's a big difference between 1) and 4) - the image becomes darker. My goal is to retain the basic look of the original.
Thanks for all input.
1) The original interlaced DV avi
2) Cleaned with NeatVideo and converted to Huffyuv with Virtualdub. Still interlaced. Colorspace is now RGB but it still looks basically the same.
3) Deinterlaced with QTGMC within Virtualdub - the basic look is still the same.
4) Resized to 1080p using Vegas Pro 8 - resized here for space considerations. Here's where things change.
Clearly there's a significant difference between 1 and 4 - again I'm talking about the color/contrast not the dimensions.
![]()
![]()
+ Reply to Thread
Results 1 to 26 of 26
-
Last edited by brassplyer; 31st Dec 2014 at 21:54.
-
Hard to tell from those pictures if (the level of) noise suppression is warranted, second I do not understand why you throw away 50% of information by discarding half of the frames during deinterlacing. Resizing is generally not a good idea as you cannot restore anything that is not there.
It is probably best if you download a few frames in video format for each stage if you want to have feedback because those scaled images do not tell enough. -
You didn't change the colorimetry/color matrix when changing to Hi-Def? Also, it looks like the levels changed, maybe something you did or didn't do in Sony Vegas.
The end result looks better to me as the source looks a bit washed out, but maybe that's because I'm on an uncalibrated monitor at the moment. -
For internet compatibility.
Resizing is generally not a good idea as you cannot restore anything that is not there. -
Nothing that I deliberately set but I allow for the possibility that there's some setting in Vegas I'm not aware of.
The end result looks better to me as the source looks a bit washed out, but maybe that's because I'm on an uncalibrated monitor at the moment.Last edited by brassplyer; 31st Dec 2014 at 23:34.
-
It's a rec.601 vs. pc.709 contrast stretch and color matrix.
Last edited by jagabo; 31st Dec 2014 at 23:42.
-
If you are downloading to Youtube, Youtube now supports 50/60fps (but only for HD sources).
While I agree that youtube HD has a higher sound bitrate (128 vs 384) the quesiton is if that is going to matter much if the sound is taken from a VHS tape.
However for video do you have any tests that backs up your suggestion that upscaled HD shows better that SD on Youtube?
According to various sources:
SD 480p on Youtube is 2500 kb/s thus that translates in an effective compression level of 0.123
HD 720p on Youtube is 5000 kb/s thus that translates in an effective compression level of 0.184
Granted upscaled material might compress better but still, the difference is significant.
-
Wasn't aware of that. The last time I looked at their encoding specs it said 30fps.
While I agree that youtube HD has a higher sound bitrate (128 vs 384) the quesiton is if that is going to matter much if the sound is taken from a VHS tape.
However for video do you have any tests that backs up your suggestion that upscaled HD shows better that SD on Youtube?
Look at any decent upconverted HD video on youtube at one of the lesser SD settings vs HD. -
-
-
-
For improved accuracy of color, 32bit. Which did you use?
******************
I have yet to be even remotely convinced. Most attempts I have seen have been sophomoric attempts to compare apples to oranges without even realizing they are not being objective nor using good scientific/critical method nor implementing valid troubleshooting comparisons.
Scott -
After seeing SO many threads like this I still say "The man who represents(upscales) himself has a fool for a client."
-
I downloaded image #3 and named it qtgmc.jpg, and image #4 and named it vegas.jpg. Then ran this script:
Code:q=ImageSource("qtgmc.jpg").Subtitle("qtgmc") v=ImageSource("vegas.jpg").BilinearResize(q.width,q.height).Subtitle("vegas") last=q ConvertToYV12(matrix="pc.709") ConvertToRGB24(matrix="rec601") Blur(0.5) Subtitle("qtgmc modified") Interleave(q,v,last)
-
So it's both a PC/TV-Levels mismatch as well as a 601/709 colorimetry mismatch.
Vegas internally works in RGB so it will convert anything you import to RGB by itself unless it's already in RGB. So you should convert to RGB using AviSynth before you import the video in Vegas to avoid it's misinterpretation. However, all you do in Vegas is resize?! Why don't you do that in AviSynth?Last edited by Skiller; 1st Jan 2015 at 08:19.
-
-
I've posted several tests in the past that show the difference in upscaling for YT, I think a few were posted in this forum. It's the one of the few situations that you can make a case for upscaling. This might not be valid now or maybe something changed recently on YT ?
SD is SD, but the reason upscaled version looks better is both bitrate allocation and encoding settings are better for HD videos for YT. Similar to how they allocate more bitrate to audio when you upload HD .
But it's not 384kbps for audio is it ? I've never got that high, the difference might be something like 190-200 vs. 120-130 kbps for audio. And I've never got 2500kbps for SD video on YT? WTF? So maybe something has changed ? Or maybe those bitrates are what they want you to upload? (recommended upload settings? )
I'll try to dig up the examples if you guys are interested, but I'm not sure how valid they are anymore -
As I test I took a 562KB 640x480 PNG file
and uploaded it uncompressed to Youtube:
http://www.youtube.com/watch?v=3tbkNV9oV2w
Then I upconverted the original PNG file into a 2483KB 1920x1440 PNG file
and uploaded it uncompressed to Youtube:
http://www.youtube.com/watch?v=jLmZpmH1v34
Retrieving both videos gave me file sizes of: 71 and 209 KB.
For the SD video the compression rate is 7.92 while for the HD video this rate is 11.88.
The resulting files retrieved from Youtube are here:
480 Test.mp4
Upconverted 480 Test.mp4
If we then 'difference' the original files with the returned video the result is dramatically worse for the upconverted case.Last edited by newpball; 1st Jan 2015 at 16:27.
-
Do you think random noise would be a "typical" upload for YT ? The compression characteristics would be different than "normal" content
Here is one, quality is pretty shitty, it was upscaled DV but that's going to be "typical" for these SD uploads. Like the OP , it was deinterlaced with QTGMC , upscaled similarly to the OP. I can't find the thread where it was discussed - I think the topic was bitrate distribution by appending still segments vs. all action or something like that. That's why there are those stupid titles if you look at the video
You can tell from the old YT viewer, that is old (2010)
480p 2010
720p 2010
I found the original file on an old HDD. 2015 reupload, does YT treat it any differently?
http://youtu.be/zgbAI5tjEKQ
480p 2015
720p 2010
You can download the actual video versions and compare offline if you want. Interesting that no audio was uploaded, but YT encoded blank AAC audio for both. 192kbps vs. 126kbps
In this test, the fine details are retained more, like the patterns on the vest. The dark areas and background details seem to be retained more as well, instead of being smudged away
mediainfo 480p
Code:Format : MPEG-4 Format profile : Base Media Codec ID : isom File size : 1.87 MiB Duration : 20s 108ms Overall bit rate : 782 Kbps Encoded date : UTC 2015-01-01 22:35:34 Tagged date : UTC 2015-01-01 22:35:34 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : Main@L3.0 Format settings, CABAC : Yes Format settings, ReFrames : 3 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 20s 41ms Bit rate : 654 Kbps Width : 854 pixels Height : 480 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.064 Stream size : 1.56 MiB (83%) Encoded date : UTC 2015-01-01 22:35:34 Tagged date : UTC 2015-01-01 22:35:34 Audio ID : 2 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC Codec ID : 40 Duration : 20s 108ms Bit rate mode : Constant Bit rate : 126 Kbps Channel(s) : 2 channels Channel positions : Front: L R Sampling rate : 44.1 KHz Compression mode : Lossy Stream size : 308 KiB (16%) Encoded date : UTC 2015-01-01 22:35:31 Tagged date : UTC 2015-01-01 22:35:31
mediainfo 720p
Code:Format : MPEG-4 Format profile : Base Media / Version 2 Codec ID : mp42 File size : 3.52 MiB Duration : 20s 62ms Overall bit rate mode : Variable Overall bit rate : 1 473 Kbps Encoded date : UTC 2015-01-01 22:35:55 Tagged date : UTC 2015-01-01 22:35:55 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L3.1 Format settings, CABAC : Yes Format settings, ReFrames : 1 frame Format settings, GOP : M=1, N=60 Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 20s 40ms Bit rate : 1 279 Kbps Maximum bit rate : 2 943 Kbps Width : 1 280 pixels Height : 720 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.056 Stream size : 3.06 MiB (87%) Tagged date : UTC 2015-01-01 22:35:55 Audio ID : 2 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC Codec ID : 40 Duration : 20s 62ms Bit rate mode : Variable Bit rate : 192 Kbps Maximum bit rate : 201 Kbps Channel(s) : 2 channels Channel positions : Front: L R Sampling rate : 44.1 KHz Compression mode : Lossy Stream size : 470 KiB (13%) Title : IsoMedia File Produced by Google, 5-11-2011 Encoded date : UTC 2015-01-01 22:35:55 Tagged date : UTC 2015-01-01 22:35:55
bits / pixel or similar metrics are usually frowned upon, because the compression curve relative to frame size is non linear (ie you don't need 2x more bitrate for 2x as many pixels to achieve a certain level of "quality" )
It's not demonstrated here in the screenshots, but another reason why 720p viewed at 720p (or 1080p viewed at 1080p) might look better is flash/YT upscaling algorithm is poor. By viewing the larger version, you "force" your upscaling method instead of relying on flash/YT. But regardless of up or downscaling algorithm , that 480p version clearly has details missing that the 720p version retainedLast edited by poisondeathray; 1st Jan 2015 at 17:22.
-
-
And these low level tests, such as test patterns, noise, luma ranges, chroma ranges are important to conduct. No arugment there
But the "upscaling" for youtube isn't so much about the antialiasing or upscaling itself. It's more about how YT handles HD material vs. SD material. It undergoes a different pathway, and gets different treatment leaving you slightly better results. This behaviour might change anyday - YT is always changing their behaviour and policies
Another interesting tidbit, is the 480p version of the 720p version, looks better than the 480p version of a 480p version upload. The difference isn't as large, but still present. -
-
haha so true....
Another question commonly asked is : if 720p HD looks better, what about going to 1080p or UHD ? I think 720p was determined to be the "sweet spot" for SD upscales , but it might need to be retested more thoroughly
Did you know you can rig your google drive to host videos as well? (basically free bandwidth). The original video un-reencoded can be streamed , but you lose some of the other reasons why people use YT (monetization, ads, hits/click through etc...) and if you get enough hits Google tends to shut it down . But for high quality version for a small audience it works -
it just looks better after upscaling it for YouTube i did tests myself as well, presented it here on forum , and nobody is trying to make a viewer a fool, it just looks better ...
for op, Vegas treats different videos differently, you might just apply "computer RGB to studio RGB" effect to bring levels down for your lossless or whatever it is you load into Vegas
and yes 720 should be enough, 1080 is not necessary -