| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Enabling VAAPI for GNU/Linux (SYS_LINUX) only, adding libraries 'X11 va-drm va-x11 va'
and USE_VAAPI define.
- hb.c:
- Adding global static 'vaapi_device_ctx0' default device
initialized via hb_avcodec_init() and released via hb_avcodec_free()
- hb_avcodec_vaapi_set_hwframe_ctx() attaches the new AVHWFramesContext
to the AVCodecContext
- hb_avcodec_test_encoder(..) adds VAAPI branch,
needs refinement
- encavcodec.c
- adding VAAPI branches, enabling available, needs refinement
Discussion:
First of all, only on Intel hardware I was able to produce a correct
encoded result. On AMD we seemingly have YUV420 / NV12 artifacts.
Therefor I need to learn more details on the pix_fmt handling
as described below.
While adding the VAAPI ffmpeg support the following might be an issue.
Usually HB seems to operate with AV_PIX_FMT_YUV420P in general
being set in the AVCodecContext's pix_fmt.
VAAPI performs as follows:
- It uses hardware frames on the target device, which are being transported
from the software device. Both format should be allowed to differ??
- AVCodecContext's pix_fmt uses AV_PIX_FMT_VAAPI
- AVHWFramesContext: format uses AV_PIX_FMT_VAAPI and sw_format AV_PIX_FMT_NV12,
the latter hinting on the actual hw-frame's target format.
- AV_PIX_FMT_NV12 uses interleaved UV data, where AV_PIX_FMT_YUV420P uses
seperated planes. Both use a separated Y plane upfront.
Therefor both formats are not picture compatible, memory requirements are same.
- Encode(..) hardcodes the source frame's to AV_PIX_FMT_YUV420P in VAAPI case,
usually the AVCodecContext's pix_fmt is being used.
I need to identify how HB uses AVCodecContext's pix_fmt, i.e. respects
the desired pix_fmt.
Then a hw_frame gets allocated and the source frame is being transported
to this target. Probably it happens here in VAAPI AMD case, that the YUV420
data is not being transformed to NV12.
Now the hw_frame is being sent 'avcodec_send_frame' and the code-path re-aligns
with non VAAPI.
Further fixes to do:
Naming of VAAPI's profile and level .. figuring out which settings are generally accepted.
Now the bf (b-frames) is set to zero, since it produces a failure otherwise.
The latter should only happen in certain profiles, but .. it does even in 100=high
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Adding the specific FFMPEG encoder suffix allows support for more encoders like VAAPI.
Cleaned up overall HB_VCODED_* to 32bit signed integer space within 0x7FFFFFFF.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Fix HB_VCODEC_FFMPEG_MASK covered values to lie within mask
- Fix HB_VCODEC_FFMPEG_H264 usage (gtk version missed a rename)
- Fix FFMPEG hwaccel build is required for Nvenc
Basically working:
- h264_nvenc
- hevc_nvenc
Possible optimization:
- Even in constant quality mode, a user ceiling bit_rate might be desirable,
currently only the maximum is used like in VP8/9: w x h x fps
Remaining issues:
1) Muxer issue with h264_nvenc + MKV, ffprobe shows:
[h264 @ 0x55ae4dedacc0] sps_id 32 out of range
[h264 @ 0x55ae4dedacc0] Invalid nal size 1677734572
[h264 @ 0x55ae4dedacc0] missing picture in access unit with size 40644
Notable: This does not happen with hevc_nvenc
Tested:
- GNU/Linux Debian 9
- GeForce GTX 950
- BD 1080p source, cropped: Around 70fps h264 + hevc
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
"Adaptive streaming" allows changing video parameters mid-stream at IDR
boundaries. Such changes require new SPS and PPS NALs at the IDR. MP4
supports this with 'avc3' and 'hev1' sample entry types.
|
|
|
|
| |
It was only used for scaling, it fails far too often and is only
faster on a limited selectoin of hardware.
|
|
|
|
|
|
|
| |
Reader can skip data at the beginning of the file. We were not
informing decsrt how much was skipped when pts_to_start caused the skip.
Fixes https://forum.handbrake.fr/viewtopic.php?f=11&t=36258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* subtitles: simplify and shorten subtitle descriptions
Generally, it eliminates parens to make things more readable.
I.e. it turns this:
English (Closed Caption)(Wide Screen)(Bitmap)(VOBSUB)
Into this:
English, Closed Caption [Wide Screen, VOBSUB]
* Revise punctuation per BradleyS request
* fix subtitle description formatting
* incorporate suggestions from PR
|
| |
|
|
|
|
|
|
|
|
|
| |
It was getting set to the title's rate instead of the rate that the
filter chain sets.
An incorrect vrate causes x265 rate control breakage.
Fixes https://github.com/HandBrake/HandBrake/issues/600
|
| |
|
|
|
|
|
|
|
|
| |
The bob filter predicts the resulting output framerate as 2 * input
framerate. So during 2 pass encoding, we must adjust the framerate with
the knows 1st pass values *after* any predictions made by filters.
Fixes https://github.com/HandBrake/HandBrake/issues/556
|
|
|
| |
Fixes https://forum.handbrake.fr/viewtopic.php?f=12&t=35583
|
| |
|
|
|
|
| |
Thanks Rodeo for pointing this out
|
| |
|
| |
|
|
|
|
|
|
| |
encavcodec saved the chapter mark and set the buffers new_chap to 0.
Then work copied the zero'd new_chap over the good mark that encavcodec
set.
|
| |
|
|
|
|
|
|
| |
Videos get decoded to NV12 in system memory and converted to our
internal colorspace via libswscale. It should be noted that QSV-
accelerated decoding now works with all our videos encoders :-)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Remove:
hb_audio_samplerate_get_best()
Add:
hb_audio_samplerate_is_supported()
hb_audio_samplerate_find_closest()
hb_audio_samplerate_get_sr_shift()
|
|
|
|
|
|
|
|
|
|
|
| |
presets are
veryfast - deadline=good:cpu-used=5
faster - deadline=good:cpu-used=4
fast - deadline=good:cpu-used=3
medium - deadline=good:cpu-used=2
slow - deadline=good:cpu-used=1
slower - deadline=good:cpu-used=0
veryslow - deadline=best:cpu-used=0
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This prevents audio from getting so far ahead of video which improves
sync's ability to fix discontinuities
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
| |
I missed some of the qsv filter settings bits that needed changing.
|
| |
|
|
|
|
|
|
| |
This simplifies accessing and changing filter parameters
programatically. It also changes the custom filter string format to a
':' separated list of key/value pairs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
set fifo_in to NULL so hb_work_loop will call repeadedly without the
hack that primes it's input fifo.
|
|
|
|
|
| |
automatically pull in shared versions of these libs or allow statically
building against any one of them.
|
|
|
|
|
| |
This adds the structure to load an libx264 10-bit shared library.
The user must install this library themselves to an appropriate place.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://forum.handbrake.fr/viewtopic.php?f=12&t=33345
Some players expect each packet to start on an mp3 frame header. Our
mp3lame encoder did not ensure this and resulted in failure to play
audio on these players.
libav already has the necessary code to parse headers and
accumulate a full frame of data, so use it.
|
|
|
|
|
| |
It only worked properly with the x264 encoder. Now it works with all
encoders.
|