| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
HandBrake uses many attributes of the FFmpeg API that are were deprecated
when we did the last bump. Many of them no longer exist in current
FFmpeg/Libav git, or are going to be removed soon.
Replaces them with non-deprecated attributes that already exist in the
build we currently use.
Thanks to Rodeo for the patch.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3964 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
The mpe2dec can return nonsense values for width and height that
make sws_getContext fail. So check the context return value and
just drop the buffer if it fails.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3963 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
| |
Since we now allow subtitles that overlap in time, it is no longer
appropriate to arbitrarily set the duration to 3 seconds when vobsubs
don't have an explicit stop time. This causes them to overlap on the display.
So now, we set the stop time for such vobsubs to -1. Then in sync adjust the
stop time to the start of the next vobsub when it is seen.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3961 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
Since PS streams don't have a directory of streams, we find them by
scanning the PES headers for stream types. We were adding them in the
order found which is pretty random. This sorts audios by substream id.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3958 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
The pid and substream were being added to the TS stream list twice which
caused 2 copies of each packet to be returned to reader. This caused sync
to drop every second packet with "time went backwards" log message.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3957 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
Was passing AV_NOPTS_VALUE that is generated by libav. Needed to
translate to -1 which is what we use to designate invalid timestamps.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3955 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
Testing shows that this should be 1024 instead of 900.
Thanks to Rodeo for validation and patch.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3954 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TrueHD and DTS-HD now show up in the audio list along side their
AC-3 and DTS counterparts.
Note that currently the DTS-HD decoder we are using (ffmpeg) discards
the HD portion of the stream and onle decodes the DTS core portion. So
there is no advantage yet to using the DTS-HD stream. In the future
I would like to add DTS-HD passthru support and hopefully ffmpeg will
improve their DTS-HD decoder.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3950 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3947 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
Should have been removed here https://trac.handbrake.fr/changeset/2917
Thanks to rodeo for spotting this.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3944 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3937 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
| |
If the source has large non-reduced PAR values, our computed value
was overflowing an int. Compute it in an int64_t then reduce it.
Also, keep num and den below 65535. Larger values just aren't really
significant and will cause more overflow issues.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3931 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each clip of a BD are allowed to have different audios if the clip
does not have a seamless connection to the previous clip. Most titles
are a series of seamless clips that all have the exact same audio. But
I found some that have a final non-seamless clip that has completely
different audios and broke the old algorithm.
New algorithm, look at each clip and count the number of other clips have
the same audio. Use the clip that has the most matches.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3918 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With p-to-p, the audio sync thread waits for the video sync thread to
reach the designated start point. There is a possibility that the video
decoder will drop so many frames that the audio sync fifo fills before
any frames reach the video sync thread. When this happens, drop some
audio to unplug the pipeline.
Also, to make this less likely to happen, start sending data to the video
decoder 2 seconds before the actual desired start point. This will allow
the decoder to find an initial i-frame before the audio stalls since the
audio sync thread drops any audio that is before the designated start point.
A side effect of this is our start time now more accurate since the decoder
is only dropping frames before the start point instead of after.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3917 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
| |
These boundaries are always discontinuities. But sometimes we were
not detecting them as such and would drop frames. So set a flag
in the buffer when libbluray tells us a new clip is starting and
use that to trigger computation of a new scr offset.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3912 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3910 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
| |
The Mkvtoolnix developer claims that MKV only allows the bibliographic form
of ISO-639-2 lang codes: https://www.bunkus.org/bugzilla/show_bug.cgi?id=598
http://matroska.org/technical/specs/index.html#languages seems to confirm this.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3909 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
| |
...from float [-32768...32767] to float [-1.0...1.0]
Using the range [-1.0..1.0] requires fewer translations of the range for our
various encoders and decoders. This also gets rid of a hacky
translation from float to int to float in decavcodec audio decoding.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3908 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
libdca downmix is broken if you ask for dolby and DCA_ADJUST_LEVEL.
Since we fixed the clipping problem that DCA_ADJUST_LEVEL is used for
with changeset 3294, we can just disable this.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3907 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
New CLI option is --gain <float>. Value is measured in dB. Negative values are
quieter, positive values are louder.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3902 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
| |
dcadec returns samples that have values in the range -1.0 to 1.0.
We need these to be converted to the range -32768 to 32767. For some
reason, decdca was scaling by 16768 instead of 32767. This has been
like this since dts support was initially added by maurj.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3900 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) whenever we log audio->id or subtitle->id using hex formatting, precede
the hex with 0x (which was already done in some places but not others)
2) format audio->id as hex instead of decimal in sync.c (makes it much easier
to see which track "went backwards" or had silence added to it, checking
the job configuration logged by work.c)
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3898 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
If the non-overlaping remainder is greater than 0.5 seconds, shorten
the subtitle instead of completely dropping it.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3897 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
| |
According to several e-mails I've read on ffmpeg-devel, avcodec_flush_buffers
should be called after any seek. It appears this is even more critical to do
when using frame based multi-threading. I don't see any immediate difference
in functionality by adding this, but it may prevent surprises in the future.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3896 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
| |
Forome reason, frames that are tagged as recovery points in many BD h.264
streams do not result in complete frames when decoded. Pushing 2 extra
frames through the decoder seems to always fix this. This patch extends
something I was already doing when generating previews from a BD structure.
This just applies the same logic to ffmpeg streams that have h.264 video.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3895 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
| |
just an old thinko that needed correcting.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3894 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
We were converting SSA to UTF8 subs which looses a lot of formatting.
Now we pass through the ssa unmodified and add all fonts as attachments
to the mkv.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3891 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
This is necessary because MP4 does not support overlapping subtitles. Attempting to use overlapping subtitles causes the display of subsequent subtitles to be delayed incorrectly.
Subsequent patches may merge UTF-8 subtitles (upstream) so that this case does not occur.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3890 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the video stream is not the first track in the file, chapters were lost.
During scan, we identify which track is video and stash this in title.
While reading, when a chapter is found we want to tag the next video buffer.
But the video track id stored in the title was not being applied when
opening the file for reading, so the chapter mark always went on track id 0.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3889 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
The reference frames were not being tagged correctly during muxing
which really screwes up qt7 but appears to have little effect on qtx
or other players.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3887 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
| |
Makes it easier to read. Gets rid of some unnecessary variables.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3886 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
| |
Although the % option has been gone for a while in the cli and gui's,
there were some mappings happening in libhb and for preset imports.
This removes the last vestages of % quality mapping.
Thanks to Rodeo for the patch.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3857 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3853 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
| |
Falls back to /tmp if neither are set.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3852 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
| |
Thanks to Rodeo for the patch.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3851 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
| |
Thanks Rodeo ;)
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3849 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
| |
An error in interjob->vrate calculation lead to specifying a different
timebase for the 1st and 2nd pass which x264 does not allow. This
improves the interjob->vrate calculation accuracy and also guarantees
the timebase is the same on both passes regardless of the calculations
accuracy.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3848 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
Was using the incorrect field for actual "display" dimensions of video.
The field I was using is most often used for pan and scan which
crops a 16:9 image to fit a 4:3 display.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3847 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3841 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cli will now accept ':' separated parameters using the '-x' option
for ffmpeg mpeg-4. The linux gui has an entry box on the advanced tab
to add options. The option keys and values are the same as what the
ffmpeg command line allows.
Calculation of DTS timestamps was added to encavcodec.c in order to allow
out of order b-frames. The algorithm is similar to what x264 uses.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3839 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
| |
mpeg-2 dimensions must be multiples of 16, so the actual coded height
is 1088. But there are fields in the sequence header that define
the "display" height and width. We were ignoring these which lead
to slightly incorrect height and PAR.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3838 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
| |
This lets ffmpeg tell us when it needs a lock instead of
us trying to guess which functions we need to wrap in a mutex.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3834 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
| |
Removal of the workaround also removes the need for a patch
that fails to apply cleanly to latest ffmpeg git. So remove
the patch as well.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3833 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
| |
make keyint and fps settings consistent across video encoders.
make interjob->vrate changes for pfr mode like we do for vfr since
pfr is the same as vfr except when it hits it's peak.
in mkv, set track default duration to actual measured vrate on 2 pass encodes.
thanks to Rodeo for the corrections in encx264
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3831 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3822 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
| |
sources that don't support multiple angles should default to 1
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3821 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Waiting for a fill threshhold in the fifos causes some non-determinism
in finding the first PTS value. Sometimes the fill level of one fifo
would not be reached until after another fifo is completely full, causing
an early exit in the loop that looks for the first PTS. When the initial PTS
is different between passes, the duration of the first frame is different.
This affects the PFR algorithm and can cause it to drop a different number
of frames.
The fill level was initially intended as a way to prevent thrashing between
threads to improve performance. But my testing indicates no degradation
when removing it.
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3819 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
|
|
|
| |
fixes win64 crash
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3818 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3813 b64f7644-9d1e-0410-96f1-a4d463321fa5
|
|
|
|
| |
git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3812 b64f7644-9d1e-0410-96f1-a4d463321fa5
|