Frequently asked questions

Pixop Prime customer FAQ for broadcast and operations teams. Use pixop-version on the appliance to see what you actually run.

Version note: AWS Marketplace shows a product version on the listing; the guest reports an AMI recipe via pixop-version. Those strings differ and both change when Pixop publishes updates. KVM appliances may track another delivery schedule. Confirm transport backends, GPU qualification notes, and CLI helpers on the running instance (pixop-version, command -v <tool>) before relying on them.

Overview and workflows

What is Pixop Prime?

Pixop Prime is a GPU appliance for real-time MPEG-TS enhancement over SRT. Ingest listens on UDP 5000, Pixop LIVE processes on the GPU, and egress listens on UDP 5001; TSDuck and the container exchange traffic via on-guest multicast.

You run a pre-built image in your AWS account (EC2) or on your KVM host—not a Pixop-operated WAN service. Pixop Studio is a separate documentation and product line (browser and cloud-oriented workflows). Prime is the fixed SRT pipeline appliance with CLIs under /opt/pixop/bin. See Pixop Prime overview.

What is pre-installed on the appliance?

Amazon Linux 2023, the NVIDIA driver and Docker with the NVIDIA Container Toolkit, TSDuck, digest-pinned Pixop LIVE and TSDuck container images, systemd units, and operator tools. Details are in overview.

Do I compile Pixop or drivers on the customer node?

No. You do not build Pixop LIVE, TSDuck, or the NVIDIA stack on the appliance.

Host OS and driver changes require a new qualified AMI or QCOW2 from Pixop. Container-only updates use pixop-image-update when Pixop publishes digests for your release line.

What live video capabilities should I expect?

Prime is built for real-time enhancement of live MPEG-TS, including workflows such as HD→4K upscaling and SDR→HDR when your license and output or profile settings support them.

Exact formats, bitrates, and restoration depth depend on nvencc.args, UI params.json, and GPU headroom—not on marketing defaults alone. Start from Configuration.

AWS Marketplace and KVM deployment

How do I deploy on AWS or KVM?

• AWS: Subscribe on Marketplace and launch the published AMI with CloudFormation (pixop-live.yaml) into an existing VPC and subnet. Set SRT and management CIDRs, then complete first-boot License Manager activation. See AWS Marketplace quickstart.

• KVM: Install the Pixop QCOW2 with pixop-install on a Linux host (reference: Ubuntu 24.04, VFIO GPU passthrough). The guest is the same AL2023 appliance as AWS, not a generic Ubuntu image. Supply a license JWT at install or runtime. See KVM quickstart and KVM deployment guide.

Which EC2 GPU size should I pick?

Start from these CloudFormation-aligned starting points for heavy versus lighter workflows.

Matching instance type, kernel, NVIDIA driver, and provider qualification matters as much as raw GPU generation—hardware capability is not production validation. Pixop does not guarantee throughput or real-time 4K60 for your encoder, profile, and concurrent load; size empirically and monitor with pixop-flow.

SRT networking and transport

Which ports does SRT use by default?

Optional auxiliary egress uses 5002 and 5003 when enabled. HTTP 8080 (UI and metrics) and SSH 22 are TCP—restrict them to management networks. Full matrix: Network and transport.

Do I need to open multicast on the firewall?

No. Defaults 239.0.0.1:5500, :5501, and :5600 are on-guest UDP multicast hand-offs between TSDuck and Pixop LIVE—not WAN endpoints. Do not put 239.0.0.1 in security groups or site firewalls.

How do I set passphrases and latency?

SRT passphrases are generated at first boot for main and egress-main; distribute them securely to encoder and receiver operators. View template-aligned values with tsduckctl credentials (never paste live secrets into tickets).

When your build ships the helper (command -v / tsduckctl help), run tsduckctl tune-latency main report-only after the feed is stable. Review the suggested PIPELINE_LATENCY (often in the 200–1500 ms range) against your RTT and plant, then use tsduckctl tune-latency main --apply only in an approved change window—--apply writes instance .env and restarts primary ingest. See Connect your first SRT stream and Transport configuration.

How do HLG, PQ, SDR, and latency fit together?

