Re: [FFmpeg-devel] [PATCH V2] avcodec/h264_mp4toannexb_bsf: add No IDR frame situation
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
Michael Niedermayer
Sent: Friday, August 24, 2018 05:30
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH V2] avcodec/h264_mp4toannexb_bsf: add No IDR
frame situation
On Thu, Aug 16, 2018 at 03:07:50PM +0800, Linjie Fu wrote:
> Fix the live stream encoding problem using qsv when the first frame is
> not an IDR frame.
>
> Add the extradata information when the IDR frame is missing in the
> first GOP.
>
> Fix the bug reported in ticket #6418.
>
> [PATCH V2] Fix the coding style.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/h264_mp4toannexb_bsf.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/h264_mp4toannexb_bsf.c
> b/libavcodec/h264_mp4toannexb_bsf.c
> index 794c82e650..fbb9f1fe20 100644
> --- a/libavcodec/h264_mp4toannexb_bsf.c
> +++ b/libavcodec/h264_mp4toannexb_bsf.c
> @@ -33,6 +33,7 @@ typedef struct H264BSFContext {
> int32_t pps_offset;
> uint8_t length_size;
> uint8_t new_idr;
> +uint8_t new_nal_slice;
> uint8_t idr_sps_seen;
> uint8_t idr_pps_seen;
> int extradata_parsed;
> @@ -243,6 +244,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *out)
> buf, nal_size, 1)) < 0)
> goto fail;
> s->new_idr = 0;
> +s->new_nal_slice = 1;
> /* if only SPS has been seen, also insert PPS */
> } else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE &&
> s->idr_sps_seen && !s->idr_pps_seen) {
> if (s->pps_offset == -1) { @@ -253,6 +255,12 @@ static
> int h264_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *out)
> ctx->par_out->extradata +
> s->pps_offset, ctx->par_out->extradata_size - s->pps_offset,
> buf, nal_size, 1)) < 0)
> goto fail;
> +} else if (s->new_idr && !s->new_nal_slice && H264_NAL_SLICE ==
> unit_type && !s->idr_sps_seen && !s->idr_pps_seen){
> +av_log(ctx, AV_LOG_WARNING, "first H264_NAL_SLICE when there is
> no IDR.\n");
> +if ((ret = alloc_and_copy(out, ctx->par_out->extradata,
> ctx->par_out->extradata_size, buf, nal_size, 1)) < 0)
> +goto fail;
> +s->new_nal_slice = 1;
> +s->new_idr = 0;
The commit message is insufficient
this adds the extradata if new_idr is set not just in the absence of IDR at the
begin
also teh addded code is identical to the first if() just a different NAL is
checked for, this code duplication is not a good idea in already complex code
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your own
failings. Then you will forget your anger. -- Epictetus
Thanks for your review.
I will adjust the code to reduce the duplication and make the commit message
clearer.
I add " new_nal_slice " to indicate the newly coming H264_NAL_IDR_SLICE and
H264_NAL_SLICE, because the new_idr is always "1" at the beginning of the
filter regardless of the nal type of slice.
This patch aims at the following issues:
1. the IDR frame is missing in the first GOP of a stream (common in live
stream, IDR.No.Inband.SPPS.mkv in ticket #6418)
2. there is no IDR frame in the input stream. (No.Inband.SPPS.No.IDR.mkv in
ticket #6418)
In issue 1, ffmpeg just drop all the frames in the first GOP without the patch
then continue to decode the following frames. (qsv and libopenh264)
In issue 2, ffmpeg could not decode any frames of the stream through
h264_mp4toannexb_filter without the patch. (qsv and libopenh264)
After applying this patch, all the frames could be decoded correctly in both
issues. (qsv works well, libopenh264 has to check the slice_nal_type in the
decode step in addition to the h264_mp4toannexb_filter, still can't decode.)
Thanks again.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_enc: print preroll and buffer size
On 24-08-2018 12:12 AM, Marton Balint wrote: On Thu, 23 Aug 2018, Gyan Doshi wrote: Plan to push tomorrow. Ok, LGTM. Thanks. Pushed as d0b48a960448cc8eb0e2c86e0804b14bdcb3e751 Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mpegts: improve read error handling
On Fri, Aug 24, 2018 at 5:38 AM Rodger Combs wrote:
>
> We previously could fail to check errors entirely, or misinterpret read
errors
> as normal EOFs.
> ---
> libavformat/mpegts.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 37a6aa8bff..1350213d39 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -2475,6 +2475,8 @@ static int mpegts_resync(AVFormatContext *s, int
seekback, const uint8_t *curren
>
> for (i = 0; i < ts->resync_size; i++) {
> c = avio_r8(pb);
> +if (pb->error)
> +return pb->error;
> if (avio_feof(pb))
> return AVERROR_EOF;
> if (c == 0x47) {
> @@ -2498,8 +2500,13 @@ static int read_packet(AVFormatContext *s, uint8_t
*buf, int raw_packet_size,
>
> for (;;) {
> len = ffio_read_indirect(pb, buf, TS_PACKET_SIZE, data);
> -if (len != TS_PACKET_SIZE)
> -return len < 0 ? len : AVERROR_EOF;
> +if (len != TS_PACKET_SIZE) {
> +if (len < 0)
> +return len;
> +if (pb->error)
> +return pb->error;
> +return AVERROR_EOF;
> +}
> /* check packet sync byte */
> if ((*data)[0] != 0x47) {
> /* find a new packet start */
> @@ -2670,6 +2677,8 @@ static int mpegts_read_header(AVFormatContext *s)
> /* read the first 8192 bytes to get packet size */
> pos = avio_tell(pb);
> len = avio_read(pb, buf, sizeof(buf));
> +if (len < 0)
> +return len;
> ts->raw_packet_size = get_packet_size(buf, len);
> if (ts->raw_packet_size <= 0) {
> av_log(s, AV_LOG_WARNING, "Could not detect TS packet size,
defaulting to non-FEC/DVHS\n");
> --
As I understand, only after avio_xxx return < 0 to check pb->error, now we
coding like:
len = avio_xxx(pb);
if (len < 0)
return len;
if (pb->error)
return pb->error;
It's stranger way for me, consider Unix API read(2), we just check the
error after -1 is returned
(
http://man7.org/linux/man-pages/man2/read.2.html
)
we usually catch the error
/ error
number like:
len = read(fd, buf, buf_size);
if (len < 0)
handle the error with error number.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/flvdec: don't propagate empty extradata
Fixes ticket #7379
Signed-off-by: James Almer
---
libavformat/flvdec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 93c7f85237..a2dea464e3 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -753,6 +753,9 @@ static int flv_read_close(AVFormatContext *s)
static int flv_get_extradata(AVFormatContext *s, AVStream *st, int size)
{
+if (!size)
+return 0;
+
av_freep(&st->codecpar->extradata);
if (ff_get_extradata(s, st->codecpar, s->pb, size) < 0)
return AVERROR(ENOMEM);
@@ -763,6 +766,9 @@ static int flv_get_extradata(AVFormatContext *s, AVStream
*st, int size)
static int flv_queue_extradata(FLVContext *flv, AVIOContext *pb, int stream,
int size)
{
+if (!size)
+return 0;
+
av_free(flv->new_extradata[stream]);
flv->new_extradata[stream] = av_mallocz(size +
AV_INPUT_BUFFER_PADDING_SIZE);
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/opus_parser: Handle complete frames flag.
On Thu, Aug 23, 2018 at 10:43 PM James Almer wrote: > > On 8/21/2018 7:47 PM, James Almer wrote: > > On 8/20/2018 3:35 PM, Jacob Trimble wrote: > >> I am not entirely sure what this flag is supposed to be, since there > >> is no documentation where it is defined. But this was suggested by > >> James Almer as a fix for my encrypted Opus problems and several other > >> codec parsers do the same thing. > > > > It's a flag that lets the parser know what kind of frames it's getting. > > libavformat will set it if the source is a demuxer that guarantees the > > propagation of complete frames, like mp4, Matroska and Ogg. > > > > Applied, thanks. > > Had to revert this as it broke packet timestamp and duration generation > for all Opus streams in Matroska and probably other containers. > You can reproduce it with the mka test vectors in the FATE sample suite > by doing a codec copy to the framecrc pseudo muxer. Decoding was > apparently unaffected, so FATE didn't detect any regression. > > I don't know how to work around the issues you had with encrypted files > if not with this. Maybe the Opus packet parsing could be done by the > Matroska demuxer, much like the Ogg demuxer does (The only container > apparently not negatively affected by the commit i just reverted). You could probably fix that by refactoring opus_find_frame_end to split the frame boundary finding and the actual packet header parsing (which sets the duration info). But it might be more interesting why it fails with encrypted streams in the first place. Does it encrypt the entire frame, including frame headers? Because if that would be the case, that change would not help anylonger. Maybe if a demuxer can know that, it should just set a flag to disable parsing entirely then. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] make work (live) libsrt
On Fri, Aug 24, 2018 at 2:55 AM Marton Balint wrote:
>
>
>
> On Thu, 23 Aug 2018, myp...@gmail.com wrote:
>
> > On Wed, Aug 22, 2018 at 4:30 AM Tudor Suciu wrote:
> >>
> >> Hello,
> >>
> >> I get errors when I try to send a live srt stream that the first packet is
> >> too big:
> >> 21:30:39.896626/ffmpeg*E: SRT.c: LiveSmoother: payload size: 1504 exceeds
> >> maximum allowed 1316
> >>
> >> Here are example commands for server and client:
> >> ffmpeg -re -i ~/Downloads/ToS-4k-1920.mov -vcodec libx264 -g 50 -refs 1 -s
> >> 640x360 -b:v 1000k -acodec aac -b:a 64k -flush_packets 0 -f mpegts "srt://
> >> 127.0.0.1:?mode=listener"
> >> ffplay srt://127.0.0.1:
> >>
> >> A patch that fully solves the issue is:
> >> diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> >> index 0f9529d263..156a4776e2 100644
> >> --- a/libavformat/libsrt.c
> >> +++ b/libavformat/libsrt.c
> >> @@ -412,6 +412,8 @@ static int libsrt_open(URLContext *h, const char *uri,
> >> int flags)
> >> return AVERROR_UNKNOWN;
> >> }
> >>
> >> +h->max_packet_size = 1316;
> >> +
> >> /* SRT options (srt/srt.h) */
> >> p = strchr(uri, '?');
> >> if (p) {
> >>
> >> How would you like this option to be made work in a way that can be
> >> accepted in ffmpeg?
> >> Is there a way to change the max packet size without this patch?
> >>
> > In your case, I don't think hard coding max packet size == 1316 is not
> > a good idea in loopback device, and after deep in the srt
> > library(https://github.com/Haivision/srt) source code, I think srt
> > library need to fix the hardcode about packet size limition.
>
> I can't think of a scenario where limiting the packet size actually causes
> problems, but if you insist on not limiting it in general, then the max
> packet size should be settable using an option, same way it is for UDP.
> (pkt_size option). I'd suggest using 1316 as default, because that
> is the more common (and currently the only working) use case...
>
> Thanks,
> Marton
I agree with you, giving an option like pkt_size and using 1316 as the
default in this case is a better way to fix this issue.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/vaapi_dec_scaling: init export
On Fri, Aug 24, 2018 at 6:54 AM Mark Thompson wrote: > > On 23/08/18 01:44, myp...@gmail.com wrote: > > On Wed, Aug 22, 2018 at 5:51 PM Carl Eugen Hoyos wrote: > >> > >> 2018-08-22 2:42 GMT+02:00, myp...@gmail.com : > >>> On Tue, Aug 21, 2018 at 4:45 PM Carl Eugen Hoyos > >>> wrote: > > 2018-06-11 13:22 GMT+02:00, Jun Zhao : > > > + * Copyright (c) 2018 Jun Zhao > > + * > > + * VA-API Acceleration API (video decoding/scaling) sample > > + * > > + * 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. > > This is not an ideal license for doc/examples. > >>> > >>> I didn't realize this problem, any other license be suggested? MIT ? > >> > >> I think so, yes. > >> > > Will change the license and update the other vaapi_xxx sample (after > > asking the other related contributor with mail), Thanks. > > I agree that all of my changes to hw_decode.c, vaapi_encode.c, > vaapi_transcode.c in doc/examples can be relicensed to MIT. > > (I'm not sure anything other than b0d9eab7 is nontrivial enough to matter, > but the above is clear.) > > Thanks, > > - Mark Thanks a lot, Mark. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2] mpeg4video: Add Studio DPCM support
0001-mpeg4video-Add-Studio-DPCM-support.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 38/41] vaapi_encode: Let the reconstructed frame pool be sized dynamically
On Thu, 23 Aug 2018 at 00:49, Mark Thompson wrote:
> No supported encode driver requires the pool to be fixed-size, so just
> remove this constraint.
> ---
> libavcodec/vaapi_encode.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index d03bd1925e..e20280065c 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1721,9 +1721,6 @@ static av_cold int
> vaapi_encode_create_recon_frames(AVCodecContext *avctx)
> ctx->recon_frames->sw_format = recon_format;
> ctx->recon_frames->width = ctx->surface_width;
> ctx->recon_frames->height= ctx->surface_height;
> -// At most three IDR/I/P frames and two runs of B frames can be in
> -// flight at any one time.
> -ctx->recon_frames->initial_pool_size = 3 + 2 * ctx->b_per_p;
>
> err = av_hwframe_ctx_init(ctx->recon_frames_ref);
> if (err < 0) {
> --
> 2.18.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/libopusenc: support encoding packets of sizes bigger than 60ms
On Thu, 23 Aug 2018 at 23:18, James Almer wrote:
> Packets of sizes 80ms, 100ms and 120ms can be encoded since libopus 1.2
>
> Signed-off-by: James Almer
> ---
> libavcodec/libopusenc.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
> index 4ae81b0bb2..7c025a66d7 100644
> --- a/libavcodec/libopusenc.c
> +++ b/libavcodec/libopusenc.c
> @@ -271,12 +271,22 @@ static av_cold int
> libopus_encode_init(AVCodecContext *avctx)
> case 960:
> case 1920:
> case 2880:
> +#ifdef OPUS_FRAMESIZE_120_MS
> +case 3840:
> +case 4800:
> +case 5760:
> +#endif
> opus->opts.packet_size =
> avctx->frame_size = frame_size * avctx->sample_rate / 48000;
> break;
> default:
> av_log(avctx, AV_LOG_ERROR, "Invalid frame duration: %g.\n"
> - "Frame duration must be exactly one of: 2.5, 5, 10, 20, 40
> or 60.\n",
> + "Frame duration must be exactly one of: 2.5, 5, 10, 20, 40"
> +#ifdef OPUS_FRAMESIZE_120_MS
> + ", 60, 80, 100 or 120.\n",
> +#else
> + " or 60.\n",
> +#endif
> opus->opts.frame_duration);
> return AVERROR(EINVAL);
> }
> @@ -463,10 +473,10 @@ static int libopus_encode(AVCodecContext *avctx,
> AVPacket *avpkt,
> memset(audio, 0, opus->opts.packet_size * sample_size);
> }
>
> -/* Maximum packet size taken from opusenc in opus-tools. 60ms packets
> - * consist of 3 frames in one packet. The maximum frame size is 1275
> +/* Maximum packet size taken from opusenc in opus-tools. 120ms packets
> + * consist of 6 frames in one packet. The maximum frame size is 1275
> * bytes along with the largest possible packet header of 7 bytes. */
> -if ((ret = ff_alloc_packet2(avctx, avpkt, (1275 * 3 + 7) *
> opus->stream_count, 0)) < 0)
> +if ((ret = ff_alloc_packet2(avctx, avpkt, (1275 * 6 + 7) *
> opus->stream_count, 0)) < 0)
> return ret;
>
> if (avctx->sample_fmt == AV_SAMPLE_FMT_FLT)
> @@ -534,7 +544,7 @@ static const AVOption libopus_options[] = {
> { "voip", "Favor improved speech intelligibility", 0,
> AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_VOIP },0, 0,
> FLAGS, "application" },
> { "audio", "Favor faithfulness to the input", 0,
> AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_AUDIO }, 0, 0,
> FLAGS, "application" },
> { "lowdelay", "Restrict to only the lowest delay modes", 0,
> AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_RESTRICTED_LOWDELAY }, 0, 0,
> FLAGS, "application" },
> -{ "frame_duration", "Duration of a frame in milliseconds",
> OFFSET(frame_duration), AV_OPT_TYPE_FLOAT, { .dbl = 20.0 }, 2.5, 60.0,
> FLAGS },
> +{ "frame_duration", "Duration of a frame in milliseconds",
> OFFSET(frame_duration), AV_OPT_TYPE_FLOAT, { .dbl = 20.0 }, 2.5, 120.0,
> FLAGS },
> { "packet_loss","Expected packet loss percentage",
> OFFSET(packet_loss),AV_OPT_TYPE_INT, { .i64 = 0 },0, 100,
> FLAGS },
> { "vbr","Variable bit rate mode",
> OFFSET(vbr),AV_OPT_TYPE_INT, { .i64 = 1 },0, 2,
> FLAGS, "vbr" },
> { "off","Use constant bit rate", 0,
> AV_OPT_TYPE_CONST, { .i64 = 0 }, 0, 0, FLAGS, "vbr" },
> --
> 2.18.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/vaapi_dec_scaling: init export
On 23/08/18 01:44, myp...@gmail.com wrote: > On Wed, Aug 22, 2018 at 5:51 PM Carl Eugen Hoyos wrote: >> >> 2018-08-22 2:42 GMT+02:00, myp...@gmail.com : >>> On Tue, Aug 21, 2018 at 4:45 PM Carl Eugen Hoyos wrote: 2018-06-11 13:22 GMT+02:00, Jun Zhao : > + * Copyright (c) 2018 Jun Zhao > + * > + * VA-API Acceleration API (video decoding/scaling) sample > + * > + * 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. This is not an ideal license for doc/examples. >>> >>> I didn't realize this problem, any other license be suggested? MIT ? >> >> I think so, yes. >> > Will change the license and update the other vaapi_xxx sample (after > asking the other related contributor with mail), Thanks. I agree that all of my changes to hw_decode.c, vaapi_encode.c, vaapi_transcode.c in doc/examples can be relicensed to MIT. (I'm not sure anything other than b0d9eab7 is nontrivial enough to matter, but the above is clear.) Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/movenc: support Opus packets with more than 60ms of audio when writing the Sample Group Description Box
Fixes assertion failures when trying to mux such streams.
Signed-off-by: James Almer
---
libavformat/movenc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 8ad7026741..1b1d765f7d 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2365,9 +2365,8 @@ static int mov_preroll_write_stbl_atoms(AVIOContext *pb,
MOVTrack *track)
decoded. */
if (roll_samples_remaining > 0)
distance = 0;
-/* Verify distance is a minimum of 2 (60ms) packets and a maximum
of
- 32 (2.5ms) packets. */
-av_assert0(distance == 0 || (distance >= 2 && distance <= 32));
+/* Verify distance is a maximum of 32 (2.5ms) packets. */
+av_assert0(distance <= 32);
if (i && distance == sgpd_entries[entries].roll_distance) {
sgpd_entries[entries].count++;
} else {
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/libopusenc: support encoding packets of sizes bigger than 60ms
Packets of sizes 80ms, 100ms and 120ms can be encoded since libopus 1.2
Signed-off-by: James Almer
---
libavcodec/libopusenc.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
index 4ae81b0bb2..7c025a66d7 100644
--- a/libavcodec/libopusenc.c
+++ b/libavcodec/libopusenc.c
@@ -271,12 +271,22 @@ static av_cold int libopus_encode_init(AVCodecContext
*avctx)
case 960:
case 1920:
case 2880:
+#ifdef OPUS_FRAMESIZE_120_MS
+case 3840:
+case 4800:
+case 5760:
+#endif
opus->opts.packet_size =
avctx->frame_size = frame_size * avctx->sample_rate / 48000;
break;
default:
av_log(avctx, AV_LOG_ERROR, "Invalid frame duration: %g.\n"
- "Frame duration must be exactly one of: 2.5, 5, 10, 20, 40 or
60.\n",
+ "Frame duration must be exactly one of: 2.5, 5, 10, 20, 40"
+#ifdef OPUS_FRAMESIZE_120_MS
+ ", 60, 80, 100 or 120.\n",
+#else
+ " or 60.\n",
+#endif
opus->opts.frame_duration);
return AVERROR(EINVAL);
}
@@ -463,10 +473,10 @@ static int libopus_encode(AVCodecContext *avctx, AVPacket
*avpkt,
memset(audio, 0, opus->opts.packet_size * sample_size);
}
-/* Maximum packet size taken from opusenc in opus-tools. 60ms packets
- * consist of 3 frames in one packet. The maximum frame size is 1275
+/* Maximum packet size taken from opusenc in opus-tools. 120ms packets
+ * consist of 6 frames in one packet. The maximum frame size is 1275
* bytes along with the largest possible packet header of 7 bytes. */
-if ((ret = ff_alloc_packet2(avctx, avpkt, (1275 * 3 + 7) *
opus->stream_count, 0)) < 0)
+if ((ret = ff_alloc_packet2(avctx, avpkt, (1275 * 6 + 7) *
opus->stream_count, 0)) < 0)
return ret;
if (avctx->sample_fmt == AV_SAMPLE_FMT_FLT)
@@ -534,7 +544,7 @@ static const AVOption libopus_options[] = {
{ "voip", "Favor improved speech intelligibility", 0,
AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_VOIP },0, 0,
FLAGS, "application" },
{ "audio", "Favor faithfulness to the input", 0,
AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_AUDIO }, 0, 0,
FLAGS, "application" },
{ "lowdelay", "Restrict to only the lowest delay modes", 0,
AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_RESTRICTED_LOWDELAY }, 0, 0,
FLAGS, "application" },
-{ "frame_duration", "Duration of a frame in milliseconds",
OFFSET(frame_duration), AV_OPT_TYPE_FLOAT, { .dbl = 20.0 }, 2.5, 60.0, FLAGS },
+{ "frame_duration", "Duration of a frame in milliseconds",
OFFSET(frame_duration), AV_OPT_TYPE_FLOAT, { .dbl = 20.0 }, 2.5, 120.0, FLAGS },
{ "packet_loss","Expected packet loss percentage",
OFFSET(packet_loss),AV_OPT_TYPE_INT, { .i64 = 0 },0, 100, FLAGS },
{ "vbr","Variable bit rate mode", OFFSET(vbr),
AV_OPT_TYPE_INT, { .i64 = 1 },0, 2,FLAGS, "vbr" },
{ "off","Use constant bit rate", 0, AV_OPT_TYPE_CONST, {
.i64 = 0 }, 0, 0, FLAGS, "vbr" },
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 32/41] vaapi_encode_h265: Improve profile support
On 8/22/2018 8:45 PM, Mark Thompson wrote: > Set profile compatibility/constraint flags properly (including the > constraint flags used for RExt profiles, as all streams we can currently > generate are RExt-compatible), and use that to add support for the "Main > Intra" and "Main 10 Intra" RExt subprofiles (for which we can re-use the > existing Main and Main10 VAAPI profiles). > --- > libavcodec/Makefile| 2 +- > libavcodec/vaapi_encode_h265.c | 70 ++ > 2 files changed, 56 insertions(+), 16 deletions(-) > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > index d07a9073af..756779ec16 100644 > --- a/libavcodec/Makefile > +++ b/libavcodec/Makefile > @@ -373,7 +373,7 @@ OBJS-$(CONFIG_HEVC_QSV_DECODER)+= qsvdec_h2645.o > OBJS-$(CONFIG_HEVC_QSV_ENCODER)+= qsvenc_hevc.o hevc_ps_enc.o \ >hevc_data.o > OBJS-$(CONFIG_HEVC_RKMPP_DECODER) += rkmppdec.o > -OBJS-$(CONFIG_HEVC_VAAPI_ENCODER) += vaapi_encode_h265.o > +OBJS-$(CONFIG_HEVC_VAAPI_ENCODER) += h265_profile_level.o > vaapi_encode_h265.o Wont this fail until the next patch is committed? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_interlace: fix numerical options
Currently numerical option values are misinterpreted in vf_interlace filter. Patch attached. Regards, Thomas 0001-avfilter-vf_interlace-fix-numerical-options.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavc/hevc_mp4toannexb_bsf: don't fail on extradata with too few arrays
I've been given a sample that does this. Not sure exactly why, but the decoder
ignores it and plays normally.
---
libavcodec/hevc_mp4toannexb_bsf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
b/libavcodec/hevc_mp4toannexb_bsf.c
index 09bce5b34c..fb4ea34a93 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -52,6 +52,11 @@ static int hevc_extradata_to_annexb(AVBSFContext *ctx)
num_arrays = bytestream2_get_byte(&gb);
for (i = 0; i < num_arrays; i++) {
+if (bytestream2_get_bytes_left(&gb) < 3) {
+av_log(ctx, AV_LOG_WARNING, "Extradata contained fewer arrays than
indicated\n");
+break;
+}
+
int type = bytestream2_get_byte(&gb) & 0x3f;
int cnt = bytestream2_get_be16(&gb);
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavc/hevc_mp4toannexb_bsf: warn if a NAL size would overflow the buffer
This didn't actually cause a buffer overread previously, but it could result
in the end of a NAL being filled with zeros silently.
---
libavcodec/hevc_mp4toannexb_bsf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
b/libavcodec/hevc_mp4toannexb_bsf.c
index fb4ea34a93..c40308f367 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -70,6 +70,10 @@ static int hevc_extradata_to_annexb(AVBSFContext *ctx)
for (j = 0; j < cnt; j++) {
int nalu_len = bytestream2_get_be16(&gb);
+if (nalu_len < 1 || bytestream2_get_bytes_left(&gb) < nalu_len) {
+av_log(ctx, AV_LOG_WARNING, "Extradata NAL ended
prematurely\n");
+goto done;
+}
if (4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len > SIZE_MAX -
new_extradata_size) {
ret = AVERROR_INVALIDDATA;
@@ -86,6 +90,7 @@ static int hevc_extradata_to_annexb(AVBSFContext *ctx)
}
}
+done:
av_freep(&ctx->par_out->extradata);
ctx->par_out->extradata = new_extradata;
ctx->par_out->extradata_size = new_extradata_size;
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/mpegts: improve read error handling
We previously could fail to check errors entirely, or misinterpret read errors
as normal EOFs.
---
libavformat/mpegts.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 37a6aa8bff..1350213d39 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2475,6 +2475,8 @@ static int mpegts_resync(AVFormatContext *s, int
seekback, const uint8_t *curren
for (i = 0; i < ts->resync_size; i++) {
c = avio_r8(pb);
+if (pb->error)
+return pb->error;
if (avio_feof(pb))
return AVERROR_EOF;
if (c == 0x47) {
@@ -2498,8 +2500,13 @@ static int read_packet(AVFormatContext *s, uint8_t *buf,
int raw_packet_size,
for (;;) {
len = ffio_read_indirect(pb, buf, TS_PACKET_SIZE, data);
-if (len != TS_PACKET_SIZE)
-return len < 0 ? len : AVERROR_EOF;
+if (len != TS_PACKET_SIZE) {
+if (len < 0)
+return len;
+if (pb->error)
+return pb->error;
+return AVERROR_EOF;
+}
/* check packet sync byte */
if ((*data)[0] != 0x47) {
/* find a new packet start */
@@ -2670,6 +2677,8 @@ static int mpegts_read_header(AVFormatContext *s)
/* read the first 8192 bytes to get packet size */
pos = avio_tell(pb);
len = avio_read(pb, buf, sizeof(buf));
+if (len < 0)
+return len;
ts->raw_packet_size = get_packet_size(buf, len);
if (ts->raw_packet_size <= 0) {
av_log(s, AV_LOG_WARNING, "Could not detect TS packet size, defaulting
to non-FEC/DVHS\n");
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] avcodec/h264_mp4toannexb_bsf: add No IDR frame situation
On Thu, Aug 16, 2018 at 03:07:50PM +0800, Linjie Fu wrote:
> Fix the live stream encoding problem using qsv when the first frame
> is not an IDR frame.
>
> Add the extradata information when the IDR frame is missing in the
> first GOP.
>
> Fix the bug reported in ticket #6418.
>
> [PATCH V2] Fix the coding style.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/h264_mp4toannexb_bsf.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/h264_mp4toannexb_bsf.c
> b/libavcodec/h264_mp4toannexb_bsf.c
> index 794c82e650..fbb9f1fe20 100644
> --- a/libavcodec/h264_mp4toannexb_bsf.c
> +++ b/libavcodec/h264_mp4toannexb_bsf.c
> @@ -33,6 +33,7 @@ typedef struct H264BSFContext {
> int32_t pps_offset;
> uint8_t length_size;
> uint8_t new_idr;
> +uint8_t new_nal_slice;
> uint8_t idr_sps_seen;
> uint8_t idr_pps_seen;
> int extradata_parsed;
> @@ -243,6 +244,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *out)
> buf, nal_size, 1)) < 0)
> goto fail;
> s->new_idr = 0;
> +s->new_nal_slice = 1;
> /* if only SPS has been seen, also insert PPS */
> } else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE &&
> s->idr_sps_seen && !s->idr_pps_seen) {
> if (s->pps_offset == -1) {
> @@ -253,6 +255,12 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *out)
> ctx->par_out->extradata +
> s->pps_offset, ctx->par_out->extradata_size - s->pps_offset,
> buf, nal_size, 1)) < 0)
> goto fail;
> +} else if (s->new_idr && !s->new_nal_slice && H264_NAL_SLICE ==
> unit_type && !s->idr_sps_seen && !s->idr_pps_seen){
> +av_log(ctx, AV_LOG_WARNING, "first H264_NAL_SLICE when there is
> no IDR.\n");
> +if ((ret = alloc_and_copy(out, ctx->par_out->extradata,
> ctx->par_out->extradata_size, buf, nal_size, 1)) < 0)
> +goto fail;
> +s->new_nal_slice = 1;
> +s->new_idr = 0;
The commit message is insufficient
this adds the extradata if new_idr is set not just in the absence of IDR at
the begin
also teh addded code is identical to the first if() just a different NAL is
checked for, this code duplication is not a good idea in already complex
code
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
2018-08-23 15:58 GMT+02:00, Carl Eugen Hoyos : > 2018-08-23 15:35 GMT+02:00, Carl Eugen Hoyos : >> 2018-08-23 15:08 GMT+02:00, Paul B Mahol : >>> From 100x real-time decoding to 138x real-time decoding for 320x240 >>> video. >> >> On x86_64 I get an even better improvement, on x86_32 >> decoding gets slower by approximately 10%. >> Without the patch, decoding is faster on x86_32 than >> x86_64 here... > > Using vanilla gcc-6.4. > > clang 3.4: > 5% slower with patch on x86_32 >>40% faster with patch on x86_64 > x86_32 again faster than x86_64 without patch. On Linux ppc, gcc 7.2.1 64bit: 580 -> 740 fps 32bit: ~730fps, both with and without the patch On Linux aarch64, gcc 4.8 358 -> 492 fps Not sure if I can find a reliable arm 32bit target. (Only mobile phones) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/12] avformat/mxfenc: automatically update descriptors klv size
Hey Carl, On Wed, Aug 22, 2018 at 12:00 PM, Carl Eugen Hoyos wrote: > 2018-07-06 19:17 GMT+02:00, Carl Eugen Hoyos : > > 2018-07-04 20:35 GMT+02:00, Baptiste Coudurier > > : > >> --- > >> libavformat/mxfenc.c | 80 +--- > >> 1 file changed, 39 insertions(+), 41 deletions(-) > > > > Does any of the patches fix ticket #6693? > > Ping? > > Or #6781? I haven't tested, so I don't know. -- Baptiste ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/opus_parser: Handle complete frames flag.
On 8/21/2018 7:47 PM, James Almer wrote: > On 8/20/2018 3:35 PM, Jacob Trimble wrote: >> I am not entirely sure what this flag is supposed to be, since there >> is no documentation where it is defined. But this was suggested by >> James Almer as a fix for my encrypted Opus problems and several other >> codec parsers do the same thing. > > It's a flag that lets the parser know what kind of frames it's getting. > libavformat will set it if the source is a demuxer that guarantees the > propagation of complete frames, like mp4, Matroska and Ogg. > > Applied, thanks. Had to revert this as it broke packet timestamp and duration generation for all Opus streams in Matroska and probably other containers. You can reproduce it with the mka test vectors in the FATE sample suite by doing a codec copy to the framecrc pseudo muxer. Decoding was apparently unaffected, so FATE didn't detect any regression. I don't know how to work around the issues you had with encrypted files if not with this. Maybe the Opus packet parsing could be done by the Matroska demuxer, much like the Ogg demuxer does (The only container apparently not negatively affected by the commit i just reverted). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg.c: add an option "detail_stats" to allow ffmpeg to output stats for each stream
From: Wang Cao
Add an option "detail_stats" to ffmpeg to output stats for each video/audio
streams and each ouptut file ffmpeg output log in print_report. The format of
stats is unchanged.
Signed-off-by: Wang Cao
---
doc/ffmpeg.texi | 4
fftools/ffmpeg.c | 53 +++-
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_opt.c | 4 +++-
4 files changed, 45 insertions(+), 17 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 3717f22d42..53a5be9791 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1623,6 +1623,10 @@ rtp stream. (Requires at least one of the output formats
to be rtp).
Allows discarding specific streams or frames of streams at the demuxer.
Not all demuxers support this.
+@item -detail_stats (@emph{global})
+Allows printing stats for each output stream and output file at the end of
+processing.
+
@table @option
@item none
Discard no frame.
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2459374f08..2bd057ace1 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1530,17 +1530,28 @@ static int reap_filters(int flush)
return 0;
}
-static void print_final_stats(int64_t total_size)
+static void print_final_stats()
{
uint64_t video_size = 0, audio_size = 0, extra_size = 0, other_size = 0;
uint64_t subtitle_size = 0;
uint64_t data_size = 0;
+int64_t total_size;
float percent = -1.0;
int i, j;
int pass1_used = 1;
-
-for (i = 0; i < nb_output_streams; i++) {
+int nb_display_streams = enable_detail_stats ? nb_output_streams : 1;
+AVFormatContext *oc;
+
+for (i = 0; i < nb_display_streams; i++) {
OutputStream *ost = output_streams[i];
+if (i > 0 && ost->file_index != output_streams[i-1]->file_index) {
+video_size = 0;
+audio_size = 0;
+extra_size = 0;
+other_size = 0;
+subtitle_size = 0;
+data_size = 0;
+}
switch (ost->enc_ctx->codec_type) {
case AVMEDIA_TYPE_VIDEO: video_size += ost->data_size; break;
case AVMEDIA_TYPE_AUDIO: audio_size += ost->data_size; break;
@@ -1552,7 +1563,13 @@ static void print_final_stats(int64_t total_size)
if ( (ost->enc_ctx->flags & (AV_CODEC_FLAG_PASS1 |
AV_CODEC_FLAG_PASS2))
!= AV_CODEC_FLAG_PASS1)
pass1_used = 0;
-}
+
+// Print stats for each output file.
+if (i == nb_output_streams-1 || ost->file_index !=
output_streams[i+1]->file_index) {
+oc = output_files[ost->file_index]->ctx;
+total_size = avio_size(oc->pb);
+if (total_size <= 0) // FIXME improve avio_size() so it works with
non seekable output too
+total_size = avio_tell(oc->pb);
if (data_size && total_size>0 && total_size >= data_size)
percent = 100.0 * (total_size - data_size) / data_size;
@@ -1568,6 +1585,8 @@ static void print_final_stats(int64_t total_size)
else
av_log(NULL, AV_LOG_INFO, "unknown");
av_log(NULL, AV_LOG_INFO, "\n");
+}
+}
/* print verbose per-stream stats */
for (i = 0; i < nb_input_files; i++) {
@@ -1680,13 +1699,6 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
t = (cur_time-timer_start) / 100.0;
-
-oc = output_files[0]->ctx;
-
-total_size = avio_size(oc->pb);
-if (total_size <= 0) // FIXME improve avio_size() so it works with non
seekable output too
-total_size = avio_tell(oc->pb);
-
vid = 0;
av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
av_bprint_init(&buf_script, 0, AV_BPRINT_SIZE_AUTOMATIC);
@@ -1697,12 +1709,14 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
if (!ost->stream_copy)
q = ost->quality / (float) FF_QP2LAMBDA;
-if (vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (is_last_report && vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
av_bprintf(&buf, "q=%2.1f ", q);
av_bprintf(&buf_script, "stream_%d_%d_q=%.1f\n",
ost->file_index, ost->index, q);
}
-if (!vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+// Only print the stats for the first stream during processing
+if ((is_last_report && (enable_detail_stats && vid || !vid)) ||
!is_last_report && !vid) {
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
float fps;
frame_number = ost->frame_number;
@@ -1761,7 +1775,9 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
ost->st->time_base, AV_TIME_BASE_Q));
if (is_last_report)
nb_frames_drop += ost->last_dropped;
-}
+total_size = avio_size(output_files[ost->file_index]->ctx->pb);
+if (total_size <= 0) // FIXME improve avio_size(
Re: [FFmpeg-devel] make work (live) libsrt
On Thu, 23 Aug 2018, myp...@gmail.com wrote:
On Wed, Aug 22, 2018 at 4:30 AM Tudor Suciu wrote:
Hello,
I get errors when I try to send a live srt stream that the first packet is
too big:
21:30:39.896626/ffmpeg*E: SRT.c: LiveSmoother: payload size: 1504 exceeds
maximum allowed 1316
Here are example commands for server and client:
ffmpeg -re -i ~/Downloads/ToS-4k-1920.mov -vcodec libx264 -g 50 -refs 1 -s
640x360 -b:v 1000k -acodec aac -b:a 64k -flush_packets 0 -f mpegts "srt://
127.0.0.1:?mode=listener"
ffplay srt://127.0.0.1:
A patch that fully solves the issue is:
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 0f9529d263..156a4776e2 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -412,6 +412,8 @@ static int libsrt_open(URLContext *h, const char *uri,
int flags)
return AVERROR_UNKNOWN;
}
+h->max_packet_size = 1316;
+
/* SRT options (srt/srt.h) */
p = strchr(uri, '?');
if (p) {
How would you like this option to be made work in a way that can be
accepted in ffmpeg?
Is there a way to change the max packet size without this patch?
In your case, I don't think hard coding max packet size == 1316 is not
a good idea in loopback device, and after deep in the srt
library(https://github.com/Haivision/srt) source code, I think srt
library need to fix the hardcode about packet size limition.
I can't think of a scenario where limiting the packet size actually causes
problems, but if you insist on not limiting it in general, then the max
packet size should be settable using an option, same way it is for UDP.
(pkt_size option). I'd suggest using 1316 as default, because that
is the more common (and currently the only working) use case...
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [bisected] Crashing Firefox
On 8/23/2018 2:34 PM, Mohammad_AlSaleh wrote: > On Fri, Aug 17, 2018 at 12:07:56AM -0300, James Almer wrote: >> On 7/28/2018 6:28 PM, Michael Niedermayer wrote: >>> On Sat, Jul 28, 2018 at 01:25:36PM -0300, James Almer wrote: On 7/28/2018 4:09 AM, Michael Niedermayer wrote: > On Fri, Jul 27, 2018 at 11:11:47PM -0300, James Almer wrote: >> On 7/27/2018 10:58 PM, Michael Niedermayer wrote: >>> On Fri, Jul 27, 2018 at 11:57:49AM -0300, James Almer wrote: Certain AVCodecParameters, like the contents of the extradata, may be changed by the init() function of any of the bitstream filters in the chain. Signed-off-by: James Almer --- Now it's not going to be called after the codec has been opened. libavcodec/decode.c | 4 1 file changed, 4 insertions(+) >>> >>> This breaks: >>> ffmpeg -i >>> https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png >>> -bitexact -pix_fmt rgba -f framecrc - >> >> Is any other decoder failing the same way? Because the apng decoder >> threading code may be faulty otherwise. Plenty of avctx fields are >> changed after ff_thread_init() is called within avcodec_open2(). There >> should not be a race at this point. > > I found a failure with mpeg4 (with bframes) decoding + pcm_alaw from mkv > but it > does not want to reproduce. The slightest change i do makes this not > happen > even just duplicating a command line parameter (which should have no > effect) > simply adding the -threads parameter to it independant of value makes it > go away > too > > > in the png case > this hits teh issue: > -threads 2 -i > https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png > -f framecrc - > > this does not: > -threads 1 -i > https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png > -f framecrc - > > also odly the bitexact flag made a differnce in how it fails outside > valgrind > last i tried. (doesnt make a difference in valgrind it seems) A solution may be moving the ff_decode_bsfs_init call in patch 7/8 right above the call to ff_thread_init (See attachment), hopefully preventing this race once this patch is applied afterwards, but it will result in the bsfs initialized before the decoder, and some of the avctx fields that are changed later in avcodec_open2 like channels and bit_rate not being reflected during said bsfs initialization. I can't say if the former is correct or ideal, but for now the latter would not be an issue. I don't know what may happen if we were to autoinsert a filter that does care about such fields in the future, though. If the above change doesn't solve it, or is not ideal, then this patch 8/8 can be dropped or postponed, and the rest of the set pushed without it. >>> >>> with this patch, the pachset seems not to trigger these errors anymore >>> >>> thanks >> >> Set pushed. Thanks. >> > > Just so you know, f631c328e680a3dd491936b92f69970c20cdcfc7 > causes Firefox's media playback thread to crash. > > Just try playing any local or remote mp4 file. The crash is > reproducible. > > Tested and bisected with FF Developer Edition (64-bit linux). Can you give us some more details, and a gdb output? And please open a ticket in http://trac.ffmpeg.org/ for this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_enc: print preroll and buffer size
On Thu, 23 Aug 2018, Gyan Doshi wrote: Plan to push tomorrow. Ok, LGTM. Thanks: Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] swscale : add bitexact conv for grayf32 and gray16 to f32 conv
Hello, Patch in attach add some bitexact conversion for grayf32 and unscaled conv for gray16 to grayf32. Pass fate test for me (x86_64, macos 10.12) 001 : Add bit exact conv for float to uint16 002 : Add bit exact conv for float to uint8 003 : Add bit exact lut generation for 8b to float (alloc/free the lut). 004 : Add bit exact and non bitexact lut generation for 16b to float and add unscale conv from uint16 to grayF32. In bit exact mode, the last part of the lut (32768 to 65535), have on some value an offset of 1 in the mantissa part (comparing to float conv). In practice, doesn't have a visual impact on the result. I will add later patch to add swap managment in the unscale part for float input/output I still have a problem with output func : yuv2plane1_float_c_template/yuv2planeX_float_c_template, where i would like to use the uint2float lut, store inside SwsContext, but doesn't find a way to pass it to the processing func. Will take a look later, for SIMD for the float to uint conv (in order to decide if we keep float and bitexact version of the conv). For lut generation, i'm not sure, trying to add SIMD is need (probably not a lot of impact on global speed) Martin 0001-swscale-input-add-bit_exact-for-float-to-uint16-conv.patch Description: Binary data 0003-swscale-add-bit_exact-lut-creation-for-8bit-to-float.patch Description: Binary data 0004-swscale-swscale_unscaled-add-conversion-from-float-Y.patch Description: Binary data 0002-swscale-unscale-add-bitexact-conversion-for-float-to.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_enc: print preroll and buffer size
Plan to push tomorrow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [bisected] Crashing Firefox
On Fri, Aug 17, 2018 at 12:07:56AM -0300, James Almer wrote: > On 7/28/2018 6:28 PM, Michael Niedermayer wrote: > > On Sat, Jul 28, 2018 at 01:25:36PM -0300, James Almer wrote: > >> On 7/28/2018 4:09 AM, Michael Niedermayer wrote: > >>> On Fri, Jul 27, 2018 at 11:11:47PM -0300, James Almer wrote: > On 7/27/2018 10:58 PM, Michael Niedermayer wrote: > > On Fri, Jul 27, 2018 at 11:57:49AM -0300, James Almer wrote: > >> Certain AVCodecParameters, like the contents of the extradata, may be > >> changed > >> by the init() function of any of the bitstream filters in the chain. > >> > >> Signed-off-by: James Almer > >> --- > >> Now it's not going to be called after the codec has been opened. > >> > >> libavcodec/decode.c | 4 > >> 1 file changed, 4 insertions(+) > > > > This breaks: > > ffmpeg -i > > https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png > > -bitexact -pix_fmt rgba -f framecrc - > > Is any other decoder failing the same way? Because the apng decoder > threading code may be faulty otherwise. Plenty of avctx fields are > changed after ff_thread_init() is called within avcodec_open2(). There > should not be a race at this point. > >>> > >>> I found a failure with mpeg4 (with bframes) decoding + pcm_alaw from mkv > >>> but it > >>> does not want to reproduce. The slightest change i do makes this not > >>> happen > >>> even just duplicating a command line parameter (which should have no > >>> effect) > >>> simply adding the -threads parameter to it independant of value makes it > >>> go away > >>> too > >>> > >>> > >>> in the png case > >>> this hits teh issue: > >>> -threads 2 -i > >>> https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png > >>> -f framecrc - > >>> > >>> this does not: > >>> -threads 1 -i > >>> https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png > >>> -f framecrc - > >>> > >>> also odly the bitexact flag made a differnce in how it fails outside > >>> valgrind > >>> last i tried. (doesnt make a difference in valgrind it seems) > >> > >> A solution may be moving the ff_decode_bsfs_init call in patch 7/8 right > >> above the call to ff_thread_init (See attachment), hopefully preventing > >> this race once this patch is applied afterwards, but it will result in > >> the bsfs initialized before the decoder, and some of the avctx fields > >> that are changed later in avcodec_open2 like channels and bit_rate not > >> being reflected during said bsfs initialization. > >> I can't say if the former is correct or ideal, but for now the latter > >> would not be an issue. I don't know what may happen if we were to > >> autoinsert a filter that does care about such fields in the future, though. > >> > >> If the above change doesn't solve it, or is not ideal, then this patch > >> 8/8 can be dropped or postponed, and the rest of the set pushed without it. > > > > with this patch, the pachset seems not to trigger these errors anymore > > > > thanks > > Set pushed. Thanks. > Just so you know, f631c328e680a3dd491936b92f69970c20cdcfc7 causes Firefox's media playback thread to crash. Just try playing any local or remote mp4 file. The crash is reproducible. Tested and bisected with FF Developer Edition (64-bit linux). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Optimize libavformat/metadata.c
On Fri, 20 Jul 2018 14:31:55 +0300 Shlomi Fish wrote: > On Wed, 11 Jul 2018 19:42:09 +0300 > Shlomi Fish wrote: > > > On Wed, 4 Jul 2018 23:10:46 +0300 > > Shlomi Fish wrote: > > > > Ping! Can this patch be reviewed please? > > > > Ping! bump / ping. -- - Shlomi Fish http://www.shlomifish.org/ My Aphorisms - http://www.shlomifish.org/humour.html Tomorrow never dies, unless Chuck Norris volunteers to take it out of its misery. — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ Please reply to list if it's a mailing list post - http://shlom.in/reply . ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/cfhd: Drop an unused function
On Thu, Aug 23, 2018 at 7:33 PM Paul B Mahol wrote: > On 8/23/18, Carl Eugen Hoyos wrote: > > Hi! > > > > Attached patch removes an unused function from cfhd.c. > > > > Please comment, Carl Eugen > > > > Not acceptable. Function is needed, but was dropped due programmer's error. > I just noticed. Will add it back in the updated patch that i will work on saturday. Thanks. Gagandeep Singh > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Register for VDD 2018 conference
On Wed, 22 Aug 2018 at 20:12, Michael Niedermayer wrote: > On Wed, Aug 22, 2018 at 03:14:53PM +0200, Jean-Baptiste Kempf wrote: > > Hello fellow devs, > > > > VideoLAN is happy to invite you to the usual conference of the end of > the summer: > > VDD2018 is happening in Paris, for the 10 years of the original conf. > > > > As usual, this is a very technical conference focused on open source > multimedia development. > > We will talk about AV1, FFv1, FFv2, x264/x265, VLC, FFmpeg and other > related technologies. > > what is FFv2 ? > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Observe your enemies, for they first find out your faults. -- Antisthenes > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I'm working on it https://github.com/atomnuker/FFmpeg/tree/exp_ffv2_daala ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 26/41] lavc/h264: Add common code for level handling
On 8/22/2018 8:44 PM, Mark Thompson wrote: > Including a unit test. > --- > libavcodec/Makefile| 3 +- > libavcodec/h264_levels.c | 130 +++ > libavcodec/h264_levels.h | 53 ++ > libavcodec/tests/.gitignore| 1 + > libavcodec/tests/h264_levels.c | 183 + > tests/fate/libavcodec.mak | 5 + > 6 files changed, 374 insertions(+), 1 deletion(-) > create mode 100644 libavcodec/h264_levels.c > create mode 100644 libavcodec/h264_levels.h > create mode 100644 libavcodec/tests/h264_levels.c > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > index cbbfc9af2e..d07a9073af 100644 > --- a/libavcodec/Makefile > +++ b/libavcodec/Makefile > @@ -355,7 +355,7 @@ OBJS-$(CONFIG_H264_OMX_ENCODER)+= omx.o > OBJS-$(CONFIG_H264_QSV_DECODER)+= qsvdec_h2645.o > OBJS-$(CONFIG_H264_QSV_ENCODER)+= qsvenc_h264.o > OBJS-$(CONFIG_H264_RKMPP_DECODER) += rkmppdec.o > -OBJS-$(CONFIG_H264_VAAPI_ENCODER) += vaapi_encode_h264.o > +OBJS-$(CONFIG_H264_VAAPI_ENCODER) += h264_levels.o vaapi_encode_h264.o > OBJS-$(CONFIG_H264_VIDEOTOOLBOX_ENCODER) += videotoolboxenc.o > OBJS-$(CONFIG_H264_V4L2M2M_DECODER)+= v4l2_m2m_dec.o > OBJS-$(CONFIG_H264_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o > @@ -1134,6 +1134,7 @@ TESTPROGS-$(CONFIG_IDCTDSP) += dct > TESTPROGS-$(CONFIG_IIRFILTER) += iirfilter > TESTPROGS-$(HAVE_MMX) += motion > TESTPROGS-$(CONFIG_MPEGVIDEO) += mpeg12framerate > +TESTPROGS-$(CONFIG_H264_VAAPI_ENCODER)+= h264_levels Needing h264_vaapi_encoder to test this is not ideal. You'd be limiting the amount of fate clients testing an internal module to those with an unrelated external encoder enabled. Maybe just add h264_levels.o to h264parse, and check for that instead? Alternatively, since you need to add that object to h264_metadata to fix the build failure Michael reported for patch 28, you could check for that bsf instead. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 28/41] h264_metadata: Add option to set the level of the stream
On Thu, Aug 23, 2018 at 12:45:01AM +0100, Mark Thompson wrote: > --- > doc/bitstream_filters.texi | 9 > libavcodec/h264_metadata_bsf.c | 90 ++ > 2 files changed, 99 insertions(+) fails to build on mingw64 libavcodec/h264_metadata_bsf.c:243: undefined reference to `ff_h264_guess_level' libavcodec/h264_metadata_bsf.c:243:(.text+0x36c): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `ff_h264_guess_level' [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
On 8/23/18, Carl Eugen Hoyos wrote: > 2018-08-23 16:00 GMT+02:00, Paul B Mahol : >> On 8/23/18, Carl Eugen Hoyos wrote: >>> 2018-08-23 15:35 GMT+02:00, Carl Eugen Hoyos : 2018-08-23 15:08 GMT+02:00, Paul B Mahol : > From 100x real-time decoding to 138x real-time decoding for 320x240 > video. On x86_64 I get an even better improvement, on x86_32 decoding gets slower by approximately 10%. Without the patch, decoding is faster on x86_32 than x86_64 here... >>> >>> Using vanilla gcc-6.4. >>> >>> clang 3.4: >>> 5% slower with patch on x86_32 40% faster with patch on x86_64 >>> x86_32 again faster than x86_64 without patch. >> >> x86_32 is going to be less and less used. > > Is there a reason why we cannot use > the change in the x86_64 case (and others that we > show to be faster) but not for x86_32? The define could be only enabled for x86_64. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Tools: drop hard dependency on python2
On Thu, Aug 23, 2018 at 11:54:25AM +0200, Mayeul Cantan wrote:
> Some tools had an artificial dependency on python2: zmqshell.py and
> normalize.py
>
> This patch changes the requested environment to a generic "python",
> and add parenthesis to the "print" calls. 2to3 shows no other
> modifications are needed, so I expect this to be okay.
>
> Please note that this was untested.
>
> ---
> tools/normalize.py | 13 +++--
> tools/zmqshell.py | 7 ---
> 2 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/tools/normalize.py b/tools/normalize.py
> index 7d87c5e154..a550d06906 100755
> --- a/tools/normalize.py
> +++ b/tools/normalize.py
> @@ -1,4 +1,5 @@
> -#!/usr/bin/env python2
> +#!/usr/bin/env python
> +# This script is compatible both with python 2 and 3; please keep it so
>
> import sys, subprocess
>
> @@ -7,7 +8,7 @@ if len(sys.argv) > 2:
> encopt = sys.argv[2:-1]
> ofile = sys.argv[-1]
> else:
> -print 'usage: %s [encode_options] ' % sys.argv[0]
> +print('usage: %s [encode_options] ' % sys.argv[0])
> sys.exit(1)
>
> analysis_cmd = 'ffprobe -v error -of compact=p=0:nk=1 '
> @@ -15,7 +16,7 @@ analysis_cmd += '-show_entries
> frame_tags=lavfi.r128.I -f lavfi '
this patch looks corrupted by newlines
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
2018-08-23 16:00 GMT+02:00, Paul B Mahol : > On 8/23/18, Carl Eugen Hoyos wrote: >> 2018-08-23 15:35 GMT+02:00, Carl Eugen Hoyos : >>> 2018-08-23 15:08 GMT+02:00, Paul B Mahol : From 100x real-time decoding to 138x real-time decoding for 320x240 video. >>> >>> On x86_64 I get an even better improvement, on x86_32 >>> decoding gets slower by approximately 10%. >>> Without the patch, decoding is faster on x86_32 than >>> x86_64 here... >> >> Using vanilla gcc-6.4. >> >> clang 3.4: >> 5% slower with patch on x86_32 >>>40% faster with patch on x86_64 >> x86_32 again faster than x86_64 without patch. > > x86_32 is going to be less and less used. Is there a reason why we cannot use the change in the x86_64 case (and others that we show to be faster) but not for x86_32? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/cfhd: Drop an unused function
On 8/23/18, Carl Eugen Hoyos wrote: > Hi! > > Attached patch removes an unused function from cfhd.c. > > Please comment, Carl Eugen > Not acceptable. Function is needed, but was dropped due programmer's error. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
On 8/23/18, Carl Eugen Hoyos wrote: > 2018-08-23 15:35 GMT+02:00, Carl Eugen Hoyos : >> 2018-08-23 15:08 GMT+02:00, Paul B Mahol : >>> From 100x real-time decoding to 138x real-time decoding for 320x240 >>> video. >> >> On x86_64 I get an even better improvement, on x86_32 >> decoding gets slower by approximately 10%. >> Without the patch, decoding is faster on x86_32 than >> x86_64 here... > > Using vanilla gcc-6.4. > > clang 3.4: > 5% slower with patch on x86_32 >>40% faster with patch on x86_64 > x86_32 again faster than x86_64 without patch. x86_32 is going to be less and less used. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/cfhd: Drop an unused function
Hi!
Attached patch removes an unused function from cfhd.c.
Please comment, Carl Eugen
From 191c7baea8b820d07bbcf1ddb50ffcff8f6c6a08 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 23 Aug 2018 15:56:06 +0200
Subject: [PATCH] lavc/cfhd: Remove an unused function.
---
libavcodec/cfhd.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 846d334..616f5af 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -136,20 +136,6 @@ static inline void peak_table(int16_t *band, Peak *peak, int length)
band[i] = bytestream2_get_le16(&peak->base);
}
-static inline void process_alpha(int16_t *alpha, int width)
-{
-int i, channel;
-for (i = 0; i < width; i++) {
-channel = alpha[i];
-channel -= ALPHA_COMPAND_DC_OFFSET;
-channel <<= 3;
-channel *= ALPHA_COMPAND_GAIN;
-channel >>= 16;
-channel = av_clip_uintp2(channel, 12);
-alpha[i] = channel;
-}
-}
-
static inline void filter(int16_t *output, ptrdiff_t out_stride,
int16_t *low, ptrdiff_t low_stride,
int16_t *high, ptrdiff_t high_stride,
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
2018-08-23 15:35 GMT+02:00, Carl Eugen Hoyos : > 2018-08-23 15:08 GMT+02:00, Paul B Mahol : >> From 100x real-time decoding to 138x real-time decoding for 320x240 >> video. > > On x86_64 I get an even better improvement, on x86_32 > decoding gets slower by approximately 10%. > Without the patch, decoding is faster on x86_32 than > x86_64 here... Using vanilla gcc-6.4. clang 3.4: 5% slower with patch on x86_32 >40% faster with patch on x86_64 x86_32 again faster than x86_64 without patch. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
Paul B Mahol wrote: >Byte Order: Little Endian I will check the mixed endian on my PDP-11 ;-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
2018-08-23 15:35 GMT+02:00, Paul B Mahol : > On 8/23/18, James Almer wrote: >> On 8/23/2018 10:24 AM, Paul B Mahol wrote: >>> On 8/23/18, Carl Eugen Hoyos wrote: 2018-08-23 15:21 GMT+02:00, Paul B Mahol : > On 8/23/18, Carl Eugen Hoyos wrote: >> 2018-08-23 15:08 GMT+02:00, Paul B Mahol : >>> From 100x real-time decoding to 138x real-time decoding for 320x240 >>> video. >> >> On which hardware did you test? > > That is highly confidental info. In that case this patch is not ok. >>> >>> Ugh, can you explain why? >> >> Christ, just say what CPU you used already. > > When you insist! > > Architecture:x86_64 > CPU op-mode(s): 32-bit, 64-bit Sorry if you disagree but this is not a useful answer: The important question is (actually was, now that I confirmed what was claimed earlier) if you compiled for 32 or 64 bit. Yes, my original question wasn't much better: Sorry about it! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
2018-08-23 15:08 GMT+02:00, Paul B Mahol : > From 100x real-time decoding to 138x real-time decoding for 320x240 video. On x86_64 I get an even better improvement, on x86_32 decoding gets slower by approximately 10%. Without the patch, decoding is faster on x86_32 than x86_64 here... Testfile produced with: $ ffmpeg -f lavfi -i testsrc=s=320x240 -vcodec utvideo -vframes 1 out.avi Same question I thought of when this patch was originally dropped: Is there any problem with using the new reader on some targets but not others? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
On 8/23/18, James Almer wrote: > On 8/23/2018 10:24 AM, Paul B Mahol wrote: >> On 8/23/18, Carl Eugen Hoyos wrote: >>> 2018-08-23 15:21 GMT+02:00, Paul B Mahol : On 8/23/18, Carl Eugen Hoyos wrote: > 2018-08-23 15:08 GMT+02:00, Paul B Mahol : >> From 100x real-time decoding to 138x real-time decoding for 320x240 >> video. > > On which hardware did you test? That is highly confidental info. >>> >>> In that case this patch is not ok. >> >> Ugh, can you explain why? > > Christ, just say what CPU you used already. When you insist! Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 61 Model name: Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz Stepping:4 CPU MHz: 1895.954 CPU max MHz: 1900, CPU min MHz: 500, BogoMIPS:3990.53 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache:256K L3 cache:3072K NUMA node0 CPU(s): 0-3 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap intel_pt xsaveopt dtherm arat pln pts ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
2018-08-23 15:25 GMT+02:00, Nicolas George : > Paul B Mahol (2018-08-23): >> Ugh, can you explain why? > > Need provable claims. What I meant was just that I would prefer to only test on other platforms... Not that it wouldn't make sense to add the tested platform to the commit message though. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
On 8/23/2018 10:24 AM, Paul B Mahol wrote: > On 8/23/18, Carl Eugen Hoyos wrote: >> 2018-08-23 15:21 GMT+02:00, Paul B Mahol : >>> On 8/23/18, Carl Eugen Hoyos wrote: 2018-08-23 15:08 GMT+02:00, Paul B Mahol : > From 100x real-time decoding to 138x real-time decoding for 320x240 > video. On which hardware did you test? >>> >>> That is highly confidental info. >> >> In that case this patch is not ok. > > Ugh, can you explain why? Christ, just say what CPU you used already. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
Paul B Mahol (2018-08-23): > Try it yourself Your patch. Still not ok. -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
On 8/23/18, Nicolas George wrote: > Paul B Mahol (2018-08-23): >> Ugh, can you explain why? > > Need provable claims. Try it yourself, that is only way you will prove it to self. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
Paul B Mahol (2018-08-23): > Ugh, can you explain why? Need provable claims. -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
On 8/23/18, Carl Eugen Hoyos wrote: > 2018-08-23 15:21 GMT+02:00, Paul B Mahol : >> On 8/23/18, Carl Eugen Hoyos wrote: >>> 2018-08-23 15:08 GMT+02:00, Paul B Mahol : From 100x real-time decoding to 138x real-time decoding for 320x240 video. >>> >>> On which hardware did you test? >> >> That is highly confidental info. > > In that case this patch is not ok. Ugh, can you explain why? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
2018-08-23 15:21 GMT+02:00, Paul B Mahol : > On 8/23/18, Carl Eugen Hoyos wrote: >> 2018-08-23 15:08 GMT+02:00, Paul B Mahol : >>> From 100x real-time decoding to 138x real-time decoding for 320x240 >>> video. >> >> On which hardware did you test? > > That is highly confidental info. In that case this patch is not ok. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
On 8/23/18, Carl Eugen Hoyos wrote: > 2018-08-23 15:08 GMT+02:00, Paul B Mahol : >> From 100x real-time decoding to 138x real-time decoding for 320x240 video. > > On which hardware did you test? That is highly confidental info. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
2018-08-23 15:08 GMT+02:00, Paul B Mahol : > From 100x real-time decoding to 138x real-time decoding for 320x240 video. On which hardware did you test? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avcodec/get_bits: add cached bitstream reader
Signed-off-by: Paul B Mahol
---
libavcodec/get_bits.h | 218 +-
libavcodec/golomb.h | 151 +
2 files changed, 367 insertions(+), 2 deletions(-)
diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index 56ef5f0cbe..58ebb64656 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -1,5 +1,6 @@
/*
- * copyright (c) 2004 Michael Niedermayer
+ * Copyright (c) 2004 Michael Niedermayer
+ * Copyright (c) 2016 Alexandra Hájková
*
* This file is part of FFmpeg.
*
@@ -55,11 +56,19 @@
typedef struct GetBitContext {
const uint8_t *buffer, *buffer_end;
+#ifdef CACHED_BITSTREAM_READER
+uint64_t cache;
+unsigned bits_left;
+#endif
int index;
int size_in_bits;
int size_in_bits_plus8;
} GetBitContext;
+static inline unsigned int get_bits(GetBitContext *s, int n);
+static inline void skip_bits(GetBitContext *s, int n);
+static inline unsigned int show_bits(GetBitContext *s, int n);
+
/* Bitstream reader API docs:
* name
* arbitrary name which is used as prefix for the internal variables
@@ -107,12 +116,16 @@ typedef struct GetBitContext {
* For examples see get_bits, show_bits, skip_bits, get_vlc.
*/
-#ifdef LONG_BITSTREAM_READER
+#ifdef CACHED_BITSTREAM_READER
+# define MIN_CACHE_BITS 64
+#elif defined LONG_BITSTREAM_READER
# define MIN_CACHE_BITS 32
#else
# define MIN_CACHE_BITS 25
#endif
+#ifndef CACHED_BITSTREAM_READER
+
#define OPEN_READER_NOSIZE(name, gb)\
unsigned int name ## _index = (gb)->index; \
unsigned int av_unused name ## _cache
@@ -197,11 +210,75 @@ typedef struct GetBitContext {
#define GET_CACHE(name, gb) ((uint32_t) name ## _cache)
+#endif
+
static inline int get_bits_count(const GetBitContext *s)
{
+#ifdef CACHED_BITSTREAM_READER
+return s->index - s->bits_left;
+#else
return s->index;
+#endif
+}
+
+#ifdef CACHED_BITSTREAM_READER
+static inline void refill_32(GetBitContext *s)
+{
+#if !UNCHECKED_BITSTREAM_READER
+if (s->index >> 3 >= s->buffer_end - s->buffer)
+return;
+#endif
+
+#ifdef BITSTREAM_READER_LE
+s->cache = (uint64_t)AV_RL32(s->buffer + (s->index >> 3)) <<
s->bits_left | s->cache;
+#else
+s->cache = s->cache | (uint64_t)AV_RB32(s->buffer + (s->index >> 3))
<< (32 - s->bits_left);
+#endif
+s->index += 32;
+s->bits_left += 32;
}
+static inline void refill_64(GetBitContext *s)
+{
+#if !UNCHECKED_BITSTREAM_READER
+if (s->index >> 3 >= s->buffer_end - s->buffer)
+return;
+#endif
+
+#ifdef BITSTREAM_READER_LE
+s->cache = AV_RL64(s->buffer + (s->index >> 3));
+#else
+s->cache = AV_RB64(s->buffer + (s->index >> 3));
+#endif
+s->index += 64;
+s->bits_left = 64;
+}
+
+static inline uint64_t get_val(GetBitContext *s, unsigned n, int is_le)
+{
+uint64_t ret;
+av_assert2(n>0 && n<=63);
+if (is_le) {
+ret = s->cache & ((UINT64_C(1) << n) - 1);
+s->cache >>= n;
+} else {
+ret = s->cache >> (64 - n);
+s->cache <<= n;
+}
+s->bits_left -= n;
+return ret;
+}
+
+static inline unsigned show_val(const GetBitContext *s, unsigned n)
+{
+#ifdef BITSTREAM_READER_LE
+return s->cache & ((UINT64_C(1) << n) - 1);
+#else
+return s->cache >> (64 - n);
+#endif
+}
+#endif
+
/**
* Skips the specified number of bits.
* @param n the number of bits to skip,
@@ -211,13 +288,29 @@ static inline int get_bits_count(const GetBitContext *s)
*/
static inline void skip_bits_long(GetBitContext *s, int n)
{
+#ifdef CACHED_BITSTREAM_READER
+skip_bits(s, n);
+#else
#if UNCHECKED_BITSTREAM_READER
s->index += n;
#else
s->index += av_clip(n, -s->index, s->size_in_bits_plus8 - s->index);
#endif
+#endif
}
+#ifdef CACHED_BITSTREAM_READER
+static inline void skip_remaining(GetBitContext *s, unsigned n)
+{
+#ifdef BITSTREAM_READER_LE
+s->cache >>= n;
+#else
+s->cache <<= n;
+#endif
+s->bits_left -= n;
+}
+#endif
+
/**
* Read MPEG-1 dc-style VLC (sign bit + mantissa with no MSB).
* if MSB not set it is negative
@@ -225,6 +318,13 @@ static inline void skip_bits_long(GetBitContext *s, int n)
*/
static inline int get_xbits(GetBitContext *s, int n)
{
+#ifdef CACHED_BITSTREAM_READER
+int32_t cache = show_bits(s, 32);
+int sign = ~cache >> 31;
+skip_remaining(s, n);
+
+return uint32_t)(sign ^ cache)) >> (32 - n)) ^ sign) - sign;
+#else
register int sign;
register int32_t cache;
OPEN_READER(re, s);
@@ -235,8 +335,10 @@ static inline int get_xbits(GetBitContext *s, int n)
LAST_SKIP_BITS(re, s, n);
CLOSE_READER(re, s);
return (NEG_USR32(sign ^ cache, n) ^ sign) - sign;
+#endif
}
+#ifndef CACHED_BITSTREAM_READER
static inline int get_xbits_le(GetBitContext *s, int n)
{
register int sign;
@@ -250,16 +352,22 @@ static inline int get_xbits_le(GetBitContext *s, int n)
CLOSE_READER(re, s);
return (zero_extend(si
[FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader
From 100x real-time decoding to 138x real-time decoding for 320x240 video. Signed-off-by: Paul B Mahol --- libavcodec/utvideodec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c index 82cb038ccd..99b37aa0f3 100644 --- a/libavcodec/utvideodec.c +++ b/libavcodec/utvideodec.c @@ -27,6 +27,7 @@ #include #include +#define CACHED_BITSTREAM_READER #define UNCHECKED_BITSTREAM_READER 1 #include "libavutil/intreadwrite.h" -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] doc/libav-merge: bitstream reader is now merged
Signed-off-by: Paul B Mahol --- doc/libav-merge.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt index 8c182ae78d..d5e671ca55 100644 --- a/doc/libav-merge.txt +++ b/doc/libav-merge.txt @@ -95,7 +95,6 @@ Stuff that didn't reach the codebase: - 0cef06df0 checkasm: add HEVC MC tests - e7078e842 hevcdsp: add x86 SIMD for MC - 7993ec19a hevc: Add hevc_get_pixel_4/8/12/16/24/32/48/64 -- new bitstream reader (see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html) - use av_cpu_max_align() instead of hardcoding alignment requirements (see https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215834.html) - f44ec22e0 lavc: use av_cpu_max_align() instead of hardcoding alignment requirements - 4de220d2e frame: allow align=0 (meaning automatic) for av_frame_get_buffer() -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V2] examples/vaapi_dec_scaling: add a vaapi decoding/scaling sample
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
diff --git a/configure b/configure
index 9b5421d..77ed4bf 100755
--- a/configure
+++ b/configure
@@ -1612,6 +1612,7 @@ EXAMPLE_LIST="
scaling_video_example
transcode_aac_example
transcoding_example
+vaapi_dec_scaling_example
vaapi_encode_example
vaapi_transcode_example
"
@@ -3461,6 +3462,7 @@ resampling_audio_example_deps="avutil swresample"
scaling_video_example_deps="avutil swscale"
transcode_aac_example_deps="avcodec avformat swresample"
transcoding_example_deps="avfilter avcodec avformat avutil"
+vaapi_dec_scaling_example_deps="avfilter avcodec avformat avutil"
vaapi_encode_example_deps="avcodec avutil h264_vaapi_encoder"
vaapi_transcode_example_deps="avcodec avformat avutil h264_vaapi_encoder"
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 928ff30..3ea6899 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -19,6 +19,7 @@ EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE) +=
resampling_audio
EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE) += transcoding
+EXAMPLES-$(CONFIG_VAAPI_DEC_SCALING_EXAMPLE) += vaapi_dec_scaling
EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE) += vaapi_encode
EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE) += vaapi_transcode
diff --git a/doc/examples/vaapi_dec_scaling.c b/doc/examples/vaapi_dec_scaling.c
new file mode 100644
index 000..30aa163
--- /dev/null
+++ b/doc/examples/vaapi_dec_scaling.c
@@ -0,0 +1,377 @@
+/*
+ * Copyright (c) 2018 Jun Zhao
+ *
+ * VA-API Acceleration API (video decoding/scaling) sample
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * @file
+ * VA-API-Accelerated decoding/scaling example.
+ *
+ * @example vaapi_dec_scaling.c
+ * This example shows how to do VA-API-accelerated decoding/scaling with output
+ * frames from the HW video surfaces.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static AVBufferRef *hw_device_ctx = NULL;
+static enum AVPixelFormat hw_pix_fmt;
+static FILE *output_file = NULL;
+AVFilterContext *buffersink_ctx;
+AVFilterContext *buffersrc_ctx;
+AVFilterGraph *filter_graph;
+const char *filter_descr =
+"format=vaapi,scale_vaapi=w=iw/2:h=ih/2,hwdownload,format=nv12";
+int init_filter = 0;
+
+static int init_hw_decode(AVCodecContext *ctx, const enum AVHWDeviceType type)
+{
+int err = 0;
+
+if ((err = av_hwdevice_ctx_create(&hw_device_ctx, type,
+ NULL, NULL, 0)) < 0) {
+fprintf(stderr, "Failed to create specified HW device.\n");
+return err;
+}
+ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
+
+return err;
+}
+
+static int init_filters(AVFormatContext *fmt_ctx, AVCodecContext *dec_ctx,
+int video_stream_index, const char *filters_descr)
+{
+char args[512];
+int ret = 0;
+const AVFilter *buffersrc = avfilter_get_by_name("buffer");
+const AVFilter *buffersink = avfilter_get_by_name("buffersink");
+AVFilterInOut *outputs = avfilter_inout_alloc();
+AVFilterInOut *inputs = avfilter_inout_alloc();
+AVRational time_base = fmt_ctx->streams[video_stream_index]->time_base;
+AVBufferSrcParameters *par = av_buffersrc_parameters_alloc();
+
+filter_graph = avfilter_graph_alloc();
+if (!outputs || !inputs || !filter_graph || !par) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
+
+/* buffer video source: the decoded frames from the decoder will be
insert
Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder
On 8/23/18, Carl Eugen Hoyos wrote:
> 2018-08-23 14:51 GMT+02:00, Paul B Mahol :
>> On 8/23/18, Carl Eugen Hoyos wrote:
>>> 2018-08-23 14:29 GMT+02:00, Paul B Mahol :
On 8/23/18, Carl Eugen Hoyos wrote:
> 2018-08-23 11:11 GMT+02:00, Paul B Mahol :
>> On 8/23/18, Carl Eugen Hoyos wrote:
>>> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
On 8/22/18, Carl Eugen Hoyos wrote:
> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>
>> +switch (avctx->bits_per_coded_sample) {
>> +case 12:
>> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>> + break;
>> +default:
>> + return AVERROR_INVALIDDATA;
>> +}
>
> Why are the condition and the error needed?
Because only that is supported.
>>>
>>> Do valid samples with other values exist?
>>
>> No.
>
> Then I suggest to make the whole block above just:
> s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
Nope, bits per coded sample must be checked.
>>>
>>> Could you explain why?
>>
>> Reference decoder checks it, so do we.
>
> Shouldn't we try to decode files if at all possible?
Nope.
>
>>> Am I correct that no other decoder does that?
>>
>> Nope.
>
> Which decoder does it?
>
Utvideo, magicyuv, y41p...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder
2018-08-23 14:51 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos wrote:
>> 2018-08-23 14:29 GMT+02:00, Paul B Mahol :
>>> On 8/23/18, Carl Eugen Hoyos wrote:
2018-08-23 11:11 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos wrote:
>> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
>>> On 8/22/18, Carl Eugen Hoyos wrote:
2018-08-22 18:00 GMT+02:00, Paul B Mahol :
> +switch (avctx->bits_per_coded_sample) {
> +case 12:
> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
> + break;
> +default:
> + return AVERROR_INVALIDDATA;
> +}
Why are the condition and the error needed?
>>>
>>> Because only that is supported.
>>
>> Do valid samples with other values exist?
>
> No.
Then I suggest to make the whole block above just:
s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>>>
>>> Nope, bits per coded sample must be checked.
>>
>> Could you explain why?
>
> Reference decoder checks it, so do we.
Shouldn't we try to decode files if at all possible?
>> Am I correct that no other decoder does that?
>
> Nope.
Which decoder does it?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder
On 8/23/18, Carl Eugen Hoyos wrote:
> 2018-08-23 14:29 GMT+02:00, Paul B Mahol :
>> On 8/23/18, Carl Eugen Hoyos wrote:
>>> 2018-08-23 11:11 GMT+02:00, Paul B Mahol :
On 8/23/18, Carl Eugen Hoyos wrote:
> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
>> On 8/22/18, Carl Eugen Hoyos wrote:
>>> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>>>
+switch (avctx->bits_per_coded_sample) {
+case 12:
+ s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
+ break;
+default:
+ return AVERROR_INVALIDDATA;
+}
>>>
>>> Why are the condition and the error needed?
>>
>> Because only that is supported.
>
> Do valid samples with other values exist?
No.
>>>
>>> Then I suggest to make the whole block above just:
>>> s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>>
>> Nope, bits per coded sample must be checked.
>
> Could you explain why?
Reference decoder checks it, so do we.
>
> Am I correct that no other decoder does that?
Nope.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder
2018-08-23 14:29 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos wrote:
>> 2018-08-23 11:11 GMT+02:00, Paul B Mahol :
>>> On 8/23/18, Carl Eugen Hoyos wrote:
2018-08-22 21:24 GMT+02:00, Paul B Mahol :
> On 8/22/18, Carl Eugen Hoyos wrote:
>> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>>
>>> +switch (avctx->bits_per_coded_sample) {
>>> +case 12:
>>> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>>> + break;
>>> +default:
>>> + return AVERROR_INVALIDDATA;
>>> +}
>>
>> Why are the condition and the error needed?
>
> Because only that is supported.
Do valid samples with other values exist?
>>>
>>> No.
>>
>> Then I suggest to make the whole block above just:
>> s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>
> Nope, bits per coded sample must be checked.
Could you explain why?
Am I correct that no other decoder does that?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder
On 8/23/18, Carl Eugen Hoyos wrote:
> 2018-08-23 11:11 GMT+02:00, Paul B Mahol :
>> On 8/23/18, Carl Eugen Hoyos wrote:
>>> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
On 8/22/18, Carl Eugen Hoyos wrote:
> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>
>> +switch (avctx->bits_per_coded_sample) {
>> +case 12:
>> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>> + break;
>> +default:
>> + return AVERROR_INVALIDDATA;
>> +}
>
> Why are the condition and the error needed?
Because only that is supported.
>>>
>>> Do valid samples with other values exist?
>>
>> No.
>
> Then I suggest to make the whole block above just:
> s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
Nope, bits per coded sample must be checked.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder
2018-08-23 11:11 GMT+02:00, Paul B Mahol :
> On 8/23/18, Carl Eugen Hoyos wrote:
>> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
>>> On 8/22/18, Carl Eugen Hoyos wrote:
2018-08-22 18:00 GMT+02:00, Paul B Mahol :
> +switch (avctx->bits_per_coded_sample) {
> +case 12:
> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
> + break;
> +default:
> + return AVERROR_INVALIDDATA;
> +}
Why are the condition and the error needed?
>>>
>>> Because only that is supported.
>>
>> Do valid samples with other values exist?
>
> No.
Then I suggest to make the whole block above just:
s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder
On 8/23/18, Michael Niedermayer wrote: > On Wed, Aug 22, 2018 at 06:00:54PM +0200, Paul B Mahol wrote: >> Signed-off-by: Paul B Mahol >> --- >> libavcodec/Makefile | 1 + >> libavcodec/allcodecs.c | 1 + >> libavcodec/avcodec.h| 1 + >> libavcodec/codec_desc.c | 7 + >> libavcodec/prosumer.c | 405 >> libavformat/riff.c | 1 + >> 6 files changed, 416 insertions(+) >> create mode 100644 libavcodec/prosumer.c >> [...] >> +} >> +pos = bytestream2_tell(gb) ^ 2; >> +bytestream2_seek(gb, pos, SEEK_SET); >> +AV_WN16(&a, bytestream2_peek_le16(gb)); >> +pos = pos ^ 2; >> +bytestream2_seek(gb, pos, SEEK_SET); >> +bytestream2_skip(gb, 2); >> +cnt = 4; >> +idx--; >> +} > >> +b = PAIR(4, a) >> 16; > > I think this assumes sizeof(int) == 4, this is not guranteed it could be 8 Fixed locally. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Correct opus-in-mp4 pre-skip to be uint16_t versus int16_t.
On Wed, Aug 22, 2018 at 12:58:13AM -0300, James Almer wrote: > On 8/21/2018 7:45 PM, Dale Curtis wrote: > > This field is a uint16_t, see docs: > > http://opus-codec.org/docs/opus_in_isobmff.html#4.3.2 > > > > Signed-off-by: Dale Curtis > > > > > > 0001-Correct-opus-in-mp4-pre-skip-to-be-uint16_t-versus-i.patch > > > > > > From 7f1588bc92ef4a70025aa140a8e660a36875c89c Mon Sep 17 00:00:00 2001 > > From: Dale Curtis > > Date: Tue, 21 Aug 2018 15:42:31 -0700 > > Subject: [PATCH] Correct opus-in-mp4 pre-skip to be uint16_t versus int16_t. > > > > This field is a uint16_t, see docs: > > http://opus-codec.org/docs/opus_in_isobmff.html#4.3.2 > > > > Signed-off-by: Dale Curtis > > --- > > libavformat/mov.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavformat/mov.c b/libavformat/mov.c > > index 1bd7d7e483..02f6c1e0a1 100644 > > --- a/libavformat/mov.c > > +++ b/libavformat/mov.c > > @@ -6608,7 +6608,7 @@ static int mov_read_dops(MOVContext *c, AVIOContext > > *pb, MOVAtom atom) > > const int OPUS_SEEK_PREROLL_MS = 80; > > AVStream *st; > > size_t size; > > -int16_t pre_skip; > > +uint16_t pre_skip; > > > > if (c->fc->nb_streams < 1) > > return 0; > > -- 2.18.0.1017.ga543ac7ca45-goog > > Should be ok. will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add lut1d filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 31 +++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_lut3d.c | 438 +++
4 files changed, 471 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 32c95b591c..37e79d34e1 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10962,6 +10962,37 @@ Set maximal size in number of frames. Default is 0.
Set first frame of loop. Default is 0.
@end table
+@section lut1d
+
+Apply a 1D LUT to an input video.
+
+The filter accepts the following options:
+
+@table @option
+@item file
+Set the 1D LUT file name.
+
+Currently supported formats:
+@table @samp
+@item cube
+Iridas
+@end table
+
+@item interp
+Select interpolation mode.
+
+Available values are:
+
+@table @samp
+@item nearest
+Use values from the nearest defined point.
+@item linear
+Interpolate values using the linear interpolation.
+@item cubic
+Interpolate values using the cubic interpolation.
+@end table
+@end table
+
@anchor{lut3d}
@section lut3d
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e5d3a57af7..e412000c8f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -258,6 +258,7 @@ OBJS-$(CONFIG_LIBVMAF_FILTER)+=
vf_libvmaf.o framesync.o
OBJS-$(CONFIG_LIMITER_FILTER)+= vf_limiter.o
OBJS-$(CONFIG_LOOP_FILTER) += f_loop.o
OBJS-$(CONFIG_LUMAKEY_FILTER)+= vf_lumakey.o
+OBJS-$(CONFIG_LUT1D_FILTER) += vf_lut3d.o
OBJS-$(CONFIG_LUT_FILTER)+= vf_lut.o
OBJS-$(CONFIG_LUT2_FILTER) += vf_lut2.o framesync.o
OBJS-$(CONFIG_LUT3D_FILTER) += vf_lut3d.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9732ae5345..2fa9460335 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -246,6 +246,7 @@ extern AVFilter ff_vf_limiter;
extern AVFilter ff_vf_loop;
extern AVFilter ff_vf_lumakey;
extern AVFilter ff_vf_lut;
+extern AVFilter ff_vf_lut1d;
extern AVFilter ff_vf_lut2;
extern AVFilter ff_vf_lut3d;
extern AVFilter ff_vf_lutrgb;
diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 27b79b860b..6ec0cad650 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2013 Clément Bœsch
+ * Copyright (c) 2018 Paul B Mahol
*
* This file is part of FFmpeg.
*
@@ -975,3 +976,440 @@ AVFilter ff_vf_haldclut = {
.flags = AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL |
AVFILTER_FLAG_SLICE_THREADS,
};
#endif
+
+#if CONFIG_LUT1D_FILTER
+
+enum interp_1d_mode {
+INTERPOLATE_1D_NEAREST,
+INTERPOLATE_1D_LINEAR,
+INTERPOLATE_1D_CUBIC,
+NB_INTERP_1D_MODE
+};
+
+#define MAX_1D_LEVEL 65536
+
+typedef struct LUT1DContext {
+const AVClass *class;
+char *file;
+int interpolation; ///lutsize = size;
+for (i = 0; i < size; i++) {
+lut1d->lut[0][i] = i * c;
+lut1d->lut[1][i] = i * c;
+lut1d->lut[2][i] = i * c;
+}
+}
+
+static int parse_cube_1d(AVFilterContext *ctx, FILE *f)
+{
+LUT1DContext *lut1d = ctx->priv;
+char line[MAX_LINE_SIZE];
+float min[3] = {0.0, 0.0, 0.0};
+float max[3] = {1.0, 1.0, 1.0};
+
+while (fgets(line, sizeof(line), f)) {
+if (!strncmp(line, "LUT_1D_SIZE ", 12)) {
+const int size = strtol(line + 12, NULL, 0);
+int i;
+
+if (size < 2 || size > MAX_1D_LEVEL) {
+av_log(ctx, AV_LOG_ERROR, "Too large or invalid 1D LUT
size\n");
+return AVERROR(EINVAL);
+}
+lut1d->lutsize = size;
+for (i = 0; i < size; i++) {
+do {
+try_again:
+NEXT_LINE(0);
+if (!strncmp(line, "DOMAIN_", 7)) {
+float *vals = NULL;
+if (!strncmp(line + 7, "MIN ", 4)) vals = min;
+else if (!strncmp(line + 7, "MAX ", 4)) vals = max;
+if (!vals)
+return AVERROR_INVALIDDATA;
+sscanf(line + 11, "%f %f %f", vals, vals + 1, vals +
2);
+av_log(ctx, AV_LOG_DEBUG, "min: %f %f %f | max: %f %f
%f\n",
+ min[0], min[1], min[2], max[0], max[1], max[2]);
+goto try_again;
+}
+} while (skip_line(line));
+if (sscanf(line, "%f %f %f", &lut1d->lut[0][i],
&lut1d->lut[1][i], &lut1d->lut[2][i]) != 3)
+return AVERROR_INVALIDDATA;
+lut1d->lut[0][i] *= max[0] - min[0];
+lut1d->lut[1][i] *= max[1] - min[1];
+lut1d->lut[2][i] *= max[2] - min[2];
+}
+break;
+}
+}
+return 0;
+}
+
+static const AVOption lut1d_options[] = {
+{ "file", "set 1D LUT file name", OFFSET(fi
Re: [FFmpeg-devel] [PATCH] lavc/extract_extradata_bsf.c: add AVS2
On Tue, Aug 21, 2018 at 09:27:27PM -0300, James Almer wrote:
> On 8/6/2018 10:42 AM, hwren wrote:
> > Signed-off-by: hwren
> > ---
> > libavcodec/extract_extradata_bsf.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/extract_extradata_bsf.c
> > b/libavcodec/extract_extradata_bsf.c
> > index 6deb663..f37427c 100644
> > --- a/libavcodec/extract_extradata_bsf.c
> > +++ b/libavcodec/extract_extradata_bsf.c
> > @@ -331,6 +331,7 @@ static const struct {
> > uint8_t **data, int *size);
> > } extract_tab[] = {
> > { AV_CODEC_ID_AV1,extract_extradata_av1 },
> > +{ AV_CODEC_ID_AVS2, extract_extradata_mpeg4 },
> > { AV_CODEC_ID_CAVS, extract_extradata_mpeg4 },
> > { AV_CODEC_ID_H264, extract_extradata_h2645 },
> > { AV_CODEC_ID_HEVC, extract_extradata_h2645 },
> > @@ -397,6 +398,7 @@ static void extract_extradata_close(AVBSFContext *ctx)
> >
> > static const enum AVCodecID codec_ids[] = {
> > AV_CODEC_ID_AV1,
> > +AV_CODEC_ID_AVS2,
> > AV_CODEC_ID_CAVS,
> > AV_CODEC_ID_H264,
> > AV_CODEC_ID_HEVC,
> >
>
> Should be ok.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
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: add Brooktree ProSumer Video decoder
On Wed, Aug 22, 2018 at 06:00:54PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 +
> libavcodec/prosumer.c | 405
> libavformat/riff.c | 1 +
> 6 files changed, 416 insertions(+)
> create mode 100644 libavcodec/prosumer.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index f0c8226283..9a309c348e 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -515,6 +515,7 @@ OBJS-$(CONFIG_PRORES_DECODER) += proresdec2.o
> proresdsp.o proresdata.o
> OBJS-$(CONFIG_PRORES_ENCODER) += proresenc_anatoliy.o
> OBJS-$(CONFIG_PRORES_AW_ENCODER) += proresenc_anatoliy.o
> OBJS-$(CONFIG_PRORES_KS_ENCODER) += proresenc_kostya.o proresdata.o
> +OBJS-$(CONFIG_PROSUMER_DECODER)+= prosumer.o
> OBJS-$(CONFIG_PSD_DECODER) += psd.o
> OBJS-$(CONFIG_PTX_DECODER) += ptx.o
> OBJS-$(CONFIG_QCELP_DECODER) += qcelpdec.o \
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index fd35fc1d0b..b1d1ef26c0 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -235,6 +235,7 @@ extern AVCodec ff_prores_encoder;
> extern AVCodec ff_prores_decoder;
> extern AVCodec ff_prores_aw_encoder;
> extern AVCodec ff_prores_ks_encoder;
> +extern AVCodec ff_prosumer_decoder;
> extern AVCodec ff_psd_decoder;
> extern AVCodec ff_ptx_decoder;
> extern AVCodec ff_qdraw_decoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 31e50d5a94..2a4be2ca4f 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -448,6 +448,7 @@ enum AVCodecID {
> AV_CODEC_ID_GDV,
> AV_CODEC_ID_FITS,
> AV_CODEC_ID_IMM4,
> +AV_CODEC_ID_PROSUMER,
>
> /* various PCM "codecs" */
> AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
> start of audio codecs
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index af66b35d2b..e611183599 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1661,6 +1661,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .long_name = NULL_IF_CONFIG_SMALL("Infinity IMM4"),
> .props = AV_CODEC_PROP_LOSSY,
> },
> +{
> +.id= AV_CODEC_ID_PROSUMER,
> +.type = AVMEDIA_TYPE_VIDEO,
> +.name = "prosumer",
> +.long_name = NULL_IF_CONFIG_SMALL("Brooktree ProSumer Video"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
> +},
>
> /* various PCM "codecs" */
> {
> diff --git a/libavcodec/prosumer.c b/libavcodec/prosumer.c
> new file mode 100644
> index 00..7b9d5e7bdb
> --- /dev/null
> +++ b/libavcodec/prosumer.c
> @@ -0,0 +1,405 @@
> +/*
> + * Brooktree ProSumer Video decoder
> + * Copyright (c) 2018 Paul B Mahol
> + *
> + * 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 "libavutil/imgutils.h"
> +#include "libavutil/internal.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mem.h"
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +typedef struct ProSumerContext {
> +GetByteContext gb;
> +PutByteContext pb;
> +
> +unsigned stride;
> +unsigned size;
> +unsigned lut[0x1];
> +uint8_t *table_b;
> +uint8_t *decbuffer;
> +} ProSumerContext;
> +
> +#define PAIR(high, low) (((uint64_t)(high)< +
> +static int decompress(GetByteContext *gb, int size, PutByteContext *pb,
> const unsigned *lut)
> +{
> +int i, pos, idx, cnt, fill;
> +unsigned a, b, c;
> +
> +bytestream2_skip(gb, 32);
> +cnt = 4;
> +a = bytestream2_get_le32(gb);
> +idx = a >> 20;
> +b = lut[2 * idx];
> +
> +while (1) {
> +if (((b & 0xFF00u) != 0x8000u) || (b & 0xFFu)) {
> +if ((b & 0xFF00u) != 0x8000u) {
> +bytestream2_put_le16(pb, b);
> +} else if (b & 0xFFu) {
> +idx = 0;
> +for (i = 0; i < (b & 0xFFu); i++)
Re: [FFmpeg-devel] [PATCH] mpeg4video: Add Studio DPCM support
On Wed, Aug 22, 2018 at 12:29:57AM +0100, Kieran Kunhya wrote:
> $subj
>
> Depends on Michael's patch.
> I have a FATE sample frame.
> mpeg4videodec.c | 101
> ++--
> mpegvideo.c | 75 -
> mpegvideo.h |2 +
> 3 files changed, 158 insertions(+), 20 deletions(-)
> 530459506bce209c83f6e3d477c2bbf77cd5d072
> 0001-mpeg4video-Add-Studio-DPCM-support.patch
> From 909fba9afc7edc94a8fd043899ff44c022a32d17 Mon Sep 17 00:00:00 2001
> From: Kieran Kunhya
> Date: Sun, 19 Aug 2018 02:31:42 +0100
> Subject: [PATCH] mpeg4video: Add Studio DPCM support
>
> ---
> libavcodec/mpeg4videodec.c | 101
> +++--
> libavcodec/mpegvideo.c | 75 +
> libavcodec/mpegvideo.h | 2 +
> 3 files changed, 158 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> index 1686ed1001..dda462c2ea 100644
> --- a/libavcodec/mpeg4videodec.c
> +++ b/libavcodec/mpeg4videodec.c
> @@ -24,6 +24,7 @@
>
> #include "libavutil/internal.h"
> #include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
> #include "error_resilience.h"
> #include "hwaccel.h"
> #include "idctdsp.h"
> @@ -36,6 +37,7 @@
> #include "profiles.h"
> #include "thread.h"
> #include "xvididct.h"
> +#include "unary.h"
>
> /* The defines below define the number of bits that are read at once for
> * reading vlc values. Changing these may improve speed and data cache needs
> @@ -1923,10 +1925,101 @@ static int mpeg4_decode_studio_block(MpegEncContext
> *s, int32_t block[64], int n
> return 0;
> }
>
> +static int mpeg4_decode_dpcm_macroblock(MpegEncContext *s, int16_t
> macroblock[256], int n)
> +{
> +int i, j, w, h, idx = 0;
> +int block_mean, rice_parameter, rice_prefix_code, rice_suffix_code;
> +int dpcm_residual, a, b, c, p, p2;
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(s->avctx->pix_fmt);
> +h = 16 >> (n ? desc->log2_chroma_h : 0);
> +w = 16 >> (n ? desc->log2_chroma_w : 0);
you can use chroma_x_shift, chroma_y_shift from the context, theres no
need to obtain a AVPixFmtDescriptor
> +
> +block_mean = get_bits(&s->gb, s->avctx->bits_per_raw_sample);
> +if (block_mean == 0){
> +av_log(s->avctx, AV_LOG_ERROR, "Forbidden block_mean\n");
> +return AVERROR_INVALIDDATA;
> +}
> +s->last_dc[n] = block_mean * (1 << (s->dct_precision +
> s->intra_dc_precision));
> +
> +rice_parameter = get_bits(&s->gb, 4);
> +if (rice_parameter == 0) {
> +av_log(s->avctx, AV_LOG_ERROR, "Forbidden rice_parameter\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (rice_parameter == 15)
> +rice_parameter = 0;
> +
> +if (rice_parameter > 11) {
> +av_log(s->avctx, AV_LOG_ERROR, "Forbidden rice_parameter\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +for (i = 0; i < h; i++) {
> +for (j = 0; j < w; j++) {
> +rice_prefix_code = get_unary(&s->gb, 1, 12);
> +
> +/* Escape */
> +if (rice_prefix_code == 11)
> +dpcm_residual = get_bits(&s->gb,
> s->avctx->bits_per_raw_sample);
> +else {
> +rice_suffix_code = get_bitsz(&s->gb, rice_parameter);
> +dpcm_residual = (rice_prefix_code << rice_parameter) +
> rice_suffix_code;
> +}
> +
> +/* Map to a signed residual */
> +if (dpcm_residual & 1)
> +dpcm_residual = (-1 * dpcm_residual) >> 1;
> +else
> +dpcm_residual = (dpcm_residual >> 1);
This could be optimized, not sure how common DPCM blocks are so maybe this
doesnt matter
> +
> +/* Calculate predictors
> + a = left
> + b = top
> + c = top left
> + */
> +if (j == 0)
> +a = 1 << (s->avctx->bits_per_raw_sample - 1);
> +else
> +a = macroblock[idx-1];
you can move this out of the loop and just update "a" at the end of the loop, as
its the previous value
> +
> +if (i == 0)
> +b = 1 << (s->avctx->bits_per_raw_sample - 1);
> +else
> +b = macroblock[idx-w];
> +
> +if ((j == 0) || (i == 0))
> +c = 1 << (s->avctx->bits_per_raw_sample - 1);
> +else
> +c = macroblock[idx-w-1];
this too can be avoided by simply updating "c" at the end of teh loop and
setting it outside before the loop
> +
> +p = a + b - c;
> +if (p < FFMIN(a, b))
> +p = FFMIN(a, b);
> +
> +if (p > FFMAX(a, b))
> +p = FFMAX(a, b);
> +
> +p2 = (FFMIN3(a, b, c) + FFMAX3(a, b, c)) / 2;
using >> instead of /2 should be faster here
also FFMIN(a, b) and FFMAX(a, b) have alr
Re: [FFmpeg-devel] [PATCH v3] doc/filters: Add double-pass example for loudnorm
On 22-8-2018 12:52, Gyan Doshi wrote: > On 22-08-2018 04:01 PM, Marvin Scholz wrote: >> [Parsed_aresample_1 @ 0x7fb7c540d500] Cannot select channel layout for the >> link between filters Parsed_aresample_1 and format_out_0_1. > For this file, > > aresample=48000:ocl=stereo > > > Gyan Related and still unresolved: https://trac.ffmpeg.org/ticket/6638. -- Reino ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Tools: drop hard dependency on python2
Some tools had an artificial dependency on python2: zmqshell.py and normalize.py
This patch changes the requested environment to a generic "python",
and add parenthesis to the "print" calls. 2to3 shows no other
modifications are needed, so I expect this to be okay.
Please note that this was untested.
---
tools/normalize.py | 13 +++--
tools/zmqshell.py | 7 ---
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/tools/normalize.py b/tools/normalize.py
index 7d87c5e154..a550d06906 100755
--- a/tools/normalize.py
+++ b/tools/normalize.py
@@ -1,4 +1,5 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python
+# This script is compatible both with python 2 and 3; please keep it so
import sys, subprocess
@@ -7,7 +8,7 @@ if len(sys.argv) > 2:
encopt = sys.argv[2:-1]
ofile = sys.argv[-1]
else:
-print 'usage: %s [encode_options] ' % sys.argv[0]
+print('usage: %s [encode_options] ' % sys.argv[0])
sys.exit(1)
analysis_cmd = 'ffprobe -v error -of compact=p=0:nk=1 '
@@ -15,7 +16,7 @@ analysis_cmd += '-show_entries
frame_tags=lavfi.r128.I -f lavfi '
analysis_cmd += "amovie='%s',ebur128=metadata=1" % ifile
try:
probe_out = subprocess.check_output(analysis_cmd, shell=True)
-except subprocess.CalledProcessError, e:
+except subprocess.CalledProcessError as e:
sys.exit(e.returncode)
loudness = ref = -23
for line in probe_out.splitlines():
@@ -24,10 +25,10 @@ for line in probe_out.splitlines():
loudness = sline
adjust = ref - float(loudness)
if abs(adjust) < 0.0001:
-print 'No normalization needed for ' + ifile
+print('No normalization needed for ' + ifile)
else:
-print "Adjust %s by %.1fdB" % (ifile, adjust)
+print("Adjust %s by %.1fdB" % (ifile, adjust))
norm_cmd = ['ffmpeg', '-i', ifile, '-af', 'volume=%fdB' % adjust]
norm_cmd += encopt + [ofile]
-print ' => %s' % ' '.join(norm_cmd)
+print(' => %s' % ' '.join(norm_cmd))
subprocess.call(norm_cmd)
diff --git a/tools/zmqshell.py b/tools/zmqshell.py
index a7d1126006..ff229b29c9 100755
--- a/tools/zmqshell.py
+++ b/tools/zmqshell.py
@@ -1,4 +1,5 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python
+# This script is compatible both with python 2 and 3; please keep it so
import sys, zmq, cmd
@@ -14,10 +15,10 @@ class LavfiCmd(cmd.Cmd):
def onecmd(self, cmd):
if cmd == 'EOF':
sys.exit(0)
-print 'Sending command:[%s]' % cmd
+print('Sending command:[%s]' % cmd)
self.requester.send(cmd)
message = self.requester.recv()
-print 'Received reply:[%s]' % message
+print('Received reply:[%s]' % message)
try:
bind_address = sys.argv[1] if len(sys.argv) > 1 else "tcp://localhost:"
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Register for VDD 2018 conference
Michael Niedermayer wrote: >I think future work should be done as FFV1v5 v6 v7 on >CELLAR/IETF That is how it should be, in my opinion. >why you ask ? >because that way >its on its way to be a proper IETF standard from day 1 >there are already people who are interrested in this there, >like myself and IIRC reto, and iam sure there are many more who >would like to see more discussions about improving and >extending the codecs in more fundamental ways. Indeed, you remember correctly. >also, you get more comments and testing on IETF/CELLAR >and for work beyond ffv1v3/4 to be successfull a critical mass >of people / time is needed. If everyone works seperate, which >it seems a bit to me thats what is happening, it would be >harder to move such an effort to completion I plenty agree with you! The reason why I worked more alone is the not welcoming environment. I am really too ill now and I do not have anymore the energy for just ignoring the insults. If you have any concrete idea how the environment could be made more welcoming, I would be more than happy. (I am not thinking about another code of conduct ;-) I would like to continue the FFV1 journey with you and other interested people, because it could be a fascinating one! Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add lut1d filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 29 +++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_lut3d.c | 404 +++
4 files changed, 435 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 32c95b591c..72ce95f94a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10962,6 +10962,35 @@ Set maximal size in number of frames. Default is 0.
Set first frame of loop. Default is 0.
@end table
+@section lut1d
+
+Apply a 1D LUT to an input video.
+
+The filter accepts the following options:
+
+@table @option
+@item file
+Set the 1D LUT file name.
+
+Currently supported formats:
+@table @samp
+@item cube
+Iridas
+@end table
+
+@item interp
+Select interpolation mode.
+
+Available values are:
+
+@table @samp
+@item nearest
+Use values from the nearest defined point.
+@item linear
+Interpolate values using the linear interpolation.
+@end table
+@end table
+
@anchor{lut3d}
@section lut3d
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e5d3a57af7..e412000c8f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -258,6 +258,7 @@ OBJS-$(CONFIG_LIBVMAF_FILTER)+=
vf_libvmaf.o framesync.o
OBJS-$(CONFIG_LIMITER_FILTER)+= vf_limiter.o
OBJS-$(CONFIG_LOOP_FILTER) += f_loop.o
OBJS-$(CONFIG_LUMAKEY_FILTER)+= vf_lumakey.o
+OBJS-$(CONFIG_LUT1D_FILTER) += vf_lut3d.o
OBJS-$(CONFIG_LUT_FILTER)+= vf_lut.o
OBJS-$(CONFIG_LUT2_FILTER) += vf_lut2.o framesync.o
OBJS-$(CONFIG_LUT3D_FILTER) += vf_lut3d.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9732ae5345..2fa9460335 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -246,6 +246,7 @@ extern AVFilter ff_vf_limiter;
extern AVFilter ff_vf_loop;
extern AVFilter ff_vf_lumakey;
extern AVFilter ff_vf_lut;
+extern AVFilter ff_vf_lut1d;
extern AVFilter ff_vf_lut2;
extern AVFilter ff_vf_lut3d;
extern AVFilter ff_vf_lutrgb;
diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 27b79b860b..b5673b82bf 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2013 Clément Bœsch
+ * Copyright (c) 2018 Paul B Mahol
*
* This file is part of FFmpeg.
*
@@ -975,3 +976,406 @@ AVFilter ff_vf_haldclut = {
.flags = AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL |
AVFILTER_FLAG_SLICE_THREADS,
};
#endif
+
+#if CONFIG_LUT1D_FILTER
+
+enum interp_1d_mode {
+INTERPOLATE_1D_NEAREST,
+INTERPOLATE_1D_LINEAR,
+NB_INTERP_1D_MODE
+};
+
+#define MAX_1D_LEVEL 65536
+
+typedef struct LUT1DContext {
+const AVClass *class;
+char *file;
+int interpolation; ///lutsize = size;
+for (i = 0; i < size; i++) {
+lut1d->lut[0][i] = i * c;
+lut1d->lut[1][i] = i * c;
+lut1d->lut[2][i] = i * c;
+}
+}
+
+static int parse_cube_1d(AVFilterContext *ctx, FILE *f)
+{
+LUT1DContext *lut1d = ctx->priv;
+char line[MAX_LINE_SIZE];
+float min[3] = {0.0, 0.0, 0.0};
+float max[3] = {1.0, 1.0, 1.0};
+
+while (fgets(line, sizeof(line), f)) {
+if (!strncmp(line, "LUT_1D_SIZE ", 12)) {
+const int size = strtol(line + 12, NULL, 0);
+int i;
+
+if (size < 2 || size > MAX_1D_LEVEL) {
+av_log(ctx, AV_LOG_ERROR, "Too large or invalid 1D LUT
size\n");
+return AVERROR(EINVAL);
+}
+lut1d->lutsize = size;
+for (i = 0; i < size; i++) {
+do {
+try_again:
+NEXT_LINE(0);
+if (!strncmp(line, "DOMAIN_", 7)) {
+float *vals = NULL;
+if (!strncmp(line + 7, "MIN ", 4)) vals = min;
+else if (!strncmp(line + 7, "MAX ", 4)) vals = max;
+if (!vals)
+return AVERROR_INVALIDDATA;
+sscanf(line + 11, "%f %f %f", vals, vals + 1, vals +
2);
+av_log(ctx, AV_LOG_DEBUG, "min: %f %f %f | max: %f %f
%f\n",
+ min[0], min[1], min[2], max[0], max[1], max[2]);
+goto try_again;
+}
+} while (skip_line(line));
+if (sscanf(line, "%f %f %f", &lut1d->lut[0][i],
&lut1d->lut[1][i], &lut1d->lut[2][i]) != 3)
+return AVERROR_INVALIDDATA;
+lut1d->lut[0][i] *= max[0] - min[0];
+lut1d->lut[1][i] *= max[1] - min[1];
+lut1d->lut[2][i] *= max[2] - min[2];
+}
+break;
+}
+}
+return 0;
+}
+
+static const AVOption lut1d_options[] = {
+{ "file", "set 1D LUT file name", OFFSET(file), AV_OPT_TYPE_STRING,
{.str=NULL}, .flags = FLAGS },
+{ "interp", "select interpola
Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder
On 8/23/18, Carl Eugen Hoyos wrote:
> 2018-08-22 21:24 GMT+02:00, Paul B Mahol :
>> On 8/22/18, Carl Eugen Hoyos wrote:
>>> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>>>
+switch (avctx->bits_per_coded_sample) {
+case 12:
+ s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
+ break;
+default:
+ return AVERROR_INVALIDDATA;
+}
>>>
>>> Why are the condition and the error needed?
>>
>> Because only that is supported.
>
> Do valid samples with other values exist?
No.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder
2018-08-22 21:24 GMT+02:00, Paul B Mahol :
> On 8/22/18, Carl Eugen Hoyos wrote:
>> 2018-08-22 18:00 GMT+02:00, Paul B Mahol :
>>
>>> +switch (avctx->bits_per_coded_sample) {
>>> +case 12:
>>> + s->stride = 3LL * FFALIGN(avctx->width, 8) >> 1;
>>> + break;
>>> +default:
>>> + return AVERROR_INVALIDDATA;
>>> +}
>>
>> Why are the condition and the error needed?
>
> Because only that is supported.
Do valid samples with other values exist?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Register for VDD 2018 conference
On Wed, Aug 22, 2018 at 03:24:05PM -0500, Dave Rice wrote: > > >> On Aug 22, 2018, at 14:12, Michael Niedermayer > >> wrote: > >> > >> On Wed, Aug 22, 2018 at 03:14:53PM +0200, Jean-Baptiste Kempf wrote: > >> Hello fellow devs, > >> > >> VideoLAN is happy to invite you to the usual conference of the end of the > >> summer: > >> VDD2018 is happening in Paris, for the 10 years of the original conf. > >> > >> As usual, this is a very technical conference focused on open source > >> multimedia development. > >> We will talk about AV1, FFv1, FFv2, x264/x265, VLC, FFmpeg and other > >> related technologies. > > > > what is FFv2 ? > > FFV2 is referenced in this patch http://akuvian.org/src/x264/ffv2.94.diff. > > Also FFV2 is referenced as a derivative experimental work from Daala. > https://twitter.com/atomnuker/status/924846477083578368?s=21 > > Also FFV2 is referenced by Reto Kromer as a forked alternative to the work on > FFV1 version 4 by the IETF cellar working group. > https://twitter.com/retokromer/status/884030201050648576?s=21 I think future work should be done as FFV1v5 v6 v7 on CELLAR/IETF why you ask ? because that way its on its way to be a proper IETF standard from day 1 there are already people who are interrested in this there, like myself and IIRC reto, and iam sure there are many more who would like to see more discussions about improving and extending the codecs in more fundamental ways. also, you get more comments and testing on IETF/CELLAR and for work beyond ffv1v3/4 to be successfull a critical mass of people / time is needed. If everyone works seperate, which it seems a bit to me thats what is happening, it would be harder to move such an effort to completion thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] avcodec/h264_mp4toannexb_bsf: add No IDR frame situation
-Original Message-
From: Fu, Linjie
Sent: Thursday, August 16, 2018 15:08
To: ffmpeg-devel@ffmpeg.org
Cc: Fu, Linjie
Subject: [PATCH V2] avcodec/h264_mp4toannexb_bsf: add No IDR frame situation
Fix the live stream encoding problem using qsv when the first frame is not an
IDR frame.
Add the extradata information when the IDR frame is missing in the first GOP.
Fix the bug reported in ticket #6418.
[PATCH V2] Fix the coding style.
Signed-off-by: Linjie Fu
---
libavcodec/h264_mp4toannexb_bsf.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index 794c82e650..fbb9f1fe20 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -33,6 +33,7 @@ typedef struct H264BSFContext {
int32_t pps_offset;
uint8_t length_size;
uint8_t new_idr;
+uint8_t new_nal_slice;
uint8_t idr_sps_seen;
uint8_t idr_pps_seen;
int extradata_parsed;
@@ -243,6 +244,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
buf, nal_size, 1)) < 0)
goto fail;
s->new_idr = 0;
+s->new_nal_slice = 1;
/* if only SPS has been seen, also insert PPS */
} else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE &&
s->idr_sps_seen && !s->idr_pps_seen) {
if (s->pps_offset == -1) {
@@ -253,6 +255,12 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
ctx->par_out->extradata +
s->pps_offset, ctx->par_out->extradata_size - s->pps_offset,
buf, nal_size, 1)) < 0)
goto fail;
+} else if (s->new_idr && !s->new_nal_slice && H264_NAL_SLICE ==
unit_type && !s->idr_sps_seen && !s->idr_pps_seen){
+av_log(ctx, AV_LOG_WARNING, "first H264_NAL_SLICE when there is no
IDR.\n");
+if ((ret = alloc_and_copy(out, ctx->par_out->extradata,
ctx->par_out->extradata_size, buf, nal_size, 1)) < 0)
+goto fail;
+s->new_nal_slice = 1;
+s->new_idr = 0;
} else {
if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size, unit_type ==
H264_NAL_SPS || unit_type == H264_NAL_PPS)) < 0)
goto fail;
--
2.17.1
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Register for VDD 2018 conference
Paul B Mahol wrote: >So we already have 3 FFV2 variants. > >Which of them are actually useful? Useful for what? E.g. 1 is a great source of inspiration! (At least to me, since Dave Rice tweeted it on 2016-07-15.) Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
