Some versions of the GNU assembler do not handle 64-bit
immediate operands containing arithmetic. Writing the
value out in full works correctly.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit fce1e43410)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Set the frame size when decoding DTS audio.
This has the side effect of fixing the computation of timestamps for DTS-HD in compute_pkt_fields. Since frame_size is
not currently set, the duration of a frame is being guessed based on the streams bitrate. But for DTS-HD, the bitrate
currently used is the rate of the DTS core which is much different than the whole DTS-HD stream and leads to a wildly
inaccurate frame duration estimate.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit 49c7006c7e)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
filter_mb_fast assumed that qscale_table was padded like many of the other tables.
(cherry picked from commit 5029a40633)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The previously suggested replacement - av_get_bits_per_sample_fmt() -
was also deprecated.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit ccfa626db8)
Before this, almost all module groups have been used for grouping functions
and fields in structures semantically. This causes them to not appear
properly in the file documentation and needlessly clutters up the "Modules"
index.
Additionally, this commit streamlines some spelling and appearances.
(cherry picked from commit 21a19b7912)
2tap qpel isn't implemented yet for high bit depth, so it just breaks decoding.
(cherry picked from commit 9a0dda8b3a)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
From some tests it results that:
1. All of the AVI/MOV WRAW files need to be flipped.
2. MOV WRAW files need to use AVI color modes.
3. Assigning PAL8 mode by default to WRAW codec is not correct.
(cherry picked from commit 67e7dc5404)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The assert referenced a variable that no longer exists since 4:4:4 support.
(cherry picked from commit 6371ce4b0f)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
By observation it did not seem to handle prev_frame_num > frame_num.
This does not affect any files I have.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
One of the causes of this bug is that the h264 parser defaults low_delay
to 1, but the h264 codec defaults low_delay to 0. Really Ugly.
After many hours of looking at this, I'm still not sure how has_b_frames
is *intended* to behave, but to me the implementation appears way more
complicated than it ought to be.
My patch relies on the encoder to set an optional field in the SPS. This
works for libx264 streams, but I'm not sure that all h264 encoders will
set it.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
