Re: [FFmpeg-devel] [PATCH v2 06/11] avcodec: add cbs for h266/vvc
On Tue, Jan 12, 2021 at 4:45 AM Mark Thompson wrote:
> On 10/01/2021 09:10, Nuo Mi wrote:
> > On Sun, Jan 10, 2021 at 5:34 AM Mark Thompson wrote:
> >> On 09/01/2021 07:34, Nuo Mi wrote:
> >>> ---
> >>>configure |2 +
> >>>libavcodec/Makefile |1 +
> >>>libavcodec/cbs.c |6 +
> >>>libavcodec/cbs_h2645.c| 373
> >>>libavcodec/cbs_h266.h | 840
> >>>libavcodec/cbs_h266_syntax_template.c | 2761
> +
> >>>libavcodec/cbs_internal.h |3 +-
> >>>7 files changed, 3985 insertions(+), 1 deletion(-)
> >>>create mode 100644 libavcodec/cbs_h266.h
> >>>create mode 100644 libavcodec/cbs_h266_syntax_template.c
> >>>
> >>> ...
> >>> @@ -920,6 +934,135 @@ static int
> >> cbs_h265_read_nal_unit(CodedBitstreamContext *ctx,
> >>>return 0;
> >>>}
> >>>
> >>> +static int cbs_h266_replace_ph(CodedBitstreamContext *ctx,
> >>> + CodedBitstreamUnit *unit)
> >>> +{
> >>> +CodedBitstreamH266Context *priv = ctx->priv_data;
> >>> +int err;
> >>> +err = ff_cbs_make_unit_refcounted(ctx, unit);
> >>> +if (err < 0)
> >>> +return err;
> >>> +av_buffer_unref(>ph_ref);
> >>> +av_assert0(unit->content_ref);
> >>> +priv->ph_ref = av_buffer_ref(unit->content_ref);
> >>> +if (!priv->ph_ref)
> >>> +return AVERROR(ENOMEM);
> >>> +priv->active_ph = priv->ph = (H266RawPH *)priv->ph_ref->data;
> >>
> >> Why are there too variables here? They seem to always be the same.
> >>
> >priv->active_ph is read-only, priv->ph is writeable pointer. I can
> change
> > to priv->ph only if you prefer.
>
> Reading more carefully, H.266 doesn't appear to have the concept of a
> parameter set being "active" any more (the term never appears).
>
> Does it actually follow the same rules as H.26[45]? Is there some newer
> terminology which we should be using in all of this?
>
No, I guess not, two evidences:
1. buffering_period has no bp_seq_parameter_set_id any more
2. sei payload type 129 is not active_parameter_sets any more.
Not sure in which cases we need the papram activication, h264,h265 slice
header always has pps id.
>
> >>> +return 0;
> >>> +}
> >>> +
> >>> ...
> >>> diff --git a/libavcodec/cbs_h266_syntax_template.c
> >> b/libavcodec/cbs_h266_syntax_template.c
> >>> new file mode 100644
> >>> index 00..6a6defc8a5
> >>> --- /dev/null
> >>> +++ b/libavcodec/cbs_h266_syntax_template.c
> >>> @@ -0,0 +1,2761 @@
> >>> +/*
> >>> + * 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
> >>> + */
> >>> +
> >>> +#ifndef H266_CEIL
> >>> +#define H266_CEIL(v, a) (((v) + (a) - 1) / (a))
> >>> +#endif
> >>
> >> If it's useful to have this separately then put it in cbs_h2645.c rather
> >> than doubled in the template. (See for example cbs_av1_tile_log2().)
> >>
> > It's protected by ifdef, not doubled.
>
> It would still make more sense to make it a(n inline?) function in
> cbs_h2645.c. The template file is intended to contain the standard
> template code and not other stuff.
>
sure, fixed with h266_ceil in cbs_h2645.c
>
> >>> +
> >>> ...
> >>> +
> >>> +static int FUNC(vui_parameters)(CodedBitstreamContext *ctx, RWContext
> >> *rw,
> >>> +H266RawVUI *current)
> >>> +{
> >>> +int err;
> >>> +
> >>> +flag(vui_progressive_source_flag);
> >>> +flag(vui_interlaced_source_flag);
> >>> +flag(vui_non_packed_constraint_flag);
> >>> +flag(vui_non_projected_constraint_flag);
> >>> +flag(vui_aspect_ratio_info_present_flag);
> >>> +if (current->vui_aspect_ratio_info_present_flag) {
> >>> +flag(vui_aspect_ratio_constant_flag);
> >>> +ub(8, vui_aspect_ratio_idc);
> >>> +if (current->vui_aspect_ratio_idc == 255) {
> >>> +ub(16, vui_sar_width);
> >>> +ub(16, vui_sar_height);
> >>> +}
> >>> +} else {
> >>> +infer(vui_aspect_ratio_constant_flag, 0);
> >>> +infer(vui_aspect_ratio_idc, 0);
> >>> +}
> >>> +flag(vui_overscan_info_present_flag);
> >>> +
Re: [FFmpeg-devel] [PATCH v3 07/11] avcodec: add cbs for h266/vvc
On Thu, Jan 14, 2021 at 12:22 PM James Almer wrote:
> On 1/11/2021 1:33 PM, Nuo Mi wrote:
> > @@ -1218,6 +1464,20 @@ static int cbs_h2645_unit_requires_zero_byte(enum
> AVCodecID codec_id,
> > return type == H264_NAL_SPS || type == H264_NAL_PPS;
> > if (codec_id == AV_CODEC_ID_HEVC)
> > return type == HEVC_NAL_VPS || type == HEVC_NAL_SPS || type ==
> HEVC_NAL_PPS;
> > +if (codec_id == AV_CODEC_ID_VVC) {
> > +switch (type) {
> > +case VVC_DCI_NUT:
> > +case VVC_OPI_NUT:
> > +case VVC_VPS_NUT:
> > +case VVC_SPS_NUT:
> > +case VVC_PPS_NUT:
> > +case VVC_PREFIX_APS_NUT:
> > +case VVC_SUFFIX_APS_NUT:
> > +return 1;
> > +default:
> > +return 0;
> > +}
>
> return type >= VVC_OPI_NUT && type <= VVC_SUFFIX_APS_NUT;
>
good suggestion. thanks fixed.
>
> > +}
> > return 0;
> > }
> >
> > @@ -1369,6 +1629,34 @@ static void cbs_h265_close(CodedBitstreamContext
> *ctx)
> > av_buffer_unref(>pps_ref[i]);
> > }
> >
> > +static void cbs_h266_flush(CodedBitstreamContext *ctx)
> > +{
> > +CodedBitstreamH266Context *h266 = ctx->priv_data;
> > +
> > +for (int i = 0; i < FF_ARRAY_ELEMS(h266->sps); i++) {
> > +av_buffer_unref(>sps_ref[i]);
> > +h266->sps[i] = NULL;
> > +}
> > +for (int i = 0; i < FF_ARRAY_ELEMS(h266->pps); i++) {
> > +av_buffer_unref(>pps_ref[i]);
> > +h266->pps[i] = NULL;
> > +}
> > +av_buffer_unref(>ph_ref);
> > +h266->ph = NULL;
> > +
> > +h266->active_sps = NULL;
> > +h266->active_pps = NULL;
> > +}
> > +
> > +static void cbs_h266_close(CodedBitstreamContext *ctx)
> > +{
> > +CodedBitstreamH266Context *h266 = ctx->priv_data;
> > +
> > +cbs_h266_flush(ctx);
> > +ff_h2645_packet_uninit(>common.read_packet);
> > +
> > + }
> > +
> > static void cbs_h264_free_sei_payload(H264RawSEIPayload *payload)
> > {
> > switch (payload->payload_type) {
> > @@ -1513,6 +1801,76 @@ static const CodedBitstreamUnitTypeDescriptor
> cbs_h265_unit_types[] = {
> > CBS_UNIT_TYPE_END_OF_LIST
> > };
> >
> > +static void cbs_h266_free_sei(void *opaque, uint8_t *content)
> > +{
> > +}
>
> static void cbs_h266_free_sei_payload(H266RawSEIPayload *payload)
> {
> switch (payload->payload_type) {
> case VVC_SEI_TYPE_DECODED_PICTURE_HASH:
> break;
> default:
> av_buffer_unref(>payload.other.data_ref);
> break;
> }
> av_buffer_unref(>extension_data.data_ref);
> }
>
> static void cbs_h266_free_sei(void *opaque, uint8_t *content)
> {
> H266RawSEI *sei = (H266RawSEI*)content;
>
> for (int i = 0; i < sei->payload_count; i++)
> cbs_h266_free_sei_payload(>payload[i]);
> av_freep();
> }
>
fixed
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 06/11] avcodec: add cbs for h266/vvc
On Tue, Jan 12, 2021 at 9:28 AM James Almer wrote:
> On 1/11/2021 5:45 PM, Mark Thompson wrote:
> +static int FUNC(vui_parameters)(CodedBitstreamContext *ctx, RWContext
> >>> *rw,
> +H266RawVUI *current)
> +{
> +int err;
> +
> +flag(vui_progressive_source_flag);
> +flag(vui_interlaced_source_flag);
> +flag(vui_non_packed_constraint_flag);
> +flag(vui_non_projected_constraint_flag);
> +flag(vui_aspect_ratio_info_present_flag);
> +if (current->vui_aspect_ratio_info_present_flag) {
> +flag(vui_aspect_ratio_constant_flag);
> +ub(8, vui_aspect_ratio_idc);
> +if (current->vui_aspect_ratio_idc == 255) {
> +ub(16, vui_sar_width);
> +ub(16, vui_sar_height);
> +}
> +} else {
> +infer(vui_aspect_ratio_constant_flag, 0);
> +infer(vui_aspect_ratio_idc, 0);
> +}
> +flag(vui_overscan_info_present_flag);
> +if (current->vui_overscan_info_present_flag)
> +flag(vui_overscan_appropriate_flag);
> +flag(vui_colour_description_present_flag);
> +if (current->vui_colour_description_present_flag) {
> +ub(8, vui_colour_primaries);
> +ub(8, vui_transfer_characteristics);
> +ub(8, vui_matrix_coeffs);
> +flag(vui_full_range_flag);
> +} else {
> +infer(vui_colour_primaries, 2);
> +infer(vui_transfer_characteristics, 2);
> +infer(vui_matrix_coeffs, 2);
> +infer(vui_full_range_flag, 0);
> +}
> +flag(vui_chroma_loc_info_present_flag);
> +if (current->vui_chroma_loc_info_present_flag) {
> +if (current->vui_progressive_source_flag &&
> +!current->vui_interlaced_source_flag) {
> +ue(vui_chroma_sample_loc_type_frame, 0, 6);
> +} else {
> +ue(vui_chroma_sample_loc_type_top_field, 0, 6);
> +ue(vui_chroma_sample_loc_type_bottom_field, 0, 6);
> +}
> +}
> >>>
> >>> These are inferred as 6 when not present?
> >>>
> >> 6 only happened when ChromaFormatIdc = 1, others are not defined.
> >> and 6 is the unspecific value in the spec...
> >> Do we really need to infer it :)
> >
> > To match the colour description cases probably yes?
>
> "When vui_chroma_loc_info_present_flag is equal to 0,
> vui_chroma_sample_loc_type_frame is not present and is inferred to be
> equal to 6, which indicates that the location of the chroma samples is
> unknown or unspecified or specified by other means not specified in this
> Specification. When vui_chroma_sample_loc_type_top_field and
> vui_chroma_sample_loc_type_bottom_field are not present, the values of
> vui_chroma_sample_loc_type_top_field and
> vui_chroma_sample_loc_type_bottom_field are inferred to be equal to
> vui_chroma_sample_loc_type_frame."
>
> So the correct implementation i think would be
>
> flag(vui_chroma_loc_info_present_flag);
> if (current->vui_chroma_loc_info_present_flag) {
> if (current->vui_progressive_source_flag &&
> !current->vui_interlaced_source_flag) {
> ue(vui_chroma_sample_loc_type_frame, 0, 6);
> infer(vui_chroma_sample_loc_type_top_field,
>current->vui_chroma_sample_loc_type_frame);
> infer(vui_chroma_sample_loc_type_bottom_field,
>current->vui_chroma_sample_loc_type_frame);
> } else {
> infer(vui_chroma_sample_loc_type_frame, 6);
> ue(vui_chroma_sample_loc_type_top_field, 0, 6);
> ue(vui_chroma_sample_loc_type_bottom_field, 0, 6);
> }
> } else {
> infer(vui_chroma_sample_loc_type_frame, 6);
> infer(vui_chroma_sample_loc_type_top_field,
>current->vui_chroma_sample_loc_type_frame);
> infer(vui_chroma_sample_loc_type_bottom_field,
>current->vui_chroma_sample_loc_type_frame);
> }
>
Thanks for the suggestion. But, according to spec, the infer is only work
for ChromaFormatIdc == 1.
I have followed spec to fix it.
>
> Also, you also need to infer the default value of almost everything when
> sps_vui_parameters_present_flag is 0. See section D.8 and how h265 does
> it with the vui_parameters_default() custom function.
>
fixed with vui_parameters_default
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Re: [FFmpeg-devel] [PATCH v3 07/11] avcodec: add cbs for h266/vvc
On Thu, Jan 14, 2021 at 6:25 AM James Almer wrote:
> On 1/12/2021 11:34 PM, James Almer wrote:
> >> +if (err < 0)
> >> +return err;
> >> +}
> >> +break;
> >> +
> >> +case VVC_TRAIL_NUT:
> >> +case VVC_STSA_NUT:
> >> +case VVC_RADL_NUT:
> >> +case VVC_RASL_NUT:
> >> +case VVC_IDR_W_RADL:
> >> +case VVC_IDR_N_LP:
> >> +case VVC_CRA_NUT:
> >> +case VVC_GDR_NUT:
> >> +{
> >> +H266RawSlice *slice = unit->content;
> >> +int pos, len;
> >> +
> >> +err = cbs_h266_read_slice_header(ctx, ,
> >header);
> >> +if (err < 0)
> >> +return err;
> >
> > Add a call to cbs_h266_replace_ph() here when
> > slice->header.sh_picture_header_in_slice_header_flag is true, and pass a
> > pointer to slice->header.sh_picture_header to it.
>
> Actually no, this wouldn't work as is in the cases where
> ff_cbs_make_unit_refcounted() makes it refcounted. Neither slice or the
> pointer passed to cbs_h266_replace_ph() would be valid.
>
> You'd have ensure the slice variable points the new unit->content after
> a successful call to cbs_h266_replace_ph() (Which you can leave
> untouched), and then make priv->ph point to the H266RawPH struct within
> slice.
>
Yes, It's not workable. The allocation is done by the cbs framework. not by
us.
The cbs_h266_replace_ph just take a reference. it's very cheap.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 6/6] avcodec/qsvdec: refact, remove duplicate code for plugin loading
Hi Lingjie,
thanks for the comment.
We can use codec id to do special things for a specific codec. Just like
qsv_decode_init.
thanks
On Sat, Jan 16, 2021 at 3:22 PM Linjie Fu
wrote:
> Guangxin:
>
> On Tue, Jan 5, 2021 at 10:44 AM Xu Guangxin wrote:
> >
> > ---
> > libavcodec/qsvdec.c | 29 +++--
> > 1 file changed, 11 insertions(+), 18 deletions(-)
> >
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> > index 3ca16dafae..d10f90a0db 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -682,21 +682,12 @@ static av_cold int qsv_decode_init(AVCodecContext
> *avctx)
> > {
> > QSVDecContext *s = avctx->priv_data;
> > int ret;
> > +const char *uid = NULL;
> >
> > if (avctx->codec_id == AV_CODEC_ID_VP8) {
> > -static const char *uid_vp8dec_hw =
> "f622394d8d87452f878c51f2fc9b4131";
> > -
> > -av_freep(>qsv.load_plugins);
> > -s->qsv.load_plugins = av_strdup(uid_vp8dec_hw);
> > -if (!s->qsv.load_plugins)
> > -return AVERROR(ENOMEM);
> > +uid = "f622394d8d87452f878c51f2fc9b4131";
> > } else if (avctx->codec_id == AV_CODEC_ID_VP9) {
> > -static const char *uid_vp9dec_hw =
> "a922394d8d87452f878c51f2fc9b4131";
> > -
> > -av_freep(>qsv.load_plugins);
> > -s->qsv.load_plugins = av_strdup(uid_vp9dec_hw);
> > -if (!s->qsv.load_plugins)
> > -return AVERROR(ENOMEM);
> > +uid = "a922394d8d87452f878c51f2fc9b4131";
> > }
> > else if (avctx->codec_id == AV_CODEC_ID_HEVC && s->load_plugin !=
> LOAD_PLUGIN_NONE) {
> > static const char * const uid_hevcdec_sw =
> "15dd936825ad475ea34e35f3f54217a6";
> > @@ -707,16 +698,18 @@ static av_cold int qsv_decode_init(AVCodecContext
> *avctx)
> > "load_plugins is not empty, but load_plugin is not
> set to 'none'."
> > "The load_plugin value will be ignored.\n");
> > } else {
> > -av_freep(>qsv.load_plugins);
> > -
> > if (s->load_plugin == LOAD_PLUGIN_HEVC_SW)
> > -s->qsv.load_plugins = av_strdup(uid_hevcdec_sw);
> > +uid = uid_hevcdec_sw;
> > else
> > -s->qsv.load_plugins = av_strdup(uid_hevcdec_hw);
> > -if (!s->qsv.load_plugins)
> > -return AVERROR(ENOMEM);
> > +uid = uid_hevcdec_hw;
> > }
> > }
> > +if (uid) {
> > +av_freep(>qsv.load_plugins);
> > +s->qsv.load_plugins = av_strdup(uid);
> > +if (!s->qsv.load_plugins)
> > +return AVERROR(ENOMEM);
> > +}
> >
> > s->qsv.orig_pix_fmt = AV_PIX_FMT_NV12;
> > s->packet_fifo = av_fifo_alloc(sizeof(AVPacket));
> > --
> Merging the AVCodec descriptions for all qsv decoders makes the code
> cleaner, since
> the majority of them are identical. And all checks passed in [1].
>
> One concern is it may be less convenient or more tricky to modify in
> the future, if a
> specific decoder changes and differs from the rest.
>
> Anyway, lgtm at least for now, and prefer to apply if no more
> comments/objections/concerns.
>
> [1] https://github.com/intel-media-ci/ffmpeg/pull/326
>
> - linjie
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Revert "avutil/timecode: fix sscanf format string with garbage at the end"
On Sun, 17 Jan 2021, lance.lmw...@gmail.com wrote:
On Sat, Jan 16, 2021 at 09:49:42AM +0100, Marton Balint wrote:
This reverts commit 6696a07ac62bfec49dd488510a719367918b9f7a.
It is wrong to restrict timecodes to always contain leading zeros or for hours
or frames to be 2 chars only.
Sorry, I think I was misunderstood by the following syntax description:
syntax: hh:mm:ss[:;.]ff
maybe it's better to change it to hour:minute:second[:;.]frame?
That would better reflect on what the code did before the patch.
After revisiting the code, I think we may support more valid syntax for the
timecode
string:
ss
ss[:;.]ff
mm:ss
mm:ss[:;.]ff
hh:mm:ss
hh:mm:ss[:;.]ff
I don't like this idea much, it is good if we are strict about the
timecode format (e.g request all components to be present and no garbage
after the parsed string), the main reasons I suggested the revert are
because timecode has to support > 100 fps and >= 100 hours because our
timecode API also has support for such timecodes.
Regards,
Marton
Signed-off-by: Marton Balint
---
libavutil/timecode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/timecode.c b/libavutil/timecode.c
index 5106f642b9..c1fa445d31 100644
--- a/libavutil/timecode.c
+++ b/libavutil/timecode.c
@@ -252,7 +252,7 @@ int av_timecode_init_from_string(AVTimecode *tc, AVRational
rate, const char *st
char c;
int hh, mm, ss, ff, flags;
-if (sscanf(str, "%02u:%02u:%02u%c%02u", , , , , ) != 5) {
+if (sscanf(str, "%d:%d:%d%c%d", , , , , ) != 5) {
av_log(log_ctx, AV_LOG_ERROR, "Unable to parse timecode, "
"syntax: hh:mm:ss[:;.]ff\n");
return AVERROR_INVALIDDATA;
--
2.26.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat/hlsenc: use AV_OPT_TYPE_DURATION
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/muxers.texi | 15 +++
libavformat/hlsenc.c | 18 +-
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 8e12aca..1f9f293 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -609,14 +609,21 @@ segmentation.
This muxer supports the following options:
@table @option
-@item hls_init_time @var{seconds}
-Set the initial target segment length in seconds. Default value is @var{0}.
+@item hls_init_time @var{duration}
+Set the initial target segment length. Default value is @var{0}.
+
+@var{duration} must be a time duration specification,
+see @ref{time duration syntax,,the Time duration section in the
ffmpeg-utils(1) manual,ffmpeg-utils}.
+
Segment will be cut on the next key frame after this time has passed on the
first m3u8 list.
After the initial playlist is filled @command{ffmpeg} will cut segments
at duration equal to @code{hls_time}
-@item hls_time @var{seconds}
-Set the target segment length in seconds. Default value is 2.
+@item hls_time @var{duration}
+Set the target segment length. Default value is 2.
+
+@var{duration} must be a time duration specification,
+see @ref{time duration syntax,,the Time duration section in the
ffmpeg-utils(1) manual,ffmpeg-utils}.
Segment will be cut on the next key frame after this time has passed.
@item hls_list_size @var{size}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 7f38db7..94fd505 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -196,8 +196,8 @@ typedef struct HLSContext {
int64_t start_sequence;
uint32_t start_sequence_source_type; // enum StartSequenceSourceType
-float time;// Set by a private option.
-float init_time; // Set by a private option.
+int64_t time; // Set by a private option.
+int64_t init_time; // Set by a private option.
int max_nb_segments; // Set by a private option.
int hls_delete_threshold; // Set by a private option.
#if FF_API_HLS_WRAP
@@ -2454,9 +2454,9 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
if (vs->sequence - vs->nb_entries > hls->start_sequence && hls->init_time
> 0) {
/* reset end_pts, hls->recording_time at end of the init hls list */
-int64_t init_list_dur = hls->init_time * vs->nb_entries * AV_TIME_BASE;
-int64_t after_init_list_dur = (vs->sequence - hls->start_sequence -
vs->nb_entries) * (hls->time * AV_TIME_BASE);
-hls->recording_time = hls->time * AV_TIME_BASE;
+int64_t init_list_dur = hls->init_time * vs->nb_entries;
+int64_t after_init_list_dur = (vs->sequence - hls->start_sequence -
vs->nb_entries) * hls->time;
+hls->recording_time = hls->time;
end_pts = init_list_dur + after_init_list_dur ;
}
@@ -2941,7 +2941,7 @@ static int hls_init(AVFormatContext *s)
av_log(hls, AV_LOG_DEBUG, "start_number evaluated to %"PRId64"\n",
hls->start_sequence);
}
-hls->recording_time = (hls->init_time ? hls->init_time : hls->time) *
AV_TIME_BASE;
+hls->recording_time = hls->init_time ? hls->init_time : hls->time;
if (hls->flags & HLS_SPLIT_BY_TIME && hls->flags &
HLS_INDEPENDENT_SEGMENTS) {
// Independent segments cannot be guaranteed when splitting by time
@@ -3094,7 +3094,7 @@ static int hls_init(AVFormatContext *s)
av_log(s, AV_LOG_WARNING, "append_list mode does not support
hls_init_time,"
" hls_init_time value will have no effect\n");
hls->init_time = 0;
-hls->recording_time = hls->time * AV_TIME_BASE;
+hls->recording_time = hls->time;
}
}
@@ -3110,8 +3110,8 @@ static int hls_init(AVFormatContext *s)
#define E AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
{"start_number", "set first number in the sequence",
OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX, E},
-{"hls_time", "set segment length in seconds", OFFSET(time),
AV_OPT_TYPE_FLOAT, {.dbl = 2}, 0, FLT_MAX, E},
-{"hls_init_time", "set segment length in seconds at init list",
OFFSET(init_time),AV_OPT_TYPE_FLOAT, {.dbl = 0}, 0, FLT_MAX, E},
+{"hls_time", "set segment length", OFFSET(time),
AV_OPT_TYPE_DURATION, {.i64 = 200}, 0, INT64_MAX, E},
+{"hls_init_time", "set segment length at init list",
OFFSET(init_time), AV_OPT_TYPE_DURATION, {.i64 = 0}, 0, INT64_MAX, E},
{"hls_list_size", "set maximum number of playlist entries",
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX, E},
{"hls_delete_threshold", "set number of unreferenced segments to keep
before deleting", OFFSET(hls_delete_threshold),AV_OPT_TYPE_INT,{.i64 =
1}, 1, INT_MAX, E},
[FFmpeg-devel] [PATCH v2] avformat/mov: fix timecode with counter mode flag set
From: Mark Reid
The current behaviour ends up squaring the avg_frame_rate if the conter mode
flag is set.
This messes up the timecode calculation, and looks to me as a regression that
seems to have been introduced 428b4aac.
Upon further testing is seems that no special case is need for having the
counter flag set.
av_timecode_init appears to handles the timecode correctly, at least in the
sample files
I have.
Here is a sample mov file with the counter flag set
https://www.dropbox.com/s/5l4fucb9lhq523s/timecode_counter_mode.mov
before the patch ffmpeg will report the timecode as:
00:37:11:97 and warns that the timecode framerate is 57600/1002001
after patch:
14:50:55:02
---
libavformat/mov.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 3215b53636..f8856a43dd 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2350,19 +2350,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
st->codec->time_base = av_inv_q(st->avg_frame_rate);
FF_ENABLE_DEPRECATION_WARNINGS
#endif
-/* adjust for per frame dur in counter mode */
-if (tmcd_ctx->tmcd_flags & 0x0008) {
-int timescale = AV_RB32(st->codecpar->extradata + 8);
-int framedur = AV_RB32(st->codecpar->extradata + 12);
-st->avg_frame_rate.num *= timescale;
-st->avg_frame_rate.den *= framedur;
-#if FF_API_LAVF_AVCTX
-FF_DISABLE_DEPRECATION_WARNINGS
-st->codec->time_base.den *= timescale;
-st->codec->time_base.num *= framedur;
-FF_ENABLE_DEPRECATION_WARNINGS
-#endif
-}
if (size > 30) {
uint32_t len = AV_RB32(st->codecpar->extradata + 18); /* name
atom length */
uint32_t format = AV_RB32(st->codecpar->extradata + 22);
--
2.21.1 (Apple Git-122.3)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Populate field order returned by avs script, Trac Ticket 8757
The purpose of this is to tell ffmpeg which field order the returned
clip of the avisynth .avs script decided to finally deliver, which is
handy in an automated environment.
Interlacing is generally a very hard topic in avisynth, the huge comment
is neccessary to explain my reasons.
Additionally to the comment in the patch, i can tell that i set unknown
instead of progressive for backward compatibility. (i was struggeling
with this, maybe i should have even left it unset in case it is not
clearly tff or bff interlaced.
/* Set interlacing type.
http://avisynth.nl/index.php/Interlaced_fieldbased
* The following typically only works when assumetff (-bff) and
assumefieldbased is used in the avs.
* This is because most avisynth source plugins do not set the
parity info in the clip properties.
* We could use GetParity() to be more accurate but it decodes a
frame which is
* expensive and can potentially lead to unforeseen behaviour when
seeking later.
* In case Parity is not known, we still cannot guarantee that
*/
Tests with different avisynth source plugins, e.g. directshowsource,
ffms2, mpeg2source delivered the expected result.
Make FATE passed.From 31a37518afa5f9b635e6c52a8f29513bc756c715 Mon Sep 17 00:00:00 2001
From: emcodem
Date: Sun, 17 Jan 2021 01:02:08 +0100
Subject: [PATCH] Populate field order returned by avs script, Trac Ticket 8757
---
libavformat/avisynth.c | 20
1 file changed, 20 insertions(+)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 2c08ace8db..67348a61d7 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -241,6 +241,26 @@ static int avisynth_create_stream_video(AVFormatContext *s, AVStream *st)
st->nb_frames = avs->vi->num_frames;
avpriv_set_pts_info(st, 32, avs->vi->fps_denominator, avs->vi->fps_numerator);
+av_log(s, AV_LOG_TRACE, "avs_is_field_based: %d\n", avs_is_field_based(avs->vi));
+av_log(s, AV_LOG_TRACE, "avs_is_parity_known: %d\n", avs_is_parity_known(avs->vi));
+
+st->codecpar->field_order = AV_FIELD_UNKNOWN;
+if (avs_is_field_based(avs->vi)) {
+/* Set interlacing type. http://avisynth.nl/index.php/Interlaced_fieldbased
+* The following typically only works when assumetff (-bff) and assumefieldbased is used in the avs.
+* This is because most avisynth source plugins do not set the parity info in the clip properties.
+* We could use GetParity() to be more accurate but it decodes a frame which is
+* expensive and can potentially lead to unforeseen behaviour when seeking later.
+* In case Parity is not known, we still cannot guarantee that
+*/
+if (avs_is_tff(avs->vi)) {
+st->codecpar->field_order = AV_FIELD_TT;
+}
+else if (avs_is_bff(avs->vi)) {
+st->codecpar->field_order = AV_FIELD_BB;
+}
+}
+
switch (avs->vi->pixel_type) {
/* 10~16-bit YUV pix_fmts (AviSynth+) */
case AVS_CS_YUV444P10:
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Revert "avutil/timecode: fix sscanf format string with garbage at the end"
On Sat, Jan 16, 2021 at 09:49:42AM +0100, Marton Balint wrote:
> This reverts commit 6696a07ac62bfec49dd488510a719367918b9f7a.
>
> It is wrong to restrict timecodes to always contain leading zeros or for hours
> or frames to be 2 chars only.
Sorry, I think I was misunderstood by the following syntax description:
syntax: hh:mm:ss[:;.]ff
maybe it's better to change it to hour:minute:second[:;.]frame?
After revisiting the code, I think we may support more valid syntax for the
timecode
string:
ss
ss[:;.]ff
mm:ss
mm:ss[:;.]ff
hh:mm:ss
hh:mm:ss[:;.]ff
>
> Signed-off-by: Marton Balint
> ---
> libavutil/timecode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/timecode.c b/libavutil/timecode.c
> index 5106f642b9..c1fa445d31 100644
> --- a/libavutil/timecode.c
> +++ b/libavutil/timecode.c
> @@ -252,7 +252,7 @@ int av_timecode_init_from_string(AVTimecode *tc,
> AVRational rate, const char *st
> char c;
> int hh, mm, ss, ff, flags;
>
> -if (sscanf(str, "%02u:%02u:%02u%c%02u", , , , , ) != 5) {
> +if (sscanf(str, "%d:%d:%d%c%d", , , , , ) != 5) {
> av_log(log_ctx, AV_LOG_ERROR, "Unable to parse timecode, "
>"syntax: hh:mm:ss[:;.]ff\n");
> return AVERROR_INVALIDDATA;
> --
> 2.26.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [GASPP PATCH 2/2] Match aarch64 register lists with tbl/tbx too
Remove the restriction on matching on the same line as ld1/st1 and
similar ones; the pattern for the register list itself should be
strict enough to avoid false matches.
---
gas-preprocessor.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 4d78dac..06e376f 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -1087,7 +1087,7 @@ sub handle_serialized_line {
}
# Convert "ld1 {v0.4h-v3.4h}" into "ld1 {v0.4h,v1.4h,v2.4h,v3.4h}"
-if ($line =~
/(?:ld|st)\d\s+(\{\s*v(\d+)\.(\d+[bhsdBHSD])\s*-\s*v(\d+)\.(\d+[bhsdBHSD])\s*\})/)
{
+if ($line =~
/(\{\s*v(\d+)\.(\d+[bhsdBHSD])\s*-\s*v(\d+)\.(\d+[bhsdBHSD])\s*\})/) {
my $regspec = $1;
my $reg1 = $2;
my $layout1 = $3;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [GASPP PATCH 1/2] Recognize aarch64 register ranges with .16b suffixes too
Match e.g. "ld1 {v16.16b-v19.16b}".
Previously this regex only matched lane specifiers with a single
digit, e.g. "ld1 {v16.8h-v19.8h}".
---
gas-preprocessor.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index c4b1c1d..4d78dac 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -1087,7 +1087,7 @@ sub handle_serialized_line {
}
# Convert "ld1 {v0.4h-v3.4h}" into "ld1 {v0.4h,v1.4h,v2.4h,v3.4h}"
-if ($line =~
/(?:ld|st)\d\s+(\{\s*v(\d+)\.(\d[bhsdBHSD])\s*-\s*v(\d+)\.(\d[bhsdBHSD])\s*\})/)
{
+if ($line =~
/(?:ld|st)\d\s+(\{\s*v(\d+)\.(\d+[bhsdBHSD])\s*-\s*v(\d+)\.(\d+[bhsdBHSD])\s*\})/)
{
my $regspec = $1;
my $reg1 = $2;
my $layout1 = $3;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/7] avformat/mpsubdec: Use av_sat_add/sub64() in fracval handling
Fixes: signed integer overflow: 922337203685000 + 900 cannot be represented in type 'long long' Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_MPSUB_fuzzer-665448017480908 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/mpsubdec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/mpsubdec.c b/libavformat/mpsubdec.c index e7b83a1d85..2e6dc883eb 100644 --- a/libavformat/mpsubdec.c +++ b/libavformat/mpsubdec.c @@ -72,8 +72,8 @@ static int parse_line(const char *line, int64_t *value, int64_t *value2) fracval *= 10; for (;p2 - p1 > 7 + 1; p1++) fracval /= 10; -if (intval > 0) intval += fracval; -elseintval -= fracval; +if (intval > 0) intval = av_sat_add64(intval, fracval); +elseintval = av_sat_sub64(intval, fracval); line += p2; } else line += p1; -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] lavc/aarch64: add HEVC sao_band NEON
On Thu, 7 Jan 2021, Josh Dekker wrote:
Only works for 8x8.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 3 +-
libavcodec/aarch64/hevcdsp_init.c | 7 +++
libavcodec/aarch64/hevcdsp_sao_neon.S | 87 +++
3 files changed, 96 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64/hevcdsp_sao_neon.S
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 42d80bf74c..1f54fc31f4 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -55,7 +55,8 @@ NEON-OBJS-$(CONFIG_VP8DSP) +=
aarch64/vp8dsp_neon.o
NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_neon.o
NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o
NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_add_res_neon.o \
- aarch64/hevcdsp_idct_neon.o
+ aarch64/hevcdsp_idct_neon.o
\
+ aarch64/hevcdsp_sao_neon.o
NEON-OBJS-$(CONFIG_OPUS_DECODER)+= aarch64/opusdsp_neon.o
NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o
NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o \
diff --git a/libavcodec/aarch64/hevcdsp_init.c
b/libavcodec/aarch64/hevcdsp_init.c
index 2cd7ef3a6c..8f0a923ab1 100644
--- a/libavcodec/aarch64/hevcdsp_init.c
+++ b/libavcodec/aarch64/hevcdsp_init.c
@@ -23,6 +23,11 @@
#include "libavcodec/hevcdsp.h"
#include "libavcodec/avcodec.h"
+void ff_hevc_sao_band_filter_8x8_8_neon(uint8_t *_dst, uint8_t *_src,
+ ptrdiff_t stride_dst, ptrdiff_t stride_src,
+ int16_t *sao_offset_val, int sao_left_class,
+ int width, int height);
+
void ff_hevc_idct_4x4_dc_8_neon(int16_t *coeffs);
void ff_hevc_idct_8x8_dc_8_neon(int16_t *coeffs);
void ff_hevc_idct_16x16_dc_8_neon(int16_t *coeffs);
@@ -53,6 +58,8 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
{
int cpu_flags = av_get_cpu_flags();
if (have_neon(cpu_flags) && bit_depth == 8) {
+c->sao_band_filter[0] = ff_hevc_sao_band_filter_8x8_8_neon;
+
c->add_residual[0] = ff_hevc_add_residual_4x4_8_neon;
c->add_residual[1] = ff_hevc_add_residual_8x8_8_neon;
c->add_residual[2] = ff_hevc_add_residual_16x16_8_neon;
diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S
b/libavcodec/aarch64/hevcdsp_sao_neon.S
new file mode 100644
index 00..25b6c25117
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_sao_neon.S
@@ -0,0 +1,87 @@
+/* -*-arm64-*-
+ * vim: syntax=arm64asm
+ *
+ * AArch64 NEON optimised SAO functions for HEVC decoding
+ *
+ * Copyright (c) 2020 Josh Dekker
+ *
+ * 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 "libavutil/aarch64/asm.S"
+
+// void sao_band_filter(uint8_t *_dst, uint8_t *_src,
+// ptrdiff_t stride_dst, ptrdiff_t stride_src,
+// int16_t *sao_offset_val, int sao_left_class,
+// int width, int height)
+function ff_hevc_sao_band_filter_8x8_8_neon, export=1
+sub sp, sp, #64
+stp xzr, xzr, [sp]
+stp xzr, xzr, [sp, #16]
+stp xzr, xzr, [sp, #32]
+stp xzr, xzr, [sp, #48]
+mov w8, #4
+.setup:
Please use a numeric anonymous label for this one; gas-preprocessor
doesn't handle these kinds of labels. This actually creates a real symbol
(though, a non-external one) here; to make it just a local label, you'd
prefix it with .L on ELF and with L on MachO. In dav1d there's a macro in
asm.S for doing this, but for here, I'd just suggest you'd go with 1:
instead, for simplicity.
+ldrsh x9, [x4, x8, lsl #1] // x9 = sao_offset_val[k+1]
+subs w8, w8, #1
+add w10, w8, w5 // x10 = k + sao_left_class
+and w10, w10, #0x1F
+strh w9, [sp, x10, lsl #1]
+bne .setup
+ld1 {v16.16B-v19.16B}, [sp], #64
MSVC's armasm64 can't handle these register lists with a dash;
gas-preprocessor does try to expand them, but it turned out it had a minor
bug. I'll send patches for fixing that though.
+movi v20.8H, #1
+0: //
[FFmpeg-devel] [PATCH 4/7] avformat/nistspheredec: Check bits_per_coded_sample and channels
Fixes: signed integer overflow: 80 * 92233009 cannot be represented in type 'int' Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_NISTSPHERE_fuzzer-6669100654919680 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/nistspheredec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavformat/nistspheredec.c b/libavformat/nistspheredec.c index 079369929f..fec5c88892 100644 --- a/libavformat/nistspheredec.c +++ b/libavformat/nistspheredec.c @@ -80,7 +80,9 @@ static int nist_read_header(AVFormatContext *s) avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate); -st->codecpar->block_align = st->codecpar->bits_per_coded_sample * st->codecpar->channels / 8; +if (st->codecpar->bits_per_coded_sample * (uint64_t)st->codecpar->channels / 8 > INT_MAX) +return AVERROR_INVALIDDATA; +st->codecpar->block_align = st->codecpar->bits_per_coded_sample * (uint64_t)st->codecpar->channels / 8; if (avio_tell(s->pb) > header_size) return AVERROR_INVALIDDATA; -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/7] avformat/mvi: Use 64bit for testing dimensions
Fixes: signed integer overflow: 65535 * 65535 cannot be represented in type
'int'
Fixes:
26910/clusterfuzz-testcase-minimized-ffmpeg_dem_MVI_fuzzer-6649291124899840
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mvi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mvi.c b/libavformat/mvi.c
index 06c9cfe3f0..2d4b11aa32 100644
--- a/libavformat/mvi.c
+++ b/libavformat/mvi.c
@@ -94,7 +94,7 @@ static int read_header(AVFormatContext *s)
vst->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
vst->codecpar->codec_id = AV_CODEC_ID_MOTIONPIXELS;
-mvi->get_int = (vst->codecpar->width * vst->codecpar->height < (1 << 16))
? avio_rl16 : avio_rl24;
+mvi->get_int = (vst->codecpar->width * (int64_t)vst->codecpar->height < (1
<< 16)) ? avio_rl16 : avio_rl24;
mvi->audio_frame_size = ((uint64_t)mvi->audio_data_size <<
MVI_FRAC_BITS) / frames_count;
if (mvi->audio_frame_size <= 1 << MVI_FRAC_BITS - 1) {
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 7/7] avformat/sbgdec: Reduce the amount of floating point in str_to_time()
Fixes: 1e+75 is outside the range of representable values of type 'long' Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-6626834808700928 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/sbgdec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavformat/sbgdec.c b/libavformat/sbgdec.c index f56eb9ff59..8672e2e976 100644 --- a/libavformat/sbgdec.c +++ b/libavformat/sbgdec.c @@ -181,6 +181,7 @@ static int str_to_time(const char *str, int64_t *rtime) char *end; int hours, minutes; double seconds = 0; +int64_t ts = 0; if (*cur < '0' || *cur > '9') return 0; @@ -196,8 +197,9 @@ static int str_to_time(const char *str, int64_t *rtime) seconds = strtod(cur + 1, ); if (end > cur + 1) cur = end; +ts = av_clipd(seconds * AV_TIME_BASE, INT64_MIN/2, INT64_MAX/2); } -*rtime = (hours * 3600LL + minutes * 60LL + seconds) * AV_TIME_BASE; +*rtime = (hours * 3600LL + minutes * 60LL) * AV_TIME_BASE + ts; return cur - str; } -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/7] avformat/nutdec: Fix integer overflow in count computation
Note, the value is checked a few lines later already Fixes: signed integer overflow: -440402016 - 1879048064 cannot be represented in type 'int' Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_NUT_fuzzer-6603876618469376 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/nutdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c index 53a052503e..88891721ca 100644 --- a/libavformat/nutdec.c +++ b/libavformat/nutdec.c @@ -260,7 +260,7 @@ static int decode_main_header(NUTContext *nut) if (tmp_fields > 5) count = ffio_read_varlen(bc); else -count = tmp_mul - tmp_size; +count = tmp_mul - (unsigned)tmp_size; if (tmp_fields > 6) get_s(bc); if (tmp_fields > 7) -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/7] avformat/utils: Check dts in update_initial_timestamps() more
Fixes: signed integer overflow: -9223372036853488158 - 9000 cannot be represented in type 'long long' Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_MPSUB_fuzzer-6696625298866176 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/utils.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/utils.c b/libavformat/utils.c index bf904ef2c5..7f547c77ed 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -1103,6 +1103,7 @@ static void update_initial_timestamps(AVFormatContext *s, int stream_index, dts == AV_NOPTS_VALUE || st->cur_dts == AV_NOPTS_VALUE || st->cur_dts < INT_MIN + RELATIVE_TS_BASE || +dts < INT_MIN + (st->cur_dts - RELATIVE_TS_BASE) || is_relative(dts)) return; -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/7] avformat/realtextdec: Avoid undefined overflow in the end of read_ts()
Fixes: signed integer overflow: 234080282628234040 * 100 cannot be represented in type 'long long' Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_REALTEXT_fuzzer-6649867065753600 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/realtextdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/realtextdec.c b/libavformat/realtextdec.c index 390f8ddc67..f534774420 100644 --- a/libavformat/realtextdec.c +++ b/libavformat/realtextdec.c @@ -54,7 +54,7 @@ static int64_t read_ts(const char *s) if (sscanf(s,"%u:%u.%u", , , ) == 3) return ( mm*60LL + ss) * 100LL + ms; if (sscanf(s,"%u:%u" , , ) == 2) return ( mm*60LL + ss) * 100LL; if (sscanf(s, "%u.%u", , ) == 2) return ( ss) * 100LL + ms; -return strtol(s, NULL, 10) * 100LL; +return strtoll(s, NULL, 10) * 100ULL; } static int realtext_read_header(AVFormatContext *s) -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] lavc/aarch64: add HEVC idct_dc NEON
On Thu, 7 Jan 2021, Josh Dekker wrote:
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile| 3 +-
libavcodec/aarch64/hevcdsp_idct_neon.S | 74 ++
libavcodec/aarch64/hevcdsp_init.c | 19 +++
3 files changed, 95 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 4bdd554e7e..42d80bf74c 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -54,7 +54,8 @@ NEON-OBJS-$(CONFIG_VP8DSP) +=
aarch64/vp8dsp_neon.o
# decoders/encoders
NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_neon.o
NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o
-NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_add_res_neon.o
+NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_add_res_neon.o
\
+ aarch64/hevcdsp_idct_neon.o
NEON-OBJS-$(CONFIG_OPUS_DECODER)+= aarch64/opusdsp_neon.o
NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o
NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o \
diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S
b/libavcodec/aarch64/hevcdsp_idct_neon.S
new file mode 100644
index 00..cd886bb6dc
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_idct_neon.S
@@ -0,0 +1,74 @@
+/* -*-arm64-*-
+ *
+ * AArch64 NEON optimised IDCT functions for HEVC decoding
+ *
+ * Copyright (c) 2020 Josh Dekker
+ *
+ * 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 "libavutil/aarch64/asm.S"
+
+.macro idct_dc size bitdepth
+function ff_hevc_idct_\size\()x\size\()_dc_\bitdepth\()_neon, export=1
As a bonus, it'd be nice to have the function prototype in a comment above
here, as a quick reference for what the inputs are.
+ldrsh w1, [x0]
+mov w2, #(1 << (13 - \bitdepth))
+add w1, w1, #1
+asr w1, w1, #1
+add w1, w1, w2
As commented on the other patch, please align things like in existing
assembly, and add another extra space after the commas here, to keep
things aligned even if you'd be using e.g. w10.
+asr w1, w1, #(14 - \bitdepth)
+dup v0.8h, w1
+dup v1.8h, w1
+.if \size > 4
+dup v2.8h, w1
+dup v3.8h, w1
+.if \size > 16 /* dc 32x32 */
+mov x2, #4
+1:
+subs x2, x2, #1
+.endif
+.if \size > 8 /* dc 16x16 */
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+.endif /* dc 8x8 */
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
In a series of stores like this, each instruction updates the pointer x0,
which means that the next instruction can't start executing until the
previous one is done writing back the value to that register. So for a
sequence like this, it's sometimes useful to have two registers for
storing things interleavedly, e.g. like this:
add x12, x0, #64
mov x13, #128
st1 {}, [x0], x13
st1 {}, [x12], x13
st1 {}, [x0], x13
st1 {}, [x12], x13
...
Depending on the context and so on, it may or may not be worth doing that.
For such a small trivial function like this, I'd definitely try at least.
Btw, you didn't mention what core you had benchmarked your functions on.
When doing micro tuning like this, it's usually good to benchmark on both
big and small cores, as some optimizations can make things faster on one
but slower on another one.
Functionally, the patch looks ok - but as this goes into the same file as
Reimar's patches also add things into (and his patches do things that are
fairly 1:1 with the existing arm assembly), it might be good to hold off
of pushing this one until his patches are in, to rebase this one on top of
those.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavc/aarch64: add HEVC add_residual NEON
On Thu, 7 Jan 2021, Josh Dekker wrote:
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 2 +
libavcodec/aarch64/hevcdsp_add_res_neon.S | 298 ++
libavcodec/aarch64/hevcdsp_init.c | 59 +
libavcodec/hevcdsp.c | 2 +
libavcodec/hevcdsp.h | 1 +
5 files changed, 362 insertions(+)
create mode 100644 libavcodec/aarch64/hevcdsp_add_res_neon.S
create mode 100644 libavcodec/aarch64/hevcdsp_init.c
This one is pretty much equivalent to Reimar's patch. As his one goes on
top of the ported IDCT, I think I'd prefer his version of it. But in any
case, some comments below:
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index f6434e40da..4bdd554e7e 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -17,6 +17,7 @@ OBJS-$(CONFIG_VP8DSP) +=
aarch64/vp8dsp_init_aarch64.o
OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_init_aarch64.o \
aarch64/sbrdsp_init_aarch64.o
OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_init.o
+OBJS-$(CONFIG_HEVC_DECODER) += aarch64/hevcdsp_init.o
OBJS-$(CONFIG_OPUS_DECODER) += aarch64/opusdsp_init.o
OBJS-$(CONFIG_RV40_DECODER) += aarch64/rv40dsp_init_aarch64.o
OBJS-$(CONFIG_VC1DSP) += aarch64/vc1dsp_init_aarch64.o
@@ -53,6 +54,7 @@ NEON-OBJS-$(CONFIG_VP8DSP) +=
aarch64/vp8dsp_neon.o
# decoders/encoders
NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_neon.o
NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o
+NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_add_res_neon.o
NEON-OBJS-$(CONFIG_OPUS_DECODER)+= aarch64/opusdsp_neon.o
NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o
NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o \
diff --git a/libavcodec/aarch64/hevcdsp_add_res_neon.S
b/libavcodec/aarch64/hevcdsp_add_res_neon.S
new file mode 100644
index 00..4005366192
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_add_res_neon.S
@@ -0,0 +1,298 @@
+/* -*-arm64-*-
+ *
+ * AArch64 NEON optimised add residual functions for HEVC decoding
+ *
+ * Copyright (c) 2020 Josh Dekker
I believe this one is at least a bit inspired by the arm version, right?
In that case it's probably customary to bring the original copyright
along.
+ *
+ * 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 "libavutil/aarch64/asm.S"
+
+.macro clip10 in1, in2, c1, c2
+smax \in1, \in1, \c1
+smax \in2, \in2, \c1
+smin \in1, \in1, \c2
+smin \in2, \in2, \c2
+.endm
+
+function ff_hevc_add_residual_4x4_8_neon, export=1
+mov x3, x0
Please align the instructions and operands like in the existing assembly.
Also, in addition to aligning those two columns, in aarch64 assembly I
write myself, I also try to align the individual operands; for
instructions that only take GPRs, I'd write things as "x0, x1, x2", to
keep operands aligned the same for cases with registers >= x10, and for
instructions that take vector registers, align everything to line up for
the longest case register name, e.g. v31.16b. For SIMD loads, stores and
other things, where things don't generally line up, I just try to make the
code look pretty and consistent.
Also, as a matter of taste, I tend to write the lane specifications with
lower case letters, i.e. .16b instead of 16B.
+ld1 {v0.S}[0], [x3], x2
+ld1 {v0.S}[1], [x3], x2
+ld1 {v1.S}[0], [x3], x2
+ld1 {v1.S}[1], [x3], x2
+ld1 { v2.8H-v3.8H}, [x1]
+ushll v4.8H, v0.8B, #0
+ushll v5.8H, v1.8B, #0
ushll #0 is uxtl
+add v6.8H, v4.8H, v2.8H
+add v7.8H, v5.8H, v3.8H
The arm version (and Reimar's) does saturated addition here, i.e. sqadd.
There's a bunch of other minor tuning one could suggest here, but I guess
it applies equally to the existing arm versions (and it's unsure whether
it does provide any measurable benefit at all), so I'll refrain from
suggesting it here.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
[FFmpeg-devel] [PATCH] libavdevice: Add KMS/DRM output device
This patch adds KMS/DRM output device for rendering a video stream
using KMS/DRM dumb buffer.
The proposed implementation is very basic, only bgr0 pixel format is
currently supported (the most common format with KMS/DRM).
To enable this output device you need to configure FFmpeg with --enable-libdrm.
Example: ffmpeg -re -i INPUT -pix_fmt bgr0 -f kmsdumb /dev/dri/card0
Nicolas Caramelli
From 939bbbf9feeda3e94f61f2ca3b3c536702e2457a Mon Sep 17 00:00:00 2001
From: Nicolas Caramelli
Date: Sat, 16 Jan 2021 22:55:12 +0100
Subject: [PATCH] libavdevice: Add KMS/DRM output device
Signed-off-by: Nicolas Caramelli
---
configure| 1 +
doc/outdevs.texi | 14 +++
libavdevice/Makefile | 1 +
libavdevice/alldevices.c | 1 +
libavdevice/kmsdumb.c| 246 +++
5 files changed, 263 insertions(+)
create mode 100644 libavdevice/kmsdumb.c
diff --git a/configure b/configure
index 900505756b..1baddbc665 100755
--- a/configure
+++ b/configure
@@ -3417,6 +3417,7 @@ gdigrab_indev_select="bmp_decoder"
iec61883_indev_deps="libiec61883"
jack_indev_deps="libjack"
jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
+kmsdumb_outdev_deps="libdrm"
kmsgrab_indev_deps="libdrm"
lavfi_indev_deps="avfilter"
libcdio_indev_deps="libcdio"
diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index aaf247995c..b458632c40 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -266,6 +266,20 @@ ffmpeg -re -i INPUT -c:v rawvideo -pix_fmt bgra -f fbdev /dev/fb0
See also @url{http://linux-fbdev.sourceforge.net/}, and fbset(1).
+@section kmsdumb
+
+KMS/DRM output device.
+
+This output device allows one to show a video stream using KMS/DRM dumb buffer.
+Only bgr0 pixel format is currently supported (the most common format with KMS/DRM).
+To enable this output device you need to configure FFmpeg with --enable-libdrm.
+
+@subsection Examples
+Play a file on KMS/DRM device @file{/dev/dri/card0}.
+@example
+ffmpeg -re -i INPUT -pix_fmt bgr0 -f kmsdumb /dev/dri/card0
+@end example
+
@section opengl
OpenGL output device.
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index 0dfe47a1f4..965093dc0c 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -31,6 +31,7 @@ OBJS-$(CONFIG_FBDEV_OUTDEV) += fbdev_enc.o \
OBJS-$(CONFIG_GDIGRAB_INDEV) += gdigrab.o
OBJS-$(CONFIG_IEC61883_INDEV)+= iec61883.o
OBJS-$(CONFIG_JACK_INDEV)+= jack.o timefilter.o
+OBJS-$(CONFIG_KMSDUMB_OUTDEV)+= kmsdumb.o
OBJS-$(CONFIG_KMSGRAB_INDEV) += kmsgrab.o
OBJS-$(CONFIG_LAVFI_INDEV) += lavfi.o
OBJS-$(CONFIG_OPENAL_INDEV) += openal-dec.o
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index 92b27a1d14..9a982b60b1 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -39,6 +39,7 @@ extern AVOutputFormat ff_fbdev_muxer;
extern AVInputFormat ff_gdigrab_demuxer;
extern AVInputFormat ff_iec61883_demuxer;
extern AVInputFormat ff_jack_demuxer;
+extern AVOutputFormat ff_kmsdumb_muxer;
extern AVInputFormat ff_kmsgrab_demuxer;
extern AVInputFormat ff_lavfi_demuxer;
extern AVInputFormat ff_openal_demuxer;
diff --git a/libavdevice/kmsdumb.c b/libavdevice/kmsdumb.c
new file mode 100644
index 00..6312773ff5
--- /dev/null
+++ b/libavdevice/kmsdumb.c
@@ -0,0 +1,246 @@
+/*
+ * KMS/DRM ouput device
+ *
+ * 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
+#include
+#include
+#include
+#include
+
+#include "avdevice.h"
+
+typedef struct {
+AVClass *class;
+int fd;
+uint32_t connector_id;
+uint32_t encoder_id;
+uint32_t crtc_id;
+drmModeCrtc *crtc;
+drmModeModeInfo mode_info;
+uint32_t handle;
+uint32_t width;
+uint32_t height;
+uint32_t pitch;
+uint32_t size;
+uint32_t fb_id;
+uint8_t *data;
+} KMSDumbContext;
+
+static av_cold int kmsdumb_write_trailer(AVFormatContext *s)
+{
+KMSDumbContext *kmsdumb = s->priv_data;
+struct drm_mode_destroy_dumb dreq;
+
+if (kmsdumb->data) {
+munmap(kmsdumb->data, kmsdumb->size);
+kmsdumb->data = NULL;
+}
+
+if (kmsdumb->fb_id) {
+drmModeRmFB(kmsdumb->fd, kmsdumb->fb_id);
+
Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
On Sat, 16 Jan 2021, Reimar Döffinger wrote:
On 15 Jan 2021, at 23:55, Martin Storsjö wrote:
On Tue, 12 Jan 2021, reimar.doeffin...@gmx.de wrote:
create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S
create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c
This patch fails checkasm
Fixed, one mis-translated coefficient index...
Ok, good.
+.macro fixsqrshrn d, dt, n, m
+ .ifc \dt, .8H
+sqrshrn2\d\dt, \n\().4S, \m
+ .else
+sqrshrn \n\().4H, \n\().4S, \m
+mov \d\().D[0], \n\().D[0]
+ .endif
+.endm
Is this to set the lower half of the dest register, without wiping the upper
part? It looks a bit clumsy (and stall-prone on in-order cores), but I guess
it's not easy to do things differently without rewriting the higher level
structure?
Did not have a good idea, but I was also aiming for keeping the structure of
the 32-bit and 64-bit code similar.
In particular since I did not know about checkasm and expected some further
painful debug.
+.macro transpose_8x8 r0, r1, r2, r3, r4, r5, r6, r7
+transpose8_4x4 \r0, \r1, \r2, \r3
+transpose8_4x4 \r4, \r5, \r6, \r7
+.endm
+
There's a bunch of existing transposes in libavcodec/aarch64/neon.S - can they
be used? Not that they're rocket science, though... And I see that the existing
arm version also has got its own transpose macros.
If it's inconvenient to use shared macros, this is fine.
They are different and seem to not be documented, so it would take some
time to figure out how to replace them.
There’s also a bit of a question if I’d want to give up alignment
with the 32-bit code just yet.
Sure - one doesn't have to give up on matching the overall structure, but
it doesn't necessarily need to stay 1:1 on the individual instruction
level, if things are done more efficiently in one way or another on the
other architecture. Not saying that these are more or less efficient; a
transpose usually is the same anyway, but the aarch64 macros take a number
of more temp regs as arguments.
+// Transpose each 4x4 block, and swap how d4-d7 and d8-d11 are used.
+// Layout before:
+// d0 d1
+// d2 d3
+// d4 d5
+// d6 d7
+// d8 d9
+// d10 d11
+// d12 d13
+// d14 d15
These layouts don't look like they're up to date for the aarch64 version?
Removed in new version as it seems not that useful.
+vst1.s32{\in7}, [r3, :128]
+.endm
This is left behind untranslated (and thus unused)
Removed. I am not sure if that means it’s also unused in the 32-bit version.
Possibly - a patch for removing that, if it is, would be good too.
+
+movrel x1, trans + 16
The movrel macro has got a separate third optional argument for the offset, so write this
"movrel x1, trans, 16". (Older versions of llvm are picky with the symbol
offset syntax and break with this, as the macro right now adds its own implicit +(0)
here. If you pass the offset in the macro parameter, all the offsets get passed within
the parentheses.
Changed.
+.macro idct_16x16 bitdepth
+function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1
+//r0 - coeffs
+mov x15, lr
+
Binutils doesn't recognize "lr" as alias for x30
It didn’t have an issue in the Debian unstable VM?
That seems like the kind of workaround where it would be
better to leave a comment with more info, if you know
what exactly is affected.
Binutils 2.28 doesn't recognize "lr" while 2.30 does, it seems.
FWIW, all the existing aarch64 assembly just uses "x30" to refer to this
register, none of it uses "lr".
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: Set MSVC as_default later.
On Sat, 16 Jan 2021, Reimar Döffinger wrote:
On 15 Jan 2021, at 23:25, Martin Storsjö wrote:
On Fri, 15 Jan 2021, reimar.doeffin...@gmx.de wrote:
From: Reimar Döffinger
It would get immediately overridden to $cc, which in case
of gas-preprocessor missing would result in it trying
to use cl.exe for asm files instead of erroring out.
This is because cl.exe does not fail but just print a warning
when it is given a file it does not know what to do with it...
As this setup seems to work fine in the setups I've tried, can you think of why
it's overwritten with $cc in your cases?
With the line
: ${as_default:=$cc}
it only sets as_default to $cc if $as_default is empty.
Actually after a few debug prints it’s clear what actually happens:
$arch is not set at that point unless specified on command-line.
Not sure if it’s reasonable to just check arch_default as fallback or such?
Yeah that sounds sensible - maybe just "case ${arch-${arch_default}}"
would work?
You can't really do that here. Probe_cc only should set the existing set of
_type/_ident/_ldflags/_cflags* etc variables, which are picked up by the caller
of probe_cc. probe_cc is called separately for both host and target compilers,
so if e.g. cross compiling, with MSVC as host compiler, with a different
compiler for the target, this wouldn't do the right thing.
Then the armcc logic in there is broken I guess?
I would say so, yes - ideally that should be changed behave like the other
vars like _cflags_* and picked up by caller, only for the target compiler
case.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/librav1e: Pass through timestamps as opaque user data
On 1/14/2021 10:55 AM, Derek Buitenhuis wrote:
avcodec has no facilities to generate timestamps properly from
output frame numbers (and it would be wrong for VFR anyway),
so pass through the timestamps using rav1e's opaque user data
feature, which was added in v0.4.0.
This bumps the minimum librav1e version to 0.4.0.
Signed-off-by: Derek Buitenhuis
---
configure | 2 +-
libavcodec/librav1e.c | 12 +++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 900505756b..54fbbd6b5f 100755
--- a/configure
+++ b/configure
@@ -6408,7 +6408,7 @@ enabled libopus && {
}
enabled libpulse && require_pkg_config libpulse libpulse
pulse/pulseaudio.h pa_context_new
enabled librabbitmq && require_pkg_config librabbitmq "librabbitmq >=
0.7.1" amqp.h amqp_new_connection
-enabled librav1e && require_pkg_config librav1e "rav1e >= 0.1.0"
rav1e.h rav1e_context_new
+enabled librav1e && require_pkg_config librav1e "rav1e >= 0.4.0"
rav1e.h rav1e_context_new
enabled librsvg && require_pkg_config librsvg librsvg-2.0
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
enabled librtmp && require_pkg_config librtmp librtmp
librtmp/rtmp.h RTMP_Socket
enabled librubberband && require_pkg_config librubberband "rubberband >= 1.8.1"
rubberband/rubberband-c.h rubberband_new -lstdc++ && append librubberband_extralibs "-lstdc++"
diff --git a/libavcodec/librav1e.c b/libavcodec/librav1e.c
index 46071bcdac..c1c0de45a6 100644
--- a/libavcodec/librav1e.c
+++ b/libavcodec/librav1e.c
@@ -445,10 +445,18 @@ static int librav1e_receive_packet(AVCodecContext *avctx,
AVPacket *pkt)
if (frame->buf[0]) {
const AVPixFmtDescriptor *desc =
av_pix_fmt_desc_get(frame->format);
+int64_t *pts = av_malloc(sizeof(int64_t));
+if (!pts) {
+av_log(avctx, AV_LOG_ERROR, "Could not allocate PTS
buffer.\n");
+return AVERROR(ENOMEM);
+}
+*pts = frame->pts;
+
rframe = rav1e_frame_new(ctx->ctx);
if (!rframe) {
av_log(avctx, AV_LOG_ERROR, "Could not allocate new rav1e
frame.\n");
av_frame_unref(frame);
+av_freep();
return AVERROR(ENOMEM);
}
@@ -461,6 +469,7 @@ static int librav1e_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
}
av_frame_unref(frame);
}
+rav1e_frame_set_opaque(rframe, pts, av_free);
pts was declared inside the if (frame->buf[0]) block, so compilation
fails. You need to move this line inside that block.
}
ret = rav1e_send_frame(ctx->ctx, rframe);
@@ -535,7 +544,8 @@ retry:
if (rpkt->frame_type == RA_FRAME_TYPE_KEY)
pkt->flags |= AV_PKT_FLAG_KEY;
-pkt->pts = pkt->dts = rpkt->input_frameno * avctx->ticks_per_frame;
+pkt->pts = pkt->dts = *((int64_t *) rpkt->opaque);
+av_free(rpkt->opaque);
rav1e_packet_unref(rpkt);
if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/librav1e: Fix indentation
On 14/01/2021 13:55, Derek Buitenhuis wrote: > Signed-off-by: Derek Buitenhuis > --- > Seems it got mangled at some point. > --- > libavcodec/librav1e.c | 32 > 1 file changed, 16 insertions(+), 16 deletions(-) Will push both of these tomorrow if nobody objects. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avfilter/vsrc_testsrc: add planar support to rgbtestsrc
Signed-off-by: Paul B Mahol
---
libavfilter/vsrc_testsrc.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vsrc_testsrc.c b/libavfilter/vsrc_testsrc.c
index 7001f9ba16..c047fe8e86 100644
--- a/libavfilter/vsrc_testsrc.c
+++ b/libavfilter/vsrc_testsrc.c
@@ -77,6 +77,7 @@ typedef struct TestSourceContext {
/* only used by rgbtest */
uint8_t rgba_map[4];
+int depth;
/* only used by haldclut */
int level;
@@ -970,12 +971,15 @@ AVFILTER_DEFINE_CLASS(rgbtestsrc);
#define B 2
#define A 3
-static void rgbtest_put_pixel(uint8_t *dst, int dst_linesize,
+static void rgbtest_put_pixel(uint8_t *dstp[4], int dst_linesizep[4],
int x, int y, unsigned r, unsigned g, unsigned
b, enum AVPixelFormat fmt,
uint8_t rgba_map[4])
{
+uint8_t *dst = dstp[0];
+int dst_linesize = dst_linesizep[0];
uint32_t v;
uint8_t *p;
+uint16_t *p16;
switch (fmt) {
case AV_PIX_FMT_BGR444: ((uint16_t*)(dst + y*dst_linesize))[x] = ((r >> 4)
<< 8) | ((g >> 4) << 4) | (b >> 4); break;
@@ -998,6 +1002,25 @@ static void rgbtest_put_pixel(uint8_t *dst, int
dst_linesize,
p = dst + 4*x + y*dst_linesize;
AV_WL32(p, v);
break;
+case AV_PIX_FMT_GBRP:
+p = dstp[0] + x + y * dst_linesizep[0];
+p[0] = g;
+p = dstp[1] + x + y * dst_linesizep[1];
+p[0] = b;
+p = dstp[2] + x + y * dst_linesizep[2];
+p[0] = r;
+case AV_PIX_FMT_GBRP9:
+case AV_PIX_FMT_GBRP10:
+case AV_PIX_FMT_GBRP12:
+case AV_PIX_FMT_GBRP14:
+case AV_PIX_FMT_GBRP16:
+p16 = (uint16_t *)(dstp[0] + x*2 + y * dst_linesizep[0]);
+p16[0] = g;
+p16 = (uint16_t *)(dstp[1] + x*2 + y * dst_linesizep[1]);
+p16[0] = b;
+p16 = (uint16_t *)(dstp[2] + x*2 + y * dst_linesizep[2]);
+p16[0] = r;
+break;
}
}
@@ -1008,14 +1031,14 @@ static void rgbtest_fill_picture(AVFilterContext *ctx,
AVFrame *frame)
for (y = 0; y < h; y++) {
for (x = 0; x < w; x++) {
- int c = 256*x/w;
+ int c = (1 << FFMAX(test->depth, 8))*x/w;
int r = 0, g = 0, b = 0;
if (3*y < h ) r = c;
else if (3*y < 2*h) g = c;
elseb = c;
- rgbtest_put_pixel(frame->data[0], frame->linesize[0], x, y, r, g,
b,
+ rgbtest_put_pixel(frame->data, frame->linesize, x, y, r, g, b,
ctx->outputs[0]->format, test->rgba_map);
}
}
@@ -1038,6 +1061,8 @@ static int rgbtest_query_formats(AVFilterContext *ctx)
AV_PIX_FMT_RGB444, AV_PIX_FMT_BGR444,
AV_PIX_FMT_RGB565, AV_PIX_FMT_BGR565,
AV_PIX_FMT_RGB555, AV_PIX_FMT_BGR555,
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10,
+AV_PIX_FMT_GBRP12, AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16,
AV_PIX_FMT_NONE
};
@@ -1050,7 +1075,9 @@ static int rgbtest_query_formats(AVFilterContext *ctx)
static int rgbtest_config_props(AVFilterLink *outlink)
{
TestSourceContext *test = outlink->src->priv;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(outlink->format);
+test->depth = desc->comp[0].depth;
ff_fill_rgba_map(test->rgba_map, outlink->format);
return config_props(outlink);
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avfilter/vsrc_testsrc: add complement mode to rgbtestsrc
Signed-off-by: Paul B Mahol
---
libavfilter/vsrc_testsrc.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vsrc_testsrc.c b/libavfilter/vsrc_testsrc.c
index c047fe8e86..2cf33aadc9 100644
--- a/libavfilter/vsrc_testsrc.c
+++ b/libavfilter/vsrc_testsrc.c
@@ -77,6 +77,7 @@ typedef struct TestSourceContext {
/* only used by rgbtest */
uint8_t rgba_map[4];
+int complement;
int depth;
/* only used by haldclut */
@@ -963,7 +964,13 @@ AVFilter ff_vsrc_testsrc2 = {
#if CONFIG_RGBTESTSRC_FILTER
-#define rgbtestsrc_options options
+static const AVOption rgbtestsrc_options[] = {
+COMMON_OPTIONS
+{ "complement", "set complement colors", OFFSET(complement),
AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS },
+{ "co", "set complement colors", OFFSET(complement),
AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS },
+{ NULL }
+};
+
AVFILTER_DEFINE_CLASS(rgbtestsrc);
#define R 0
@@ -1024,6 +1031,29 @@ static void rgbtest_put_pixel(uint8_t *dstp[4], int
dst_linesizep[4],
}
}
+static void rgbtest_fill_picture_complement(AVFilterContext *ctx, AVFrame
*frame)
+{
+TestSourceContext *test = ctx->priv;
+int x, y, w = frame->width, h = frame->height;
+
+for (y = 0; y < h; y++) {
+ for (x = 0; x < w; x++) {
+ int c = (1 << FFMAX(test->depth, 8))*x/w;
+ int r = 0, g = 0, b = 0;
+
+ if (6*y < h ) r = c;
+ else if (6*y < 2*h) g = c, b = c;
+ else if (6*y < 3*h) g = c;
+ else if (6*y < 4*h) r = c, b = c;
+ else if (6*y < 5*h) b = c;
+ elser = c, g = c;
+
+ rgbtest_put_pixel(frame->data, frame->linesize, x, y, r, g, b,
+ ctx->outputs[0]->format, test->rgba_map);
+ }
+ }
+}
+
static void rgbtest_fill_picture(AVFilterContext *ctx, AVFrame *frame)
{
TestSourceContext *test = ctx->priv;
@@ -1049,7 +1079,7 @@ static av_cold int rgbtest_init(AVFilterContext *ctx)
TestSourceContext *test = ctx->priv;
test->draw_once = 1;
-test->fill_picture_fn = rgbtest_fill_picture;
+test->fill_picture_fn = test->complement ? rgbtest_fill_picture_complement
: rgbtest_fill_picture;
return init(ctx);
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/bsf: set pctx to NULL when av_bsf_alloc failed
> 在 2021年1月16日，21:19，James Almer 写道： > > On 1/16/2021 2:24 AM, Steven Liu wrote: >> av_bsf_free will free invalid pointer when av_bsf_alloc failed. >> because av_bsf_list_parse_str called av_bsf_get_null_filter, >> av_bsf_get_null_filter called av_bsf_alloc, and av_bsf_alloc >> should set a value to the *pctx before return success or failed, >> because it dose not initial a null pointer ever, so it will free >> invalid pointer in av_bsf_free which is called by ff_decode_bsfs_init. > > The pointer passed to av_bsf_list_parse_str() in ff_decode_bsfs_init() is > already NULL, because avctx->internal was allocated with av_mallocz(). It’s good point, yes, you are right. > > In what scenario is av_bsf_free() getting an invalid pointer? only call ff_decode_bsfs_init and not use avcodec_open2, call it by myself write internal code, maybe nobody will use it like my way :( > >> Found-by: Zu-Ming Jiang >> Signed-off-by: Steven Liu >> --- >> libavcodec/bsf.c | 1 + >> 1 file changed, 1 insertion(+) >> diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c >> index d71bc32584..5bb3349138 100644 >> --- a/libavcodec/bsf.c >> +++ b/libavcodec/bsf.c >> @@ -141,6 +141,7 @@ int av_bsf_alloc(const AVBitStreamFilter *filter, >> AVBSFContext **pctx) >> return 0; >> fail: >> av_bsf_free(); >> +*pctx = NULL; >> return ret; >> } >> > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/dv_profile: dv files with wrong dsf flag - detect via buf_size
Trying to fix https://trac.ffmpeg.org/ticket/8333 Some of my old DV AVI files have the DSF-Flag of frames set to 0, although it is PAL (I think they were rendered with Ulead Media Studio Pro) ... this causes ffmpeg/VLC-player to produce/play corrupted video. In other players/editors it works fine including: - VirtualDub - Windows Media Player - AVCutty - Ulead Media Studio Pro (very old) I had a look at VirtualDub ... there the PAL/NTSC detection is based on the frame rate from AVISTREAMINFO header (dwRate/dwScale) - see https://github.com/Pavuucek/VirtualDub/blob/f47ebd2536f0034b048180d0b9cb9bde0ab10c73/src/VirtualDub/source/VideoSource.cpp#L1211 As I don't know, how to access the AVI header info inside dvvideo_decode_frame()/ff_dv_frame_profile(), I tried another workaround by checking the buf_size against the dv_profile. It works fine now, but I don't know, if this is really the best solution ... >From 9dd240e6700c28601014e79e55d3ddee5f6b13c7 Mon Sep 17 00:00:00 2001 From: Mark Plomer Date: Sat, 16 Jan 2021 14:04:44 +0100 Subject: [PATCH] avcodec/dv_profile: dv files with wrong dsf flag - detect via buf_size --- libavcodec/dv_profile.c | 4 1 file changed, 4 insertions(+) diff --git a/libavcodec/dv_profile.c b/libavcodec/dv_profile.c index 66505c886b..8f9a358032 100644 --- a/libavcodec/dv_profile.c +++ b/libavcodec/dv_profile.c @@ -281,6 +281,10 @@ const AVDVProfile* ff_dv_frame_profile(AVCodecContext* codec, const AVDVProfile && codec->coded_height==576) return _profiles[1]; +/* hack for trac issue #8333, dv files with wrong dsf flag - detect via buf_size */ +if (dsf == 0 && stype == dv_profiles[1].video_stype && buf_size == dv_profiles[1].frame_size) +return _profiles[1]; + for (i = 0; i < FF_ARRAY_ELEMS(dv_profiles); i++) if (dsf == dv_profiles[i].dsf && stype == dv_profiles[i].video_stype) return _profiles[i]; -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/bsf: set pctx to NULL when av_bsf_alloc failed
On 1/16/2021 2:24 AM, Steven Liu wrote: av_bsf_free will free invalid pointer when av_bsf_alloc failed. because av_bsf_list_parse_str called av_bsf_get_null_filter, av_bsf_get_null_filter called av_bsf_alloc, and av_bsf_alloc should set a value to the *pctx before return success or failed, because it dose not initial a null pointer ever, so it will free invalid pointer in av_bsf_free which is called by ff_decode_bsfs_init. The pointer passed to av_bsf_list_parse_str() in ff_decode_bsfs_init() is already NULL, because avctx->internal was allocated with av_mallocz(). In what scenario is av_bsf_free() getting an invalid pointer? Found-by: Zu-Ming Jiang Signed-off-by: Steven Liu --- libavcodec/bsf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c index d71bc32584..5bb3349138 100644 --- a/libavcodec/bsf.c +++ b/libavcodec/bsf.c @@ -141,6 +141,7 @@ int av_bsf_alloc(const AVBitStreamFilter *filter, AVBSFContext **pctx) return 0; fail: av_bsf_free(); +*pctx = NULL; return ret; } ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/af_astats: fix possible crash because of undefined float to integer rounding
Fixes ticket #9049. Signed-off-by: Marton Balint --- libavfilter/af_astats.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/af_astats.c b/libavfilter/af_astats.c index ebaae29f44..f50cbe199c 100644 --- a/libavfilter/af_astats.c +++ b/libavfilter/af_astats.c @@ -329,11 +329,11 @@ static inline void update_stat(AudioStatsContext *s, ChannelStats *p, double d, drop = p->win_samples[p->win_pos]; p->win_samples[p->win_pos] = nd; -index = av_clip(FFABS(av_clipd(nd, -1.0, 1.0)) * HISTOGRAM_MAX, 0, HISTOGRAM_MAX); +index = av_clip(lrint(av_clipd(FFABS(nd), 0.0, 1.0) * HISTOGRAM_MAX), 0, HISTOGRAM_MAX); p->max_index = FFMAX(p->max_index, index); p->histogram[index]++; if (!isnan(p->noise_floor)) -p->histogram[av_clip(FFABS(drop) * HISTOGRAM_MAX, 0, HISTOGRAM_MAX)]--; +p->histogram[av_clip(lrint(av_clipd(FFABS(drop), 0.0, 1.0) * HISTOGRAM_MAX), 0, HISTOGRAM_MAX)]--; p->win_pos++; while (p->histogram[p->max_index] == 0) -- 2.26.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Revert "avutil/timecode: fix sscanf format string with garbage at the end"
This reverts commit 6696a07ac62bfec49dd488510a719367918b9f7a.
It is wrong to restrict timecodes to always contain leading zeros or for hours
or frames to be 2 chars only.
Signed-off-by: Marton Balint
---
libavutil/timecode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/timecode.c b/libavutil/timecode.c
index 5106f642b9..c1fa445d31 100644
--- a/libavutil/timecode.c
+++ b/libavutil/timecode.c
@@ -252,7 +252,7 @@ int av_timecode_init_from_string(AVTimecode *tc, AVRational
rate, const char *st
char c;
int hh, mm, ss, ff, flags;
-if (sscanf(str, "%02u:%02u:%02u%c%02u", , , , , ) != 5) {
+if (sscanf(str, "%d:%d:%d%c%d", , , , , ) != 5) {
av_log(log_ctx, AV_LOG_ERROR, "Unable to parse timecode, "
"syntax: hh:mm:ss[:;.]ff\n");
return AVERROR_INVALIDDATA;
--
2.26.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