Encoded signalling (SDR vs HLG vs PQ) is set in /etc/pixop-live/nvencc.args and must match downstream expectations. Picture-side SDR→HDR and restoration use the :8080 UI (params.json). After nvencc.args edits, run pixopctl restart.

Latency depends on SRT buffers, GOP, PCR/PID handling, GPU depth, and RTT. Use tsduckctl tune-latency and measure your end-to-end path; docs give patterns, not a fixed millisecond guarantee. Transport troubleshooting.

When is bonded or multipath SRT needed?

A single WAN link and one appliance IP uses one listener on 5000—no bonding.

Bonded SRT (semicolon group URIs, grouptype=broadcast) requires the relay transport backend and helpers such as tsduck-transport-info—not native-only .env templates. If you have one active gateway with backup via external routing, bonding is often unnecessary. Details: Multipath and bonded SRT.

Does Prime pass through the original “clean” video if enhancement fails?

There is no transparent clean-feed bypass. Optional PIXOP_VIDEO_LOSS_POLICY=fail-open can keep a transport stream emitting when Pixop replacement disappears; it does not restore the original encoder video.

Treat fail-open as an explicit operational policy, not default fail-safe passthrough. Transport configuration.

GPU compatibility, image profiles, and performance

What is “hardware-capable” versus “qualified”?

Hardware-capable means the GPU generation and driver stack can run NVENC/NVDEC paths Pixop uses. Qualified means Pixop has tested a specific recipe (AMI/QCOW2, driver branch, instance type, or KVM host) for production acceptance.

Capable hardware on an unqualified host or driver override is lab territory until you pass the same checks (for example pixop-install doctor, pixop-preflight, live pixop-flow).

Which NVIDIA GPUs are in scope?

Pixop targets NVIDIA GPUs from Turing onward on x86-64 Linux with Pixop’s open kernel module policy. Pre-Turing GPUs are out of scope.

On AWS, the published AMI is tied to qualified instance families, drivers, and kernels—not every Turing+ GPU shape is validated for your workload. KVM qualifies discrete NVIDIA cards via VFIO on a qualified host (integrated graphics stays on the host).

Does a recommended GPU instance guarantee real-time 4K60?

No. A documented starting instance is a sizing hint, not a performance certification. Achieved frame rate depends on your processing profile, codec, GPU generation and model, frame cadence, and concurrent load. Run acceptance benchmarks with representative content on the exact qualified AMI or QCOW2 you deploy. CLI helpers and relay transport features depend on the installed image — confirm with command -v and pixop-version before relying on them.

Engineering AMI recipes also target Blackwell on g7e for qualification work—your running pixop-version may differ from that line.

What about KVM GPUs?

Reference qualification: NVIDIA RTX 5080 on Ubuntu 24.04, QEMU 8.2, libvirt 10, after pixop-install doctor and live acceptance tests (KVM deployment guide).

Dual RTX PRO 6000 Blackwell appears as a planned PoC target—not yet qualified on the public installer until the same acceptance passes on your host. PCIe P2P, GPUDirect, NVLink, and NCCL are not qualified KVM features.

Which NVIDIA driver branch ships?

Some qualified appliance recipes bake NVIDIA driver branch 610 (open modules only) for recent NVENC/NVDEC including 4:2:2 on Blackwell-class hardware. Your instance may report a different branch; pixop-preflight warns when branch 610 is not detected—treat that as a signal to compare against your qualified image, not a universal requirement.

You cannot upgrade the host driver in place; request a new tested image.

What output chroma (--output-csp) can I use?

Set in /etc/pixop-live/nvencc.args, then pixopctl restart. See Configuration.

How many GPUs does live processing use?

Pixop LIVE sees GPUs exposed inside the container (NVIDIA_DRIVER_CAPABILITIES=compute,utility,video). On multi-GPU hosts, scheduling may use all visible devices, but exact split depends on pipeline, license, and build.

Validate with metrics and nvidia-smi on your workload rather than assuming linear scaling.

Licensing, security, and updates

How does licensing work on AWS versus KVM?

• AWS Marketplace: Entitlement via License Manager and first-boot activation—use pixop-license doctor and pixop-license status. See pixop-license and AWS Marketplace quickstart.

• KVM: Install a JWT on the guest (pixop-install license on the host). No AWS account is required on the guest for JWT entitlement. Use pixop-license decode for claims inspection, not as a substitute for your contract.

