- 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.
James Hutchinson [Fri, 16 May 2025 15:09:11 +0000 (16:09 +0100)]
transcode: improve logging of packet transcode errors
Improve visibility of decoding failures during transcoding by logging
the error code, a human-readable description, and the packet PTS when
the hardware decoder fails to process a packet.
Previously, these errors would silently trigger `tvh_stream_stop()` on
the affected stream, with minimal context about the underlying cause.
This made it difficult to diagnose issues such as hardware acceleration
glitches or codec-specific decode failures.
With this change, such errors are logged at warning level, and full
packet details are included if trace logging is enabled. This provides
valuable diagnostic information when investigating stream interruptions
or video dropout.
This commit does not alter transcoder behavior; errors are still
filtered or handled by other components as before. It simply makes
decoder error conditions more transparent for debugging purposes.
Ukn Unknown [Tue, 11 Feb 2025 00:39:02 +0000 (16:39 -0800)]
allow NVENC, VAAPI and MMAL to coexist in the same build
- allow NVENC, VAAPI and MMAL to coexist in the same build.
- give the user the capability for prioritize hw decoder or to match the hw decoder with hw encoder
- refactor source code: remove duplicate source code in codec.js
wizard: increase buffer size to silence -Wformat-truncation on GCC 15
GCC 15.1 introduces stricter checks around `snprintf`-like functions
under `-Wformat-truncation`, even when the format string itself is
under developer control. This triggers a false positive in
`hello_changed()` when building with `-Werror=format-truncation`:
error: ‘__builtin___snprintf_chk’ output may be truncated before the
last format character [-Werror=format-truncation=]
note: output between 1 and 33 bytes into a destination of size 32
This warning is triggered due to a theoretical edge case in
`tvh_strlcatf()` where combining strings like `"en,fr,de"` could
approach the buffer limit of 32 bytes. While truncation is unlikely in
practice, the warning is still emitted aggressively by the new FORTIFY
logic.
Increase the buffer from 32 to 64 bytes to silence the warning and
ensure headroom. This avoids having to disable the diagnostic, while
still keeping the logic and usage intact. This is a defensive fix with
no behavioral change, and aligns with similar mitigations used in other
projects facing the same issue with GCC >= 13 and especially 15+.
dave-p [Tue, 13 May 2025 06:38:55 +0000 (07:38 +0100)]
Remove links to old Wiki (#1793)
* Remove links to old Wiki. Fixes #1660
Also remove references to CIC and CLA, and other content where a more recent version exists on the documentation site.
Michael Marley [Tue, 13 May 2025 05:43:04 +0000 (01:43 -0400)]
httpc.c: Fix HTTPS with OpenSSL 3.5 (#1813)
The TLS Client Hello message is larger in OpenSSL 3.5 and will not
fit in the previous hc_io_size of 1024 bytes. This causes the TLS
Client Hello message to be truncated, resulting in HTTPS requests
stalling and eventually timing out. To fix this, increase
hc_io_size to 2048 bytes.
Michael Marley [Tue, 13 May 2025 05:41:47 +0000 (01:41 -0400)]
lovcombo-all.js: Fix autorec create/edit TypeError with Firefox 134 (#1786)
Firefox 134 added the RegExp.escape() method
(https://tc39.es/proposal-regex-escaping/#sec-regexp.escape) with a
standards-compliant implementation that throws TypeError if
any value other than a String is passed in. This differs from the
existing polyfill that simply returns the argument unmodified if it
isn't a String. In TVHeadend, the day-of-the-week selector (as
used in the Autorec and Timer configuration) uses Integers as keys
for options, causing an Integer to get passed to RegExp.escape() on
line 300 of lovcombo-all.js. Because of the non-standards-
compliant permissive behavior of the polyfill, this previously
didn't cause an issue. However, with Firefox 134 (and an upcoming
version of Safari), the added standards-compliant method causes a
TypeError to be thrown on every attempt to create or edit a timer
or autorec, causing the edit window to not be shown. To solve the
issue, pass the response from r.get(this.valueField) through the
String() constructor to ensure anything that gets passed in is a
String. This has been tested with Firefox and Chrome with both
Integer and String keys.
projects / thirdparty / tvheadend.git / log
