View Full Version : Source codec question
neil wilkes
30th December 2013, 11:46
Just out of curiosity (and I hope this is in the right place) what is a good source codec to feed CCE-SP3 with please?
Second part of question - what is the difference between YUV2 and Aja 2vuy?
Final part - what is the difference between the YUV2/2vuy and RGB variants, and what is a good source to use for good results from CCE-SP3 please?
This is a project where the bitrates have to be very low indeed - around 3500 kbps and as low as 3000 kbps.
Many Thanks
mp3dom
30th December 2013, 13:52
Essentiallty whichever codec can be decoded in YUY2 colorspace by CCE is a good choice. Even if a codec supports YUY2, you can't be sure it's correctly decode as YUY2 in CCE. You need to look at the log CCE produces. It write down if the decode to YUY2 was successfully or not.
YUY2 and 2VUY(UYVY) are the same. It changes the way Y/U/V are stored but it's always an 8bit YUV video.
neil wilkes
30th December 2013, 15:39
Much appreciated.
What are the correct options for progressive source and interlaced out NTSC?
I leave "Output top field first" unticked and offset line to 0 - is this right?
I also disable the noise filters.
Tried the FAQ but it seems to talk much more about CCE2 rather than CCE3 (running version latest on servers 3.1.0.3 or something similar.....and I have some files to encode that will require a brutally low bitrate of around 3mbps maximum.
mp3dom
30th December 2013, 15:53
For progressive source you mean 23.98/24 fps as input or a 30p input? Better if you change also the Picture Type=Progressive in Window->Picture Settings. Save a new profile and apply it to your source. For 23.98/24fps you also need to enable the 3:2 pulldown to be dvd compliant (you can apply it afterwards with DGPulldown, but doing it inside CCE ensure that the final frame will not be a 'repeated' one, which create problems on authoring especially if you want to do seamless muxing between two videos)
neil wilkes
30th December 2013, 16:17
For progressive source you mean 23.98/24 fps as input or a 30p input? Better if you change also the Picture Type=Progressive in Window->Picture Settings. Save a new profile and apply it to your source. For 23.98/24fps you also need to enable the 3:2 pulldown to be dvd compliant (you can apply it afterwards with DGPulldown, but doing it inside CCE ensure that the final frame will not be a 'repeated' one, which create problems on authoring especially if you want to do seamless muxing between two videos)
This is excellent info - thanks for this.
It's timecode says 29.97DF Progressive Scan.
They started life as 1920x1080 HD at 25p, and we have had them converted to NTSC at 29.97DF Progressive (Pretty certain it's not progressive-segmented but not totally certain how to tell) and they are all signed off - only remains to run the MPEG-2 process from the source, which is Aja 2vuy 720x480 NTSC - what is good to check field orders with? I tried MediaInfo but it seems to get things wrong a lot.
mp3dom
30th December 2013, 20:10
If the original materials were 25p, unless they have converted to 30p via blend (which means totally unwatchable) there are possibilities that they have repeated 1 frame every 5 and slowed down a little to match the framerate. If this was the case, your best bet is to remove that 5th repeated frame, encode the file, and re-apply a soft pulldown. Since your bitrate is so low, you can gain something if you split the bitrate to a lesser number of frames.
Apart this, you can check the field order with avisynth and virtualdub. Import the video, add "AssumeXFF()" with X= T or B for Top or Bottom respectively, and add "Separatefields()". Watch it in Virtualdub. Check a portion where there's motion. If the motion is jerky your video has the opposite field order. If it's ok then you've selected the right field order.
I don't have the manual here, but as far as I remember, you can check the field order even inside CCE. Put a look at the 'deinterlacing' option.
kolak
30th December 2013, 20:25
This is excellent info - thanks for this.
It's timecode says 29.97DF Progressive Scan.
They started life as 1920x1080 HD at 25p, and we have had them converted to NTSC at 29.97DF Progressive (Pretty certain it's not progressive-segmented but not totally certain how to tell) and they are all signed off - only remains to run the MPEG-2 process from the source, which is Aja 2vuy 720x480 NTSC - what is good to check field orders with? I tried MediaInfo but it seems to get things wrong a lot.
AJA codec will be read by SP3 own engine, so this is good.
99% that your video is lower filed in this case. It will be probably Alchemist semi-interlaced conversion (field repeating approach), which is ok , but far from being perfect. Do you see interlacing lines (than progressive parts) when watched in QT player at 1:1 size?
Tick top field and offset=1.
SP3 can do similar fps conversion and end result won't be much worse than Alchemist's.
neil wilkes
31st December 2013, 13:16
Again, much useful info here and much appreciated.
The source is certainly not Alchemist done - no idea how our chap does it, but he always gets better results than Alchemist HD can but then again he has forgotten more than I know.
We sent various versions out of CCE for test, and the client picked the "Output TFF" unchecked, with offset line at 0.
What I was trying to ascertain is to learn if there is a way of making the results (how am I supposed to not use the word "better" FFS?).
Deinterlacing where motion present apparently done during the conversion from PAL SD to NTSC SD, and again when faced with multiple options, the version picked by client was the one where we went from 1920x1080/25P to 720x576/25p Anamorphic to 720x480/29.97DF NTSC Anamorphic, and not scaling and converting at the same time. At each interim stage the Aja 2vuy codec was used to maintain colour balance as far as possible.
No slowdown has happened at all - the resulting run times are identical in hh:mm:ss:ccc to the originals - this is an absolute condition as any sort of slow down or speed up is unacceptable.
How I wish people would shoot at the right frame rate to begin with though.
Thanks again - this has been very, very helpful
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.