If the License Manager service-linked role is missing, complete account-level License Manager setup with Pixop support guidance before repeating activation.

On first boot (marker /var/lib/pixop-live/instance-init.complete absent), restarting pixop-instance-init.service re-runs mutating activation and is not a casual operator step. After the marker exists, the unit is gated so a restart typically does nothing—prefer pixop-license doctor and support over unconditional systemctl restart.

How long does a license last?

Commercial terms (subscription, FLEX hours, expiry) come from your agreement and fields in pixop-license status when AWS or JWT data is present. Pixop documentation does not promise unlimited runtime hours.

How should I protect management access?

Restrict TCP 8080 and 22 to trusted management CIDRs (sample CloudFormation rejects 0.0.0.0/0 on 8080). SRT passphrases are secrets—use tsduckctl credentials locally, not chat logs.

Optional REST API auth on Pixop (Basic/Bearer in restapi config) may require credentials for /v1/* scrapes even from localhost patterns described in monitoring and health signals.

What can I safely change day to day?

Avoid hand-editing image tags, disabling health timers without cause, or docker restart on pixop-live.

What is the difference between pixopctl restart and pixopctl recover?

pixopctl restart restarts only pixop-live.service—primary SRT ingest stays up. Use after nvencc.args or Pixop-only fixes.

pixopctl recover stops primary ingest, restarts Pixop, and restarts ingest—expect a brief ingest gap. The pixop-healthcheck timer may invoke it after consecutive failures (with cooldown). If recover loops on idle input, confirm with pixop-flow and frame counters before changing policy. pixopctl, Incident response runbook.

Can I run pixopctl pull to update containers?

No. pixopctl pull is refused; use pixop-image-update with digest-pinned references Pixop publishes. Generic docker pull on mutable tags is not a supported operator workflow.

When do I need a new AMI or QCOW2 versus a container update?

Container images (Pixop LIVE, TSDuck) may update via pixop-image-update on supported builds. Host OS, NVIDIA driver, and systemd integration require a new qualified AMI/QCOW2—not an in-place yum upgrade recipe.

Monitoring, operations, and support

How do I know the appliance is truly “on air”?

Use these checks in order:

1. Release and stack — pixop-version, pixop-preflight, pixop-stack status; on AWS, pixop-license doctor.
2. Listeners ready — tsduckctl check main / egress-main.
3. Peer connected — encoder and receiver logs (bind alone does not prove a session).
4. Bytes moving — pixop-flow --secs 5.
5. Frames processed — pixopctl health, /v1/metrics, JSON control status.

Before first traffic, stay read-only—do not use tsduckctl detect-video-pid … --apply or tsduckctl tune-latency … --apply without an active feed; both mutate instance .env and restart ingest. Those subcommands may be absent on some recipes—confirm with command -v or tsduckctl --help on your appliance.

With a stable live feed, optional report-only checks when supported: tsduckctl detect-video-pid main --secs 10, tsduckctl tune-latency main. Use --apply only after reviewing the recommendation and during an approved change window. Monitoring and troubleshooting, pixop-preflight, Connect your first SRT stream.

Why does output look wrong for the first minute?

Cold GPU and model warmup, license standby, PCR/PID selection, and egress packet skip windows can produce pre-enhancement or idle-looking TS early in a session.

Record a longer timeline; align PID/program selection after warmup. Incident response runbook.

How do I collect data for Pixop support?

Run pixop-version, note UTC time of the incident, then pixop-support-bundle. For quick triage use pixopctl logs, TSDuck unit journals, and /var/log/pixop-live/live.log.

Bundles exclude JWT bodies where possible and run best-effort redaction—review the archive before upload. Do not attach pixop-license token, raw license.jwt, tsduckctl credentials output, or SRT passphrases. pixop-support-bundle, Incident response runbook.

File workflows

Can Prime process files as well as live SRT?

Yes, with pixop-process: same digest-pinned Pixop LIVE image, presets (TOML) under /opt/pixop/share/process-presets/ (plus site overrides), file or directory I/O—separate from live params.json UI settings.

Batch jobs share GPU with live paths; avoid heavy file runs during on-air windows. Confirm the CLI on your build (command -v pixop-process). pixop-process.