[FFmpeg-devel] [PATCH v2] libavformat/mxfenc: add missing dnxhr mxf container essence ULs
Add missing dnxhr mxf container essence ULs to the mxf encoder.
set proper mxf frame size for dnxhr.
This fixes dnxhr mxf files being quarantined by Avid Media Composer.
---
libavformat/mxfenc.c | 55 +++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 7f629dbe53..7991a1c6de 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -146,6 +146,11 @@ enum ULIndex {
INDEX_DNXHD_720p_8bit_HIGH,
INDEX_DNXHD_720p_8bit_MEDIUM,
INDEX_DNXHD_720p_8bit_LOW,
+INDEX_DNXHR_LB,
+INDEX_DNXHR_SQ,
+INDEX_DNXHR_HQ,
+INDEX_DNXHR_HQX,
+INDEX_DNXHR_444,
INDEX_JPEG2000,
INDEX_H264,
};
@@ -345,6 +350,31 @@ static const MXFContainerEssenceEntry
mxf_essence_container_uls[] = {
{
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
},
{
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x13,0x00,0x00
},
mxf_write_cdci_desc },
+// DNxHR LB - CID 1274
+{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
},
+ {
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
},
+ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x28,0x00,0x00
},
+ mxf_write_cdci_desc },
+// DNxHR SQ - CID 1273
+{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
},
+ {
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
},
+ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x27,0x00,0x00
},
+ mxf_write_cdci_desc },
+// DNxHR HQ - CID 1272
+{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
},
+ {
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
},
+ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x26,0x00,0x00
},
+ mxf_write_cdci_desc },
+// DNxHR HQX - CID 1271
+{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
},
+ {
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
},
+ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x25,0x00,0x00
},
+ mxf_write_cdci_desc },
+// DNxHR 444 - CID 1270
+{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
},
+ {
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
},
+ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x24,0x00,0x00
},
+ mxf_write_cdci_desc },
// JPEG2000
{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c,0x01,0x00
},
{
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x08,0x00
},
@@ -1959,7 +1989,13 @@ AVPacket *pkt)
header_cid = pkt->data + 0x28;
cid = header_cid[0] << 24 | header_cid[1] << 16 | header_cid[2] << 8 |
header_cid[3];
-if ((frame_size = avpriv_dnxhd_get_frame_size(cid)) < 0)
+if ((cid >= 1270) && (cid <= 1274)) {
+frame_size = pkt->size; // DNxHR is not predefined, use encoded frame
size
+} else {
+frame_size = avpriv_dnxhd_get_frame_size(cid); // DNxHD predefined
frame sizes
+}
+
+if (frame_size < 0)
return -1;
if ((sc->interlaced = avpriv_dnxhd_get_interlaced(cid)) < 0)
return AVERROR_INVALIDDATA;
@@ -1998,6 +2034,23 @@ AVPacket *pkt)
case 1253:
sc->index = INDEX_DNXHD_720p_8bit_LOW;
break;
+case 1274:
+sc->index = INDEX_DNXHR_LB;
+break;
+case 1273:
+sc->index = INDEX_DNXHR_SQ;
+break;
+case 1272:
+sc->index = INDEX_DNXHR_HQ;
+break;
+case 1271:
+sc->index = INDEX_DNXHR_HQX;
+sc->component_depth = 10;
+break;
+case 1270:
+sc->index = INDEX_DNXHR_444;
+sc->component_depth = 10;
+break;
default:
return -1;
}
--
2.18.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/mscc: fix several bugs
On 8/28/18, Carl Eugen Hoyos wrote:
> 2018-08-26 18:05 GMT+02:00, Paul B Mahol :
>
>> switch (avctx->bits_per_coded_sample) {
>> -case 8: avctx->pix_fmt = AV_PIX_FMT_GRAY8; break;
>> +case 8: avctx->pix_fmt = AV_PIX_FMT_PAL8; break;
>
> Do you have a sample that looks correct with this particular change?
> Can you share it?
No, but PAL8 samples looks same as in VirtualDub2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/mscc: fix several bugs
2018-08-28 12:00 GMT+02:00, Paul B Mahol :
> On 8/28/18, Carl Eugen Hoyos wrote:
>> 2018-08-26 18:05 GMT+02:00, Paul B Mahol :
>>
>>> switch (avctx->bits_per_coded_sample) {
>>> -case 8: avctx->pix_fmt = AV_PIX_FMT_GRAY8; break;
>>> +case 8: avctx->pix_fmt = AV_PIX_FMT_PAL8; break;
>>
>> Do you have a sample that looks correct with this particular change?
>> Can you share it?
>
> No, but PAL8 samples looks same as in VirtualDub2.
But GRAY8 looks really nice and there is no palette in extradata
for the two files I can test.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/mscc: fix several bugs
On 8/28/18, Carl Eugen Hoyos wrote:
> 2018-08-28 12:00 GMT+02:00, Paul B Mahol :
>> On 8/28/18, Carl Eugen Hoyos wrote:
>>> 2018-08-26 18:05 GMT+02:00, Paul B Mahol :
>>>
switch (avctx->bits_per_coded_sample) {
-case 8: avctx->pix_fmt = AV_PIX_FMT_GRAY8; break;
+case 8: avctx->pix_fmt = AV_PIX_FMT_PAL8; break;
>>>
>>> Do you have a sample that looks correct with this particular change?
>>> Can you share it?
>>
>> No, but PAL8 samples looks same as in VirtualDub2.
>
> But GRAY8 looks really nice and there is no palette in extradata
> for the two files I can test.
There is palette, as side data.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/mscc: fix several bugs
> Am 28.08.2018 um 12:05 schrieb Paul B Mahol :
>
>> On 8/28/18, Carl Eugen Hoyos wrote:
>> 2018-08-28 12:00 GMT+02:00, Paul B Mahol :
On 8/28/18, Carl Eugen Hoyos wrote:
2018-08-26 18:05 GMT+02:00, Paul B Mahol :
> switch (avctx->bits_per_coded_sample) {
> -case 8: avctx->pix_fmt = AV_PIX_FMT_GRAY8; break;
> +case 8: avctx->pix_fmt = AV_PIX_FMT_PAL8; break;
Do you have a sample that looks correct with this particular change?
Can you share it?
>>>
>>> No, but PAL8 samples looks same as in VirtualDub2.
>>
>> But GRAY8 looks really nice and there is no palette in extradata
>> for the two files I can test.
>
> There is palette, as side data.
Did you look at the actual data?
It doesn’t look like a palette to me...
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: add 10-bit test for hue video filter
Signed-off-by: Tobias Rapp --- tests/fate/filter-video.mak | 3 +++ tests/ref/fate/filter-hue4 | 1 + 2 files changed, 4 insertions(+) create mode 100644 tests/ref/fate/filter-hue4 diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index edd51e1..c87a7ba 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -514,6 +514,9 @@ fate-filter-hue2: CMD = video_filter "perms=random,hue=h=18*n" -frames:v 20 FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue3 fate-filter-hue3: CMD = video_filter "perms=random,hue=b=n-10" -frames:v 20 +FATE_FILTER_VSYNTH-$(call ALLYES, FORMAT_FILTER PERMS_FILTER HUE_FILTER) += fate-filter-hue4 +fate-filter-hue4: CMD = video_filter "format=yuv422p10,perms=random,hue=h=18*n:s=n/10" -frames:v 20 + FATE_FILTER_VSYNTH-$(CONFIG_IDET_FILTER) += fate-filter-idet fate-filter-idet: CMD = framecrc -flags bitexact -idct simple -i $(SRC) -vf idet -frames:v 25 -flags +bitexact diff --git a/tests/ref/fate/filter-hue4 b/tests/ref/fate/filter-hue4 new file mode 100644 index 000..2a08c33 --- /dev/null +++ b/tests/ref/fate/filter-hue4 @@ -0,0 +1 @@ +hue46279ed43527e7b5be645819e08880107 -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.
If a packet is full-sample encrypted, then packet data can't be parsed
without decrypting it. So this skips the packet parsing for those
packets. If the packet has sub-sample encryption, it is assumed that
the headers are in the clear and the parser will only need that info.
Signed-off-by: Jacob Trimble
---
libavformat/utils.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index b0b5e164a6..1107787eae 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -27,6 +27,7 @@
#include "libavutil/avassert.h"
#include "libavutil/avstring.h"
#include "libavutil/dict.h"
+#include "libavutil/encryption_info.h"
#include "libavutil/internal.h"
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
@@ -1576,6 +1577,9 @@ static int read_frame_internal(AVFormatContext *s,
AVPacket *pkt)
while (!got_packet && !s->internal->parse_queue) {
AVStream *st;
AVPacket cur_pkt;
+uint8_t *enc_side_data;
+int enc_side_data_size;
+int is_full_encrypted = 0;
/* read next packet */
ret = ff_read_packet(s, &cur_pkt);
@@ -1659,7 +1663,22 @@ FF_ENABLE_DEPRECATION_WARNINGS
st->parser->flags |= PARSER_FLAG_USE_CODEC_TS;
}
-if (!st->need_parsing || !st->parser) {
+/* if the packet is full-sample encrypted, we can't parse it. If the
+ * packet uses sub-sample encryption, assume the headers are clear and
+ * can still be parsed.
+ */
+enc_side_data = av_packet_get_side_data(
+&cur_pkt, AV_PKT_DATA_ENCRYPTION_INFO, &enc_side_data_size);
+if (enc_side_data) {
+AVEncryptionInfo *enc_info =
+av_encryption_info_get_side_data(enc_side_data,
enc_side_data_size);
+if (enc_info) {
+is_full_encrypted = enc_info->subsample_count == 0;
+av_encryption_info_free(enc_info);
+}
+}
+
+if (!st->need_parsing || !st->parser || is_full_encrypted) {
/* no parsing needed: we just output the packet as is */
*pkt = cur_pkt;
compute_pkt_fields(s, st, NULL, pkt, AV_NOPTS_VALUE,
AV_NOPTS_VALUE);
--
2.19.0.rc0.228.g281dcd1b4d0-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_framerate: switch to activate
Signed-off-by: Marton Balint
---
libavfilter/vf_framerate.c | 119 -
1 file changed, 63 insertions(+), 56 deletions(-)
diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index 3e2615be5e..fb65381923 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -38,6 +38,7 @@
#include "avfilter.h"
#include "internal.h"
#include "video.h"
+#include "filters.h"
#include "framerate.h"
#define OFFSET(x) offsetof(FrameRateContext, x)
@@ -360,53 +361,81 @@ static int config_input(AVFilterLink *inlink)
return 0;
}
-static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
+static int activate(AVFilterContext *ctx)
{
-int ret;
-AVFilterContext *ctx = inlink->dst;
+int ret, status;
+AVFilterLink *inlink = ctx->inputs[0];
+AVFilterLink *outlink = ctx->outputs[0];
FrameRateContext *s = ctx->priv;
+AVFrame *inpicref;
int64_t pts;
-if (inpicref->interlaced_frame)
-av_log(ctx, AV_LOG_WARNING, "Interlaced frame found - the output will
not be correct.\n");
+FF_FILTER_FORWARD_STATUS_BACK(outlink, inlink);
-if (inpicref->pts == AV_NOPTS_VALUE) {
-av_log(ctx, AV_LOG_WARNING, "Ignoring frame without PTS.\n");
-return 0;
+retry:
+ret = process_work_frame(ctx);
+if (ret < 0)
+return ret;
+else if (ret == 1)
+return ff_filter_frame(outlink, s->work);
+
+ret = ff_inlink_consume_frame(inlink, &inpicref);
+if (ret < 0)
+return ret;
+
+if (inpicref) {
+if (inpicref->interlaced_frame)
+av_log(ctx, AV_LOG_WARNING, "Interlaced frame found - the output
will not be correct.\n");
+
+if (inpicref->pts == AV_NOPTS_VALUE) {
+av_log(ctx, AV_LOG_WARNING, "Ignoring frame without PTS.\n");
+av_frame_free(&inpicref);
+}
}
-pts = av_rescale_q(inpicref->pts, s->srce_time_base, s->dest_time_base);
-if (s->f1 && pts == s->pts1) {
-av_log(ctx, AV_LOG_WARNING, "Ignoring frame with same PTS.\n");
-return 0;
+if (inpicref) {
+pts = av_rescale_q(inpicref->pts, s->srce_time_base,
s->dest_time_base);
+
+if (s->f1 && pts == s->pts1) {
+av_log(ctx, AV_LOG_WARNING, "Ignoring frame with same PTS.\n");
+av_frame_free(&inpicref);
+}
}
-av_frame_free(&s->f0);
-s->f0 = s->f1;
-s->pts0 = s->pts1;
-s->f1 = inpicref;
-s->pts1 = pts;
-s->delta = s->pts1 - s->pts0;
-s->score = -1.0;
-
-if (s->delta < 0) {
-av_log(ctx, AV_LOG_WARNING, "PTS discontinuity.\n");
-s->start_pts = s->pts1;
-s->n = 0;
+if (inpicref) {
av_frame_free(&s->f0);
+s->f0 = s->f1;
+s->pts0 = s->pts1;
+s->f1 = inpicref;
+s->pts1 = pts;
+s->delta = s->pts1 - s->pts0;
+s->score = -1.0;
+
+if (s->delta < 0) {
+av_log(ctx, AV_LOG_WARNING, "PTS discontinuity.\n");
+s->start_pts = s->pts1;
+s->n = 0;
+av_frame_free(&s->f0);
+}
+
+if (s->start_pts == AV_NOPTS_VALUE)
+s->start_pts = s->pts1;
+
+goto retry;
}
-if (s->start_pts == AV_NOPTS_VALUE)
-s->start_pts = s->pts1;
+if (ff_inlink_acknowledge_status(inlink, &status, &pts)) {
+if (!s->flush) {
+s->flush = 1;
+goto retry;
+}
+ff_outlink_set_status(outlink, status, pts);
+return 0;
+}
-do {
-ret = process_work_frame(ctx);
-if (ret <= 0)
-return ret;
-ret = ff_filter_frame(ctx->outputs[0], s->work);
-} while (ret >= 0);
+FF_FILTER_FORWARD_WANTED(outlink, inlink);
-return ret;
+return FFERROR_NOT_READY;
}
static int config_output(AVFilterLink *outlink)
@@ -454,33 +483,11 @@ static int config_output(AVFilterLink *outlink)
return 0;
}
-static int request_frame(AVFilterLink *outlink)
-{
-AVFilterContext *ctx = outlink->src;
-FrameRateContext *s = ctx->priv;
-int ret;
-
-ff_dlog(ctx, "request_frame()\n");
-
-ret = ff_request_frame(ctx->inputs[0]);
-if (ret == AVERROR_EOF && s->f1 && !s->flush) {
-s->flush = 1;
-ret = process_work_frame(ctx);
-if (ret < 0)
-return ret;
-ret = ret ? ff_filter_frame(ctx->outputs[0], s->work) : AVERROR_EOF;
-}
-
-ff_dlog(ctx, "request_frame() source's request_frame() returned:%d\n",
ret);
-return ret;
-}
-
static const AVFilterPad framerate_inputs[] = {
{
.name = "default",
.type = AVMEDIA_TYPE_VIDEO,
.config_props = config_input,
-.filter_frame = filter_frame,
},
{ NULL }
};
@@ -489,7 +496,6 @@ static const AVFilterPad framerate_outputs[] = {
{
.name = "default",
.type = AVMEDIA_TYPE_VIDEO,
-.request_frame = request_
Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: Parse encryption init info from streams.
On Mon, Aug 20, 2018 at 11:39 AM Jacob Trimble wrote:
>
> On Thu, Aug 9, 2018 at 9:14 AM Jacob Trimble wrote:
> >
> > On Wed, Aug 1, 2018 at 1:46 PM Jacob Trimble wrote:
> > >
> > > On Mon, Jul 23, 2018 at 2:01 PM Jacob Trimble wrote:
> > > >
> > > > On Thu, Jul 12, 2018 at 5:05 PM Jacob Trimble
> > > > wrote:
> > > > >
> > > > > Signed-off-by: Jacob Trimble
> > > > > ---
> > > > > libavformat/matroskadec.c | 43
> > > > > +--
> > > > > 1 file changed, 32 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> > > > > index 1ded431b80..bfef329e59 100644
> > > > > --- a/libavformat/matroskadec.c
> > > > > +++ b/libavformat/matroskadec.c
> > > > > @@ -2080,7 +2080,8 @@ static int
> > > > > matroska_parse_tracks(AVFormatContext *s)
> > > > > int extradata_offset = 0;
> > > > > uint32_t fourcc = 0;
> > > > > AVIOContext b;
> > > > > -char* key_id_base64 = NULL;
> > > > > +char* key_id = NULL;
> > > > > +int key_id_size = 0;
> > > > > int bit_depth = -1;
> > > > >
> > > > > /* Apply some sanity checks. */
> > > > > @@ -2133,14 +2134,8 @@ static int
> > > > > matroska_parse_tracks(AVFormatContext *s)
> > > > > if (encodings[0].encryption.key_id.size > 0) {
> > > > > /* Save the encryption key id to be stored later
> > > > > as a
> > > > > metadata tag. */
> > > > > -const int b64_size =
> > > > > AV_BASE64_SIZE(encodings[0].encryption.key_id.size);
> > > > > -key_id_base64 = av_malloc(b64_size);
> > > > > -if (key_id_base64 == NULL)
> > > > > -return AVERROR(ENOMEM);
> > > > > -
> > > > > -av_base64_encode(key_id_base64, b64_size,
> > > > > -
> > > > > encodings[0].encryption.key_id.data,
> > > > > -
> > > > > encodings[0].encryption.key_id.size);
> > > > > +key_id = encodings[0].encryption.key_id.data;
> > > > > +key_id_size =
> > > > > encodings[0].encryption.key_id.size;
> > > > > } else {
> > > > > encodings[0].scope = 0;
> > > > > av_log(matroska->ctx, AV_LOG_ERROR,
> > > > > @@ -2198,14 +2193,40 @@ static int
> > > > > matroska_parse_tracks(AVFormatContext *s)
> > > > >
> > > > > st = track->stream = avformat_new_stream(s, NULL);
> > > > > if (!st) {
> > > > > -av_free(key_id_base64);
> > > > > return AVERROR(ENOMEM);
> > > > > }
> > > > >
> > > > > -if (key_id_base64) {
> > > > > +if (key_id) {
> > > > > +AVEncryptionInitInfo *init_info;
> > > > > +uint8_t *side_data;
> > > > > +size_t side_data_size;
> > > > > +const int b64_size = AV_BASE64_SIZE(key_id_size);
> > > > > +char *key_id_base64 = av_malloc(b64_size);
> > > > > +if (!key_id_base64)
> > > > > +return AVERROR(ENOMEM);
> > > > > +av_base64_encode(key_id_base64, b64_size, key_id,
> > > > > key_id_size);
> > > > > +
> > > > > /* export encryption key id as base64 metadata tag */
> > > > > av_dict_set(&st->metadata, "enc_key_id", key_id_base64,
> > > > > 0);
> > > > > av_freep(&key_id_base64);
> > > > > +
> > > > > +
> > > > > +/* Convert the key ID to a generic encryption init info
> > > > > */
> > > > > +init_info = av_encryption_init_info_alloc(/*
> > > > > system_id_size */ 0, /* num_key_ids */ 1,
> > > > > + /* key_id_size
> > > > > */ key_id_size, /* data_size */ 0);
> > > > > +if (!init_info)
> > > > > +return AVERROR(ENOMEM);
> > > > > +memcpy(init_info->key_ids[0], key_id, key_id_size);
> > > > > +side_data =
> > > > > av_encryption_init_info_add_side_data(init_info, &side_data_size);
> > > > > +av_encryption_init_info_free(init_info);
> > > > > +if (!side_data)
> > > > > +return AVERROR(ENOMEM);
> > > > > +ret = av_stream_add_side_data(st,
> > > > > AV_PKT_DATA_ENCRYPTION_INIT_INFO,
> > > > > + side_data, side_data_size);
> > > > > +if (ret < 0) {
> > > > > +av_free(side_data);
> > > > > +return ret;
> > > > > +}
> > > > > }
> > > > >
> > > > > if (!strcmp(track->codec_id, "V_MS/VFW/FOURCC") &&
> > > > > --
> > > > > 2.18.0.203.gfac676dfb9-goog
> > > > >
> > > >
> > > > Ping.
> > >
> > > Ping.
> >
> > Ping (only 43 lines changed, in "review" for 28 days...)
>
> Ping.
Ping. (initially sent 47 days ago, attached again for you
Re: [FFmpeg-devel] [PATCH] ffmpeg: block output == input for files
On Tue, Aug 28, 2018 at 08:31:51AM +0200, Marton Balint wrote: > > > On Tue, 28 Aug 2018, Gyan Doshi wrote: > > > > >With some regularity, we have users trying to update input files using > >ffmpeg, usually for the purposes of tagging, but occasionally for changing > >the encoding or something else. Other apps like mp4box or taggers edit the > >files in-place i.e. destination file is same as the source. FFmpeg cannot > >do this. But since these users don't realize that, they will answer Yes to > >the overwrite prompt and then discover their source has been destroyed. > > > >Attached patch checks the URL for file protocol outputs against inputs and > >aborts upon a match. An option is provided for the user to force the > >operation. > > > >The check isn't robust. In particular, it looks for exact url string > >matches, so a command like > > > > ffmpeg -i file:somefile -some_op somefile > > > >will still pass through. But I consider such invocations rare. Most times > >I've seen users trying this (on Stackexchange or other support forums), > >the command is typically of the form, > > > > for i; do ffmpeg -i $i -some_op -y $i > > > >Such a scenario was filed as a bug in #4655 but it was marked as wontfix > >since some protocols/services can manage bidir ops to the same endpoint. > >For that reason, everything other than file protocol sources/sinks are > >exempt i.e. http, pipes, devices..etc. > > > >This patch doesn't affect the semantics of '-y' and adds the check after it. > > Instead of this, maybe we should add support to write lock the files when > opening them for reading. Then ffmpeg can request this. That would be an > useful option, and not just for unexperienced users. depending on how this is done, it could interfere with reading a file while it is being written/appeneded to by another process [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] make work (live) libsrt
On Sat, 25 Aug 2018, Tudor Suciu wrote:
Hello Marton,
The new version takes into account your remarks, modifications.
I checked the srt API, and we are doing this all wrong.
The SRTO_PAYLOADSIZE socket parameter defines the maximum allowed packet
size. So we should query this parameter, and set
UrlContext->max_packet_size accordingly.
And should simply set SRTO_PACKETSIZE to our pkt_size parameter if we
don't want the libsrt default 1356.
I have attached a new patch. Let me know what you think.
Thanks,
MartonFrom eac0d702fd91de1f62bb9c001ce83ce5f178993e Mon Sep 17 00:00:00 2001
From: Tudor Suciu
Date: Sat, 25 Aug 2018 14:06:57 +0200
Subject: [PATCH] avformat/libsrt: add pkt_size parameter to libsrt
Also make sure we set the URL context max packet size accordingly.
Signed-off-by: Marton Balint
---
configure| 2 +-
doc/protocols.texi | 6 ++
libavformat/libsrt.c | 26 ++
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 3cf9412947..27a594f246 100755
--- a/configure
+++ b/configure
@@ -6112,7 +6112,7 @@ enabled libsnappy && require libsnappy snappy-c.h snappy_compress -lsnap
enabled libsoxr && require libsoxr soxr.h soxr_create -lsoxr
enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h sftp_init
enabled libspeex && require_pkg_config libspeex speex speex/speex.h speex_decoder_init
-enabled libsrt&& require_pkg_config libsrt "srt >= 1.2.0" srt/srt.h srt_socket
+enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0" srt/srt.h srt_socket
enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h TF_Version -ltensorflow
enabled libtesseract && require_pkg_config libtesseract tesseract tesseract/capi.h TessBaseAPICreate
enabled libtheora && require libtheora theora/theoraenc.h th_info_init -ltheoraenc -ltheoradec -logg
diff --git a/doc/protocols.texi b/doc/protocols.texi
index e9091e068c..4c5e972a04 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1263,6 +1263,12 @@ Not required on receiver (set to 0),
key size obtained from sender in HaiCrypt handshake.
Default value is 0.
+@item pkt_size=@var{bytes}
+Set maximum SRT payload size, expressed in bytes. Default is -1 (automatic),
+which typically means 1316 as that is the libsrt default for live mode. Libsrt
+can also support payload sizes up to 1456 bytes. (MTU(1500) - UDP.hdr(28) -
+SRT.hdr(16))
+
@item recv_buffer_size=@var{bytes}
Set receive buffer size, expressed in bytes.
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 0f9529d263..9260c1bf37 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -48,6 +48,7 @@ typedef struct SRTContext {
int64_t listen_timeout;
int recv_buffer_size;
int send_buffer_size;
+int pkt_size;
int64_t maxbw;
int pbkeylen;
@@ -73,6 +74,7 @@ static const AVOption libsrt_options[] = {
{ "listen_timeout", "Connection awaiting timeout", OFFSET(listen_timeout), AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX, .flags = D|E },
{ "send_buffer_size", "Socket send buffer size (in bytes)", OFFSET(send_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = D|E },
{ "recv_buffer_size", "Socket receive buffer size (in bytes)", OFFSET(recv_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = D|E },
+{ "pkt_size", "Maximum SRT packet size", OFFSET(pkt_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = D|E },
{ "maxbw", "Maximum bandwidth (bytes per second) that the connection can use", OFFSET(maxbw),AV_OPT_TYPE_INT64,{ .i64 = -1 }, -1, INT64_MAX, .flags = D|E },
{ "pbkeylen", "Crypto key len in bytes {16,24,32} Default: 16 (128-bit)", OFFSET(pbkeylen), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 32,.flags = D|E },
{ "passphrase", "Crypto PBKDF2 Passphrase size[0,10..64] 0:disable crypto", OFFSET(passphrase), AV_OPT_TYPE_STRING, { .str = NULL }, .flags = D|E },
@@ -240,6 +242,15 @@ static int libsrt_setsockopt(URLContext *h, int fd, SRT_SOCKOPT optname, const c
return 0;
}
+static int libsrt_getsockopt(URLContext *h, int fd, SRT_SOCKOPT optname, const char * optnamestr, void * optval, int * optlen)
+{
+if (srt_getsockopt(fd, 0, optname, optval, optlen) < 0) {
+av_log(h, AV_LOG_ERROR, "failed to get option %s on socket: %s\n", optnamestr, srt_getlasterror_str());
+return AVERROR(EIO);
+}
+return 0;
+}
+
/* - The "POST" options can be altered any time on a connected socket.
They MAY have also some meaning when set prior to connecting; such
option is SRTO_RCVSYN, which makes
[FFmpeg-devel] [PATCH] aacenc: remove unsupported PCE mappings
Turns out those ones make the decoder unable to accurately determine the
layout, hence making some API users' guess, and sometimes those are correct
(ffmpeg.c), but most often (especially with side channels) they're wrong.
The removed ones need to be investigated into as to why the decoder rejects
them.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/aacenc.h | 177
1 file changed, 177 deletions(-)
diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index 5a015ca92e..74f8fcf43a 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -167,38 +167,6 @@ static const AACPCEInfo aac_pce_configs[] = {
.config_map = { 2, TYPE_CPE, TYPE_SCE },
.reorder_map = { 0, 1, 2 },
},
-{
-.layout = AV_CH_LAYOUT_SURROUND,
-.num_ele = { 2, 0, 0, 0 },
-.pairing = { { 1, 0 }, },
-.index = { { 0, 0 }, },
-.config_map = { 2, TYPE_CPE, TYPE_SCE, },
-.reorder_map = { 0, 1, 2 },
-},
-{
-.layout = AV_CH_LAYOUT_3POINT1,
-.num_ele = { 2, 0, 0, 1 },
-.pairing = { { 1, 0 }, },
-.index = { { 0, 0 }, { 0 }, { 0 }, { 0 }, },
-.config_map = { 3, TYPE_CPE, TYPE_SCE, TYPE_LFE },
-.reorder_map = { 0, 1, 2, 3 },
-},
-{
-.layout = AV_CH_LAYOUT_4POINT0,
-.num_ele = { 2, 0, 1, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 0 }, },
-.index = { { 0, 0 }, { 0 }, { 1 } },
-.config_map = { 3, TYPE_CPE, TYPE_SCE, TYPE_SCE },
-.reorder_map = { 0, 1, 2, 3 },
-},
-{
-.layout = AV_CH_LAYOUT_4POINT1,
-.num_ele = { 2, 1, 1, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 0 }, },
-.index = { { 0, 0 }, { 1 }, { 2 }, { 0 } },
-.config_map = { 4, TYPE_CPE, TYPE_SCE, TYPE_SCE, TYPE_SCE },
-.reorder_map = { 0, 1, 2, 3, 4 },
-},
{
.layout = AV_CH_LAYOUT_2_2,
.num_ele = { 1, 1, 0, 0 },
@@ -215,46 +183,6 @@ static const AACPCEInfo aac_pce_configs[] = {
.config_map = { 2, TYPE_CPE, TYPE_CPE },
.reorder_map = { 0, 1, 2, 3 },
},
-{
-.layout = AV_CH_LAYOUT_5POINT0,
-.num_ele = { 2, 1, 0, 0 },
-.pairing = { { 1, 0 }, { 1 }, },
-.index = { { 0, 0 }, { 1 } },
-.config_map = { 3, TYPE_CPE, TYPE_SCE, TYPE_CPE },
-.reorder_map = { 0, 1, 2, 3, 4 },
-},
-{
-.layout = AV_CH_LAYOUT_5POINT1,
-.num_ele = { 2, 1, 1, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 1 }, },
-.index = { { 0, 0 }, { 1 }, { 1 } },
-.config_map = { 4, TYPE_CPE, TYPE_SCE, TYPE_SCE, TYPE_CPE },
-.reorder_map = { 0, 1, 2, 3, 4, 5 },
-},
-{
-.layout = AV_CH_LAYOUT_5POINT0_BACK,
-.num_ele = { 2, 0, 1, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 1 } },
-.index = { { 0, 0 }, { 0 }, { 1 } },
-.config_map = { 3, TYPE_CPE, TYPE_SCE, TYPE_CPE },
-.reorder_map = { 0, 1, 2, 3, 4 },
-},
-{
-.layout = AV_CH_LAYOUT_5POINT1_BACK,
-.num_ele = { 2, 1, 1, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 1 }, },
-.index = { { 0, 0 }, { 1 }, { 1 } },
-.config_map = { 4, TYPE_CPE, TYPE_SCE, TYPE_SCE, TYPE_CPE },
-.reorder_map = { 0, 1, 2, 3, 4, 5 },
-},
-{
-.layout = AV_CH_LAYOUT_6POINT0,
-.num_ele = { 2, 1, 1, 0 },
-.pairing = { { 1, 0 }, { 1 }, { 0 }, },
-.index = { { 0, 0 }, { 1 }, { 1 } },
-.config_map = { 4, TYPE_CPE, TYPE_SCE, TYPE_CPE, TYPE_SCE },
-.reorder_map = { 0, 1, 2, 3, 4, 5 },
-},
{
.layout = AV_CH_LAYOUT_6POINT0_FRONT,
.num_ele = { 2, 1, 0, 0 },
@@ -263,111 +191,6 @@ static const AACPCEInfo aac_pce_configs[] = {
.config_map = { 3, TYPE_CPE, TYPE_CPE, TYPE_CPE, },
.reorder_map = { 0, 1, 2, 3, 4, 5 },
},
-{
-.layout = AV_CH_LAYOUT_HEXAGONAL,
-.num_ele = { 2, 0, 2, 0 },
-.pairing = { { 1, 0 },{ 0 },{ 1, 0 }, },
-.index = { { 0, 0 },{ 0 },{ 1, 1 } },
-.config_map = { 4, TYPE_CPE, TYPE_SCE, TYPE_CPE, TYPE_SCE, },
-.reorder_map = { 0, 1, 2, 3, 4, 5 },
-},
-{
-.layout = AV_CH_LAYOUT_6POINT1,
-.num_ele = { 2, 1, 2, 0 },
-.pairing = { { 1, 0 },{ 0 },{ 1, 0 }, },
-.index = { { 0, 0 },{ 1 },{ 1, 2 } },
-.config_map = { 5, TYPE_CPE, TYPE_SCE, TYPE_SCE, TYPE_CPE, TYPE_SCE },
-.reorder_map = { 0, 1, 2, 3, 4, 5, 6 },
-},
-{
-.layout = AV_CH_LAYOUT_6POINT1_BACK,
-.num_ele = { 2, 1, 2, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 1, 0 }, },
-.index = { { 0, 0 }, { 1 }, { 1, 2 } },
-.config_map = { 5, TYPE_CPE, TYPE_SCE, TYPE_SCE, TYPE_CPE, TYPE_SCE },
-.reorder_map = { 0, 1, 2, 3, 4, 5, 6 },
-},
-{
-.layout = AV_CH_LAYOUT_6POINT1_FRONT,
-.num_ele = { 2, 1, 2, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 1, 0 }, },
-.index =
[FFmpeg-devel] [PATCH] configure: _deps: validate, reduce sensitivity
I analyzed the linkage failures at:
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233674.html
After finding their immediate cause - expecting a specific output
order from unique() - I realized that there might be a related issue
where devs are expected to maintain _deps (e.g. avfilter_deps)
in linking order. This can be awkward and bug-prone if the list is
not empty. I noticed at least one such existing order bug.
This patch makes it easier to add to these lists, in any order,
while also addressing few smaller issues and adding validation.
More details at the commit message of the attached patch.
Avi
From 4940963648cb431f1a8e827adefb58d318186b38 Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)"
Date: Tue, 28 Aug 2018 17:14:55 +0300
Subject: [PATCH] configure: _deps: validate, reduce sensitivity
- Allow to add deps in any order rather than "in linking order".
- Expand deps chains as required rather than just once.
- Validate that there are no cycles.
- Validate that [after expansion] deps are limited to other fflibs.
- Remove expectation for a specific output order of unique().
Previously when adding items to _deps, developers were
required to add them in linking order. This can be awkward and
bug-prone, especially when a list is not empty, e.g. when adding
conditional deps.
It also implicitly expected unique() to keep the last instance of
recurring items such that these lists maintain their linking order
after removing duplicate items.
This patch mainly allows to add deps in any order by keeping just
one master list in linking order, and then reordering all the
_deps lists to align with the master list order.
This master list is LIBRARY_LIST itself, where otherwise its order
doesn't matter.
The patch also removes a limit where these deps lists were expanded
only once. This could have resulted in incomplete expanded lists,
or forcing devs to add already-deducable deps to avoid this issue.
Note: it is possible to deduce the master list order automatically
from the deps lists, but in this case it's probably not worth the
added complexity, even if minor. Maintaining one list should be OK.
---
configure | 46 --
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/configure b/configure
index 3cf94129..8bbcd530 100755
--- a/configure
+++ b/configure
@@ -1818,16 +1818,17 @@ FEATURE_LIST="
swscale_alpha
"
+# this list should be kept in linking order
LIBRARY_LIST="
-avcodec
avdevice
avfilter
+swscale
+postproc
avformat
+avcodec
+swresample
avresample
avutil
-postproc
-swresample
-swscale
"
LICENSE_LIST="
@@ -3491,7 +3492,7 @@ vaapi_transcode_example_deps="avcodec avformat avutil h264_vaapi_encoder"
cpu_init_extralibs="pthreads_extralibs"
cws2fws_extralibs="zlib_extralibs"
-# libraries, in linking order
+# libraries, in any order
avcodec_deps="avutil"
avcodec_suggest="libm"
avcodec_select="null_bsf"
@@ -6846,7 +6847,7 @@ done
enabled zlib && add_cppflags -DZLIB_CONST
-# conditional library dependencies, in linking order
+# conditional library dependencies, in any order
enabled afftfilt_filter && prepend avfilter_deps "avcodec"
enabled afir_filter && prepend avfilter_deps "avcodec"
enabled amovie_filter && prepend avfilter_deps "avformat avcodec"
@@ -6889,11 +6890,36 @@ enabled sdl2_outdev && add_cflags $(filter_out '-Dmain=SDL_main' $sdl2_cflag
enabled opus_decoder&& prepend avcodec_deps "swresample"
+# reorder the items at var $1 to align with the items order at var $2 .
+# die if an item at $1 is not at $2 .
+reorder_by(){
+eval rb_in=\$$1
+eval rb_ordered=\$$2
+
+for rb in $rb_in; do
+is_in $rb $rb_ordered || die "$rb at \$$1 is not at \$$2"
+done
+
+rb_out=
+for rb in $rb_ordered; do
+is_in $rb $rb_in && rb_out="$rb_out$rb "
+done
+eval $1=\$rb_out
+}
+
+# deps-expand fflib $1: N x {append all expanded deps; unique}
+# within a set of N items, N expansions are enough to expose a cycle.
expand_deps(){
-lib_deps=${1}_deps
-eval "deps=\$$lib_deps"
-append $lib_deps $(map 'eval echo \$${v}_deps' $deps)
-unique $lib_deps
+unique ${1}_deps # required for the early break test.
+for dummy in $LIBRARY_LIST; do # N iteratios
+eval deps=\$${1}_deps
+append ${1}_deps $(map 'eval echo \$${v}_deps' $deps)
+unique ${1}_deps
+eval '[ ${#deps} = ${#'${1}_deps'} ]' && break # doesn't expand anymore
+done
+
+eval is_in $1 \$${1}_deps && die "Dependency cycle at ${1}_deps"
+reorder_by ${1}_deps LIBRARY_LIST # linking order is expected later
}
#we have to remove gpl from the deps here as some code assumes all lib deps are libs
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: remove unsupported PCE mappings
On 28 August 2018 at 22:29, Rostislav Pehlivanov wrote: > Turns out those ones make the decoder unable to accurately determine the > layout, hence making some API users' guess, and sometimes those are correct > (ffmpeg.c), but most often (especially with side channels) they're wrong. > The removed ones need to be investigated into as to why the decoder rejects > them. > > Signed-off-by: Rostislav Pehlivanov > --- > libavcodec/aacenc.h | 177 > 1 file changed, 177 deletions(-) > CCing pkv, if you have the time can you go over what's happening? Its a bit suspicious that 5.1, 6.1, 7.1, etc. don't use TYPE_LFE but rather just an SCE (there's a difference in coding). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] make work (live) libsrt
Hello Marton, And should simply set SRTO_PACKETSIZE to our pkt_size parameter if we > don't want the libsrt default 1356. > At least for the specific case of mpegts I believe it's much better to have fixed size packets(188x*). It helps error recovery if we don't have to re-synchronize ts so (7*188=1316) seems a better default. The 1356 value could be treated as a maximum special case value, all sorts of network configurations can eat from the MTU (vpn comes to mind). If I understand correctly the working of libsrt, it "creates" a packet each time we send it some data. So without touching on the "maximum" value, h->max_packet_size insures that the "medium" value is effectively the expected one. The 1356 value, assuming no vpn/tunnel will spoil the party, will make ts advance with 40 bytes each packet, so almost any packet loss will produce ts that does not start with ts header. This doesn't seem good for packet loss recovery. Rtp encapsulated mpeg ts with pkt_size of 1316 will add an rtp header of ~ 12 bytes so the needed srt payloadsize will be 1328. As wireshark does not recognize the protocol yet, I couldn't check in detail. I'm absolutely certain that ffmpeg will do bad things if rtp header is misplaced (not synchronized with a lost packet), it will end up happily reading random ts data as rtp header at some point given enough packet loss. Regards, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: block output == input for files
On 29-08-2018 02:43 AM, Michael Niedermayer wrote: On Tue, Aug 28, 2018 at 08:31:51AM +0200, Marton Balint wrote: Instead of this, maybe we should add support to write lock the files when opening them for reading. Then ffmpeg can request this. That would be an useful option, and not just for unexperienced users. depending on how this is done, it could interfere with reading a file while it is being written/appeneded to by another process Yes, a user may use a growing MPEG-TS file as input. Also, is there a universal & portable way to secure a write lock across all platforms? I think a 'soft' solution is preferable. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
