| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The filters (decomb, denoise, detelecine, lapsharp, nlmeans, unsharp)
were all setting color_range to the source color_range after it had
already been converted in decavcodec.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I fixed an earlier problem with searches for a full preset path. Turns
out there were actually 2 bugs that the first bug concealed.
|
| |
|
|
|
|
| |
Fixes https://github.com/HandBrake/HandBrake/issues/2804
|
|
|
|
|
|
| |
The category name was getting ignored in the search.
Fixes updates to presets in different categories with the same name in
LinGui.
|
|
|
|
|
| |
Thanks to Pierce Lopez for pointing out a solution
Fixes https://github.com/HandBrake/HandBrake/issues/2427
|
| |
|
| |
|
|
|
|
|
| |
DVD and BD do not have PAR specified at container level. Since the
title is initialized with PAR 1:1, the warning was triggered.
|
|
|
|
|
| |
Duration of subtitle packets was getting set to 0 and sync was dropping
the subs.
|
|
|
|
| |
The previous hardcoded path is now the fallback.
|
| |
|
|
|
|
| |
The larger font size was causing rendering outside the frame boundaries
|
| |
|
|
|
|
| |
The "clear" subtitle packets were not making it through to the muxer
|
|
|
|
|
| |
This seems to be what ffmpeg expects. This way we also mux it correctly
into mkv, i.e. without the trailing 0xff stuffing byte.
|
|
|
|
| |
Simplifies code, removes encvobsub.c (was never used) and decvobsub.c.
|
|
|
|
| |
simplifies code, eliminates deccc608sub.c
|
| |
|
|
|
|
| |
passthrough will hopefully come later ;)
|
|
|
|
| |
Currently using it for pgs, srt, and ssa subtitles.
|
|
|
|
|
| |
These errors are currently difficult to see in the log and can result in
incorrect output. So make it more visible.
|
|
|
|
|
|
|
| |
rendersub was using incorrect crop values when the cropscale filter is
removed from the filter chain.
Fixes https://github.com/HandBrake/HandBrake/issues/2449
|
|
|
|
|
|
| |
Enforces minimum values that ensure we stay in buffer boundaries
Fixes https://github.com/HandBrake/HandBrake/issues/2560
|
|
|
|
|
|
|
|
|
|
| |
range was already getting converted to limited in decavcodec.c
The range of each frame is provided in AVFrame.color_range and we are
already propagating that through the pipeline. Manually setting
"in_range" in the "scale" filter was overriding that per frame setting.
Fixes https://github.com/HandBrake/HandBrake/issues/2561
|
|
|
|
| |
Fixes https://github.com/HandBrake/HandBrake/issues/2603
|
|
|
|
|
| |
Can't tell where these failures are comming from because all the logs
look the same :(
|
|
|
|
|
|
|
| |
seconds and frames were not writting to the "Range" dict but instead
writting to the "Source" dict.
Fortunately, nobody has been relying on this behavior
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
With HandBrakeCLI --all-subtitles and *no* --subtitle-lang-list, no
subtitles were added
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When nlmeans_prefilter() is preparing to apply a pre-filter
to an image plane, it first attempts to make a copy of the
mem image plane into the mem_pre plane which will hold the
pre-filter's output.
However, the existing logic, which mirrors the loop over
all pixel rows in nlmeans_alloc(), improperly leaves the
bottom 2*border rows of the mem_pre plane uninitialized.
Where nlmeans_alloc() correctly copies the source image's rows
into its plane, by adding the correct offset to the memcpy(3)
destination to locate the image pixel data between the
horizontal and vertical borders, in nlmeans_prefilter() the
intention is to copy both the image and the borders. However,
the current loop only iterates h times, i.e., the size of
the image itself, and skips the last (bh - h) = 2*border rows.
Instead, we replace the loop with a single memcpy(3) call
which just duplicates the entire mem image plane, including
the border data.
|
| |
|
| |
|
| |
|
|
|
|
| |
We have received numerous reports about x265 in HandBrake 1.3.0 creating ~30% larger files with no perceived quality gain, and have confirmed this to be true in most cases. This appears to be the result of x265 recently switching to use aq-mode 2 by default. This change makes the behavior of the official presets more closely match that of HandBrake 1.2.2 and earlier. This seems to be the best course of action both technically and for the user experience until the default aq-mode improves.
|
| |
|
|
|
|
|
|
|
|
| |
There are actually 2 types. One "secondary" audio type is designated
by a distinct stream id. The other "secondary" audio type is disignated
by being in a separate "secondary" audio list.
Maybe fixes https://github.com/HandBrake/HandBrake/issues/2501
|
|
|
|
| |
It was resolving to "Any" instead of "Unknown"
|
| |
|
| |
|
| |
|