Re: [FFmpeg-devel] [PATCH] avformat/dashenc: only write video streams into HLS master playlist
On 9/14/18 12:38 PM, Jian Yang wrote:
> Tool mediastreamvalidator reports error "Variant media_[N].m3u8 is
> missing audio group" for audio streams in HLS master playlist. As audio
> streams are already listed in audio group, skip them as variant media
> streams in master playlist.
> ---
> libavformat/dashenc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 87e31e25fc..45763301db 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -911,8 +911,10 @@ static int write_manifest(AVFormatContext *s, int final)
> OutputStream *os = &c->streams[i];
> char *agroup = NULL;
> int stream_bitrate = st->codecpar->bit_rate + os->muxer_overhead;
> +if (st->codecpar->codec_type != AVMEDIA_TYPE_VIDEO)
> +continue;
> av_strlcpy(codec_str, os->codec_str, sizeof(codec_str));
> -if ((st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) &&
> max_audio_bitrate) {
> +if (max_audio_bitrate) {
> agroup = (char *)audio_group;
> stream_bitrate += max_audio_bitrate;
> av_strlcat(codec_str, ",", sizeof(codec_str));
Pushed this patch. Thanks.
In spite of my original objections for supporting audio-only, I am pushing this
patch as I am hearing reports of HLS master playlist generated being not
playable in iOS devices due to this issue.
Hence pushing this patch becomes important for supporting basic HLS playback is
more important than supporting audio-only HLS stream.
Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] avformat:hlsenc.c: remove the useless variable - fmp4_init_mode.
Signed-off-by: Charles Liu
---
libavformat/hlsenc.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c322b5a48f..0fd5d2a995 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -147,7 +147,6 @@ typedef struct VariantStream {
char *fmp4_init_filename;
char *base_output_dirname;
-int fmp4_init_mode;
AVStream **streams;
char codec_attr[128];
@@ -733,7 +732,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream
*vs)
vs->packets_written = 1;
vs->start_pos = 0;
vs->new_start = 1;
-vs->fmp4_init_mode = 0;
if (hls->segment_type == SEGMENT_TYPE_FMP4) {
if (hls->max_seg_size > 0) {
@@ -743,7 +741,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream
*vs)
vs->packets_written = 0;
vs->init_range_length = 0;
-vs->fmp4_init_mode = !byterange_mode;
set_http_options(s, &options, hls);
if ((ret = avio_open_dyn_buf(&oc->pb)) < 0)
return ret;
@@ -2291,7 +2288,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
vs->start_pos += vs->size;
}
-vs->fmp4_init_mode = 0;
if (hls->flags & HLS_SINGLE_FILE) {
vs->number++;
} else if (hls->max_seg_size > 0) {
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] avformat:hlsenc.c: fix memory leak in fmp4 mode.
Signed-off-by: Charles Liu --- libavformat/hlsenc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c index 3ccd8756f6..c322b5a48f 100644 --- a/libavformat/hlsenc.c +++ b/libavformat/hlsenc.c @@ -2205,6 +2205,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket *pkt) avio_flush(oc->pb); range_length = avio_close_dyn_buf(oc->pb, &buffer); avio_write(vs->out, buffer, range_length); +av_free(buffer); vs->init_range_length = range_length; avio_open_dyn_buf(&oc->pb); vs->packets_written = 0; -- 2.19.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] avformat/hlsenc: fix the duration of m4s segment is unusually smaller than expected.
In fmp4 mode, the duration of the second m4s segment is unusually smaller than
the expected segment time.
Signed-off-by: Charles Liu
---
libavformat/hlsenc.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 28c2dd62fc..3ccd8756f6 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2233,10 +2233,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
}
}
-if (vs->fmp4_init_mode) {
-vs->number--;
-}
-
if (hls->segment_type == SEGMENT_TYPE_FMP4) {
if (hls->flags & HLS_SINGLE_FILE) {
ret = flush_dynbuf(vs, &range_length);
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/5] avformat:hlsenc.c: the size of init.mp4 is zero.
The size of init.mp4 is zero in fmp4 mode, when the input duraton smaller than
the expected segment time.
fix ticket: 7166
Signed-off-by: Charles Liu
---
libavformat/hlsenc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 0fd5d2a995..8b3a9b78f4 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2348,6 +2348,25 @@ static int hls_write_trailer(struct AVFormatContext *s)
return AVERROR(ENOMEM);
}
if ( hls->segment_type == SEGMENT_TYPE_FMP4) {
+if (!vs->init_range_length) {
+av_write_frame(vs->avf, NULL); /* Flush any buffered data */
+avio_flush(oc->pb);
+
+uint8_t *buffer = NULL;
+int range_length = avio_close_dyn_buf(oc->pb, &buffer);
+avio_write(vs->out, buffer, range_length);
+av_free(buffer);
+vs->init_range_length = range_length;
+avio_open_dyn_buf(&oc->pb);
+vs->packets_written = 0;
+vs->start_pos = range_length;
+int byterange_mode = (hls->flags & HLS_SINGLE_FILE) ||
(hls->max_seg_size > 0);
+if (!byterange_mode) {
+ff_format_io_close(s, &vs->out);
+hlsenc_io_close(s, &vs->out, vs->base_output_dirname);
+}
+}
+
int range_length = 0;
if (!(hls->flags & HLS_SINGLE_FILE)) {
ret = hlsenc_io_open(s, &vs->out, vs->avf->url, NULL);
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] avformat:hlsenc.c: fix the output's duration smaller than input's in sub-range mode.
In fmp4 & sub-range mode, the output's duration always smaller than expected,
because the size of the last #EXT-X-BYTERANGE is too small.
Signed-off-by: Charles Liu
---
libavformat/hlsenc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 8b3a9b78f4..f8f060d065 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2380,6 +2380,7 @@ static int hls_write_trailer(struct AVFormatContext *s)
if (ret < 0) {
goto failed;
}
+vs->size = range_length;
ff_format_io_close(s, &vs->out);
}
@@ -2388,8 +2389,6 @@ failed:
if (oc->pb) {
if (hls->segment_type != SEGMENT_TYPE_FMP4) {
vs->size = avio_tell(vs->avf->pb) - vs->start_pos;
-} else {
-vs->size = avio_tell(vs->avf->pb);
}
if (hls->segment_type != SEGMENT_TYPE_FMP4)
ff_format_io_close(s, &oc->pb);
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavc/qsvenc_jpeg: add async_depth support
Currently qsv (m)jpeg encoding is broken.
Regression introducing by the commit(id: c1bcd3): fix async support,
which requires the minimum async_depth to be 1, instead previous zero.
But the default async_depth of qsv (m)jpeg encoding is still initialized
(mostly) as zero.
This patch also abviously improves qsv (m)jpeg encoding performance
due to the default async_depth is changed to 4.
Signed-off-by: Zhong Li
---
libavcodec/qsvenc_jpeg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/qsvenc_jpeg.c b/libavcodec/qsvenc_jpeg.c
index c18fe91..01c10125 100644
--- a/libavcodec/qsvenc_jpeg.c
+++ b/libavcodec/qsvenc_jpeg.c
@@ -64,6 +64,7 @@ static av_cold int qsv_enc_close(AVCodecContext *avctx)
#define OFFSET(x) offsetof(QSVMJPEGEncContext, x)
#define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
+{ "async_depth", "Maximum processing parallelism",
OFFSET(qsv.async_depth), AV_OPT_TYPE_INT, { .i64 = ASYNC_DEPTH_DEFAULT }, 1,
INT_MAX, VE },
{ NULL },
};
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavc/qsvenc_jpeg: set a default quality
Keep alignment with vaapi mjpeg encoder.
Signed-off-by: Zhong Li
---
libavcodec/qsvenc_jpeg.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/qsvenc_jpeg.c b/libavcodec/qsvenc_jpeg.c
index 01c10125..1e7785a 100644
--- a/libavcodec/qsvenc_jpeg.c
+++ b/libavcodec/qsvenc_jpeg.c
@@ -75,6 +75,11 @@ static const AVClass class = {
.version= LIBAVUTIL_VERSION_INT,
};
+static const AVCodecDefault qsv_enc_defaults[] = {
+{ "global_quality", "80" },
+{ NULL },
+};
+
AVCodec ff_mjpeg_qsv_encoder = {
.name = "mjpeg_qsv",
.long_name = NULL_IF_CONFIG_SMALL("MJPEG (Intel Quick Sync Video
acceleration)"),
@@ -89,5 +94,6 @@ AVCodec ff_mjpeg_qsv_encoder = {
AV_PIX_FMT_QSV,
AV_PIX_FMT_NONE },
.priv_class = &class,
+.defaults = qsv_enc_defaults,
.wrapper_name = "qsv",
};
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: log corrupted packets and frames
On Wed, Oct 10, 2018 at 01:32:13AM +0200, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > fftools/ffmpeg.c | 16 ++-- > 1 file changed, 10 insertions(+), 6 deletions(-) maybe this should also print some time information so the user knows from the printout when issues occured but LGTM otherwise thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: keep CORRUPT and TRUSTED packet flags when parsing packets
On Wed, Oct 10, 2018 at 01:32:14AM +0200, Marton Balint wrote:
> An FF_ macro got defined in avcodec.h to store the flags which need to be
> propagated when parsers split packets so this won't be forgotten when a new
> packet flag is introduced.
>
> (I wonder if DISPOSABLE also fits here, or maybe some special handling is
> needed like it is done for the keyframe flag?)
> ---
> libavcodec/avcodec.h | 9 -
> libavcodec/version.h | 2 +-
> libavformat/utils.c | 2 +-
> tests/ref/fate/flv-demux | 2 +-
> tests/ref/fate/iv8-demux | 2 +-
> tests/ref/fate/segment-mp4-to-ts | 6 +++---
> tests/ref/fate/ts-demux | 2 +-
> 7 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 705a3ce4f3..9a3f9b6226 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1493,7 +1493,14 @@ typedef struct AVPacket {
> * be discarded by the decoder. I.e. Non-reference frames.
> */
> #define AV_PKT_FLAG_DISPOSABLE 0x0010
> -
> +/**
> + * Packet flags which must always be kept when parsers split packets
> + */
> +#define FF_PKT_FLAGS_KEEP_WHEN_PARSING (\
> +AV_PKT_FLAG_CORRUPT | \
> +AV_PKT_FLAG_DISCARD | \
> +AV_PKT_FLAG_TRUSTED | \
> +0)
>
> enum AVSideDataParamChangeFlags {
> AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 97d134851f..79c5dc6773 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -29,7 +29,7 @@
>
> #define LIBAVCODEC_VERSION_MAJOR 58
> #define LIBAVCODEC_VERSION_MINOR 32
> -#define LIBAVCODEC_VERSION_MICRO 100
> +#define LIBAVCODEC_VERSION_MICRO 101
>
> #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> LIBAVCODEC_VERSION_MINOR, \
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index a8ac90213e..351bd88fa5 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1511,7 +1511,7 @@ static int parse_packet(AVFormatContext *s, AVPacket
> *pkt, int stream_index)
> out_pkt.pts = st->parser->pts;
> out_pkt.dts = st->parser->dts;
> out_pkt.pos = st->parser->pos;
> -out_pkt.flags |= pkt->flags & AV_PKT_FLAG_DISCARD;
> +out_pkt.flags |= pkt->flags & FF_PKT_FLAGS_KEEP_WHEN_PARSING;
I think this is wrong
this looks like the packet flags are not passed through the parsers, so they
would
not neccessarily be attached to the correct packets, there could be a delay
from a buffer ...
more so, these flags cannot be handled identically
for example if there is output packet formed from concatenating a trusted and
untrusted input packet the output cannot be trusted because it is not just
trusted data
compared to corrupt, if there is output packet formed from concatenating a
corrupt and non-corrupt input packet the output still is corrupt
It gets further complicated if only part of a AV_PKT_FLAG_CORRUPT input is
used. You cant mark the output as corrupt in this case because as documented
AV_PKT_FLAG_CORRUPT means the packet IS corrupt but a subpart of it may be
corrupt or may be undamaged.
A finer granularity of corruption likelyness would be needed here.
(checksums matching, probably ok - no checksums, possibly corrupt,
certainly some corrupt, certain significant corruption)
Independant of this there could be information about packet truncation.
a packet content could be known to be correct but possibly incomplete
All these cases differ in how they would have to be passed on when packets
are merged / split
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There will always be a question for which you do not know the correct answer.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Is Patchwork broken?
On Wed, Oct 10, 2018 at 11:00:07PM +0530, Gyan wrote: > The latest commit that shows at > https://patchwork.ffmpeg.org/project/ffmpeg/list/?state=%2A&archive=both is > from 1st October. > > Is Patchwork no longer active? fixed by raz Thanks for reporting the issue -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/aacdec_template: Allow duplicated elements
On 10/7/18, Michael Niedermayer wrote:
> Such streams are invalid according to
> 4.5.2.1 Top level payloads for the audio object types AAC main, AAC SSR, AAC
> LC and AAC LTP
> 4.5.2.1.1 Definitions
> ...cIn the raw_data_block(), several instances of the
> same syntactic element may occur, but must have a different 4 bit
> element_instance_tag, except for data_stream_element()'s and
> fill_element()'s.
>
> Fixes: Ticket7477
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/aacdec_template.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index b60b31a92c..dce6035d67 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -3161,12 +3161,15 @@ static int aac_decode_frame_int(AVCodecContext
> *avctx, void *data,
>
> if (elem_type < TYPE_DSE) {
> if (che_presence[elem_type][elem_id]) {
> -av_log(ac->avctx, AV_LOG_ERROR, "channel element %d.%d
> duplicate\n",
> +int error = che_presence[elem_type][elem_id] > 1;
> +av_log(ac->avctx, error ? AV_LOG_ERROR : AV_LOG_DEBUG,
> "channel element %d.%d duplicate\n",
> elem_type, elem_id);
> -err = AVERROR_INVALIDDATA;
> -goto fail;
> +if (error) {
> +err = AVERROR_INVALIDDATA;
> +goto fail;
> +}
> }
> -che_presence[elem_type][elem_id] = 1;
> +che_presence[elem_type][elem_id]++;
>
> if (!(che=get_che(ac, elem_type, elem_id))) {
> av_log(ac->avctx, AV_LOG_ERROR, "channel element %d.%d is
> not allocated\n",
> --
> 2.19.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
probably ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: keep CORRUPT and TRUSTED packet flags when parsing packets
On Thu, Oct 11, 2018 at 12:50:53PM +0200, Michael Niedermayer wrote:
> On Wed, Oct 10, 2018 at 01:32:14AM +0200, Marton Balint wrote:
> > An FF_ macro got defined in avcodec.h to store the flags which need to be
> > propagated when parsers split packets so this won't be forgotten when a new
> > packet flag is introduced.
> >
> > (I wonder if DISPOSABLE also fits here, or maybe some special handling is
> > needed like it is done for the keyframe flag?)
> > ---
> > libavcodec/avcodec.h | 9 -
> > libavcodec/version.h | 2 +-
> > libavformat/utils.c | 2 +-
> > tests/ref/fate/flv-demux | 2 +-
> > tests/ref/fate/iv8-demux | 2 +-
> > tests/ref/fate/segment-mp4-to-ts | 6 +++---
> > tests/ref/fate/ts-demux | 2 +-
> > 7 files changed, 16 insertions(+), 9 deletions(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 705a3ce4f3..9a3f9b6226 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1493,7 +1493,14 @@ typedef struct AVPacket {
> > * be discarded by the decoder. I.e. Non-reference frames.
> > */
> > #define AV_PKT_FLAG_DISPOSABLE 0x0010
> > -
> > +/**
> > + * Packet flags which must always be kept when parsers split packets
> > + */
> > +#define FF_PKT_FLAGS_KEEP_WHEN_PARSING (\
> > +AV_PKT_FLAG_CORRUPT | \
> > +AV_PKT_FLAG_DISCARD | \
> > +AV_PKT_FLAG_TRUSTED | \
> > +0)
> >
> > enum AVSideDataParamChangeFlags {
> > AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
> > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > index 97d134851f..79c5dc6773 100644
> > --- a/libavcodec/version.h
> > +++ b/libavcodec/version.h
> > @@ -29,7 +29,7 @@
> >
> > #define LIBAVCODEC_VERSION_MAJOR 58
> > #define LIBAVCODEC_VERSION_MINOR 32
> > -#define LIBAVCODEC_VERSION_MICRO 100
> > +#define LIBAVCODEC_VERSION_MICRO 101
> >
> > #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> > LIBAVCODEC_VERSION_MINOR, \
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index a8ac90213e..351bd88fa5 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -1511,7 +1511,7 @@ static int parse_packet(AVFormatContext *s, AVPacket
> > *pkt, int stream_index)
> > out_pkt.pts = st->parser->pts;
> > out_pkt.dts = st->parser->dts;
> > out_pkt.pos = st->parser->pos;
> > -out_pkt.flags |= pkt->flags & AV_PKT_FLAG_DISCARD;
> > +out_pkt.flags |= pkt->flags & FF_PKT_FLAGS_KEEP_WHEN_PARSING;
>
> I think this is wrong
> this looks like the packet flags are not passed through the parsers, so they
> would
> not neccessarily be attached to the correct packets, there could be a delay
> from a buffer ...
>
> more so, these flags cannot be handled identically
> for example if there is output packet formed from concatenating a trusted and
> untrusted input packet the output cannot be trusted because it is not just
> trusted data
btw, also consider 256 1 byte trusted packets, arbitrary combination of these
are not trusted, the order by which they are combined has to be trusted too
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: improve the intra stream discontinuity message
On Wed, Oct 10, 2018 at 02:10:25AM +0300, Jan Ekström wrote: > Now it actually tells which stream from which input and of > which type had an absolute DTS discontinuity larger than > dts_delta_threshold. > --- > fftools/ffmpeg.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"
Hi,
Testing FFmpeg FFV1 encoder on big frames (more than 4K: 4300x3956), I
have a warning for each frame encoded (so a lot of warnings!):
[ffv1 @ 024a6bcfe880] Cannot allocate worst case packet size, the
encoding could fail
Checking avcodec/ffv1enc.c, it is due to the following lines:
int64_t maxsize = AV_INPUT_BUFFER_MIN_SIZE
+ avctx->width*avctx->height*37LL*4;
[...]
if (maxsize > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE - 32) {
av_log(avctx, AV_LOG_WARNING, "Cannot allocate worst case
packet size, the encoding could fail\n");
maxsize = INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE - 32;
}
The value of maxsize is 2517614784, more than INT_MAX, sure, but I don't
understand:
- why does FFmpeg need to allocate 148 times the size of a frame?
- why is having a number > INT_MAX an issue? modern machines are 64-bit
and have 8+ GB of RAM, and in practice I currently saw no encoding
failure on thousands of frames.
Additionally I didn't get why maxsize is reduced ("only" need of 12
times the size of the frame) in case of FFV1 version > 3 (experimental
right now):
if (f->version > 3)
maxsize = AV_INPUT_BUFFER_MIN_SIZE +
avctx->width*avctx->height*3LL*4;
maxsize is used for calling ff_alloc_packet2(), which accepts 64-bit
numbers.
if ((ret = ff_alloc_packet2(avctx, pkt, maxsize, 0)) < 0)
return ret;
Is it possible to reduce this "37x4" multiplier without risk and/or
remove maxsize reduction in case of sizeof(size_t) == 8 and/or show the
warning only once?
Issue can be reproduced with:
./ffmpeg.exe -f lavfi -i testsrc2=size=4300x3956 -t 0.040 -pix_fmt
rgba64 rgba64.dpx
./ffmpeg.exe -i rgba64.dpx -c:v ffv1 rgba64.mkv
Jérôme
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"
On 10/11/18, Jerome Martinez wrote:
> Hi,
>
> Testing FFmpeg FFV1 encoder on big frames (more than 4K: 4300x3956), I
> have a warning for each frame encoded (so a lot of warnings!):
> [ffv1 @ 024a6bcfe880] Cannot allocate worst case packet size, the
> encoding could fail
>
> Checking avcodec/ffv1enc.c, it is due to the following lines:
> int64_t maxsize = AV_INPUT_BUFFER_MIN_SIZE
>+ avctx->width*avctx->height*37LL*4;
> [...]
> if (maxsize > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE - 32) {
> av_log(avctx, AV_LOG_WARNING, "Cannot allocate worst case
> packet size, the encoding could fail\n");
> maxsize = INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE - 32;
> }
>
> The value of maxsize is 2517614784, more than INT_MAX, sure, but I don't
> understand:
> - why does FFmpeg need to allocate 148 times the size of a frame?
> - why is having a number > INT_MAX an issue? modern machines are 64-bit
> and have 8+ GB of RAM, and in practice I currently saw no encoding
> failure on thousands of frames.
>
> Additionally I didn't get why maxsize is reduced ("only" need of 12
> times the size of the frame) in case of FFV1 version > 3 (experimental
> right now):
> if (f->version > 3)
> maxsize = AV_INPUT_BUFFER_MIN_SIZE +
> avctx->width*avctx->height*3LL*4;
>
> maxsize is used for calling ff_alloc_packet2(), which accepts 64-bit
> numbers.
> if ((ret = ff_alloc_packet2(avctx, pkt, maxsize, 0)) < 0)
> return ret;
>
> Is it possible to reduce this "37x4" multiplier without risk and/or
> remove maxsize reduction in case of sizeof(size_t) == 8 and/or show the
> warning only once?
>
> Issue can be reproduced with:
> ./ffmpeg.exe -f lavfi -i testsrc2=size=4300x3956 -t 0.040 -pix_fmt
> rgba64 rgba64.dpx
> ./ffmpeg.exe -i rgba64.dpx -c:v ffv1 rgba64.mkv
You are not using latest version of FFv1.
In latest version, encoder will not produce packets which are bigger than
input ones -- uncompressed raw. And instead if that happens it will encode
as raw video.
Theoretically output packets for old versions of FFv1 could be several
times bigger than raw input frame.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avcodec/libopenh264enc.c
When using libx264 (GPL) encoder, sample aspect ratio gets stored on both container and frame levels. For libopenh264 (LGPL), aspect ratio on codec/frame level currently is ignored, which results in weird display aspect ratio for non-square pixels on some players. Proposed patch fixes that, if FFmpeg being build against libopenh264 1.7 or newer. 0001-Set-sample-aspect-ratio-in-libopenh264-encoder.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] h264/pic_timing: support multiple timecodes
On 9 October 2018 at 21:03, Carl Eugen Hoyos wrote: > 2018-10-09 15:32 GMT+02:00, jos...@ob-encoder.com : >> From: Josh de Kock > >> [...] > > If the first patch gets committed as-is, please split this one > in a functional and a cosmetic patch, above is unreviewable. > > Thank you, Carl Eugen I assume you mean split vf_showinfo out, I had intended to do that but clearly I forgot so will do that. And why is it unreviewable? Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"
On 11/10/2018 14:08, Paul B Mahol wrote:
On 10/11/18, Jerome Martinez wrote:
Hi,
Testing FFmpeg FFV1 encoder on big frames (more than 4K: 4300x3956), I
have a warning for each frame encoded (so a lot of warnings!):
[ffv1 @ 024a6bcfe880] Cannot allocate worst case packet size, the
encoding could fail
Checking avcodec/ffv1enc.c, it is due to the following lines:
int64_t maxsize = AV_INPUT_BUFFER_MIN_SIZE
+ avctx->width*avctx->height*37LL*4;
[...]
if (maxsize > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE - 32) {
av_log(avctx, AV_LOG_WARNING, "Cannot allocate worst case
packet size, the encoding could fail\n");
maxsize = INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE - 32;
}
The value of maxsize is 2517614784, more than INT_MAX, sure, but I don't
understand:
- why does FFmpeg need to allocate 148 times the size of a frame?
- why is having a number > INT_MAX an issue? modern machines are 64-bit
and have 8+ GB of RAM, and in practice I currently saw no encoding
failure on thousands of frames.
Additionally I didn't get why maxsize is reduced ("only" need of 12
times the size of the frame) in case of FFV1 version > 3 (experimental
right now):
if (f->version > 3)
maxsize = AV_INPUT_BUFFER_MIN_SIZE +
avctx->width*avctx->height*3LL*4;
maxsize is used for calling ff_alloc_packet2(), which accepts 64-bit
numbers.
if ((ret = ff_alloc_packet2(avctx, pkt, maxsize, 0)) < 0)
return ret;
Is it possible to reduce this "37x4" multiplier without risk and/or
remove maxsize reduction in case of sizeof(size_t) == 8 and/or show the
warning only once?
Issue can be reproduced with:
./ffmpeg.exe -f lavfi -i testsrc2=size=4300x3956 -t 0.040 -pix_fmt
rgba64 rgba64.dpx
./ffmpeg.exe -i rgba64.dpx -c:v ffv1 rgba64.mkv
You are not using latest version of FFv1.
As far as I know, version 3 is the latest (stable) version of FFV1, and
I use this one.
version > 3 are experimental.
I am not sure that advising to use an experimental version for "fixing"
a warning is good.
Additionally, in theory a 16kx16k content would still produce this
warning with FFV1 (experimental) v4 encoding, even if there is 16
Terabytes of RAM (more than enough for having the MAX_INT = 2 GiB raw
frame in RAM), so I understand that the warning would still be there (in
theory) with FFV1 (experimental) v4.
In latest version, encoder will not produce packets which are bigger than
input ones -- uncompressed raw. And instead if that happens it will encode
as raw video.
Theoretically output packets for old versions of FFv1 could be several
times bigger than raw input frame.
In this case, the ratio (148 times the size of input) is proportional to
the input frame size, and the test is on a fixed value (MAX_INT).
I get now the reason to reserve more than the size of the input frame.
I don't get the relationship between your explanation and these hard
coded values (148 times the size of input and MAX_INT limit).
Why 148x (37x4) and not 147 or 149?
Why a warning and maxsize forced to MAX_INT if maxsize > MAX_INT? Is it
an internal constraint of FFmpeg which would be not able to store
encoded frames bigger than MAX_INT?
Can any of that be changed e.g. warning only once for avoiding "spam" of
such warning which hides other warnings during encoding?
Jérôme
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavf/timecode: document SMPTE struct
On 9 October 2018 at 21:21, Devin Heitmueller wrote: > >> On Oct 9, 2018, at 4:07 PM, Carl Eugen Hoyos wrote: >> >> 2018-10-09 15:32 GMT+02:00, jos...@ob-encoder.com : >>> From: Devin Heitmueller >>> >>> There are a number of different binary representations in which >>> SMPTE timecodes can use. Make clear that the specific representation >>> that ffmpeg refers to corresponds to the DV video spec, which is >>> SMPTE S314M:2005 for standard definition video and ST 370-2013 for >>> high definition video. >> >> If this is correct - I have no idea - why is only one standard >> mentioned in the actual change? >> >>> +/* See SMPTE ST 314M-2005 Sec 4.4.2.2.1 "Time code pack (TC)" */ >> > > Yeah, I noticed this after I did the original commit and planned to fix it > before I submitted the patch upstream. Was reminded of it myself when I saw > Josh submitted the patch on my behalf. > > The information describing the structure is identical between the two specs, > and thus referring to both doesn’t give you any additional information. > However it’s possible that someone has access to one spec but not the other > (since they are not freely available), and thus referring to both specs > probably makes sense. > > Josh, feel free to update the patch to refer to both specifications, or drop > the patch from your series and I’ll include an updated patch in my next patch > series. Whatever works best for you. > > Devin I don't have access to either specs, so I couldn't reference it even if I wanted to. I'll drop it from this set and you can include it in your next one. Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avcodec/libopenh264enc.c
When using libx264 (GPL) encoder, sample aspect ratio gets stored on
both container and frame levels. For libopenh264 (LGPL), aspect ratio
on codec/frame level currently is ignored, which results in weird
display aspect ratio for non-square pixels on some players.
Proposed patch fixes that, if FFmpeg being build against libopenh264
1.7 or newer.
---
libavcodec/libopenh264enc.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 83c3f0ce20..6d4d9e6192 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -164,6 +164,32 @@ FF_ENABLE_DEPRECATION_WARNINGS
param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
param.sSpatialLayers[0].iMaxSpatialBitrate = param.iMaxBitrate;
+#if OPENH264_VER_AT_LEAST(1, 7)
+if(avctx->sample_aspect_ratio.num == 0 ||
avctx->sample_aspect_ratio.den == 0)
+param.sSpatialLayers[0].bAspectRatioPresent = false;
+else {
+param.sSpatialLayers[0].bAspectRatioPresent = true;
+if (!av_cmp_q(av_make_q( 1, 1),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_1x1;
+else if (!av_cmp_q(av_make_q(12, 11),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_12x11;
+else if (!av_cmp_q(av_make_q(10, 11),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_10x11;
+else if (!av_cmp_q(av_make_q(16, 11),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_16x11;
+else if (!av_cmp_q(av_make_q(40, 33),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_40x33;
+else if (!av_cmp_q(av_make_q(24, 11),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_24x11;
+else if (!av_cmp_q(av_make_q(20, 11),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_20x11;
+else if (!av_cmp_q(av_make_q(32, 11),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_32x11;
+else if (!av_cmp_q(av_make_q(80, 33),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_80x33;
+else if (!av_cmp_q(av_make_q(18, 11),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_18x11;
+else if (!av_cmp_q(av_make_q(15, 11),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_15x11;
+else if (!av_cmp_q(av_make_q(64, 33),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_64x33;
+else if (!av_cmp_q(av_make_q(160,99),
avctx->sample_aspect_ratio)) param.sSpatialLayers[0].eAspectRatio =
ASP_160x99;
+else {
+param.sSpatialLayers[0].eAspectRatio = ASP_EXT_SAR;
+param.sSpatialLayers[0].sAspectRatioExtWidth =
avctx->sample_aspect_ratio.num;
+param.sSpatialLayers[0].sAspectRatioExtHeight =
avctx->sample_aspect_ratio.den;
+}
+}
+#endif
+
if ((avctx->slices > 1) && (s->max_nal_size)) {
av_log(avctx, AV_LOG_ERROR,
"Invalid combination -slices %d and -max_nal_size %d.\n",
--
2.15.1.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/libopenh264enc.c
This patch is corrupted, also needs a more meaningful commit message. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"
On 10/11/18, Jerome Martinez wrote:
> On 11/10/2018 14:08, Paul B Mahol wrote:
>> On 10/11/18, Jerome Martinez wrote:
>>> Hi,
>>>
>>> Testing FFmpeg FFV1 encoder on big frames (more than 4K: 4300x3956), I
>>> have a warning for each frame encoded (so a lot of warnings!):
>>> [ffv1 @ 024a6bcfe880] Cannot allocate worst case packet size, the
>>> encoding could fail
>>>
>>> Checking avcodec/ffv1enc.c, it is due to the following lines:
>>> int64_t maxsize = AV_INPUT_BUFFER_MIN_SIZE
>>> + avctx->width*avctx->height*37LL*4;
>>> [...]
>>> if (maxsize > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE - 32) {
>>> av_log(avctx, AV_LOG_WARNING, "Cannot allocate worst case
>>> packet size, the encoding could fail\n");
>>> maxsize = INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE - 32;
>>> }
>>>
>>> The value of maxsize is 2517614784, more than INT_MAX, sure, but I don't
>>> understand:
>>> - why does FFmpeg need to allocate 148 times the size of a frame?
>>> - why is having a number > INT_MAX an issue? modern machines are 64-bit
>>> and have 8+ GB of RAM, and in practice I currently saw no encoding
>>> failure on thousands of frames.
>>>
>>> Additionally I didn't get why maxsize is reduced ("only" need of 12
>>> times the size of the frame) in case of FFV1 version > 3 (experimental
>>> right now):
>>> if (f->version > 3)
>>> maxsize = AV_INPUT_BUFFER_MIN_SIZE +
>>> avctx->width*avctx->height*3LL*4;
>>>
>>> maxsize is used for calling ff_alloc_packet2(), which accepts 64-bit
>>> numbers.
>>> if ((ret = ff_alloc_packet2(avctx, pkt, maxsize, 0)) < 0)
>>> return ret;
>>>
>>> Is it possible to reduce this "37x4" multiplier without risk and/or
>>> remove maxsize reduction in case of sizeof(size_t) == 8 and/or show the
>>> warning only once?
>>>
>>> Issue can be reproduced with:
>>> ./ffmpeg.exe -f lavfi -i testsrc2=size=4300x3956 -t 0.040 -pix_fmt
>>> rgba64 rgba64.dpx
>>> ./ffmpeg.exe -i rgba64.dpx -c:v ffv1 rgba64.mkv
>> You are not using latest version of FFv1.
>
>
> As far as I know, version 3 is the latest (stable) version of FFV1, and
> I use this one.
> version > 3 are experimental.
> I am not sure that advising to use an experimental version for "fixing"
> a warning is good.
>
> Additionally, in theory a 16kx16k content would still produce this
> warning with FFV1 (experimental) v4 encoding, even if there is 16
> Terabytes of RAM (more than enough for having the MAX_INT = 2 GiB raw
> frame in RAM), so I understand that the warning would still be there (in
> theory) with FFV1 (experimental) v4.
>
>
>> In latest version, encoder will not produce packets which are bigger than
>> input ones -- uncompressed raw. And instead if that happens it will encode
>> as raw video.
>>
>> Theoretically output packets for old versions of FFv1 could be several
>> times bigger than raw input frame.
>
>
> In this case, the ratio (148 times the size of input) is proportional to
> the input frame size, and the test is on a fixed value (MAX_INT).
> I get now the reason to reserve more than the size of the input frame.
> I don't get the relationship between your explanation and these hard
> coded values (148 times the size of input and MAX_INT limit).
>
> Why 148x (37x4) and not 147 or 149?
> Why a warning and maxsize forced to MAX_INT if maxsize > MAX_INT? Is it
> an internal constraint of FFmpeg which would be not able to store
> encoded frames bigger than MAX_INT?
>
> Can any of that be changed e.g. warning only once for avoiding "spam" of
> such warning which hides other warnings during encoding?
Real issue is in enforced limit of av_malloc size.
For answer to that question and others ask author who introduced such
limitation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/libopenh264enc.c
On Thu, Oct 11, 2018 at 16:45:02 +0200, Timo Rothenpieler wrote: > This patch is corrupted, also needs a more meaningful commit message. Valery previously sent the patch as an attachment, which looked okay. (Perhaps needed a better commit message nevertheless.) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: bump the intra stream discontinuity message to warning
On Wed, Oct 10, 2018 at 02:10:26AM +0300, Jan Ekström wrote: > As libavformat should at this point be handling general input > timestamp discontinuities for us - such as with MPEG-TS - the > amount of messages from this case should be small, and if it > does start spamming messages, that would be a sign that either > the input, or the discontinuity handling code itself is broken. libavformat handles the case where a timestamp wraps around that is goes beyond the maximum value. Thats not the only type of discontinuity. Is there some code i am missing or that i forgot about ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] swscale/x86/rgb2rgb : port shuffle2103 to external asm
> > the split should be > the removal of the code that stays removed > the porting of the remaining code > > I understand its easier to drop both and then add one but thats a ugly way > to split the patch. The patch porting the code should show both the code > thats removed as well as the added code. That makes it much clearer what it > does. > > New patch in attach Martin 0001-swscale-x86-rgb2rgb-remove-mmx-version-for-shuffle21.patch Description: Binary data 0002-swscale-x86-rgb2rgb-port-shuffle-2103-mmxext-to.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: bump the intra stream discontinuity message to warning
On Thu, 11 Oct 2018, Michael Niedermayer wrote: On Wed, Oct 10, 2018 at 02:10:26AM +0300, Jan Ekström wrote: As libavformat should at this point be handling general input timestamp discontinuities for us - such as with MPEG-TS - the amount of messages from this case should be small, and if it does start spamming messages, that would be a sign that either the input, or the discontinuity handling code itself is broken. libavformat handles the case where a timestamp wraps around that is goes beyond the maximum value. Thats not the only type of discontinuity. Is there some code i am missing or that i forgot about ? FWIW libavformat only handles wraparound _once_. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sat, Oct 6, 2018 at 10:37 AM Mark Thompson wrote:
> On 05/10/18 21:45, Alex Sukhanov wrote:
> > On Mon, Oct 1, 2018 at 11:01 AM wrote:
> >
> >> From: Alex Sukhanov
> >>
> >> ---
> >> libavformat/ivfenc.c | 50 +---
> >> 1 file changed, 38 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> >> index 66441a2a43..6410828533 100644
> >> --- a/libavformat/ivfenc.c
> >> +++ b/libavformat/ivfenc.c
> >> @@ -36,19 +36,29 @@ static int ivf_write_header(AVFormatContext *s)
> >> return AVERROR(EINVAL);
> >> }
> >> par = s->streams[0]->codecpar;
> >> -if (par->codec_type != AVMEDIA_TYPE_VIDEO ||
> >> -!(par->codec_id == AV_CODEC_ID_AV1 ||
> >> - par->codec_id == AV_CODEC_ID_VP8 ||
> >> - par->codec_id == AV_CODEC_ID_VP9)) {
> >> -av_log(s, AV_LOG_ERROR, "Currently only VP8, VP9 and AV1 are
> >> supported!\n");
> >> -return AVERROR(EINVAL);
> >> -}
> >> avio_write(pb, "DKIF", 4);
> >> avio_wl16(pb, 0); // version
> >> avio_wl16(pb, 32); // header length
> >> -avio_wl32(pb,
> >> - par->codec_id == AV_CODEC_ID_VP9 ? AV_RL32("VP90") :
> >> - par->codec_id == AV_CODEC_ID_VP8 ? AV_RL32("VP80") :
> >> AV_RL32("AV01"));
> >> +switch (par->codec_id) {
> >> + case AV_CODEC_ID_AV1:
> >> +avio_wl32(pb, AV_RL32("AV01"));
> >> +break;
> >> + case AV_CODEC_ID_H264:
> >> +avio_wl32(pb, AV_RL32("H264"));
> >> +break;
> >> + case AV_CODEC_ID_HEVC:
> >> +avio_wl32(pb, AV_RL32("HEVC"));
> >> +break;
> >> + case AV_CODEC_ID_VP8:
> >> +avio_wl32(pb, AV_RL32("VP80"));
> >> +break;
> >> + case AV_CODEC_ID_VP9:
> >> +avio_wl32(pb, AV_RL32("VP90"));
> >> +break;
> >> + default:
> >> +av_log(s, AV_LOG_ERROR, "Currently only AV1, H264, HEVC, VP8
> and
> >> VP9 and AV1 are supported!\n");
> >> +return AVERROR(EINVAL);
> >> +}
> >> avio_wl16(pb, par->width);
> >> avio_wl16(pb, par->height);
> >> avio_wl32(pb, s->streams[0]->time_base.den);
> >> @@ -95,16 +105,32 @@ static int ivf_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_VP9)
> >> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> >> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> >> + (AV_RB24(pkt->data) != 0x01 ||
> >> + (st->codecpar->extradata_size > 0 &&
> >> + st->codecpar->extradata[0] == 1)))
> >> +ret = ff_stream_add_bitstream_filter(st,
> "h264_mp4toannexb",
> >> NULL);
> >> +} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> >> +if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
> >> + (AV_RB24(pkt->data) != 0x01 ||
> >> + (st->codecpar->extradata_size > 0 &&
> >> + st->codecpar->extradata[0] == 1)))
> >> +ret = ff_stream_add_bitstream_filter(st,
> "hevc_mp4toannexb",
> >> NULL);
> >> +} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
> >> ret = ff_stream_add_bitstream_filter(st, "vp9_superframe",
> NULL);
> >> +}
> >>
> >> return ret;
> >> }
> >>
> >> static const AVCodecTag codec_ivf_tags[] = {
> >> +{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
> >> +{ AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') },
> >> +{ AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') },
> >> { AV_CODEC_ID_VP8, MKTAG('V', 'P', '8', '0') },
> >> { AV_CODEC_ID_VP9, MKTAG('V', 'P', '9', '0') },
> >> -{ AV_CODEC_ID_AV1, MKTAG('A', 'V', '0', '1') },
> >> +
> >> { AV_CODEC_ID_NONE, 0 }
> >> };
> >>
> >> --
> >> 2.19.0.605.g01d371f741-goog
> >>
> >>
> > Can you please take a look on this patch?
>
> Can you answer the question posed in <
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2018-September/234655.html>
> about the reasoning for this patch?
>
> In particular, it might be helpful if you could point out any
> tools/standards which support (or are in future intending to support) this
> format - in my experience pretty much everything dealing with H.26[45] raw
> streams uses the Annex B format.
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi Mark,
at Google we have some old service which is still running and it works only
with the IVF container. It would be great if ffmpeg could generate such
videos so we could give them to the service then. Given that ffmpeg IVF
demuxer already supports reading such files, I think it's reasonable to
make IVF muxer be abl
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: keep CORRUPT and TRUSTED packet flags when parsing packets
On Thu, 11 Oct 2018, Michael Niedermayer wrote:
On Wed, Oct 10, 2018 at 01:32:14AM +0200, Marton Balint wrote:
An FF_ macro got defined in avcodec.h to store the flags which need to be
propagated when parsers split packets so this won't be forgotten when a new
packet flag is introduced.
(I wonder if DISPOSABLE also fits here, or maybe some special handling is
needed like it is done for the keyframe flag?)
---
libavcodec/avcodec.h | 9 -
libavcodec/version.h | 2 +-
libavformat/utils.c | 2 +-
tests/ref/fate/flv-demux | 2 +-
tests/ref/fate/iv8-demux | 2 +-
tests/ref/fate/segment-mp4-to-ts | 6 +++---
tests/ref/fate/ts-demux | 2 +-
7 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 705a3ce4f3..9a3f9b6226 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1493,7 +1493,14 @@ typedef struct AVPacket {
* be discarded by the decoder. I.e. Non-reference frames.
*/
#define AV_PKT_FLAG_DISPOSABLE 0x0010
-
+/**
+ * Packet flags which must always be kept when parsers split packets
+ */
+#define FF_PKT_FLAGS_KEEP_WHEN_PARSING (\
+AV_PKT_FLAG_CORRUPT | \
+AV_PKT_FLAG_DISCARD | \
+AV_PKT_FLAG_TRUSTED | \
+0)
enum AVSideDataParamChangeFlags {
AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 97d134851f..79c5dc6773 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 32
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavformat/utils.c b/libavformat/utils.c
index a8ac90213e..351bd88fa5 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1511,7 +1511,7 @@ static int parse_packet(AVFormatContext *s, AVPacket
*pkt, int stream_index)
out_pkt.pts = st->parser->pts;
out_pkt.dts = st->parser->dts;
out_pkt.pos = st->parser->pos;
-out_pkt.flags |= pkt->flags & AV_PKT_FLAG_DISCARD;
+out_pkt.flags |= pkt->flags & FF_PKT_FLAGS_KEEP_WHEN_PARSING;
I think this is wrong
this looks like the packet flags are not passed through the parsers, so they
would
not neccessarily be attached to the correct packets, there could be a delay
from a buffer ...
True, this solution is not perfect, but probably better than what we have
now, which is losing the corrupt flag entirely.
more so, these flags cannot be handled identically
for example if there is output packet formed from concatenating a trusted and
untrusted input packet the output cannot be trusted because it is not just
trusted data
OK, TRUSTED should be removed from the flags which are propagated.
compared to corrupt, if there is output packet formed from concatenating a
corrupt and non-corrupt input packet the output still is corrupt
It gets further complicated if only part of a AV_PKT_FLAG_CORRUPT input is
used. You cant mark the output as corrupt in this case because as documented
AV_PKT_FLAG_CORRUPT means the packet IS corrupt but a subpart of it may be
corrupt or may be undamaged.
IMHO there is no harm in setting corrupt flag if part of the (or the
whole) packet comes from a corrupt source. Suspicion is enough. Losing the
flag is a much bigger issue.
A finer granularity of corruption likelyness would be needed here.
(checksums matching, probably ok - no checksums, possibly corrupt,
certainly some corrupt, certain significant corruption)
Independant of this there could be information about packet truncation.
a packet content could be known to be correct but possibly incomplete
All these cases differ in how they would have to be passed on when packets
are merged / split
Seems a bit of overdesign to me, a typical user app either bails out on
error, or try decoding no matter how corrupted the input is, so not much
point in signalling stuff between. That is also why I think that it is OK
if we define AV_PKT_FLAG_CORRUPT as _suspected_ corruption, because it
does not affect either use case.
Anyway, I still think setting the flag as it is done for
AV_PKT_FLAG_DISCARD is better than ignoring it. Do you see a way to
implement propagating the flag in a more sophisticated way with reasonable
amount of work? On first look, the parser.c code seems pretty scary.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: bump the intra stream discontinuity message to warning
On Thu, Oct 11, 2018 at 10:50 PM Marton Balint wrote: > On Thu, 11 Oct 2018, Michael Niedermayer wrote: > > > On Wed, Oct 10, 2018 at 02:10:26AM +0300, Jan Ekström wrote: > >> As libavformat should at this point be handling general input > >> timestamp discontinuities for us - such as with MPEG-TS - the > >> amount of messages from this case should be small, and if it > >> does start spamming messages, that would be a sign that either > >> the input, or the discontinuity handling code itself is broken. > > > > libavformat handles the case where a timestamp wraps around > > that is goes beyond the maximum value. Thats not the only > > type of discontinuity. Is there some code i am missing or that > > i forgot about ? > > FWIW libavformat only handles wraparound _once_. > > Regards, > Marton Looking at update_wrap_reference and where it gets called from et al, it would seem like it should take care of multiple as it keeps updating the reference and applying wrap-around as required? Generally the one in ffmpeg.c seemed to only get hit when there was some sort of jump in the timestamps in addition to the wrap-arounds - or if the lavf wrap-around logic decided to go follow a teletext track with utterly broken timestamps as the reference. As for the comment, yes - lavf's wrap-around logic doesn't try to poke all sorts of discontinuities, but in my opinion the fact that "casual" discontinuities should no longer happen at this stage definitely makes logging that a discontinuity happened and that we tried to apply a new offset to all streams worth mentioning on a more normal verbosity level than "debug". Currently you will never, ever hear anything about this logic activating unless your verbosity level is ridiculously high. And as a general case, if the logic is working correctly this code should only fire once per discontinuity, not in an eternal loop. Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Thu, Oct 11, 2018 at 10:58 PM Alex Sukhanov wrote: > > Hi Mark, > > at Google we have some old service which is still running and it works only > with the IVF container. It would be great if ffmpeg could generate such > videos so we could give them to the service then. Given that ffmpeg IVF > demuxer already supports reading such files, I think it's reasonable to > make IVF muxer be able to generate them. > Hope it answers the question. > > Thank you Given the amount of code is not large I'm not against having it in, but if it's not something that ever was meant to go into the public I'd probably disable creation of such files unless you enable a less standards-compliant strictness mode. Or if others are against it, I'm OK with this thing not being included as it clearly is to enable some GOOG internal workflows only. Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: bump the intra stream discontinuity message to warning
On Thu, 11 Oct 2018, Jan Ekström wrote: On Thu, Oct 11, 2018 at 10:50 PM Marton Balint wrote: On Thu, 11 Oct 2018, Michael Niedermayer wrote: > On Wed, Oct 10, 2018 at 02:10:26AM +0300, Jan Ekström wrote: >> As libavformat should at this point be handling general input >> timestamp discontinuities for us - such as with MPEG-TS - the >> amount of messages from this case should be small, and if it >> does start spamming messages, that would be a sign that either >> the input, or the discontinuity handling code itself is broken. > > libavformat handles the case where a timestamp wraps around > that is goes beyond the maximum value. Thats not the only > type of discontinuity. Is there some code i am missing or that > i forgot about ? FWIW libavformat only handles wraparound _once_. Regards, Marton Looking at update_wrap_reference and where it gets called from et al, it would seem like it should take care of multiple as it keeps updating the reference and applying wrap-around as required? Timestamps are updated in wrap_timestamp and that only adds or substracts the wrap amount once, so it can't be right. Generally the one in ffmpeg.c seemed to only get hit when there was some sort of jump in the timestamps in addition to the wrap-arounds - or if the lavf wrap-around logic decided to go follow a teletext track with utterly broken timestamps as the reference. As for the comment, yes - lavf's wrap-around logic doesn't try to poke all sorts of discontinuities, but in my opinion the fact that "casual" discontinuities should no longer happen at this stage definitely makes logging that a discontinuity happened and that we tried to apply a new offset to all streams worth mentioning on a more normal verbosity level than "debug". Currently you will never, ever hear anything about this logic activating unless your verbosity level is ridiculously high. And as a general case, if the logic is working correctly this code should only fire once per discontinuity, not in an eternal loop. Agreed. In fact there is another similar message with DEBUG level, that should be bumped as well at least to INFO. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 11/10/2018 22:21, Jan Ekström wrote: > I'd probably disable creation of such files unless you enable a less > standards-compliant strictness mode. Is there even an IVF spec, though? If not, there's not really such a thing as "standards-compliant". - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Thu, Oct 11, 2018 at 2:47 PM Derek Buitenhuis wrote: > On 11/10/2018 22:21, Jan Ekström wrote: > > I'd probably disable creation of such files unless you enable a less > > standards-compliant strictness mode. > > Is there even an IVF spec, though? If not, there's not really such a > thing as "standards-compliant". > > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel The only "spec" I'm aware of: https://wiki.multimedia.cx/index.php/IVF ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] swscale/x86/rgb2rgb : port shuffle2103 to external asm
On Thu, Oct 11, 2018 at 09:37:52PM +0200, Martin Vignali wrote: > > > > the split should be > > the removal of the code that stays removed > > the porting of the remaining code > > > > I understand its easier to drop both and then add one but thats a ugly way > > to split the patch. The patch porting the code should show both the code > > thats removed as well as the added code. That makes it much clearer what it > > does. > > > > > New patch in attach thats eliminates my concern thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/aacdec_template: Allow duplicated elements
On Thu, Oct 11, 2018 at 12:56:30PM +0200, Paul B Mahol wrote:
> On 10/7/18, Michael Niedermayer wrote:
> > Such streams are invalid according to
> > 4.5.2.1 Top level payloads for the audio object types AAC main, AAC SSR, AAC
> > LC and AAC LTP
> > 4.5.2.1.1 Definitions
> > ...cIn the raw_data_block(), several instances of the
> > same syntactic element may occur, but must have a different 4 bit
> > element_instance_tag, except for data_stream_element()'s and
> > fill_element()'s.
> >
> > Fixes: Ticket7477
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/aacdec_template.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> > index b60b31a92c..dce6035d67 100644
> > --- a/libavcodec/aacdec_template.c
> > +++ b/libavcodec/aacdec_template.c
> > @@ -3161,12 +3161,15 @@ static int aac_decode_frame_int(AVCodecContext
> > *avctx, void *data,
> >
> > if (elem_type < TYPE_DSE) {
> > if (che_presence[elem_type][elem_id]) {
> > -av_log(ac->avctx, AV_LOG_ERROR, "channel element %d.%d
> > duplicate\n",
> > +int error = che_presence[elem_type][elem_id] > 1;
> > +av_log(ac->avctx, error ? AV_LOG_ERROR : AV_LOG_DEBUG,
> > "channel element %d.%d duplicate\n",
> > elem_type, elem_id);
> > -err = AVERROR_INVALIDDATA;
> > -goto fail;
> > +if (error) {
> > +err = AVERROR_INVALIDDATA;
> > +goto fail;
> > +}
> > }
> > -che_presence[elem_type][elem_id] = 1;
> > +che_presence[elem_type][elem_id]++;
> >
> > if (!(che=get_che(ac, elem_type, elem_id))) {
> > av_log(ac->avctx, AV_LOG_ERROR, "channel element %d.%d is
> > not allocated\n",
> > --
> > 2.19.0
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> probably ok
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ffv1dec_template: Check for the end of input after 1024 pixels
On Tue, Oct 09, 2018 at 05:14:22AM +0200, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 10385/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5689206987292672 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/ffv1dec_template.c | 5 + > 1 file changed, 5 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: keep CORRUPT and TRUSTED packet flags when parsing packets
On Thu, Oct 11, 2018 at 10:39:54PM +0200, Marton Balint wrote:
>
>
> On Thu, 11 Oct 2018, Michael Niedermayer wrote:
>
> >On Wed, Oct 10, 2018 at 01:32:14AM +0200, Marton Balint wrote:
> >>An FF_ macro got defined in avcodec.h to store the flags which need to be
> >>propagated when parsers split packets so this won't be forgotten when a new
> >>packet flag is introduced.
> >>
> >>(I wonder if DISPOSABLE also fits here, or maybe some special handling is
> >>needed like it is done for the keyframe flag?)
> >>---
> >> libavcodec/avcodec.h | 9 -
> >> libavcodec/version.h | 2 +-
> >> libavformat/utils.c | 2 +-
> >> tests/ref/fate/flv-demux | 2 +-
> >> tests/ref/fate/iv8-demux | 2 +-
> >> tests/ref/fate/segment-mp4-to-ts | 6 +++---
> >> tests/ref/fate/ts-demux | 2 +-
> >> 7 files changed, 16 insertions(+), 9 deletions(-)
> >>
> >>diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> >>index 705a3ce4f3..9a3f9b6226 100644
> >>--- a/libavcodec/avcodec.h
> >>+++ b/libavcodec/avcodec.h
> >>@@ -1493,7 +1493,14 @@ typedef struct AVPacket {
> >> * be discarded by the decoder. I.e. Non-reference frames.
> >> */
> >> #define AV_PKT_FLAG_DISPOSABLE 0x0010
> >>-
> >>+/**
> >>+ * Packet flags which must always be kept when parsers split packets
> >>+ */
> >>+#define FF_PKT_FLAGS_KEEP_WHEN_PARSING (\
> >>+AV_PKT_FLAG_CORRUPT | \
> >>+AV_PKT_FLAG_DISCARD | \
> >>+AV_PKT_FLAG_TRUSTED | \
> >>+0)
> >>
> >> enum AVSideDataParamChangeFlags {
> >> AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
> >>diff --git a/libavcodec/version.h b/libavcodec/version.h
> >>index 97d134851f..79c5dc6773 100644
> >>--- a/libavcodec/version.h
> >>+++ b/libavcodec/version.h
> >>@@ -29,7 +29,7 @@
> >>
> >> #define LIBAVCODEC_VERSION_MAJOR 58
> >> #define LIBAVCODEC_VERSION_MINOR 32
> >>-#define LIBAVCODEC_VERSION_MICRO 100
> >>+#define LIBAVCODEC_VERSION_MICRO 101
> >>
> >> #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> >>LIBAVCODEC_VERSION_MINOR, \
> >>diff --git a/libavformat/utils.c b/libavformat/utils.c
> >>index a8ac90213e..351bd88fa5 100644
> >>--- a/libavformat/utils.c
> >>+++ b/libavformat/utils.c
> >>@@ -1511,7 +1511,7 @@ static int parse_packet(AVFormatContext *s, AVPacket
> >>*pkt, int stream_index)
> >> out_pkt.pts = st->parser->pts;
> >> out_pkt.dts = st->parser->dts;
> >> out_pkt.pos = st->parser->pos;
> >>-out_pkt.flags |= pkt->flags & AV_PKT_FLAG_DISCARD;
> >>+out_pkt.flags |= pkt->flags & FF_PKT_FLAGS_KEEP_WHEN_PARSING;
> >
> >I think this is wrong
> >this looks like the packet flags are not passed through the parsers, so they
> >would
> >not neccessarily be attached to the correct packets, there could be a delay
> >from a buffer ...
>
> True, this solution is not perfect, but probably better than what we have
> now, which is losing the corrupt flag entirely.
>
> >
> >more so, these flags cannot be handled identically
> >for example if there is output packet formed from concatenating a trusted and
> >untrusted input packet the output cannot be trusted because it is not just
> >trusted data
>
> OK, TRUSTED should be removed from the flags which are propagated.
>
> >
> >compared to corrupt, if there is output packet formed from concatenating a
> >corrupt and non-corrupt input packet the output still is corrupt
> >
> >It gets further complicated if only part of a AV_PKT_FLAG_CORRUPT input is
> >used. You cant mark the output as corrupt in this case because as documented
> >AV_PKT_FLAG_CORRUPT means the packet IS corrupt but a subpart of it may be
> >corrupt or may be undamaged.
>
> IMHO there is no harm in setting corrupt flag if part of the (or the whole)
> packet comes from a corrupt source. Suspicion is enough. Losing the flag is
> a much bigger issue.
ATM the documentation says "The packet content is corrupted"
If you want to set the flag when this is not true then the documentation
would need to be changed. Otherwise the code would violate the API
and the change of the documentation strictly speaking breaks API
and needs to be documented in APIChanges.
Yes iam quite aware that is taking things very strict and litteral here
but i think thats what we should aim for with APIs. The documentation
should be strictly correct or should make it clear when/where it is
not.
>
> >A finer granularity of corruption likelyness would be needed here.
> >(checksums matching, probably ok - no checksums, possibly corrupt,
> >certainly some corrupt, certain significant corruption)
> >Independant of this there could be information about packet truncation.
> >a packet content could be known to be correct but possibly incomplete
> >All these cases differ in how they would have to be passed on when packets
> >are merged / split
>
> Seems a bit of overdesign to me, a typical user app eith
Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: bump the intra stream discontinuity message to warning
On Thu, Oct 11, 2018 at 09:50:22PM +0200, Marton Balint wrote: > > > On Thu, 11 Oct 2018, Michael Niedermayer wrote: > > >On Wed, Oct 10, 2018 at 02:10:26AM +0300, Jan Ekström wrote: > >>As libavformat should at this point be handling general input > >>timestamp discontinuities for us - such as with MPEG-TS - the > >>amount of messages from this case should be small, and if it > >>does start spamming messages, that would be a sign that either > >>the input, or the discontinuity handling code itself is broken. > > > >libavformat handles the case where a timestamp wraps around > >that is goes beyond the maximum value. Thats not the only > >type of discontinuity. Is there some code i am missing or that > >i forgot about ? > > FWIW libavformat only handles wraparound _once_. I think its more restrictive than this. If for example ths duration of a video is more then the full timestamp range (with just 1 wraparound) this will likely not work completely [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On 11/10/2018 23:39, Alex Sukhanov wrote: > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF Yeah, not really a spec. I have no strong objections, I guess. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/libaomenc.c: Added code for computing PSNR/SSIM for libaom encoder.Updated the patch to read the AV_PICTURE_TYPE_I flag for AOM.
James,
Is there anything to be done for this patch? Can you please approve this
change and apply the patch to ffmpeg head.
On Fri, Sep 28, 2018 at 3:09 PM Sam John wrote:
> ---
> libavcodec/libaomenc.c | 60 +-
> 1 file changed, 54 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 6a79d9b873..481338406c 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -50,6 +50,9 @@ struct FrameListData {
> unsigned long duration; /**< duration to show frame
>(in timebase units) */
> uint32_t flags; /**< flags for this frame */
> +uint64_t sse[4];
> +int have_sse;/**< true if we have pending sse[] */
> +uint64_t frame_number;
> struct FrameListData *next;
> };
>
> @@ -68,6 +71,9 @@ typedef struct AOMEncoderContext {
> int static_thresh;
> int drop_threshold;
> int noise_sensitivity;
> +uint64_t sse[4];
> +int have_sse; /**< true if we have pending sse[] */
> +uint64_t frame_number;
> } AOMContext;
>
> static const char *const ctlidstr[] = {
> @@ -289,7 +295,8 @@ static av_cold int aom_init(AVCodecContext *avctx,
> {
> AOMContext *ctx = avctx->priv_data;
> struct aom_codec_enc_cfg enccfg = { 0 };
> -aom_codec_flags_t flags = 0;
> +aom_codec_flags_t flags =
> +(avctx->flags & AV_CODEC_FLAG_PSNR) ? AOM_CODEC_USE_PSNR : 0;
> AVCPBProperties *cpb_props;
> int res;
> aom_img_fmt_t img_fmt;
> @@ -499,13 +506,23 @@ static av_cold int aom_init(AVCodecContext *avctx,
> }
>
> static inline void cx_pktcpy(struct FrameListData *dst,
> - const struct aom_codec_cx_pkt *src)
> + const struct aom_codec_cx_pkt *src,
> + AOMContext *ctx)
> {
> dst->pts = src->data.frame.pts;
> dst->duration = src->data.frame.duration;
> dst->flags= src->data.frame.flags;
> dst->sz = src->data.frame.sz;
> dst->buf = src->data.frame.buf;
> +dst->have_sse = 0;
> +dst->frame_number = ++ctx->frame_number;
> +dst->have_sse = ctx->have_sse;
> +if (ctx->have_sse) {
> +/* associate last-seen SSE to the frame. */
> +/* Transfers ownership from ctx to dst. */
> +memcpy(dst->sse, ctx->sse, sizeof(dst->sse));
> +ctx->have_sse = 0;
> +}
> }
>
> /**
> @@ -519,6 +536,7 @@ static int storeframe(AVCodecContext *avctx, struct
> FrameListData *cx_frame,
>AVPacket *pkt)
> {
> AOMContext *ctx = avctx->priv_data;
> +int pict_type;
> int ret = ff_alloc_packet2(avctx, pkt, cx_frame->sz, 0);
> if (ret < 0) {
> av_log(avctx, AV_LOG_ERROR,
> @@ -528,8 +546,29 @@ static int storeframe(AVCodecContext *avctx, struct
> FrameListData *cx_frame,
> memcpy(pkt->data, cx_frame->buf, pkt->size);
> pkt->pts = pkt->dts = cx_frame->pts;
>
> -if (!!(cx_frame->flags & AOM_FRAME_IS_KEY))
> +if (!!(cx_frame->flags & AOM_FRAME_IS_KEY)) {
> +pict_type = AV_PICTURE_TYPE_I;
> pkt->flags |= AV_PKT_FLAG_KEY;
> +} else {
> +#ifdef AOM_FRAME_IS_INTRAONLY
> +if (cx_frame->flags & AOM_FRAME_IS_INTRAONLY)
> +pict_type = AV_PICTURE_TYPE_I;
> +else
> +#else
> +pict_type = AV_PICTURE_TYPE_P;
> +#endif
> +}
> +
> +ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
> + cx_frame->have_sse ? 3 : 0, pict_type);
> +
> +if (cx_frame->have_sse) {
> +int i;
> +for (i = 0; i < 3; ++i) {
> +avctx->error[i] += cx_frame->sse[i + 1];
> +}
> +cx_frame->have_sse = 0;
> +}
>
> if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
> ret = av_bsf_send_packet(ctx->bsf, pkt);
> @@ -585,7 +624,7 @@ static int queue_frames(AVCodecContext *avctx,
> AVPacket *pkt_out)
> /* avoid storing the frame when the list is empty and we
> haven't yet
> * provided a frame for output */
> av_assert0(!ctx->coded_frame_list);
> -cx_pktcpy(&cx_frame, pkt);
> +cx_pktcpy(&cx_frame, pkt, ctx);
> size = storeframe(avctx, &cx_frame, pkt_out);
> if (size < 0)
> return size;
> @@ -598,7 +637,7 @@ static int queue_frames(AVCodecContext *avctx,
> AVPacket *pkt_out)
> "Frame queue element alloc failed\n");
> return AVERROR(ENOMEM);
> }
> -cx_pktcpy(cx_frame, pkt);
> +cx_pktcpy(cx_frame, pkt, ctx);
> cx_frame->buf = av_malloc(cx_frame->sz);
>
> if (!cx_frame->buf) {
> @@ -628,7 +667,16 @@ static int queue_frames(AVCodecContext *avctx,
> AVPacket *pkt_out)
> st
Re: [FFmpeg-devel] [PATCH] libavcodec/libaomenc.c: Added code for computing PSNR/SSIM for libaom encoder.Updated the patch to read the AV_PICTURE_TYPE_I flag for AOM.
On 10/11/2018 9:49 PM, Sam John wrote: > James, > > Is there anything to be done for this patch? Can you please approve this > change and apply the patch to ffmpeg head. Sorry for the delay. Pushed it after changing it so psnr is only exported when every frame can be properly tagged as intra or inter. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/utils: Fix long overflow in compute_pkt_fields()
From: Thomas Guilbert If ever we have a negative last_IP_duration, we can end up with a long overflow. This makes sure we use pkt->duration instead of last_IP_duration if last_IP_duration is negative. Fixes: compute_pkt_usan --- libavformat/utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index fa3699daef..2c965a7fb2 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -1352,7 +1352,7 @@ static void compute_pkt_fields(AVFormatContext *s, AVStream *st, /* This is tricky: the dts must be incremented by the duration * of the frame we are displaying, i.e. the last I- or P-frame. */ -if (st->last_IP_duration == 0) +if (st->last_IP_duration <= 0) st->last_IP_duration = pkt->duration; if (pkt->dts != AV_NOPTS_VALUE) st->cur_dts = pkt->dts + st->last_IP_duration; -- 2.19.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/utils: Fix integer overflow in discontinuity check
Fixes: signed integer overflow: 7738135736989908991 - -7954308516317364223
cannot be represented in type 'long'
Fixes: find_stream_info_usan
Reported-by: Thomas Guilbert
Signed-off-by: Michael Niedermayer
---
libavformat/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index a8ac90213e..fa3699daef 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3818,7 +3818,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
* sequence, we treat it as a discontinuity. */
if (st->info->fps_last_dts != AV_NOPTS_VALUE &&
st->info->fps_last_dts_idx > st->info->fps_first_dts_idx &&
-(pkt->dts - st->info->fps_last_dts) / 1000 >
+(pkt->dts - (uint64_t)st->info->fps_last_dts) / 1000 >
(st->info->fps_last_dts -
(uint64_t)st->info->fps_first_dts) /
(st->info->fps_last_dts_idx - st->info->fps_first_dts_idx)) {
av_log(ic, AV_LOG_WARNING,
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/vc1test: fix vc1test can't probe some RCV file.
case 1:
use the hexdump -C SMM0005.rcv get:
size skip (size - 4)
||
VV
18 00 00 c5 05 00 00 00 4d f1 0a 11 00 e0 01 00
0010 00 d0 02 00 00 0c 00 00 00 88 13 00 00 c0 65 52
^
|
size + 16
case 2:
same the command for SMM0015.rcv get:
size
|
V
19 00 00 c5 04 00 00 00 41 f3 80 01 40 02 00 00
0010 d0 02 00 00 0c 00 00 00 00 00 00 10 00 00 00 00
^
|
size + 16
There are different the RCV file format for VC-1, vc1test
just handle the case 2 now, this fix will support the case 1.
(Both of test clips come from: RP 228:2008 - SMPTE
Recommended Practice - VC-1 Decoder and Bitstream Conformance).
Signed-off-by: Jun Zhao
Signed-off-by: Yan, FengX
---
libavformat/vc1test.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
index a801f4b..38eb1a4 100644
--- a/libavformat/vc1test.c
+++ b/libavformat/vc1test.c
@@ -34,9 +34,13 @@
static int vc1t_probe(AVProbeData *p)
{
+int size;
+
if (p->buf_size < 24)
return 0;
-if (p->buf[3] != 0xC5 || AV_RL32(&p->buf[4]) != 4 || AV_RL32(&p->buf[20])
!= 0xC)
+
+size = AV_RL32(&p->buf[4]);
+if (p->buf[3] != 0xC5 || AV_RL32(&p->buf[size+16]) != 0xC)
return 0;
return AVPROBE_SCORE_EXTENSION;
@@ -48,10 +52,12 @@ static int vc1t_read_header(AVFormatContext *s)
AVStream *st;
int frames;
uint32_t fps;
+int size;
frames = avio_rl24(pb);
-if(avio_r8(pb) != 0xC5 || avio_rl32(pb) != 4)
+if (avio_r8(pb) != 0xC5)
return AVERROR_INVALIDDATA;
+size = avio_rl32(pb);
/* init video codec */
st = avformat_new_stream(s, NULL);
@@ -63,6 +69,8 @@ static int vc1t_read_header(AVFormatContext *s)
if (ff_get_extradata(s, st->codecpar, pb, VC1_EXTRADATA_SIZE) < 0)
return AVERROR(ENOMEM);
+
+avio_skip(pb, size - 4);
st->codecpar->height = avio_rl32(pb);
st->codecpar->width = avio_rl32(pb);
if(avio_rl32(pb) != 0xC)
@@ -114,5 +122,6 @@ AVInputFormat ff_vc1t_demuxer = {
.read_probe = vc1t_probe,
.read_header= vc1t_read_header,
.read_packet= vc1t_read_packet,
+ .extensions= "rcv",
.flags = AVFMT_GENERIC_INDEX,
};
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] avcodec/avpacket: fix whitespace
From: Aman Gupta
Signed-off-by: Aman Gupta
---
libavcodec/avpacket.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 002fa0f513..e160ad3033 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -580,10 +580,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
dst->side_data= NULL;
dst->side_data_elems = 0;
for (i = 0; i < src->side_data_elems; i++) {
- enum AVPacketSideDataType type = src->side_data[i].type;
- int size = src->side_data[i].size;
- uint8_t *src_data = src->side_data[i].data;
- uint8_t *dst_data = av_packet_new_side_data(dst, type, size);
+enum AVPacketSideDataType type = src->side_data[i].type;
+int size = src->side_data[i].size;
+uint8_t *src_data = src->side_data[i].data;
+uint8_t *dst_data = av_packet_new_side_data(dst, type, size);
if (!dst_data) {
av_packet_free_side_data(dst);
--
2.15.2 (Apple Git-101.1)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/5] avcodec/cbs: fix crash in sei_pic_timestamp
From: Aman Gupta
Signed-off-by: Aman Gupta
---
libavcodec/cbs_h264_syntax_template.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/cbs_h264_syntax_template.c
b/libavcodec/cbs_h264_syntax_template.c
index 32e6acd68e..106da0630e 100644
--- a/libavcodec/cbs_h264_syntax_template.c
+++ b/libavcodec/cbs_h264_syntax_template.c
@@ -584,6 +584,12 @@ static int FUNC(sei_pic_timestamp)(CodedBitstreamContext
*ctx, RWContext *rw,
}
sps = h264->active_sps;
+if (!sps) {
+av_log(ctx->log_ctx, AV_LOG_ERROR,
+ "No active SPS for pic_timestamp.\n");
+return AVERROR_INVALIDDATA;
+}
+
if (sps->vui.nal_hrd_parameters_present_flag)
time_offset_length = sps->vui.nal_hrd_parameters.time_offset_length;
else if (sps->vui.vcl_hrd_parameters_present_flag)
--
2.15.2 (Apple Git-101.1)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] avcodec/cbs: ensure user_data is padded for GBC parsing
From: Aman Gupta
Fixes crash noticed in the cbs_metadata patchset.
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60926c89 at
pc 0x00010725d37b bp 0x7ffeea04e750 sp 0x7ffeea04e748
READ of size 4 at 0x60926c89 thread T0
#0 0x10725d37a in ff_cbs_read_unsigned get_bits.h:274
#1 0x1072d2767 in ff_cbs_read_a53_user_data cbs_misc_syntax_template.c:119
#2 0x1078251a7 in h264_metadata_filter h264_metadata_bsf.c:595
#3 0x105c1321d in output_packet ffmpeg.c:853
0x60926c89 is located 1 bytes to the right of 8-byte region
[0x60926c80,0x60926c88)
allocated by thread T0 here:
#0 0x10aef08d7 in wrap_posix_memalign
(libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x578d7)
#1 0x10aca95e6 in av_malloc mem.c:87
#2 0x10ac545fe in av_buffer_allocz buffer.c:72
#3 0x107263b27 in cbs_h264_read_nal_unit cbs_h264_syntax_template.c:722
#4 0x10725b688 in cbs_read_fragment_content cbs.c:155
Signed-off-by: Aman Gupta
---
libavcodec/cbs_h264_syntax_template.c | 2 +-
libavcodec/cbs_mpeg2_syntax_template.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbs_h264_syntax_template.c
b/libavcodec/cbs_h264_syntax_template.c
index 106da0630e..1c8d7d5eae 100644
--- a/libavcodec/cbs_h264_syntax_template.c
+++ b/libavcodec/cbs_h264_syntax_template.c
@@ -725,7 +725,7 @@ static int
FUNC(sei_user_data_registered)(CodedBitstreamContext *ctx, RWContext
*payload_size = i + current->data_length;
#endif
-allocate(current->data, current->data_length);
+allocate(current->data, current->data_length +
AV_INPUT_BUFFER_PADDING_SIZE);
for (j = 0; j < current->data_length; j++)
xu(8, itu_t_t35_payload_byte[i], current->data[j], 0x00, 0xff, 1, i +
j);
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c
b/libavcodec/cbs_mpeg2_syntax_template.c
index 8b5d35437e..88cf453b17 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -71,7 +71,7 @@ static int FUNC(user_data)(CodedBitstreamContext *ctx,
RWContext *rw,
av_assert0(k % 8 == 0);
current->user_data_length = k /= 8;
if (k > 0) {
-current->user_data_ref = av_buffer_alloc(k);
+current->user_data_ref = av_buffer_allocz(k +
AV_INPUT_BUFFER_PADDING_SIZE);
if (!current->user_data_ref)
return AVERROR(ENOMEM);
current->user_data = current->user_data_ref->data;
--
2.15.2 (Apple Git-101.1)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] avcodec/cbs_h2645: fix crash due to assert failure on empty nalu
From: Aman Gupta Signed-off-by: Aman Gupta --- libavcodec/cbs_h2645.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c index ab33cdb69b..13e4c1561c 100644 --- a/libavcodec/cbs_h2645.c +++ b/libavcodec/cbs_h2645.c @@ -521,7 +521,8 @@ static int cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx, // Remove trailing zeroes. while (size > 0 && nal->data[size - 1] == 0) --size; -av_assert0(size > 0); +if (size == 0) +continue; data = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE); if (!data) -- 2.15.2 (Apple Git-101.1) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] avcodec/cbs_h264: silence errors about end_of_seq nalus
From: Aman Gupta [ffmpeg] AVBSFContext: Decomposition unimplemented for unit 4 (type 10). Signed-off-by: Aman Gupta --- libavcodec/cbs_h2645.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c index 13e4c1561c..2c7faf36e7 100644 --- a/libavcodec/cbs_h2645.c +++ b/libavcodec/cbs_h2645.c @@ -872,6 +872,9 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext *ctx, } break; +case H264_NAL_END_SEQUENCE: +return 0; + default: return AVERROR(ENOSYS); } -- 2.15.2 (Apple Git-101.1) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/cbs_h2645: fix crash due to assert failure on empty nalu
On Fri, Oct 12, 2018 at 12:02 PM Aman Gupta wrote: > > From: Aman Gupta > > Signed-off-by: Aman Gupta > --- > libavcodec/cbs_h2645.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c > index ab33cdb69b..13e4c1561c 100644 > --- a/libavcodec/cbs_h2645.c > +++ b/libavcodec/cbs_h2645.c > @@ -521,7 +521,8 @@ static int > cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx, > // Remove trailing zeroes. > while (size > 0 && nal->data[size - 1] == 0) > --size; > -av_assert0(size > 0); > +if (size == 0) > +continue; > I think about this fix have a discussion. https://patchwork.ffmpeg.org/patch/8919/ > data = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE); > if (!data) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] examples/vaapi_dec_scaling: add a vaapi decoding/scaling sample
On Tue, Aug 28, 2018 at 10:12 AM myp...@gmail.com wrote: > > On Tue, Aug 28, 2018 at 2:14 AM Mark Thompson wrote: > > > > On 23/08/18 14:08, Jun Zhao wrote: > > > add a vaapi decoding/scaling sample. > > > > > > Signed-off-by: Jun Zhao > > > --- > > > configure|2 + > > > doc/examples/Makefile|1 + > > > doc/examples/vaapi_dec_scaling.c | 377 > > > ++ > > > 3 files changed, 380 insertions(+), 0 deletions(-) > > > create mode 100644 doc/examples/vaapi_dec_scaling.c > > > > Looking at this, it seems like it copies a lot of code from hw_decode.c and > > filtering_video.c and combines it in a reasonably straightforward (?) way, > > but doesn't really any anything on top of that. I'm not convinced that > > adding an extra example like this for a specific combination of things > > already covered is necessarily helpful, though I could certainly be > > convinced if you have some reason for it. > > > > So, would you care to argue for why this example in particular is useful? > > > > Thanks, > > > > - Mark > > ___ > > > Hi, Mark: > > 1. Because we want to build a pipe for Media Analytic with HWaccel > decoder + scaling/csc(color space conversion) + clDNN > (https://github.com/intel/clDNN) or OpenVINO > (https://software.intel.com/en-us/openvino-toolkit) based on GPU with > FFmpeg (with buffer sharing), and If we consider the whole pipeline of > the media analytic as described above, we need to use the HW media > decoder/scaling/color space conversion and inference engine (clDNN or > OpenVINO) > 2. The other thing is we don't have an example to demo how to enable > HWaccel in AVFilter in API level (we have hw_decode for HWAccel > decoding, vaapi_encode for HWAccel encoding, vaapi_transcode for > HWaccel transcoding, but miss a HWAccel AVFilter example) Any other comments? Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
