You need to log-in to post in our forum. We encourage your participation but please keep your comments on topic and friendly.

HWS_Header

Welcome Guest 

Show/Hide Header

Welcome Guest, posting in this forum requires registration.






Pages: [1]
Author Topic: Best Practices for encoding / trans-coding Standard Definition content
DFoster
Administrator
Posts: 61
Permalink
Post Best Practices for encoding / trans-coding Standard Definition content
on: May 10, 2011, 22:18
Quote

Note: While 30 fps video playback is easily achieved with the Scala 5 since Release 2, it can be challenging to reliably achieve high quality 60 fps playback on most hardware. Scala is making significant changes to video playback so as to deliver higher quality 60 fps playback on a wide range of hardware. This will be available within the next few months.

In order to obtain the best visual results in Scala 5, it is necessary to encode video clips with the post-processing that is often done by dedicated video playback devices implemented at the encoding stage.

Encode / transcode the video file using these recommendations

Audio encoding:

Use MPEG-1, Audio Layer-II.

Down-mix 5.1 channel source material to 2 channel stereo.

It is generally recommended to keep the audio sample rate the same as the source material. However if you want to change it, for 48 KHz audio use either 192 Kbps or 224 Kbps CBR. For 44 KHz audio use: 128 Kbps, 160 Kbps or 192 Kbps CBR.

Video encoding:

Use MP@ML

720x480 @ 59.94 fps for NTSC. 720x576 @ 50 fps for PAL

Bit Rate: 6 to 8 Mbps CBR. You can use up to 9.8 Mbps CBR for very high-motion content.

Aspect Ratio: 4:3

DC Component Precision: 10-bits.

Note: If you want to reduce the effective bit rate required while maintaining visual quality you can try lowering the resolution of the horizontal scan line from 720 to 480 or 352 pixels and keep the 4:3 Aspect Ratio setting. You will often find that 480x480 4:3 NTSC video can be effectively encoded at 3-5 Mbps CBR with very good results.

De-interlace:

Apply a temporal-deinterlace filter. If the source material was originally film converted to NTSC video, apply an Inverse-Telecine deinterlace filter; this option is available on some video encoders / transcoders.

Time base Corrector (TBC)

If the source video is from a device that does not have a TBC, there will often be a flickering half-scan line at the top or the bottom of the video frames as captured with a TV tuner card. This causes two problems:

It is distracting / objectionable

It reduces the efficiency / video quality of the video encoding process.

To resolve this issue, place a crop and expand filter to the video.

For example: A video with a 1/2-scan line at the bottom of the frame - crop the 720 x 480 video to 720x [1..478] and then resize the 720x478 frame back to 720x480 with Lanczos or Bi-Cubic Interpolation.

High-Frequency Video Noise

Apply a filter to minimize high-frequency video noise. This is needed especially if the source video is from older tape stock or has poor lighting conditions. This step often dramatically improves the quality of the resulting encoded video.

High-Frequency Audio Noise

Apply a filter to minimize high-frequency audio noise. This reduces tape hiss, circuit hum or wind noise.

Potential Issues

Judder

Judder is an artifact that appears to the viewer as uneven motion or a periodic hiccup in the motion of what should be smooth panning or translation scenes.
One common cause of judder is a mismatch between the video file's encoded frame rate and the monitor's refresh rate. This symptom is often confused with motion compensation artifacts.

Examples when this can occur:

1. Film source, 24 fps, displayed at 29.97 fps, with poor, or no, 3:2 pull-down correction. Poor meaning a video file created from multiple sources - each of which had 3:2 pull-down applied independently and the resulting video has multiple mismatched 3:2 sequences.

2. For NTSC, a frame-rate of 29.97 or 59.94, video displayed on a computer monitor at 60, 70, 72, 85 fps.

3. For PAL, a frame-rate of 25 fps or 50 fps video displayed on a "Computer Monitor" at 60, 70, 72, 85 fps.

Solutions:

Use an advanced transcoder with "blending" frame rate correction. This product converts the video's frame rate to the desired destination rate. An example encoder that does this: Canopus / Grass Valley ProCoder 3.

For NTSC, use a display device that can natively display 59.94 Hz.

For PAL, use a display device that can natively display 25, 50, 75, or 100 Hz.

If you do not have the ability to set the display refresh to match the above recommendations, it is better to transcode the NTSC or PAL source material to the appropriate intended native frame rate and to set the video card on the computer to match that rate exactly.

Variable Bit Rate Encoding

Variable Bit Rate (VBR) encoding is attractive from an encoding efficiency / resulting file size perspective. For example: Setting the "typical" bit rate to, 6 Mbps and the encoder can use up to a predefined (+/-) bit-rate % for simple and / or complex scenes. As a result a 6Mbps VBR file will often have the appearance of a 12Mbps CBR file but is only half file size.

The problem with VBR video decoding is that it uses substantially more CPU than the equivalent CBR video. In cases where decoding a video pushes the CPU to its performance limits, decoding a VBR video may interfere with other running components in the system, but decoding an equivalent CBR video will work just fine.

The default settings for many encoders is to permit up to a 10:1 swing in bit rates from one Group Of Pictures (GOP) to the next group of pictures (up to the profile maximum with no real minimum value). This can result in a 2 Mbps VBR video going from 1 Mbps to 10 Mbps.

The solution to this is to use Average Bit Rate (ABR) encoding instead. This provides controls for the amount of bit rate variation by setting the maximum and minimum bit rate to be no more than 50% of the desired ABR. For example: An ABR of 6Mbps with an 8Mbps ceiling and a 4Mbps floor.

Pages: [1]


Mingle Forum by cartpauj
Version: 1.0.34 ; Page loaded in: 0.031 seconds.

Comments are closed.