![Scala - Digital Signage Software [Logo]](/images/layout_main.gif)
Video Quality Playback suggestions and issues.
InfoChannel Player 5 FAQ Solution #5, playback encode (last modified 08/14/2007):
Video Clip encoding:
Scala InfoChannel 5 Playback of video files does not currently implement any form of "post-processing"/"image enhancement" common to dedicated video playback devices. In order to obtain the "best" visual results in InfoChannel 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.
NTSC--In short:
Transcode the video file into a CBR 720x480p@59.94Hz***, 4:3 pixel-aspect ratio, MPEG-2 MP@ML System or Program Stream file:
Apply Filters:
(1) If the source video is from a "VHS Video Tape Player" that does not have a "Time Base Corrector"--often there will be a flickering "half-scan line" at the top or the bottom of the video frames as captured by the TV-Tuner card. This causes two problems:
a) It is distracting/objectionable.
b) It reduces the efficiency/video quality of the video encoding process.
To resolve this issue place a "Crop and Expand" filter to the video frames after step (3) (Example is a video with such a 1/2-scan line at the bottom of the frame: crop the 720x480 to 720x[1..478], and then resize the 720x478 frame back to 720x480 with Lanczos or Bi-Cubic Interpolation!).
(2) De-interlace: "Temporal-Deinterlace/"Blend". If the source material was originally film converted to NTSC video apply a "Inverse-Telecine" De-Interlace filter (this option is available on most of the better Encoders/Transcoders!).
(3) Filter high-frequency video noise especially if the source is from older video tape stock or a video camera under "low light" conditions. This is often dramatically improves the eventual quality of the resulting encoded image.
(4) Filter high-frequency audio noise to reduce "Tape hiss", "Circuit hum", or "Wind noise" effects on the eventual encoding efficiency of the audio track.
Encoding Data Rates:
Audio:
MPEG-1, Audio Layer-II.
Keep the audio sample rate the same as the source "down-mix" 5.1-Ch source to 2-Ch-Stereo: 192Kbps or 224Kbps CBR for 48KHz audio, 128,160,192Kbps Kbps CBR for 44KHz audio.
Video:
For NTSC/PAL source material of 720x480p(@59.94 Hz)/576p(@50 Hz). MP@ML typically at 6 to 8 Mbps CBR (up to 9.8 Mbps CBR for very high-motion content). Aspect Ratio:4:3.DC Component Precision: 10-bits.
A technique for lowing effective bit rate required while maintaining visual quality is to lower the resolution of a Horizontal Scan line from 720 to 480 or 352 pixels. 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.
Judder:
"Judder" is an artifact that appears to the viewer as "un-even-motion " or an occasional "hiccup-in-motion" of what should be smooth panning or translation scenes. Think watching a train moving by the camera or watching a pin-wheel spinning. This is caused by a miss-match of the recording, or encoded video frame rate and the display frame rate. This can be confused with a "Motion Compensation" artifact. Examples where this will happen:
Film-Source, 24fps, displayed at NTSC, 29.97fps, with poor/no 3:2 pull-down correction (poor == a video file created from multiple sources--each of which had 3:2 pull-down applied independently and the resulting composite video has multiple miss-matched 3:2-run sequences).
NTSC-frame-rate, 29.97 or 59.94, video displayed on a "Computer Monitor" at 60, 70, 72, 85 fps--this will range from very subtle at 60 fps to rather obvious at 70 fps. To avoid: with a CRT display device it is possible to, (with the appropriate video card--ATi RADEON X1K's are currently best), set the display rate at an _EXACT_ 59.94 Hz.
Lacking this ability when using LCD's or Plasma Panels it is better to transcode the NTSC source material to the appropriate intended destination display device's native frame rate and to set the video card on the computer to match this rate exactly (be that 60, 72, 85 Hz--whatever). PAL-frame-rate, 25fps, video displayed on a "Computer Monitor" at 60, 70, 72, 85 fps. The "best" solution is to have a display device that can natively display 25,50,75, or 100 Hz.
Lacking this ability when using LCD's or Plasma Panels it is better to transcode the NTSC source material to the appropriate intended destination display device's native frame rate and to set the video card on the computer to match this rate exactly (be that 60, 72, 85 Hz--whatever).
ATSC/HD content: Most current 1080p HiDef content is recorded at 24fps. Judder is a serious issue for most PDP/LCD display devices that are designed to only operate at either 59.94fps or 100fps. For the "critical observer" transcoding with frame-rate-correction/"blending" is the only practical solution.
Judder can also happen with perfectly encoded videos if for some reason a DirectShow decoder is erratic with its delivery times (which can happen when the system is under excessive CPU load), causing some individual frames to stay on screen longer or shorter than they should. Also, ~30p video will show judder in high motion areas because the frame rate is low enough that a human being can notice the frame changes. ~60i video that is played as progressive will also show the same judder (as well as interlacing artifacts) for the same reason.
"Best Practices" for encoding/transcoding ATSC or "HD" content:
MPEG-2 is the most CPU/system resource efficient format. Given CPU% decode requirements are on the order of 1/3-1/2 that of comparable visual quality HD-WMV9 or MPEG-4SP (1/4-1/3 that of MPEG4-H.264 or VC-1 in some cases!). Most 720p content is natively produced at 1280x720p@59.94 Hz. The options that should be considered for IC5 playback should be Frame-Rate-Correction--59.94 Hz to whatever is the native frame rate of the destination display device.
Produce CBR streams from what are often VBR sources. Most 720p content should be encoded at between 10 Mbps, "mostly still images", and 16 Mbps, "for Sports", CBR, MPEG-2, MP@HL (Audio as with normal NTSC video). Note: 720p HD content can be encoded as low as 8Mbit and still look half-decent. If you have enough free time, you should encode a few versions of your video and pick the best looking one. Maybe even 6Mbit will suffice.
Most 1080i content is 24fps film source that has been transcoded to either 1440x1080i or 1920x1080i @24 or 29.94fps --with a 16:9 or 2.11:1 Aspect Ratio. Transcode to 1080p at the frame rate of the destination display device encoding profiles should be:
MP@HL1440
MP@HL
HP@HL
at CBR bit-rates of between 16 Mbps and 38.4 Mbps.
"Variable Bit Rate" (VBR) encoding:
VBR is attractive from an encoding efficiency/resulting-file-size viewpoint. Set the "typical" bit rate to, for example 6 Mbps, and the encoder can use up to some-defined (+/-)bit-rate% for simple and/or complex scenes. So often a 6Mbps VBR file will have the appearance of a 12Mbps CBR file in only 1/2 the total file size.
VBR Problem:
On a General Purpose Computer with a Shared-CPU that is running the Host Operating System, the Player Application, Background Processes, and Video Decoding CODEC's is that it makes the "Video-Decoding" process extremely variable in its CPU% needs, and has a negative impact on every other component in the system. The default settings for many encoders permit up to a 10:1 "swing" in bit-rates from one "group-of-pictures" to the next "group-of-pictures"--up to the "Profile Maximum" with no real minimum value--this can result in even a, nominally 2Mbps VBR MP@ML MPEG-2, stream going from 1Mbps to 10Mbps.If VBR is desired--my suggestion is to actually use "ABR"--which provides for controls of the amount of bit-rate-variation and set the "minimum-bit-rate" and "maximum-bit-rate" caps to be no more than 50% of the desired "average-bit-rate" (example: ABR at 6Mbps with a 4Mbps floor, and an 8Mbps ceiling).
NTSC output devices--"TV-Broadcast":
Follow all of the standard NTSC design rules that have not changed in the past 50 years. Design your pages at 720x740@59.94 Hz or 1440x960@59.94 Hz (remember 59.94 Hz is *NOT* 60 Hz!!!).
Signal resolution and refresh: ATi video card, EnTech Taiwan PowerStrip3.x SW--to put the video card in the "proper" video mode: 720x480i@59.94 Hz; And a $700 CORIOscan NTSC Scan Converter. This will give what I would call a "College TV Station" quality result. You can get better by going with either a $4000 CORIOscan or a $7,000 Snell & Wilcox device--or Magni--those you can feed at 1440x960 progressive @ 59.94 Hz. This helps with line and column aliasing. Output from the Scan Converter into your RF-modulator.
Color and detail [0..255 RGB]:
Keep you black about 35 points off of baseline. Keep you whites at least 15 points off peak. Don't over-saturate your RED, and keep it 35 points off of peek. No more that 40 R/B or Blk/W transitions per scan line (Remember that NTSC "Red" is different than CRT Red--NTSC "Red" is basically a CRT "Orange"). Keep you vertical lines at least two pixels wide, and your horizontal lines at least three pixels thick. Try to avoid more than about 170 points of color component change in adjacent pixels.
Regards,
Scala Technical Support
