10- and 12-bit DNxHR use the same DC coefficient decoding process and
VLC table, just with a different shift value. From SMPTE 2019-1:2016,
8.2.4 DC Coefficient Decoding:
"For 8-bit video sampling, the maximum value of η=11 and for
10-/12-bit video sampling, the maximum value of η=13."
A sample file will be uploaded to show that with this patch, things
decode correctly:
dnxhr_hqx_12bit_1080p_smpte_colorbars_davinci_resolve.mov
Signed-off-by: Steven Robertson <steven@strobe.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In order to avoid possible clipping at the very
beginning. Especially apparent when "alternative"
boundary mode is used.
Adopted from original commit by committer.
The Doxygen command is generated from the list of installed headers,
which may change per configuration (e.g. `--enable-gpl` results in
libpostproc to be built and installed).
HDCD is only encoded in s16@44100Hz. Scan the chain of AVFilterLinks
for any resampling or format conversion/truncation that might cause
problems for the filter and issue warnings.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Issue #5727: gain adjustment should only be applied if matching
gain value from a valid packet in both channels. The existing functions process
each channel separately, so it was not possible.
* New versions of hdcd_process(), hdcd_scan(), hdcd_integrate() named
hdcd_*_stereo() that process both channels together.
* target_gain applied will be the last matching target_gain.
* The old single channel functions remain as an option. They can be
used by: -af hdcd=process_stereo=0.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'bc7f4268514624e1286ea76d27a89a56b4ee18e1':
h264: drop tests whether the codec id is AV_CODEC_ID_H264
Conflicts:
libavcodec/h264dec.c
Merged-by: James Almer <jamrial@gmail.com>
Used to attempt replication of some results from
http://www.audiomisc.co.uk/HFN/HDCD/Examined.html
May not be generally useful, defaults to off.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* Moves the filter context member out of state and into HDCDContext
* More useful information when an error is detected
* Gives a location near where the error was detected
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '70b1dcef2d859ae6b3e21d61de928c3dd0cf1aa4':
h264: tighten the valid range for ref_frame_count
Conflicts:
libavcodec/h264_ps.c
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f638b67e5790735f34620bf82025c9b9d6fc7216':
h264: move the parameter set definitions to a new header file
Conflicts:
libavcodec/h264_parse.h
libavcodec/h264_ps.c
libavcodec/h264dec.h
Merged-by: James Almer <jamrial@gmail.com>
The counter is now -1 if the code detect timer was never set,
and 0 if it was set but never expired.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The stereowiden filter uses a buffer, s->buffer[], and a pointer
within the buffer, s->write, to implement inter-channel delays.
The loop which applies the delayed samples turns out to be faulty.
109 for (n = 0; n < in->nb_samples; n++, src += 2, dst += 2) {
110 const float left = src[0], right = src[1];
111 float *read = s->write + 2;
112
113 if (read > s->buffer + s->length)
114 read = s->buffer;
115
116 dst[0] = drymix * left - crossfeed * right - feedback * read[1];
117 dst[1] = drymix * right - crossfeed * left - feedback * read[0];
118
119 s->write[0] = left;
120 s->write[1] = right;
121
122 if (s->write == s->buffer + s->length)
123 s->write = s->buffer;
124 else
125 s->write += 2;
126 }
For one, the buffer gets written past its end in lines 119-120, before
the bound check is done in lines 122-123. This can be easily confirmed
by valgrind.
==3544== Invalid read of size 4
==3544== at 0x593B41: filter_frame (af_stereowiden.c:116)
==3544== Address 0xb1b03c4 is 4 bytes after a block of size 7,680 alloc'd
==3544==
==3544== Invalid read of size 4
==3544== at 0x593B66: filter_frame (af_stereowiden.c:117)
==3544== Address 0xb1b03c0 is 0 bytes after a block of size 7,680 alloc'd
==3544==
==3544== Invalid write of size 4
==3544== at 0x593B79: filter_frame (af_stereowiden.c:119)
==3544== Address 0xb1b03c0 is 0 bytes after a block of size 7,680 alloc'd
==3544==
==3544== Invalid write of size 4
==3544== at 0x593B7D: filter_frame (af_stereowiden.c:120)
==3544== Address 0xb1b03c4 is 4 bytes after a block of size 7,680 alloc'd
Also, using two separate pointers, s->write and read = s->write + 2,
does not seem to be well thought out. To apply the delay of s->buffer[],
it is enough to read the delayed samples at the current position within
the buffer, and then to store new samples at the same current position.
Thus the application of delayed samples can probably be best described
with a single pointer s->cur.
I also introduce a minor change to ensure that the size of s->buffer[]
is always a multiple of 2. Since the delay parameter is a float, it is
otherwise possible to trick the code into allocating off-by-one buffer.
