Josef Schlehofer [Thu, 23 Oct 2025 06:49:06 +0000 (08:49 +0200)]
debian: Enable IPv6 by default
With global IPv4 exhaustion and widespread IPv6 deployment by ISPs, enabling
IPv6 by default ensures compatibility with modern dual-stack and IPv6-only
networks.
If people wants to disable it, they can do it manuallly.
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Ukn Unknown [Fri, 24 Oct 2025 19:17:19 +0000 (12:17 -0700)]
Fixes coverity 637368
- threshold was defined as double representing the maximum representation that can fit in a int64_t later on
- number is ridiculously large so is only a theoretical limit.
This PR transitions the logging and dictionary-setting macros from using the old av_dict_set_int() macro to the new function codec_av_dict_set_int(), and updates various log subsystem references accordingly. Key changes include:
- Removing the LS_VAAPI logging entry in favor of transcoding-specific logging functions.
- Updating dictionary-setting macros across multiple codec source files with an additional subsystem parameter.
- Adjusting subsystem identifiers (e.g., LS_VAAPI → LS_LIBAV) in selected logging calls.
- Applied consistent regional format: removed colon separators for single names
- Language families: "Algonquian langs", "Australian langs", "Philippine langs"
- Regional simplification: "Kyrgyz" vs "Kirghiz: Kyrgyz", "Punjabi" vs "Panjabi: Punjabi"
- Audio description: "Audio Description", "Sync Audio Desc" vs long technical names
- Historical entries: maintained "Aramaic (Ancient)", "Egyptian (Ancient)" format
- All entries now follow consistent English format
PR #1915 changed references to 'url' to 'uri' in order to display CRID information for recordings. However 'url' is used to hold a link to the recording file which is used by the 'Download' button on the UI. Reinstate 'url' where this is relevant, ie for completed and failed recordings.
Reported in https://tvheadend.org/d/9235-small-bug-in-43-2462g664cc1b62
The encoder configuration debug message previously included embedded
`\n` to print multiple lines. Following maintainer guidance discussed
on Slack, update the log to output everything on a single line instead.
This keeps the configuration details (framerate, time base, frame
duration, GOP size, sample aspect ratio) visible in one log entry,
making it easier to grep and parse while staying consistent with the
logging style.
Do not use number hardcoding in recording details dialog
Programmers can count, we all know that, so instead of proofing (and
occasionally failing) it in code, lets do away with hardcoding here
and just use an object with named members which is also a bit shorter
and easier to extend.
The display code handles various tags shown as "Parameters" in the info
dialog of an EPG event like "Subtitled", "New" or "Repeat", but only
"New" was actually displayed as the data for the other tags wasn't
requested and hence never present.
The header is included all over the place and hence also multiple times
in the same translation unit which triggers -Wredundant-decls, beside
being pointless, so we just tell the pre-processor with a slightly more
modern form of a header guard that once is enough.
As a bonus, this commit keeps the 'DO NOT EDIT' remark as intended.
transcode: fix VAAPI deinterlace mode handling for software decode/encode profiles
Move 'deinterlace_vaapi_mode' from the VAAPI codec profile to the generic Main
Video Codec Profile, allowing this setting to be applied when using VAAPI
hardware deinterlacing with software-based transcode profiles such as libx264.
This fixes a bug where 'deinterlace_vaapi_mode' was left uninitialized for
non-VAAPI codec profiles, resulting in invalid filter strings like
'deinterlace_vaapi=mode=21867:rate=2:auto=0' and filter graph setup failures.
The patch also:
- Adds validation for the mode value (range 0–4)
- Dynamically enables/disables the VAAPI mode field in the WebUI based on encoder
and decoder settings
- Consolidates enum and mode list generation logic under 'profile_video_class.c'
This ensures that VAAPI deinterlacing can be correctly configured and used across
hybrid transcode profiles, improving compatibility and user control.
James Hutchinson [Wed, 19 Mar 2025 13:12:37 +0000 (13:12 +0000)]
transcode: add advanced options for deinterlacing
This patch exposes additional configuration options for the
deinterlace_vaapi (hardware) and yadif (software) deinterlace filters:
* Deinterlace rate type (rate): frame or field
* Deinterlace fields only (auto): only deinterlace interlaced fields
* VAAPI Deinterlace mode (mode): Bob, Weave, MADI, MCDI (for VAAPI only)
These options allow the transcode deinterlace configuration to be
fine-tuned. Most notably, the deinterlace filters can now be configured
with field-rate deinterlacing, which causes (for example) 25fps
interlaced input at a 90kHz timebase to produce 50fps output with a
180kHz timebase.
To maintain MPEG-TS compliance, the output timebase is fixed at 90kHz,
and both the adjusted output frame rate (e.g. 50fps) and frame
timestamps are rescaled accordingly before encoding. For accuracy, this
rescaling is performed dynamically using libav functions such as
av_rescale_q(), based on the timebase of the final filter in the
AVFilterContext chain and the timebase of the output AVCodecContext.
This approach supports fractional frame rates and remains robust against
future changes to the filter configuration, including various
combinations of deinterlace options.
When field-rate deinterlacing is selected, this produces frames with
(for example) correct timing of 50fps playback in a 90kHz container,
ensuring that the transcoded output stream preserves the intended
cadence and temporal fidelity of the original interlaced source.
Ukn Unknown [Sat, 31 May 2025 18:09:56 +0000 (11:09 -0700)]
move filter_hw_denoise and filter_hw_sharpness to tvh_codec_profile_video
fixes: https://github.com/tvheadend/tvheadend/issues/1818
also fixes a logical define bug: filter_denoise and filter_sharpness should be transferred for all HW accels (not only for VAAPI)
This commit adds the is_new flag to the EPG event data sent to HTSP clients.
By including this property, clients such as Kodi (with the pvr.hts addon)
can now detect whether a broadcast is marked as new and set corresponding
flags (e.g. EPG_TAG_FLAG_IS_NEW in Kodi).
This enhances the metadata available to clients and supports improved EPG
event handling and display.
A corresponding pull request will also be submitted to the pvr.hts project
to make use of this flag when obtaining EPG event guide data from Tvheadend.
transcode: gracefully handle common hardware decoder errors
When using VAAPI hardware decoding, certain malformed or corrupt frames at the
start of the stream may cause the ffmpeg h/w decoder to emit `AVERROR(EIO)` or
`AVERROR(EINVAL)` early in the picture decoding phase.
In these cases, libav will log errors such as:
[ ERROR]:libav: AVCodecContext: Failed to upload decode parameters: 18 (invalid parameter).
[ ERROR]:libav: AVCodecContext: Failed to end picture decode after error: 18 (invalid parameter).
[ ERROR]:libav: AVCodecContext: hardware accelerator failed to decode picture
Currently, Tvheadend treats these errors as fatal, resulting in the transcoder
stream being torn down via `tvh_stream_stop()` and interrupting client playback,
typically leaving only audio and a black screen.
While this behavior is somewhat tolerable during live TV viewing—where the user
can manually resolve the issue by changing channels—it is significantly more
disruptive in recording scenarios, as it results in recordings containing only
audio and no video.
However, when the same streams are run directly through FFmpeg’s CLI, FFmpeg
**does not abort** on these errors — it logs them and continues transcoding.
This makes FFmpeg's failure handling more robust than Tvheadend's.
To identify which errors should be considered recoverable, the transcoder was
instrumented to log the exact `AVERROR` codes encountered during decoding failures.
A stress test was then run using a channel-hopping script that switched channels
every 5 seconds over several hours. The failure rate was approximately 1%, and
in **all** cases, the decoding failures were either `AVERROR(EIO)` or
`AVERROR(EINVAL)`. Allowing the stream to continue after these specific errors
proved effective — playback resumed, and only a minor picture glitch was visible
at the affected frame, with no need to tear down the video stream.
This patch updates `tvh_context_decode()` to include `AVERROR(EIO)` and
`AVERROR(EINVAL)` in the list of tolerated decode errors, aligning Tvheadend's
behavior with FFmpeg’s more forgiving approach.
FFmpeg’s internal decoder logic in `vaapi_h264.c` and `decode.c` supports this
tolerance model. For example, in `decode_simple_internal()` and `submit_frame()`,
errors like `EIO` may occur during `av_hwframe_transfer_data()` or `vaEndPicture()`,
but are **not considered fatal**. Instead, FFmpeg logs the issue and decoding
continues on the next frame.
projects / thirdparty / tvheadend.git / log
