Re: [FFmpeg-devel] [PATCH v4] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Tuesday, February 12, 2019 8:18 AM
It should be UTC time when received the email
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v4] Improved the performance of 1
> decode + N filter graphs and adaptive bitrate.
>
> On 11/02/2019 22:41, Shaofei Wang wrote:
And the above time I've sent the previous email is also a correct UTC time
> Please avoid sending messages from the future - the list received this about
> thirteen hours before its supposed send time (received "Mon, 11 Feb 2019
> 11:42:09 +0200", sent "Mon, 11 Feb 2019 17:41:04 -0500").
> Probably the sending machine or some intermediate has an incorrect time or
> time zone.
It may be the reason.
> Some numbers for more use-cases and platforms (with different architectures
> and core counts) would be a good idea if you intend to enable this by default.
It would be better to have more platforms data.
Actually, it provide option for user to choose a "faster" path in the previous
version. In this patch it simplified code path.
> Presumably it's a bit slower on less powerful machines with fewer cores when
> it makes many threads, but by how much? Is that acceptable?
Is it resource limited machine that we should disable HAVE_THREADS?
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index
> > 544f1a1..67b1a2a 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -1419,13 +1419,18 @@ static void
> finish_output_stream(OutputStream *ost)
> > *
> > * @return 0 for success, <0 for severe errors
> > */
> > -static int reap_filters(int flush)
> > +static int reap_filters(int flush, InputFilter * ifilter)
> > {
> > AVFrame *filtered_frame = NULL;
> > int i;
> >
> > -/* Reap all buffers present in the buffer sinks */
> > +/* Reap all buffers present in the buffer sinks or just reap specified
> > + * input filter buffer */
> > for (i = 0; i < nb_output_streams; i++) {
> > +if (ifilter) {
> > +if (ifilter != output_streams[i]->filter->graph->inputs[0])
> > +continue;
> > +}
>
> No mixed declarations and code.
OK.
> > OutputStream *ost = output_streams[i];
> > OutputFile*of = output_files[ost->file_index];
> > AVFilterContext *filter;
>
> How carefully has this been audited to make sure that there are no data races?
> The calls to init_output_stream() and do_video_out() both do /a lot/, and in
> particular they interact with the InputStream which might be shared with
> other threads (and indeed is in all your examples above).
Base on the code path of multithread, it won't have duplicated path to call
init_output_stream() and do_video_out(), since there's no output stream share
multiple filter graphs. And this concern should be hightlight, will investigate
more in the code.
> > @@ -2179,7 +2184,8 @@ static int ifilter_send_frame(InputFilter *ifilter,
> AVFrame *frame)
> > }
> > }
> >
> > -ret = reap_filters(1);
> > +ret = HAVE_THREADS ? reap_filters(1, ifilter) :
> > + reap_filters(1, NULL);
> > +
> > if (ret < 0 && ret != AVERROR_EOF) {
> > av_log(NULL, AV_LOG_ERROR, "Error while filtering: %s\n",
> av_err2str(ret));
> > return ret;
> > @@ -2208,6 +2214,14 @@ static int ifilter_send_eof(InputFilter
> > *ifilter, int64_t pts)
> >
> > ifilter->eof = 1;
> >
> > +#if HAVE_THREADS
> > +ifilter->waited_frm = NULL;
> > +pthread_mutex_lock(>process_mutex);
> > +ifilter->t_end = 1;
> > +pthread_cond_signal(>process_cond);
> > +pthread_mutex_unlock(>process_mutex);
> > +pthread_join(ifilter->f_thread, NULL); #endif
> > if (ifilter->filter) {
> > ret = av_buffersrc_close(ifilter->filter, pts,
> AV_BUFFERSRC_FLAG_PUSH);
> > if (ret < 0)
> > @@ -2252,12 +2266,95 @@ static int decode(AVCodecContext *avctx,
> AVFrame *frame, int *got_frame, AVPacke
> > return 0;
> > }
> >
> > +#if HAVE_THREADS
> > +static void *filter_pipeline(void *arg) {
> > +InputFilter *fl = arg;
> > +AVFrame *frm;
> > +int ret;
> > +while(1) {
> > +pthread_mutex_lock(>process_mutex);
> > +while (fl->waited_frm == NULL && !fl->t_end)
> > +pthread_cond_wait(>process_cond, >process_mutex);
> > +pthread_mutex_unlock(>process_mutex);
> > +
> > +if (fl->t_end) break;
> > +
> > +frm = fl->waited_frm;
> > +ret = ifilter_send_frame(fl, frm);
> > +if (ret < 0) {
> > +av_log(NULL, AV_LOG_ERROR,
> > + "Failed to inject frame into filter network: %s\n",
> av_err2str(ret));
> > +} else {
> > +ret = reap_filters(0, fl);
> > +}
> > +fl->t_error = ret;
> > +
> > +pthread_mutex_lock(>finish_mutex);
> > +fl->waited_frm = NULL;
> > +
Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Harish Krupo > Sent: Friday, February 08, 2019 4:17 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Cc: Strasser, Kevin ; Palli, Tapani > ; Sharma, Shashank > Subject: [FFmpeg-devel] SDR->HDR tone mapping algorithm? > > Hello, > > We are in the process of implementing HDR rendering support in the > Weston display compositor [1] (HDR discussion here [2]). When HDR > and SDR surfaces like a video buffer and a subtitle buffer are presented > together, the composition would take place as follows: > - If the display does not support HDR metadata: > in-coming HDR surfaces would be tone mapped using opengl to SDR and > blended with the other SDR surfaces. We are currently using the Hable > operator for tone mapping. > - If the display supports setting HDR metadata: > SDR surfaces would be tone mapped to HDR and blended with HDR surfaces. > > The literature available for SDR->HDR tone mapping varies from simple > linear expansion of luminance to CNN based approaches. We wanted to > know > your recommendations for an acceptable algorithm for SDR->HDR tone > mapping. > In ITU-R BT.2390 (https://www.itu.int/pub/R-REP-BT.2390) section 10, there is a discussion on the approach to preserve the look of the SDR content when shown on an HDR display. BTW, just curious why the HLG video/display is not considered in the wayland compositor, thanks. > Any help is greatly appreciated! > > [1] https://gitlab.freedesktop.org/wayland/weston > [2] https://lists.freedesktop.org/archives/wayland-devel/2019- > January/039809.html > > Thank you > Regards > Harish Krupo > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Automatically insert truehd_core bitstream filter
On Wed, Feb 13, 2019 at 2:57 AM Carl Eugen Hoyos wrote:
>
> 2019-02-13 0:47 GMT+01:00, Hendrik Leppkes :
> > On Tue, Feb 12, 2019 at 12:54 PM Carl Eugen Hoyos
> > wrote:
> >>
> >> 2019-02-12 12:37 GMT+01:00, Hendrik Leppkes :
> >> > On Tue, Feb 12, 2019 at 12:28 PM Carl Eugen Hoyos
> >> > wrote:
> >> >>
> >> >> Hi!
> >> >>
> >> >> Attached patch intends to fix ticket #7731.
> >> >
> >> > This is not a fix. The vast majority of TrueHD Atmos tracks work just
> >> > fine with the current limitations, and would needlessly drop the Atmos
> >> > information for every stream.
> >>
> >> Is it possible to detect if the Atmos core has to be dropped?
> >
> > Not beforehand, since the size of future frames is of course unknown,
> > and there are no indications in the bitstream.
> > One could consider starting to drop Atmos data after it happened once,
> > but it'll probably still glitch out audio at that point.
> >
> > Ideally the truehd spdif muxer should be revised to support a more
> > flexible buffering model, but its a tad bit complicated with the way
> > the spdif muxer is setup, and I've only recently learned myself how
> > its presumably supposed to be done, since the specifications are not
> > openly available.
>
> I did a few experiments before reading your mail:
> If I use a burst rate of significantly less than 2000 bytes
> audio gets broken with my receiver.
> Can you confirm that in any way?
> Otoh, it does not seem to help to insert memset(0)
> between frames if the burstrate is too low.
> ("burstrate": gap between beginnings of thd frames)
>
> It is not necessary to put 12 frames in both half-MAT frames,
> 15 and 9 work fine here.
>
> My receiver always fails / produces hickups if the thd stream
> contains atmos data: Are you sure it is supposed to work?
With every hardware? Who knows. My receiver does not support Atmos
either and it plays streams that exceed the 2560 size just fine with
correct muxing into MAT frames - although I haven't tested that one in
the ticket specifically I don't think, and I'm not near that receiver
until next week.
> Can you already provide a test stream for the audio stream
> from the ticket?
>
Sure, why not, although I have no idea how one would play this, since
you would need to make sure full MAT frames are always read and output
as one (ie. every 61440 bytes), and unfortunately our raw PCM demuxer
does not support specifying a wanted packet size, oh well.
https://files.1f0.de/tmp/truehd_11mbit_bug.spdif
Otherwise it should fit the typical TrueHD bitstreaming criteria, ie.
192kHz 8ch 16-bit "PCM", 61440 bytes frame size.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 01/12] vaapi_encode: Support more RC modes
2019-02-10 20:46 GMT+01:00, Mark Thompson : > Allow setting the mode explicitly, and try to make a sensible choice > given the available parameters if not. Please mention ticket #7650 if this patch fixes the assertion failure. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, v4] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Monday, January 14, 2019 09:08
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v4] lavc/hevc_parser: cope with more
> leading_zero_8bits and update FATE
>
> > -Original Message-
> > From: Fu, Linjie
> > Sent: Friday, January 11, 2019 15:29
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie
> > Subject: [PATCH,v4] lavc/hevc_parser: cope with more leading_zero_8bits
> > and update FATE
> >
> > Given that leading_zero_8bits can be included many times at the beginning
> > of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
> > in last frame.
> >
> > When startcode is found, go back to find all leading_zero_8bits in
> > current buffer and pc->buffer to cut correctly.
> >
> > Update the FATE checksum for fate-hevc-bsf-mp4toannexb:
> > The ref output has redundant 0x00 at the end of the SUFFIX_SEI:
> > { 50 01 84 31 00 19 39 77 d0 7b 3f bd 1e 09 38 9a 79 41
> > c0 16 11 da 18 aa 0a db 2b 19 fa 47 3f 0f 67 4a 91 9c a1
> > 12 72 67 d6 f0 8f 66 ee 95 f9 e2 b9 ba 23 9a e8 80 00 }
> >
> > To verify the output of FATE:
> > ffmpeg -i hevc-conformance/WPP_A_ericsson_MAIN10_2.bit -c copy -flags
> \
> > +bitexact hevc-mp4.mov
> > ffmpeg -i hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc hevc.out
> >
> > Signed-off-by: Linjie Fu
> > ---
> > [v2]: Update FATE checksum.
> > [v3]: Cope with more leading_zero_8bits cases.
> > [v4]: find leading_zero_8bits in pc->buffer to cut correctly.
> >
> > libavcodec/hevc_parser.c | 12
> > tests/fate/hevc.mak | 2 +-
> > 2 files changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> > index 369d1338d0..f6df43a067 100644
> > --- a/libavcodec/hevc_parser.c
> > +++ b/libavcodec/hevc_parser.c
> > @@ -267,8 +267,7 @@ static int
> > hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
> > if ((nut >= HEVC_NAL_VPS && nut <= HEVC_NAL_EOB_NUT) || nut ==
> > HEVC_NAL_SEI_PREFIX ||
> > (nut >= 41 && nut <= 44) || (nut >= 48 && nut <= 55)) {
> > if (pc->frame_start_found) {
> > -pc->frame_start_found = 0;
> > -return i - 5;
> > +goto found;
> > }
> > } else if (nut <= HEVC_NAL_RASL_R ||
> > (nut >= HEVC_NAL_BLA_W_LP && nut <= HEVC_NAL_CRA_NUT))
> {
> > @@ -277,14 +276,19 @@ static int
> > hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
> > if (!pc->frame_start_found) {
> > pc->frame_start_found = 1;
> > } else { // First slice of next frame found
> > -pc->frame_start_found = 0;
> > -return i - 5;
> > +goto found;
> > }
> > }
> > }
> > }
> >
> > return END_NOT_FOUND;
> > +
> > +found:
> > +pc->frame_start_found = 0;
> > +while (i - 6 >= 0 ? !buf[i - 6] : !pc->buffer[pc->index + i - 6])
> > +i--;
> > +return i - 5;
> > }
> >
> > static int hevc_parse(AVCodecParserContext *s, AVCodecContext *avctx,
> > diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> > index db3ea19340..ab8da53535 100644
> > --- a/tests/fate/hevc.mak
> > +++ b/tests/fate/hevc.mak
> > @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER
> > MOV_DEMUXER HEVC_MP4TOANNEXB_BSF MOV_MUXER
> > fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov
> > fate-hevc-bsf-mp4toannexb: CMD = md5 -i
> > $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f
> > hevc
> > fate-hevc-bsf-mp4toannexb: CMP = oneline
> > -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
> > +fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0
> >
> > fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i
> > $(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -
> sws_flags
> > bitexact
> > FATE_HEVC += fate-hevc-skiploopfilter
> > --
> > 2.17.1
>
> Ping for the latest update to find the correct frame end in both current buf
> and pc->buffer?
Any advice for the modification?
Checked the parser in H264, there are two conditions to find the frame end:
0x 00 00 01: return i - 4
0x 00 00 00 01 or 0x 00 00 ... 00 01 (more zero bytes): return i - 5;
more zero bytes situation will be treated as 4 bytes startcode.
So another way for this is to match the behavior in H264, and treat more zero
bytes as 4 bytes startcode temporary.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 01/12] vaapi_encode: Support more RC modes
On Mon, Feb 11, 2019 at 3:47 AM Mark Thompson wrote:
>
> Allow setting the mode explicitly, and try to make a sensible choice
> given the available parameters if not.
> ---
> doc/encoders.texi | 24 +++
> libavcodec/vaapi_encode.c | 382 +++---
> libavcodec/vaapi_encode.h | 65 +++
> 3 files changed, 358 insertions(+), 113 deletions(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5..29625ba07c 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2824,6 +2824,30 @@ Set the B-frame reference depth. When set to one (the
> default), all B-frames
> will refer only to P- or I-frames. When set to greater values multiple
> layers
> of B-frames will be present, frames in each layer only referring to frames in
> higher layers.
> +
> +@item rc_mode
> +Set the rate control mode to use. A given driver may only support a subset
> of
> +modes.
> +
> +Possible modes:
> +@table @option
> +@item auto
> +Choose the mode automatically based on driver support and the other options.
> +This is the default.
> +@item CQP
> +Constant-quality.
> +@item CBR
> +Constant-bitrate.
> +@item VBR
> +Variable-bitrate.
> +@item ICQ
> +Intelligent constant-quality.
> +@item QVBR
> +Quality-defined variable-bitrate.
> +@item AVBR
> +Average variable bitrate.
> +@end table
> +
> @end table
>
> Each encoder also has its own specific options:
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index b4e9fadaee..2dda451882 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1283,17 +1283,42 @@ fail:
> return err;
> }
>
> +static const VAAPIEncodeRCMode vaapi_encode_rc_modes[] = {
> +// Bitrate Quality
> +// | Maxrate | HRD/VBV
> +{ 0 }, // ||||
> +{ RC_MODE_CQP, "CQP", 1, VA_RC_CQP, 0, 0, 1, 0 },
> +{ RC_MODE_CBR, "CBR", 1, VA_RC_CBR, 1, 0, 0, 1 },
> +{ RC_MODE_VBR, "VBR", 1, VA_RC_VBR, 1, 1, 0, 1 },
> +#if VA_CHECK_VERSION(1, 1, 0)
> +{ RC_MODE_ICQ, "ICQ", 1, VA_RC_ICQ, 0, 0, 1, 0 },
> +#else
> +{ RC_MODE_ICQ, "ICQ", 0 },
> +#endif
> +#if VA_CHECK_VERSION(1, 3, 0)
> +{ RC_MODE_QVBR, "QVBR", 1, VA_RC_QVBR, 1, 1, 1, 1 },
> +{ RC_MODE_AVBR, "AVBR", 0, VA_RC_AVBR, 1, 0, 0, 0 },
> +#else
> +{ RC_MODE_QVBR, "QVBR", 0 },
> +{ RC_MODE_AVBR, "AVBR", 0 },
> +#endif
> +};
> +
> static av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
> {
> VAAPIEncodeContext *ctx = avctx->priv_data;
> +uint32_t supported_va_rc_modes;
> +const VAAPIEncodeRCMode *rc_mode;
> int64_t rc_bits_per_second;
> int rc_target_percentage;
> int rc_window_size;
> +int rc_quality;
> int64_t hrd_buffer_size;
> int64_t hrd_initial_buffer_fullness;
> int fr_num, fr_den;
> VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
> VAStatus vas;
> +char supported_rc_modes_string[64];
>
> vas = vaGetConfigAttributes(ctx->hwctx->display,
> ctx->va_profile, ctx->va_entrypoint,
> @@ -1303,119 +1328,213 @@ static av_cold int
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
> "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> return AVERROR_EXTERNAL;
> }
> -
> if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
> - "supported rate control modes: assuming constant-quality.\n");
> -ctx->va_rc_mode = VA_RC_CQP;
> -return 0;
> -}
> -if (ctx->codec->flags & FLAG_CONSTANT_QUALITY_ONLY ||
> -avctx->flags & AV_CODEC_FLAG_QSCALE ||
> -avctx->bit_rate <= 0) {
> -if (rc_attr.value & VA_RC_CQP) {
> -av_log(avctx, AV_LOG_VERBOSE, "Using constant-quality mode.\n");
> -ctx->va_rc_mode = VA_RC_CQP;
> -if (avctx->bit_rate > 0 || avctx->rc_max_rate > 0) {
> -av_log(avctx, AV_LOG_WARNING, "Bitrate target parameters "
> - "ignored in constant-quality mode.\n");
> + "supported rate control modes: assuming CQP only.\n");
> +supported_va_rc_modes = VA_RC_CQP;
> +strcpy(supported_rc_modes_string, "unknown");
> +} else {
> +char *str = supported_rc_modes_string;
> +size_t len = sizeof(supported_rc_modes_string);
> +int i, first = 1, res;
> +
> +supported_va_rc_modes = rc_attr.value;
> +for (i = 0; i < FF_ARRAY_ELEMS(vaapi_encode_rc_modes); i++) {
> +rc_mode = _encode_rc_modes[i];
> +if (supported_va_rc_modes & rc_mode->va_mode) {
> +res = snprintf(str, len, "%s%s",
> + first ? "" : ", ", rc_mode->name);
> +first = 0;
> +
[FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution changes little
Currently, resolution change detection is based on 16 alignment,
small resolution changes (same after FFALIGN 16) in coded width or
coded height will not trigger the reinit and will lead to a decode
failure.
Modify to use last_coded_width and last_coded_height to detect the
small resolution change.
Signed-off-by: Linjie Fu
---
libavcodec/qsvdec.c | 8 +---
libavcodec/qsvdec.h | 2 ++
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 4a0be811fb..b29f869366 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -523,9 +523,9 @@ int ff_qsv_process_data(AVCodecContext *avctx, QSVContext
*q,
avctx->field_order = q->parser->field_order;
/* TODO: flush delayed frames on reinit */
-if (q->parser->format != q->orig_pix_fmt||
-FFALIGN(q->parser->coded_width, 16) != FFALIGN(avctx->coded_width,
16) ||
-FFALIGN(q->parser->coded_height, 16) != FFALIGN(avctx->coded_height,
16)) {
+if (q->parser->format != q->orig_pix_fmt ||
+q->last_coded_height != q->parser->coded_height ||
+q->last_coded_width != q->parser->coded_width) {
enum AVPixelFormat pix_fmts[3] = { AV_PIX_FMT_QSV,
AV_PIX_FMT_NONE,
AV_PIX_FMT_NONE };
@@ -558,6 +558,8 @@ int ff_qsv_process_data(AVCodecContext *avctx, QSVContext
*q,
avctx->coded_height = FFALIGN(q->parser->coded_height, 16);
avctx->level= q->avctx_internal->level;
avctx->profile = q->avctx_internal->profile;
+q->last_coded_width = q->parser->coded_width;
+q->last_coded_height = q->parser->coded_height;
ret = ff_get_format(avctx, pix_fmts);
if (ret < 0)
diff --git a/libavcodec/qsvdec.h b/libavcodec/qsvdec.h
index 111536caba..1af0c42404 100644
--- a/libavcodec/qsvdec.h
+++ b/libavcodec/qsvdec.h
@@ -55,6 +55,8 @@ typedef struct QSVContext {
int zero_consume_run;
int buffered_count;
int reinit_flag;
+int last_coded_width;
+int last_coded_height;
// the internal parser and codec context for parsing the data
AVCodecParserContext *parser;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Automatically insert truehd_core bitstream filter
2019-02-13 0:47 GMT+01:00, Hendrik Leppkes :
> On Tue, Feb 12, 2019 at 12:54 PM Carl Eugen Hoyos
> wrote:
>>
>> 2019-02-12 12:37 GMT+01:00, Hendrik Leppkes :
>> > On Tue, Feb 12, 2019 at 12:28 PM Carl Eugen Hoyos
>> > wrote:
>> >>
>> >> Hi!
>> >>
>> >> Attached patch intends to fix ticket #7731.
>> >
>> > This is not a fix. The vast majority of TrueHD Atmos tracks work just
>> > fine with the current limitations, and would needlessly drop the Atmos
>> > information for every stream.
>>
>> Is it possible to detect if the Atmos core has to be dropped?
>
> Not beforehand, since the size of future frames is of course unknown,
> and there are no indications in the bitstream.
> One could consider starting to drop Atmos data after it happened once,
> but it'll probably still glitch out audio at that point.
>
> Ideally the truehd spdif muxer should be revised to support a more
> flexible buffering model, but its a tad bit complicated with the way
> the spdif muxer is setup, and I've only recently learned myself how
> its presumably supposed to be done, since the specifications are not
> openly available.
I did a few experiments before reading your mail:
If I use a burst rate of significantly less than 2000 bytes
audio gets broken with my receiver.
Can you confirm that in any way?
Otoh, it does not seem to help to insert memset(0)
between frames if the burstrate is too low.
("burstrate": gap between beginnings of thd frames)
It is not necessary to put 12 frames in both half-MAT frames,
15 and 9 work fine here.
My receiver always fails / produces hickups if the thd stream
contains atmos data: Are you sure it is supposed to work?
Can you already provide a test stream for the audio stream
from the ticket?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V3] tests/api/api-h264-test: Add AV_NOPTS_VALUE check for AVFrame.pkt_dts/pts
On Tue, Feb 12, 2019 at 9:27 PM Michael Niedermayer wrote: > > On Tue, Feb 12, 2019 at 02:31:20PM +0800, Jun Zhao wrote: > > Use av_ts2str() for AVFrame.pkt_dts/pts to avoid print the > > pkt_dts/pts as negative number like: > > "0,3616613, -9223372036854775808, 1001, 3110400, 0x75e37a65" > > > > Reviewed-by: Michael Niedermayer > > Signed-off-by: Jun Zhao > > --- > > tests/api/api-h264-test.c |7 --- > > 1 files changed, 4 insertions(+), 3 deletions(-) > > LGTM > > thx > Pushed, tks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] MAINTAINERS: add myself for tonemap_opencl
Signed-off-by: Ruiling Song --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7ac2d22..412a739 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -362,6 +362,7 @@ Filters: vf_ssim.c Paul B Mahol vf_stereo3d.c Paul B Mahol vf_telecine.c Paul B Mahol + vf_tonemap_opencl.c Ruiling Song vf_yadif.cMichael Niedermayer vf_zoompan.c Paul B Mahol -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for handling braces
From: Kevin Backhouse via RT
Fixes: [Semmle Security Reports #19439]
Fixes: dos_sscanf2.mkv
Signed-off-by: Michael Niedermayer
---
libavcodec/htmlsubtitles.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
index c0cfccfb16..d9221ba16b 100644
--- a/libavcodec/htmlsubtitles.c
+++ b/libavcodec/htmlsubtitles.c
@@ -24,6 +24,7 @@
#include "libavutil/common.h"
#include "libavutil/parseutils.h"
#include "htmlsubtitles.h"
+#include
static int html_color_parse(void *log_ctx, const char *str)
{
@@ -44,14 +45,32 @@ static void rstrip_spaces_buf(AVBPrint *buf)
buf->str[--buf->len] = 0;
}
+/*
+ * Fast code for scanning text enclosed in braces. Functionally
+ * equivalent to this sscanf call:
+ *
+ * sscanf(in, "{\\an%*1u}%n", ) >= 0 && len > 0
+ */
+static int scanbraces(const char* in) {
+if (strncmp(in, "{\\an", 4) != 0) {
+return 0;
+}
+if (!isdigit(in[4])) {
+return 0;
+}
+if (in[5] != '}') {
+return 0;
+}
+return 1;
+}
+
/* skip all {\xxx} substrings except for {\an%d}
and all microdvd like styles such as {Y:xxx} */
static void handle_open_brace(AVBPrint *dst, const char **inp, int *an, int
*closing_brace_missing)
{
-int len = 0;
const char *in = *inp;
-*an += sscanf(in, "{\\an%*1u}%n", ) >= 0 && len > 0;
+*an += scanbraces(in);
if (!*closing_brace_missing) {
if ( (*an != 1 && in[1] == '\\')
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for tag scaning
From: Kevin Backhouse via RT
Fixes: [Semmle Security Reports #19438]
Fixes: dos_sscanf1.mkv
Signed-off-by: Michael Niedermayer
---
libavcodec/htmlsubtitles.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
index fb9f900422..c0cfccfb16 100644
--- a/libavcodec/htmlsubtitles.c
+++ b/libavcodec/htmlsubtitles.c
@@ -74,6 +74,34 @@ struct font_tag {
uint32_t color;
};
+/*
+ * Fast code for scanning the rest of a tag. Functionally equivalent to
+ * this sscanf call:
+ *
+ * sscanf(in, "%127[^<>]>%n", buffer, lenp) == 2
+ */
+static int scantag(const char* in, char* buffer, int* lenp) {
+int len;
+
+for (len = 0; len < 128; len++) {
+const char c = *in++;
+switch (c) {
+case '\0':
+return 0;
+case '<':
+return 0;
+case '>':
+buffer[len] = '\0';
+*lenp = len+1;
+return 1;
+default:
+break;
+}
+buffer[len] = c;
+}
+return 0;
+}
+
/*
* The general politic of the convert is to mask unsupported tags or formatting
* errors (but still alert the user/subtitles writer with an error/warning)
@@ -155,7 +183,7 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst,
const char *in)
len = 0;
-if (sscanf(in+tag_close+1, "%127[^<>]>%n", buffer, ) >= 1 &&
len > 0) {
+if (scantag(in+tag_close+1, buffer, ) && len > 0) {
const int skip = len + tag_close;
const char *tagname = buffer;
while (*tagname == ' ') {
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Automatically insert truehd_core bitstream filter
On Tue, Feb 12, 2019 at 12:54 PM Carl Eugen Hoyos wrote: > > 2019-02-12 12:37 GMT+01:00, Hendrik Leppkes : > > On Tue, Feb 12, 2019 at 12:28 PM Carl Eugen Hoyos > > wrote: > >> > >> Hi! > >> > >> Attached patch intends to fix ticket #7731. > > > > This is not a fix. The vast majority of TrueHD Atmos tracks work just > > fine with the current limitations, and would needlessly drop the Atmos > > information for every stream. > > Is it possible to detect if the Atmos core has to be dropped? > Not beforehand, since the size of future frames is of course unknown, and there are no indications in the bitstream. One could consider starting to drop Atmos data after it happened once, but it'll probably still glitch out audio at that point. Ideally the truehd spdif muxer should be revised to support a more flexible buffering model, but its a tad bit complicated with the way the spdif muxer is setup, and I've only recently learned myself how its presumably supposed to be done, since the specifications are not openly available. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/jacosubdec: compute subtitle duration correctly
2019-02-13 0:13 GMT+01:00, Adam Sampson :
> When a JACOsub subtitle has two timestamps, they represent its start and
> end times (http://unicorn.us.com/jacosub/jscripts.html#l_times); the
> duration is the difference between the two, not the sum of the two.
>
> Tested using MPV, a LaserDisc, and some authentic 1993 JACOsub files.
> ---
> libavformat/jacosubdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/jacosubdec.c b/libavformat/jacosubdec.c
> index 520c435cc5..f6be5df2d7 100644
> --- a/libavformat/jacosubdec.c
> +++ b/libavformat/jacosubdec.c
> @@ -127,7 +127,7 @@ shift_and_ret:
> ts_start = (ts_start + jacosub->shift) * 100 / jacosub->timeres;
> ts_end= (ts_end + jacosub->shift) * 100 / jacosub->timeres;
> *start= ts_start;
> -*duration = ts_start + ts_end;
> +*duration = ts_end - ts_start;
> return buf + len;
> }
>
> --
> 2.20.1
Breaks fate-sub-jacosub
Carl Eugen
TESTsub-jacosub
--- ./tests/ref/fate/sub-jacosub2018-06-13 12:01:53.103787400 +0200
+++ tests/data/fate/sub-jacosub 2019-02-13 00:39:29.537974964 +0100
@@ -10,14 +10,14 @@
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
-Dialogue: 0,0:00:00.12,0:00:04.36,Default,,0,0,0,,{\an5}JACOsub\N\NThis
script demonstrates some of the capabilities of JACOsub.
-Dialogue: 0,0:00:04.12,0:00:14.86,Default,,0,0,0,,{\an8}Text may be
positioned at the top,
-Dialogue: 0,0:00:05.12,0:00:17.46,Default,,0,0,0,,{\an5}middle,
-Dialogue: 0,0:00:06.12,0:00:20.06,Default,,0,0,0,,{\an2}or bottom of
the screen.
-Dialogue: 0,0:00:08.12,0:00:27.36,Default,,0,0,0,,{\an5}{this is a
comment} (And, you just saw, {another comment} timing ranges for
different lines of text.
-Dialogue: 0,0:00:11.12,0:00:35.86,Default,,0,0,0,,{\an1}Within margin
constraints\Nthat you set, text may be\Nleft justified,
-Dialogue: 0,0:00:13.62,0:00:42.11,Default,,0,0,0,,{\an2}{the JC is
redundant - it's the default}center\Njustified,
-Dialogue: 0,0:00:14.87,0:00:45.86,Default,,0,0,0,,{\an3}and
also\Nright justified.
-Dialogue: 0,0:00:22.42,0:01:12.76,Default,,0,0,0,,Text may appear in
different styles\N(Normal, {\b1}Bold{\r}, {\i1}Italic{\r})
-Dialogue: 0,0:01:16.12,0:03:53.36,Default,,0,0,0,,{\an5}\N\NAt that
time, you may press any key to return to the Editor.
-Dialogue: 0,0:01:16.12,0:03:53.36,Default,,0,0,0,,OK, this script
will be finished when the screen goes blank.
+Dialogue: 0,0:00:00.12,0:00:04.12,Default,,0,0,0,,{\an5}JACOsub\N\NThis
script demonstrates some of the capabilities of JACOsub.
+Dialogue: 0,0:00:04.12,0:00:06.62,Default,,0,0,0,,{\an8}Text may be
positioned at the top,
+Dialogue: 0,0:00:05.12,0:00:07.22,Default,,0,0,0,,{\an5}middle,
+Dialogue: 0,0:00:06.12,0:00:07.82,Default,,0,0,0,,{\an2}or bottom of
the screen.
+Dialogue: 0,0:00:08.12,0:00:11.12,Default,,0,0,0,,{\an5}{this is a
comment} (And, you just saw, {another comment} timing ranges for
different lines of text.
+Dialogue: 0,0:00:11.12,0:00:13.62,Default,,0,0,0,,{\an1}Within margin
constraints\Nthat you set, text may be\Nleft justified,
+Dialogue: 0,0:00:13.62,0:00:14.87,Default,,0,0,0,,{\an2}{the JC is
redundant - it's the default}center\Njustified,
+Dialogue: 0,0:00:14.87,0:00:16.12,Default,,0,0,0,,{\an3}and
also\Nright justified.
+Dialogue: 0,0:00:22.42,0:00:27.92,Default,,0,0,0,,Text may appear in
different styles\N(Normal, {\b1}Bold{\r}, {\i1}Italic{\r})
+Dialogue: 0,0:01:16.12,0:01:21.12,Default,,0,0,0,,{\an5}\N\NAt that
time, you may press any key to return to the Editor.
+Dialogue: 0,0:01:16.12,0:01:21.12,Default,,0,0,0,,OK, this script
will be finished when the screen goes blank.
Test sub-jacosub failed. Look at tests/data/fate/sub-jacosub.err for details.
make: *** [fate-sub-jacosub] Error 1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/jacosubdec: compute subtitle duration correctly
When a JACOsub subtitle has two timestamps, they represent its start and end times (http://unicorn.us.com/jacosub/jscripts.html#l_times); the duration is the difference between the two, not the sum of the two. Tested using MPV, a LaserDisc, and some authentic 1993 JACOsub files. --- libavformat/jacosubdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/jacosubdec.c b/libavformat/jacosubdec.c index 520c435cc5..f6be5df2d7 100644 --- a/libavformat/jacosubdec.c +++ b/libavformat/jacosubdec.c @@ -127,7 +127,7 @@ shift_and_ret: ts_start = (ts_start + jacosub->shift) * 100 / jacosub->timeres; ts_end= (ts_end + jacosub->shift) * 100 / jacosub->timeres; *start= ts_start; -*duration = ts_start + ts_end; +*duration = ts_end - ts_start; return buf + len; } -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: Do not use reference stream in mov_read_sidx() if there is no reference stream
Fixes: NULL pointer dereference
Fixes: clusterfuzz-testcase-minimized-audio_decoder_fuzzer-5634316373721088
Reported-by: Chris Cunningham
Reviewed-by: Chris Cunningham
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 73a5ec240e..6aaba1e290 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5048,7 +5048,7 @@ static int mov_read_sidx(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
for (i = 0; i < c->fc->nb_streams; i++) {
st = c->fc->streams[i];
sc = st->priv_data;
-if (!sc->has_sidx) {
+if (ref_st && !sc->has_sidx) {
st->duration = sc->track_end = av_rescale(ref_st->duration,
sc->time_scale, ref_sc->time_scale);
}
}
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: fix dependencies for mlp and truehd encoders
2019-02-12 17:51 GMT+01:00, Moritz Barsnick : > Signed-off-by: Moritz Barsnick > --- > > Found with a minimal build using "--enable-encoder=truehd" Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] lavc/libaribb24: add error handling to region handling
On Tue, Feb 12, 2019 at 2:16 AM Michael Niedermayer wrote: > > On Mon, Feb 11, 2019 at 03:06:51AM +0200, Jan Ekström wrote: > > Fixes some rather embarrassing mistakes that somehow passed my > > eyes. > > > > * Now catches if memory allocation has failed during bprint usage > > by checking av_bprint_is_complete(). > > * Now catches if adding an ASS rectangle into an AVSubtitle failed. > > * Returns AVERROR_INVALIDDATA if we get an invalid region buffer > > length. > > --- > > libavcodec/libaribb24.c | 25 ++--- > > 1 file changed, 18 insertions(+), 7 deletions(-) > > probably ok > > thx > Thanks for the review, will do a final check-up and apply. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: fix dependencies for mlp and truehd encoders
Signed-off-by: Moritz Barsnick --- Found with a minimal build using "--enable-encoder=truehd" I reviewed other libavcodec sources makeing use of audio_frame_queue, and their dependencies all seem to include this, but I didn't check which sub- decoders are defined by these source files. (Like here: truehd_encoder is provided by mlpenc.c.) configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index ac2d7ab402..bf40c1dcb9 100755 --- a/configure +++ b/configure @@ -2699,7 +2699,7 @@ mjpeg_decoder_select="blockdsp hpeldsp exif idctdsp jpegtables" mjpeg_encoder_select="jpegtables mpegvideoenc" mjpegb_decoder_select="mjpeg_decoder" mlp_decoder_select="mlp_parser" -mlp_encoder_select="lpc" +mlp_encoder_select="lpc audio_frame_queue" motionpixels_decoder_select="bswapdsp" mp1_decoder_select="mpegaudio" mp1float_decoder_select="mpegaudio" @@ -2781,7 +2781,7 @@ thp_decoder_select="mjpeg_decoder" tiff_decoder_suggest="zlib lzma" tiff_encoder_suggest="zlib" truehd_decoder_select="mlp_parser" -truehd_encoder_select="lpc" +truehd_encoder_select="lpc audio_frame_queue" truemotion2_decoder_select="bswapdsp" truespeech_decoder_select="bswapdsp" tscc_decoder_deps="zlib" -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?
Hi Niklas, Thanks a lot for your comments. Please find my reply inline. Niklas Haas writes: > Hi, > > The important thing to consider is what constraints we are trying to > solve. And I think the expected behavior is that an SDR signal in SDR > mode should look identical to an SDR signal in HDR mode, to the end > user. > > This is, of course, an impossible constraint to solve, since we don't > know anything about the display, either in HDR or in SDR mode. At best, > in the absence of this knowledge, we could make a guess (e.g. it's > roughly described by sRGB in SDR mode, and for HDR mode it roughly > follows the techniques outlined in ITU-R Report BT.2390). Better yet > would be to actually obtain this information from somewhere, but where? > (The user? ICC profile? EDID?). Being the compositor we already have access to EDID, which means we can make intelligent decisions based on the capabilities of the display. Also, benefit of being the compositor is to have the complete knowledge of all the buffers to be displayed, thus we can make informed decisions about the optimal output for the display. > > But the bottom line is that to solve the "make SDR in HDR mode appear > identical to SDR in SDR mode" constraint, the curve you are trying to > invert is not your own tone mapping operator, but the tone mapping > operator implemented by the display (in HDR mode), which definitely > depends on what brightness level the display is targeting (in both SDR > and HDR modes). > If I have to explain our implementation better, we decide on the target HDR metadata and eotf and use this for both tone mapping as well as settting output display configuration (like setting HDMI AVI infoframes), which means the display and the compositor are in-sync about the eotf curve. > For an ideal HDR display, this would simply be the PQ curve's exact > definition (i.e. noop tone mapping). But in practice, the display will > almost surely not be capable of displaying up to 10,000 nits, so it will > implement a tone mapping operator of some kind (even if it's as simple > as clipping the extra range). Some colorimetric/reference displays > actually do the latter, since they prefer clipping out-of-range signals > over distorting in-range ones. But most consumer displays will probably > do something similar to the hable curve, most likely in per-channel > modes. > I agree. This is something which we thought of but as these implementations are internal to the display, we anyways dont have any control over this. > For an ideal SDR display, it depends on who you ask (w.r.t what "ideal" > means). In the ITU-R world, an ideal SDR reference display implements > the BT.1886 transfer function. In practice, it's probably closer to a > pure power gamma 2.2 curve. Or maybe sRGB. We really have nothing else > to do here except either consult an ICC profile or just stick our head > in the sand and guess randomly. > In our implementation: - When we have a combination of HDR and SDR content to be displayed we apply proper degamma/eotf on each buffer, convert its colorspace to the target gamut, blend both the buffers, apply output inverse_eotf of the HDR content and then send it to display. - If there is only a SDR buffer(s) we do not touch it and send it to display, setting the right (SDR) avi infoframe. Do you think this is good enough? More details here [1]. > -- > > I'd also like to comment on your compositor design proposal. A few notes: > > 1. It's always beneficial to do as few color conversion steps as >possible, to minimize cumulative errors and optimize performance. If >you use a 3DLUT as any step (e.g. for implementing an ICC-profile >based mapping), the 3DLUT should be as "wide" as possible and cover >as many operations as possible, so that the 3DLUT can be end-to-end >optimized (by the CMM). > >If you insist on doing compositing in linear light, then I would >probably composite in display-referred linear light and convert it to >non-linear light during scanout (either by implementing the needed >OETF + linear tone mapping operator via the VCGTs, or by doing a >non-linear tone mapping pass). But I would recommend trying to avoid >any second gamut conversion step (e.g. from BT.2020 to the display's >space after compositing). > >Otherwise, I would composite directly in the target color space >(saving us one final conversion step), which would obviously be >preferable if there are no transparency effects to worry about. >Maybe we could even switch dynamically between the two depending on >whether any blending needs to occur? Assuming we can update the VCGTs >atomically and without meaningful latency. > We agree and thats why, while deciding the target color space in the compositor we consider the display's supported colorspaces. This means we will only apply one gamut conversion step per
Re: [FFmpeg-devel] [PATCH V3] tests/api/api-h264-test: Add AV_NOPTS_VALUE check for AVFrame.pkt_dts/pts
On Tue, Feb 12, 2019 at 02:31:20PM +0800, Jun Zhao wrote: > Use av_ts2str() for AVFrame.pkt_dts/pts to avoid print the > pkt_dts/pts as negative number like: > "0,3616613, -9223372036854775808, 1001, 3110400, 0x75e37a65" > > Reviewed-by: Michael Niedermayer > Signed-off-by: Jun Zhao > --- > tests/api/api-h264-test.c |7 --- > 1 files changed, 4 insertions(+), 3 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/truehd_core: Initialize the last bytes of the output buffer
Hi!
The output of truehd_core is currently undeterministic, the last bytes
are uninitialized, valgrind protests if less than 8 bytes are
initialized.
I believe attached patch is simpler than calculating the necessary
write size at the bottom of the function.
Please comment, Carl Eugen
From e824c88cc15446cc0e3f80672a38f850b3a7 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 12 Feb 2019 12:54:31 +0100
Subject: [PATCH] lavc/truehd_core: Initialize the last bytes of the output
buffer.
Avoids undeterministic output.
---
libavcodec/truehd_core_bsf.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/truehd_core_bsf.c b/libavcodec/truehd_core_bsf.c
index be021af..a78eedc 100644
--- a/libavcodec/truehd_core_bsf.c
+++ b/libavcodec/truehd_core_bsf.c
@@ -117,6 +117,8 @@ static int truehd_core_filter(AVBSFContext *ctx, AVPacket *out)
out->size -= reduce * 2;
parity_nibble ^= out->size / 2;
+if (out_size > 8)
+memset(out->data + out_size - 8, 0, 8);
if (have_header) {
memcpy(out->data + 4, in->data + 4, 28);
out->data[16 + 4] = (out->data[16 + 4] & 0x0f) | (FFMIN(s->hdr.num_substreams, 3) << 4);
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Automatically insert truehd_core bitstream filter
2019-02-12 12:37 GMT+01:00, Hendrik Leppkes : > On Tue, Feb 12, 2019 at 12:28 PM Carl Eugen Hoyos > wrote: >> >> Hi! >> >> Attached patch intends to fix ticket #7731. > > This is not a fix. The vast majority of TrueHD Atmos tracks work just > fine with the current limitations, and would needlessly drop the Atmos > information for every stream. Is it possible to detect if the Atmos core has to be dropped? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Automatically insert truehd_core bitstream filter
On Tue, Feb 12, 2019 at 12:28 PM Carl Eugen Hoyos wrote: > > Hi! > > Attached patch intends to fix ticket #7731. > This is not a fix. The vast majority of TrueHD Atmos tracks work just fine with the current limitations, and would needlessly drop the Atmos information for every stream. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/spdifenc: Automatically insert truehd_core bitstream filter
Hi!
Attached patch intends to fix ticket #7731.
Please comment, Carl Eugen
From bf68eb44a9a27ca8c9e832e8f0cbd08a0d0b5281 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 12 Feb 2019 12:15:02 +0100
Subject: [PATCH] lavf/spdifenc: Automatically insert truehd_core bitstream
filter.
Fixes ticket #7731.
---
libavformat/spdifenc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavformat/spdifenc.c b/libavformat/spdifenc.c
index 9514ff8..ecfe28c 100644
--- a/libavformat/spdifenc.c
+++ b/libavformat/spdifenc.c
@@ -49,6 +49,7 @@
#include "avformat.h"
#include "avio_internal.h"
#include "spdif.h"
+#include "internal.h"
#include "libavcodec/ac3.h"
#include "libavcodec/adts_parser.h"
#include "libavcodec/dca.h"
@@ -546,6 +547,18 @@ static int spdif_write_packet(struct AVFormatContext *s, AVPacket *pkt)
return 0;
}
+static int spdif_check_bitstream(struct AVFormatContext *s, const AVPacket *pkt)
+{
+int ret = 1;
+AVStream *st = s->streams[pkt->stream_index];
+
+if (st->codecpar->codec_id == AV_CODEC_ID_TRUEHD) {
+ret = ff_stream_add_bitstream_filter(st, "truehd_core", NULL);
+}
+
+return ret;
+}
+
AVOutputFormat ff_spdif_muxer = {
.name = "spdif",
.long_name = NULL_IF_CONFIG_SMALL("IEC 61937 (used on S/PDIF - IEC958)"),
@@ -556,6 +569,7 @@ AVOutputFormat ff_spdif_muxer = {
.write_header = spdif_write_header,
.write_packet = spdif_write_packet,
.write_trailer = spdif_write_trailer,
+.check_bitstream = spdif_check_bitstream,
.flags = AVFMT_NOTIMESTAMPS,
.priv_class= _class,
};
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize theora decoding with mmi.
Optimize theora decoding with mmi in functions:
1. ff_vp3_idct_add_mmi
2. ff_vp3_idct_put_mmi
3. ff_vp3_idct_dc_add_mmi
4. ff_put_no_rnd_pixels_l2_mmi
Theora decoding speed improved about 32%(from 88fps to 116fps, Tested on
loongson 3A3000).
---
libavcodec/mips/Makefile | 1 +
libavcodec/mips/vp3dsp_idct_mmi.c | 769 +
libavcodec/mips/vp3dsp_init_mips.c | 14 +
libavcodec/mips/vp3dsp_mips.h | 6 +
4 files changed, 790 insertions(+)
create mode 100644 libavcodec/mips/vp3dsp_idct_mmi.c
diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 3029872..c827649 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -87,3 +87,4 @@ MMI-OBJS-$(CONFIG_HPELDSP)+=
mips/hpeldsp_mmi.o
MMI-OBJS-$(CONFIG_VC1_DECODER)+= mips/vc1dsp_mmi.o
MMI-OBJS-$(CONFIG_WMV2DSP)+= mips/wmv2dsp_mmi.o
MMI-OBJS-$(CONFIG_HEVC_DECODER) += mips/hevcdsp_mmi.o
+MMI-OBJS-$(CONFIG_VP3DSP) += mips/vp3dsp_idct_mmi.o
diff --git a/libavcodec/mips/vp3dsp_idct_mmi.c
b/libavcodec/mips/vp3dsp_idct_mmi.c
new file mode 100644
index 000..c5c4cf3
--- /dev/null
+++ b/libavcodec/mips/vp3dsp_idct_mmi.c
@@ -0,0 +1,769 @@
+/*
+ * Copyright (c) 2018 gxw
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "vp3dsp_mips.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mips/mmiutils.h"
+#include "libavutil/common.h"
+#include "libavcodec/rnd_avg.h"
+
+#define LOAD_CONST(dst, value)\
+"li %[tmp1], "#value" \n\t" \
+"dmtc1 %[tmp1], "#dst"\n\t" \
+"pshufh "#dst", "#dst", %[ftmp10] \n\t"
+
+static void idct_row_mmi(int16_t *input)
+{
+double ftmp[23];
+uint64_t tmp[2];
+__asm__ volatile (
+"xor%[ftmp10], %[ftmp10],%[ftmp10] \n\t"
+LOAD_CONST(%[csth_1], 1)
+"li %[tmp0],0x02\n\t"
+"1: \n\t"
+/* Load input */
+"ldc1 %[ftmp0], 0x00(%[input]) \n\t"
+"ldc1 %[ftmp1], 0x10(%[input]) \n\t"
+"ldc1 %[ftmp2], 0x20(%[input]) \n\t"
+"ldc1 %[ftmp3], 0x30(%[input]) \n\t"
+"ldc1 %[ftmp4], 0x40(%[input]) \n\t"
+"ldc1 %[ftmp5], 0x50(%[input]) \n\t"
+"ldc1 %[ftmp6], 0x60(%[input]) \n\t"
+"ldc1 %[ftmp7], 0x70(%[input]) \n\t"
+LOAD_CONST(%[ftmp8], 64277)
+LOAD_CONST(%[ftmp9], 12785)
+"pmulhh %[A], %[ftmp9], %[ftmp7] \n\t"
+"pcmpgth%[C], %[ftmp10],%[ftmp1] \n\t"
+"or %[mask],%[C], %[csth_1] \n\t"
+"pmullh %[B], %[ftmp1], %[mask] \n\t"
+"pmulhuh%[B], %[ftmp8], %[B] \n\t"
+"pmullh %[B], %[B], %[mask] \n\t"
+"paddh %[A], %[A], %[B] \n\t"
+"paddh %[A], %[A], %[C] \n\t"
+"pcmpgth%[D], %[ftmp10],%[ftmp7] \n\t"
+"or %[mask],%[D], %[csth_1] \n\t"
+"pmullh %[ftmp7], %[ftmp7], %[mask] \n\t"
+"pmulhuh%[B], %[ftmp8], %[ftmp7] \n\t"
+"pmullh %[B], %[B], %[mask] \n\t"
+"pmulhh %[C], %[ftmp9], %[ftmp1] \n\t"
+"psubh %[B], %[C], %[B] \n\t"
+"psubh %[B], %[B], %[D] \n\t"
+
+LOAD_CONST(%[ftmp8], 54491)
+LOAD_CONST(%[ftmp9], 36410)
+"pcmpgth%[Ad], %[ftmp10],%[ftmp5] \n\t"
+"or %[mask],%[Ad],%[csth_1] \n\t"
+"pmullh %[ftmp1], %[ftmp5], %[mask] \n\t"
+"pmulhuh%[C], %[ftmp9], %[ftmp1] \n\t"
+
