Interlaced video should be deinterlaced before it is encoded for a progressive live-streaming destination. The right output cadence depends on what the source actually sends and what the destination accepts: one frame per field can retain more motion detail, but it also raises the frame rate and processing load.
Start by identifying the source’s scan type, resolution, rate convention and field order. Then decide where conversion will happen and test the resulting picture and motion rather than applying a preset based only on a label such as “1080i”.
Recognise an interlaced source
A progressive frame contains image information for the whole picture at one point in time. An interlaced signal instead carries two fields, each containing alternating lines. Those fields are captured at different moments, so they include temporal information as well as different parts of the image.
That difference can be hard to see in a still frame. On a moving subject, however, simply combining the two fields can leave the edges of movement misaligned. The familiar result is comb-like horizontal teeth around a hand, face or fast-moving object. Other processing artefacts may appear depending on the source and how the fields are treated.
Do not infer scan type from the picture’s appearance alone. Check the camera, broadcast receiver, file metadata, capture-device status or source documentation. A file may be progressive even if it originated from an interlaced broadcast, and film-originated footage may need inverse telecine rather than ordinary deinterlacing. These are different source conditions and should not be treated as one generic conversion problem. AWS Elemental Live documents deinterlacing, inverse telecine and adaptive processing as distinct operations in its user guide.
If a capture device is involved, verify the exact mode it receives. A setting described as 1080i50 is not interchangeable with 1080p50: the former identifies an interlaced source convention, while the latter describes progressive output. Labels that combine resolution and rate can be ambiguous when they omit whether the rate refers to fields, frames or a system convention. Confirm what the equipment means before changing downstream settings.
Why deinterlace before encoding
If the required delivery path is progressive, deinterlace before encoding so later stages work with clean progressive frames. This matters not just to the final encoder but also to preview, overlays, compositing and any scaling or filtering performed along the way. If those stages receive unresolved fields, they may display or transform the source in ways that preserve or worsen interlacing artefacts.
Deinterlacing converts the field-based source into progressive frames. Broadly, a converter can produce one progressive frame from each pair of fields, or make a progressive frame from each individual field. The first choice results in fewer output frames; the second produces a higher output cadence and can retain more of the source’s motion timing. Neither choice can restore detail that the source never captured, and both depend on the quality of the processing method.
Avoid treating deinterlacing as a codec setting. It is a scan conversion step, separate from choosing a codec, container, bitrate or streaming destination. For example, OBS’s format documentation identifies H.264 as its default codec, but selecting a codec does not establish that an interlaced source has been converted correctly. Check the OBS formats guide for its own codec and container information, and separately confirm the destination’s current ingest requirements.
Do the conversion early enough that every downstream component sees the intended progressive signal. Depending on the workflow, that may happen in capture hardware, in the streaming application or in a live encoder. There is no guarantee that a device that accepts an interlaced input also performs deinterlacing, so establish which component owns the task.
Identify resolution, rate and field order
Before choosing output, write down the signal as it actually arrives: resolution, interlaced or progressive scan, field rate or frame-rate convention, and which field comes first. Also identify whether it is live camera or broadcast material, or film-originated content that may have been converted for television. This short inventory avoids trying to fix one problem with a setting intended for another.
Field order describes which field is temporally first. If software interprets the order incorrectly, the motion can appear to jump or judder even when the output is progressive. A deinterlacer cannot make an incorrect field-order assumption harmless. Check the source documentation or capture settings, and use a short test recording with clear movement to confirm the result.
The wording “1080i50” commonly appears in questions about whether to choose 1080p30 or retain an interlaced mode. It is a prompt to inspect the actual format, not an answer by itself. The OBS community discussion of 1080p30 versus 1080i50 is an older workflow conversation, not current authoritative guidance for every device or software version. Use current device documentation and your own signal readout to settle the format.
This check also prevents a common mismatch: selecting a progressive output number that looks familiar without knowing what the input rate describes. Keep source and destination labels explicit in your notes, such as “interlaced source, fields per second” and “progressive output, frames per second”. If a source is already progressive, do not run it through deinterlacing merely because the resolution resembles an interlaced mode.
Choose field-rate or lower-rate progressive output
The practical choice is often between one output frame per pair of input fields and one output frame per field. A lower-rate output can be appropriate where the destination cadence or available processing capacity calls for it. A field-rate output can preserve more temporal motion detail, particularly for live material, but creates more frames for later stages to process and encode.
| Conversion approach | Typical effect | Main trade-off |
|---|---|---|
| One progressive frame per pair of fields | Fewer output frames; a lower progressive cadence | Less temporal motion detail than a frame-per-field conversion may retain |
| One progressive frame per field | Higher progressive cadence, with more of the source’s motion timing represented | More frames to process and encode; verify capacity through the whole chain |
The examples in the AWS Elemental Live guide include 1080i30 to 1080p30 for a one-per-pair path, and rate-doubled examples such as 29.97 to 59.94 or 25 to 50 for one-per-field output. AMD’s Video Processing Subsystem deinterlacing guide also illustrates 1080i60 to 1080p60. Treat these as format examples, not as interchangeable interpretations of every “i” label. Confirm the rate convention of your own input before mapping it to an output.
Higher cadence has a real cost. A pipeline that previously processed fewer frames must now handle more frames through conversion, scaling, compositing and encoding. Check that capture, application and encoder remain stable under the chosen output mode. If the encoder is already struggling, the settings to check when YouTube reports an overloaded encoder are relevant to diagnosing load, but changing cadence should still be tested as a separate variable.
Processing method matters too. Spatial, temporal and motion-adaptive approaches make different choices about detail and movement; a more sophisticated label does not guarantee a better picture from every source. AMD’s guide explains the use of spatial and temporal processing to address artefacts. Evaluate moving edges and fine detail in a test rather than judging only a static frame.
Apply Apple’s HLS cadence guidance by source
Apple’s HLS authoring specification is specific guidance for authoring streams for Apple devices, not a universal rule for every platform. Apple says interlaced source content must be deinterlaced. For 30i content, it recommends 60p rather than 30p; for live NTSC/ATSC sources it recommends 60 or 59.94 fps, and for live PAL sources it recommends 50 fps. Read those recommendations in context on Apple’s HLS authoring specification for Apple devices.
The practical lesson is to map the source to the recommendation instead of applying “60p” everywhere. First establish whether the material is a live NTSC/ATSC or PAL source, and how its interlaced rate is expressed. Then check whether the destination is Apple-device HLS authoring or another ingest path. For a different platform, use that platform’s current documentation; Apple’s recommendation does not establish its requirements.
A 30i-to-60p recommendation reflects the field-rate approach: outputting a progressive frame for each field can preserve more motion timing than combining a field pair into a single 30-frame-per-second output. It also asks the processing and encoding path to handle the higher frame rate. Do not assume that the extra cadence is free, or that all capture hardware, software settings and encoders can sustain it in a particular workflow.
If you operate an always-on channel with a recorded lesson or ambience loop, the source may be progressive already, in which case Apple’s interlaced-source instruction is not a reason to convert it. For file-based loops, first check the source file and delivery chain; the discussion of formats for a YouTube 24/7 stream may help with the separate question of file compatibility. Scan conversion and file format are related workflow checks, but one does not substitute for the other.
Check capture and encoder signal handling
Choose the conversion point deliberately. Some capture hardware may deinterlace as it receives the signal; other devices may pass fields through; some may not support the exact source mode at all. Consult the manufacturer’s specifications for the resolution, rate and field order you intend to use, and confirm whether deinterlacing is performed by the device or must happen later. Do not assume that “capture card” implies support for every interlaced format.
If conversion happens in the streaming application, inspect its current source and output settings and confirm how the selected deinterlacing mode behaves. Software interfaces change, so an older forum thread or a familiar menu label should not replace current documentation. If conversion happens in a live encoder, verify both the input interpretation and progressive output settings. The chosen component should be the clear owner of conversion; accidental double processing can degrade detail.
Check the complete signal path: source, cable or receiver, capture device, application, encoder and destination. A device can report a progressive output while the application still receives an incorrectly interpreted mode, or the application can deinterlace while an upstream stage has already done so. A short test with motion is a better way to catch such a mismatch than relying on a single status indicator.
Keep the output settings consistent with the destination’s current requirements. Deinterlacing does not decide the codec, container or ingest compatibility. If you are also troubleshooting disconnects, distinguish those from scan conversion: the guide to firewall-related RTMP disconnects addresses a different failure path. A clean progressive picture cannot prevent a network session from dropping, just as a stable connection cannot correct combing.
Verify the delivered picture and motion
Make a short test before relying on a long-running broadcast. Include a moving subject, a slow pan, fine horizontal detail and a static scene. Inspect the captured output, not just the source preview, because an upstream preview may not show how the final encoder treats fields. Look for combing on moving edges, judder from incorrect field order, softness from conversion, or dropped and repeated frames under load.
Compare cadence choices using the same source segment and otherwise unchanged settings. If a one-frame-per-field output retains smoother motion but causes encoder overload or unstable output, the trade-off may not suit the current machine or destination. If lower-rate output is stable but motion looks less fluid, decide whether that is acceptable for the programme. Make one change at a time so you can tell whether the improvement came from scan conversion, scaling, encoder load or another setting.
Watch the stream from the destination as a viewer as well. A local preview can look correct while the delivered stream has a different cadence, scaling or compression artefact. For an always-on channel, check again after reconnects or restarts; settings that appear correct during a brief test can behave differently in an unattended run. A YouTube resolution drop after reconnecting is a delivery-quality issue worth separating from the original interlaced conversion decision.
Keep a short record of the source mode, field order, conversion point, progressive output rate and test result. That note makes it easier to restore a known-good configuration when a camera, capture device or software update changes the signal path. For a recorded loop, the source file and the live output should both be checked; for a live camera, verify again after any change to input mode or capture hardware.
When an always-on broadcast depends on a computer staying powered and the file or key being available, moving the repeated playback job off that computer can remove that particular operational burden. StreamNeo turns an uploaded video into a YouTube live stream, so you can switch off your own computer once the file and channel are ready.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Should I choose 1080p30 or 1080i50?
First establish what the source actually outputs and whether “50” identifies fields or frames in its mode notation. If the source is 1080i50, deinterlace it for progressive delivery, then choose a cadence that fits the destination and preserves the motion you need. Apple’s PAL live HLS guidance recommends 50 fps, but that is not a universal requirement for every destination.
Is field-rate output always better?
No. It can retain more temporal motion detail because it makes an output frame from each field, but it raises the output frame rate and the processing and encoding workload. Test whether your full chain can sustain it and whether the destination calls for that cadence.
Where should deinterlacing happen?
It can happen in capture hardware, the streaming application or a live encoder, depending on the verified capabilities of the equipment and software. Pick one clear conversion point and confirm that downstream stages receive progressive frames. Do not assume a capture device deinterlaces just because it accepts an interlaced source.
Does deinterlacing make the stream compatible with every platform?
No. It converts scan format; it does not determine codec, container or destination ingest compatibility. Check the current requirements for the platform you are using, and treat Apple’s HLS advice as guidance for Apple-device HLS authoring.