Hi folks, I apologize if this is in the wrong place.
I am using this workflow: http://www.bubblevision.com/underwater-video/Vegas-YouTube-Vimeo.htm
on ps2 footage captured from a Hauppauge HD PVR (I'm guessing this may be part of the problem, this seems to be aimed at cameras and the like).
On scenes in the game with long, slow movement, colors in the final render become blocky and "stuck". They eventually "reset", resulting in a noticeable "bump" in the color of the background. Here are some relevant screenshots:
source .M2TS File straight from the capture card:
here is an image of the playback of the final MP4 in VLC:
As you can see the picture has accumulated some blocks
here is a second later, when everything has snapped back to correct color:
I am working on a test video to illustrate this but it will take a few, as I am on the way out the door at the moment.
I have no idea what could be causing this, but it's a real drag. I am trying to use the 64 bit versions of all the AviSynth plugins from the workflow I posted, however I'm guessing I may have botched the installation. Here is my AviSynth plugins folder:
And a look at my H264 settings (perhaps 2 pass rendering is to blame? Not sure, still testing)
I would appreciate any insight anyone can give me, and I tried to make the process as easy as possible, with lots of information and screens.
+ Reply to Thread
Results 1 to 19 of 19
Last edited by Deadpangold; 11th May 2012 at 17:37.
Ah, actually, I seem to have fixed it.
While I made this post, I was rendering a test out with the settings posted above. The only thing I had changed was the deblocking value - I had previously left it at 0. (So to clarify, the screenshots are with --deblock 0:0)
I guess I'll render out a final "test" video, one with deblocking on and one with it off and see if people see the same thing I see.
Why are the colors and levels so different between the original M2TS file and video you encoded?
You should switch to CRF encoding. It's faster and you always get the quality you specify. There's no guessing what bitrate is required for each video.
My understanding is that that's the result of converting to YV12.
Last edited by Deadpangold; 11th May 2012 at 17:36.
Oh, I just noticed there's a "interlaced=true" line in the ConvertToYV12... I'll fix that
with that, I assume this is correct? :
(set up AviSource)
#Leave out AssumeTFF since source is progressive
#Leave out Lanczos Resize height and width, resolutions are already correct via sony vegas crop
#Leave out QTGMC, source is progressive
#Leave out ColorYUV(levels="PC->TV") as per this line in the workflow tutorial:
You could leave out the line ColorYUV(levels="PC->TV") and instead use Rec709 in the 2nd line of your script. i.e. ConvertToYV12(interlaced=true, matrix="Rec709". The end result will be very similar
No, I guess we're not. I thought you meant the THIRD picture, which is how it's supposed to look.
The second picture occurs sporadically, that was my question, "why is this happening sometimes".
My point was that if your source looks like the first picture, and your encoded video looks like the second and third pictures, you have a severe problem. Not just a conversion matrix or encoder problem.
Last edited by jagabo; 11th May 2012 at 20:06.
That's better but it still looks nothing like your first picture. Look at the darkest blacks. In the first picture they're near pure black (RGB~=5). In all the other pictures they're gray, RGB~=30 in the second and third pictures, RGB~=20 in the fourth picture. Is this just because the scene changes (your posting different frames in every picture) or a result of your processing? If the black level difference isn't obvious to you, you should calibrate your system.
For PS2 console, try Virtualdub with UT video Codec (YUY2).
After record use QTGMC to deinterlace and use a AAA script. The image will look awesome.
Last edited by Cauptain; 11th May 2012 at 20:43.
Seems to be so, yeah. Render came out looking like that.
As it turns out, the "flickering, random color that pop back to normal" still happens, but I believe it only occurs in VLC.
Opening the file in WMP does not cause the problem, and it looks fine on youtube as well.
VLC has always been an odd duck for me this way, that's why I wasn't surprised about the colors - I was thinking 'well yeah, it's a little bright, but it's VLC. I'm more concerned about the flashing".
Anyway, thank you very much for being patient and helping me work out the accurate colors. I may be following this "Videophile" guide for rendering, but as you can tell, I don't have the best eye.
I'm serving the frames from sony vegas via Debug Frameserver. The intention being to keep the edits I make in vegas (timeline movement, audio levels, text bumpers for information, silly pictures I decide to drop on top of the picture stream when I'm drunk).
I'm only doing it this way because I have heard Sony's AVC is alright but not GREAT (and it doesn't offer 60 FPS)
Also, saving the editted video in lagarith would create a huge file that I would then have to put in meGui's script maker (and have taking up space)
If you use vegas in 8-bit mode, most native camera formats like AVCHD, will use "studio RGB", so full range YUV => RGB conversion. So when you frameserve RGB out, you need to convert to YV12 using PC.709 matrix to expand the levels back to "normal" . YV12 using Rec matrix will show picture with elevated black level, looks "washed out" (like your screenshot"
But there are dozens of different reasons why you could be having problems. Renderer, GPU settings, method of taking screenshots
Yes, using ConvertToYV12(interlaced=false, matrix="PC.709") should bring the black level down (and the white level up) to match the original video.