| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* sync: correct timestamp discontinuities in sync instead of reader
This patch passes discontinuity information through the pipeline till it
reaches sync.c. The timestamps are passed through the pipeline as read
and unmodified to sync.c (instead of attempting to correct
discontinuities in reader). In sync, when we see a discontinuity,
we know where the next timestamp should be based on the timestamp
and duration of the previous buffer (before the discontinuity). So
we calculate an "SCR" offset based on the timestamp after the
discontinuity and what we calculate it should be.
The old discontinuity handling code was broken due to the following.
The MPEG STD timing model relies heavily on the decoder having an STC
that is phase lock looped to the PCRs in the stream. When decoding a
broadcast stream, the decoder can count on the time measure between PCRs
using the STC to match to a high degree of accuracy.
I.e. STC - lastSTC == PCR - lastPCR. When a discontinuity occurs, the
decoder calculates a new PCR offset = PCR - STC. I.e. the offset is the
new PCR value minus what it would have been if there had been no
discontinuity.
The above does not work without a reliable STC, which we do not have.
We have been attempting to approximate one by avereraging the duration
of received packets and extrapolating an "STC" based on the last PTS and
the average packet duration. But this is highly variable and
unreliable.
* decavcodec: fix data type of next_pts
It needs to be double so that partial ticks are not lost
* deccc608sub: clarify comment
* sync: allow queueing more audio
Audio is small, and there is often a significant amount of audio in the
stream before the first video frame.
* sync: improve handling of damaged streams
When data is missing, the audio decoder was extrapolating timestamps
from the last pts before the error caused by the missing data which
caused sync issues.
Also, missing data can cause the video decoder to output a frame out of
order with the wrong scr sequence. Drop such frames.
|
|
|
|
|
|
| |
When more than 2 subtitles overlapped in time, they were not merged
properly and could result in cases where the subtitle time went
backwards
|
| |
|
|
|
|
|
| |
Eliminate the need for everyone to assume that the first chapter starts
at the first frame.
|
|
|
|
|
|
|
|
|
| |
* remove dxva hw decode
It provides practically no speed increase even on a slow CPU and results
in a speed decrease on fast CPUs. And the code is exceptionally fugly.
* cli: remove USE_HWD
|
| |
|
| |
|
|
|
|
| |
HTTPS and it's terrible code.
|
| |
|
|
|
|
|
|
|
|
|
| |
Only deinterlace frames that are marked as interlaced when mode
HB_YADIF_AUTO is set in the filter settings.
Currently, this would cause no frames to be deinterlaced since all
frames are marked non-interlaced. This option will become useful in a
subsequent patch that splits comb detection into it's own filter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New filter types HB_FILTER_AVFILTER and HB_FILTER_PAD.
Settings for HB_FILTER_AVFILTER are the same as you would pass to avconv
from the command line -vf option, except that we do not support
multi-input or multi-output filters.
Settings for HB_FILTER_PAD are "width:height:color:x_offset:y_offset".
width x height is the size of the output frame after padding.
color may be a w3c color name or RGB value (default black).
x_offset, y_offset is the position of the video within the padded area
(default centered).
Any of the values may be omitted or "auto".
|
|
|
|
|
|
|
|
|
|
|
| |
sync.c was difficult to read, fragile, and prone to difficult to
diagnose bugs (see
https://forum.handbrake.fr/viewtopic.php?f=12&t=33147)
This rewrite simplifies the code, removes signals, locking and yield
that probably cause the above problem and is much more flexible. It
fixes a wider variety of timestamp issues than before and is much easier
to extend if other timestamp analysis is desired.
|
| |
|
|
|
|
|
|
|
|
| |
We split PES packets when there is a PCR change in the middle of the
packet. This works fine for audio and video where the decoder parses
the ES to find frame boundaries. But it does not work for some decoders
such as PGS subtitles. So mark split buffers and reassemble them in
reader after processing the PCR change.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
simplify job initialization sequence, clean up code, and document
dependencies in the sequence better.
Make hb_add set job->sequence_id. It is no longer necessary for the
frontend to do this. If the frontend needs the sequence_id, it is
returned by hb_add().
Clean up use of interjob. do_job() now uses sequence_id to detect when
a new sequence of related jobs is running and automatically clears
interjob.
|
|
|
|
|
| |
libav just deprecated AVPicture and all av_picture_*/avpicture_*
functions.
|
|
|
|
|
| |
It only worked properly with the x264 encoder. Now it works with all
encoders.
|
|
|
|
|
| |
This brings together several independent implementations of a simple
buffer list manager.
|
|
|
|
|
| |
The video frame subtitles are meant to be rendered to may not match the
actual video we are encoding. So scale to match as needed.
|
| |
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@7332 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
| |
... instead of a 0 length buffer.
This fixes this issue:
https://forum.handbrake.fr/viewtopic.php?f=12&t=31959
Theora can create 0 length output. These 0 length frames indicate
duplicate frames. So we can't use 0 length buffers to indicate the end
of the stream.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@7143 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
| |
Just invalidate the timestamps and let the decoders interpolate.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@7121 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
When a new PCR is seen, emit all currently cached data. This prevents
data that was referenced to the previous PCR from being associated with
the new PCR.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@7120 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@7119 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
| |
This global was shared between the CLI and libhb and used as a back door to
force scan and encode passes to use the same ffmpeg context for hardware
decoding. Aside from the fact that this context sharing should not be necessary
and needs fixing, this information belongs in the hb_handle_t that is shared
between the scan and the encode. So put it there and make sure the hb_handle_t
get propagated to where the flag is needed.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@7028 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simplifies the WinGui.
This also changes how jobs are processed. Creating the sub-jobs for
multiple passes is delayed until after scanning and immediately before
running the job.
Working status has also changed. Sub-job passes are identified in status
with an ID that allows the frontend to definitively identify what pass
is in progress.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6976 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
libav does not fix chapter timestamps for us, so we must do this until
I can figure out a good fix to libav.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6871 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6852 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6613 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
| |
Scales well with number of CPUs, so is 4x faster on quad cores.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6397 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
| |
...and enable x265 by default
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6309 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new function has a couple advantages over the old one (which we
should phase out).
It does not require hb_job_t as a parameter, instead it uses hb_ui_geometry_t
which is a smaller and simpler struct. The entire job struct is overkill as
input to this function.
It returns an hb_image_t that fully describes the returned image instead of
just a uint8_t array. The caller does not have to make assumptions about image
size, line stide, or pixel format since hb_image_t specifies these things.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6242 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
In some cases, initial data when in p-to-p mode causes libav decoder
initialization to fail. This only happens when multi-threaded encoding
is enabled.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6229 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
Non-local means averages multiple patches of similar pixels together, preserving similarities and attenuating variance (usually noise). This is typically more effective than lowpass and more faithfully restores the appearance of structure and detail found in the original source, especially in the high frequency range. Parameters for origin patch weight tuning and pre-filtering further improve on the original algorithm.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6216 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
... and probably other formats that use a palette.
The palette is stored in AVPacket side data which we did not read. So
read the side data and stash it in hb_buffer_t so that it can be used
later by the decoder.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6207 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6094 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
| |
- rational framerates
- libx265 now provides decode time stamps (DTS)
- encx265: minor refactoring + prepare for muxing to MP4/Matroska
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6088 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
| |
replace it with libavcodec ac3 decoder
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6049 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6042 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
| |
Build with --enable-x265 (requires CMake).
Use via HandBrakeCLI with -a none -e x265 -f raw
Only raw HEVC output is supported for now (no audio or subtitles).
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@6023 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
We no longer need mpeg2dec. libav now has all the features we need
for mpeg2 decoding.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@5966 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
Adds interlaced VC1 and HEVC support.
Eliminates the need for most of our local patches.
Many assorted bug fixes and improvements.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@5962 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@5958 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
RebiewBoard #670.
Patch by icchan. Thanks!
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@5957 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
This function is being remove from libav. so replace it's functionality
with a threaded implementation of our own.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@5911 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@5905 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
| |
An OpenCL SDK is no longer needed to build OpenCL support.
Note: as a result, the --enable-opencl configure option is removed.
Also, libOpenCL is no longer needed to run the application (it is still necessary to use OpenCL features, of course).
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@5886 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch originally by the Multicoreware Inc team, followed by improvements and fixes by Micheal Wootton from AMD Inc,
OpenCL:
This patch implements Bicubic Scaling in OpenCL.
Note that HandBrake currently uses Lanczos so the performance difference appears to be much more significant. We may offer an option of BiCubic in software later.
Bicubic scaling may appear a bit sharper than the equivalent Lanczos encode and may increase file size a bit. Quality may be better or worse depending on the scaling and content and personal preference towards sharpness.
When comparing performance with a custom HandBrake build that runs Software Bicubic to OpenCL Bicubic, performance increase is about 5~7% on average on a modern GPU.
Hardware Decode via DXVA:
We also have optional DXVA decoding which may come in useful for slower/lower end systems that have a capable GPU.
This is only available on input sources that use the libav decode path.
Most GPU hardware for decoding is designed for playback, so if you are running on a high end CPU, it will bottleneck the encode process.
Requires OpenCL 1.1 or later supporting GPU.
Front end changes and testing framework are not included in this patch. This will be resolved later.
Patch will be revised further before the UI is implemented.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@5792 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@5737 b64f7644-9d1e-0410-96f1-a4d463321fa5
|