Re: [FFmpeg-devel] [PATCH] avfilter/tests/integral: Check malloc fail before using it
On Sun, Feb 10, 2019 at 01:07:20PM +0800, Jun Zhao wrote: > Need to check malloc fail before using it, so adjust the location > in the code. > > Signed-off-by: Jun Zhao > --- > libavfilter/tests/integral.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/tests/integral: Fix build warning after adjust the location
On Sun, Feb 10, 2019 at 02:53:57PM +0800, Jun Zhao wrote: > Fix build warning like "warning: ISO C90 forbids mixed declarations > and code" after adjust the location for malloc fail check. > > Signed-off-by: Jun Zhao > --- > libavfilter/tests/integral.c |9 + > 1 files changed, 5 insertions(+), 4 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: don't rescale mastering display values from the SmDm atom
On Sat, Feb 09, 2019 at 08:21:41PM -0300, James Almer wrote: > Simplifies code. > > Signed-off-by: James Almer > --- > libavformat/mov.c | 21 - > 1 file changed, 8 insertions(+), 13 deletions(-) probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 08/11] vaapi_encode_mjpeg: Warn if input is not full range
On Sun, Feb 10, 2019 at 06:21:42PM +, Mark Thompson wrote:
> On 05/02/2019 13:27, Carl Eugen Hoyos wrote:
> > 2019-01-28 0:47 GMT+01:00, Mark Thompson :
> >
> >> +if (avctx->color_range == AVCOL_RANGE_MPEG) {
> >> +av_log(avctx, AV_LOG_WARNING, "Input video does not appear "
> >> + "to use full-range: output colours may be incorrect.\n");
> >
> > The wording seems not ideal to me:
> > Are you not sure if the encoder will produce correct output for
> > mpeg-range jpeg?
> > That's how it sounds to me...
>
> The problem is that, unlike H.264 and other codecs, JPEG has no way to signal
> that the data are actually limited-range. The encode will preserve the
> values, but those values will not have the right interpretation at a remote
> end which only looks at the JPEG data. On the other hand, if signalled by
> some out-of-band method (perhaps the container, or you control both ends)
> everything is perfectly usable.
>
> I agree the message isn't particularly clear; do you have any thoughts about
> how it should be phrased?
It might be worse than that.
assuming this code is used for mjpeg not just jpeg images then
IIRC some mjpeg variants in avi use the mpeg style not full range. But i might
misremember this is very long ago
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] av_write_frame(ofmt_ctx, pkt) and localtime/gmtime
Wondering how is the localtime/gmtime is calculated for writing to each frame. Is it based on pts or systemtime at the time of writing. Where exactly does that code reside ? Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/cdg: unset duration on packets
CDG doesn't ensure a constant framerate as we can have holes in the CDG
stream. So there is no guarantee of the duration of a single frame, it
will be displayed until a new packet with CDG instruction arrives in the
stream.
Signed-off-by: Guillaume Desmottes
---
libavformat/cdg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/cdg.c b/libavformat/cdg.c
index 05cac6e528..078e985223 100644
--- a/libavformat/cdg.c
+++ b/libavformat/cdg.c
@@ -74,6 +74,7 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt)
pkt->stream_index = 0;
pkt->dts=
pkt->pts= pkt->pos / CDG_PACKET_SIZE;
+pkt->duration = AV_NOPTS_VALUE;
if(ret>5 && (pkt->data[0]&0x3F) == 9 && (pkt->data[1]&0x3F)==1 &&
!(pkt->data[2+2+1] & 0x0F)){
pkt->flags = AV_PKT_FLAG_KEY;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
On Mon, Feb 11, 2019 at 05:41:04PM -0500, Shaofei Wang wrote: > It enabled multiple filter graph concurrency, which bring above about > 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration > > Below are some test cases and comparison as reference. > (Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz) > (Software: Intel iHD driver - 16.9.00100, CentOS 7) > > For 1:N transcode by GPU acceleration with vaapi: > ./ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi \ > -hwaccel_output_format vaapi \ > -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \ > -vf "scale_vaapi=1280:720" -c:v h264_vaapi -f null /dev/null \ > -vf "scale_vaapi=720:480" -c:v h264_vaapi -f null /dev/null > > test results: > 2 encoders 5 encoders 10 encoders > Improved 6.1%6.9% 5.5% > > For 1:N transcode by GPU acceleration with QSV: > ./ffmpeg -hwaccel qsv -c:v h264_qsv \ > -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \ > -vf "scale_qsv=1280:720:format=nv12" -c:v h264_qsv -f null /dev/null \ > -vf "scale_qsv=720:480:format=nv12" -c:v h264_qsv -f null /dev/null > > test results: > 2 encoders 5 encoders 10 encoders > Improved 6% 4% 15% > > For Intel GPU acceleration case, 1 decode to N scaling, by QSV: > ./ffmpeg -hwaccel qsv -c:v h264_qsv \ > -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \ > -vf "scale_qsv=1280:720:format=nv12,hwdownload" -pix_fmt nv12 -f null > /dev/null \ > -vf "scale_qsv=720:480:format=nv12,hwdownload" -pix_fmt nv12 -f null > /dev/null > > test results: > 2 scale 5 scale 10 scale > Improved 12% 21%21% > > For CPU only 1 decode to N scaling: > ./ffmpeg -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \ > -vf "scale=1280:720" -pix_fmt nv12 -f null /dev/null \ > -vf "scale=720:480" -pix_fmt nv12 -f null /dev/null > > test results: > 2 scale 5 scale 10 scale > Improved 25%107% 148% > > Signed-off-by: Wang, Shaofei > Reviewed-by: Zhao, Jun > --- > fftools/ffmpeg.c| 112 > +--- > fftools/ffmpeg.h| 14 ++ > fftools/ffmpeg_filter.c | 4 ++ > 3 files changed, 124 insertions(+), 6 deletions(-) breaks fate make: *** [fate-lavf-mxf_d10] Error 1 make: *** [fate-filter-tremolo] Error 1 make: *** [fate-filter-chorus] Error 1 make: *** [tests/data/hls-list-append.m3u8] Error 1 make: *** [fate-filter-atrim-mixed] Error 1 make: *** [fate-filter-atrim-time] Error 1 make: *** [tests/data/live_last_endlist.m3u8] Error 1 make: *** [fate-filter-volume] Error 1 make: *** [fate-filter-join] Error 1 make: *** [fate-lavf-mxf] Error 1 make: *** [fate-swr-resample-s16p-44100-8000] Error 1 make: *** [fate-swr-resample-s16p-44100-2626] Error 1 ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option
On Sat, Feb 9, 2019 at 3:15 AM Carl Eugen Hoyos wrote:
>
> 2019-02-09 7:49 GMT+01:00, Gyan :
> >
> >
> > On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
> >> 2019-02-08 6:08 GMT+01:00, Gyan :
> >>>
> >>> On 08-02-2019 03:31 AM, Carl Eugen Hoyos wrote:
> .
> No strong opinion here, I hadn't realized that -crf 0 only works with
> newer versions.
>
> Can you explain why crf alone has no effect and needs -b:v 0?
> Isn't this a bug both with libvpx and libaom?
>
> >>> With crf present but VBV params absent, VPX operates using a constrained
> >>> Q RC mode , where the target bitrate acts as a ceiling. Since acvodec
> >>> has a non-zero default -b of 200 kbps, this produces undesirable
> >>> effects. If set to 0, VPX switches to constant quality.
> >> Yes.
> >> This looks like a bug to me.
> >
> > If there's a bug, it's in libav, in that, we can't signal when a value
> > is assigned by the user or via user-initiated logic, versus being
> > assigned as a default fallback. So it's a design conflict, and the
> > workaround has been long documented.
> >
> > Maybe just before the next major bump, a new field should be
> > introduced in AVOptions which registers if the field was
> > populated at the behest of the user.
>
> We could set the default for "b" to "0" without a major bump.
>
> Is it expected that constant crf with vp8 leads to broken output?
>
> >>> I do see this block though,
> >>>
> >>> if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->lossless == 1) {
> >>> enccfg.rc_min_quantizer =
> >>> enccfg.rc_max_quantizer = 0;
> >>> } else {
> >>> if (avctx->qmin >= 0)
> >>> enccfg.rc_min_quantizer = avctx->qmin;
> >>> if (avctx->qmax >= 0)
> >>> enccfg.rc_max_quantizer = avctx->qmax;
> >>> }
> >>>
> >>>
> >>> Looks like the quantizer range is disabled only by using the deprecated
> >>> option, or has this changed?
> >> Is your question "Isn't 'lossless 1' necessary for lossless encoding"?
> >
> > Yes. A quick glance at vpx HEAD indicates it is, although
> > -qmin & -qmax 0 should also work.
>
> Given that it works for most frames, I wonder what the technical
> background is...
>
I believe the option was added as a convenience in vp9. The parameter
here matches what vpxenc uses, but min/max-q=0 is equivalent.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: warn about disabled explicitly enabled components
On Sun, 10 Feb 2019, Marton Balint wrote: On Sat, 9 Feb 2019, Marton Balint wrote: On Sat, 9 Feb 2019, Carl Eugen Hoyos wrote: 2019-02-05 22:14 GMT+01:00, Marton Balint : If we enable a component but a dependant library is disabled, then the enabled component gets silently disabled. Warning about disabled explicitly enabled components allows configure to show the missing dependencies and if --fatal-warnings is used it can also fail if the user wants it so. For example if libdav1d is not availble ./configure --enable-decoder=libdav1d succeeds but the libdav1d decoder is not be enabled. After the patch configure will warn about this: WARNING: Disabled libdav1d_decoder because not all dependencies are satisfied: libdav1d The patch produces many warnings for: $ ./configure --disable-everything --enable-decoder=mp* Is this intended? It reports only disabled decoders which start with mp, so it works as it should the way I see it. Will push this soon. Applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
On Sun, 10 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-10 23:04 GMT+01:00, Marton Balint :
On Sun, 3 Feb 2019, Charles Liu wrote:
Binary searching would hang if the fragment items do NOT have timestamp
for the specified stream.
For example, a fmp4 consists of separated 'moof' boxes for each track, and
separated 'sidx' for each segment, but no 'mfra' box.
Then every fragment item only have the timestamp for one of its tracks.
Signed-off-by: Charles Liu
---
libavformat/mov.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..35cb619e9f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1266,7 +1266,7 @@ static int64_t get_frag_time(MOVFragmentIndex
*frag_index,
static int search_frag_timestamp(MOVFragmentIndex *frag_index,
AVStream *st, int64_t timestamp)
{
-int a, b, m;
+int a, b, m, m0;
int64_t frag_time;
int id = -1;
@@ -1282,15 +1282,18 @@ static int search_frag_timestamp(MOVFragmentIndex
*frag_index,
b = frag_index->nb_items;
while (b - a > 1) {
-m = (a + b) >> 1;
-frag_time = get_frag_time(frag_index, m, id);
-if (frag_time != AV_NOPTS_VALUE) {
-if (frag_time >= timestamp)
-b = m;
-if (frag_time <= timestamp)
-a = m;
-}
+m0 = m = (a + b) >> 1;
+
+while (m < b &&
+ (frag_time = get_frag_time(frag_index, m, id)) ==
AV_NOPTS_VALUE)
+m++;
+
+if (m < b && frag_time <= timestamp)
+a = m;
+else
+b = m0;
}
+
return a;
}
As this fixes a hang, I will push this version soon.
Please mention ticket #7572 in the commit message.
Sure. Pushed.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] libavcodec/cbs: Stop needlessly reallocating the units array
Currently, a fragment's unit array is constantly reallocated during
splitting of a packet. This commit changes this: One can keep the units
array by distinguishing between the number of allocated and the number
of valid units in the units array.
The more units a packet is split into, the bigger the benefit.
So MPEG-2 benefits the most; for a video coming from an NTSC-DVD
(usually 32 units per frame) the average cost of cbs_insert_unit (for a
single unit) went down from 6717 decicycles to 450 decicycles (based
upon 10 runs with 4194304 runs each); if each packet consists of only
one unit, it went down from 2425 to 448; for a H.264 video where most
packets contain nine units, it went from 4431 to 450.
Signed-off-by: Andreas Rheinhardt
---
This time I have also changed VAAPI to stop reallocating the units
array. Keep in mind that I couldn't test this at all.
libavcodec/av1_metadata_bsf.c | 6 ++-
libavcodec/av1_parser.c | 5 ++-
libavcodec/cbs.c| 62 +
libavcodec/cbs.h| 33 +--
libavcodec/filter_units_bsf.c | 7 ++--
libavcodec/h264_metadata_bsf.c | 6 ++-
libavcodec/h264_redundant_pps_bsf.c | 6 ++-
libavcodec/h265_metadata_bsf.c | 6 ++-
libavcodec/mpeg2_metadata_bsf.c | 6 ++-
libavcodec/trace_headers_bsf.c | 5 ++-
libavcodec/vaapi_encode_h264.c | 9 +++--
libavcodec/vaapi_encode_h265.c | 9 +++--
libavcodec/vaapi_encode_mjpeg.c | 3 +-
libavcodec/vaapi_encode_mpeg2.c | 5 ++-
libavcodec/vp9_metadata_bsf.c | 4 +-
15 files changed, 113 insertions(+), 59 deletions(-)
diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
index 52d383661f..2b74b697e4 100644
--- a/libavcodec/av1_metadata_bsf.c
+++ b/libavcodec/av1_metadata_bsf.c
@@ -170,7 +170,7 @@ static int av1_metadata_filter(AVBSFContext *bsf, AVPacket
*out)
err = 0;
fail:
-ff_cbs_fragment_uninit(ctx->cbc, frag);
+ff_cbs_fragment_reset(ctx->cbc, frag);
if (err < 0)
av_packet_unref(out);
@@ -215,13 +215,15 @@ static int av1_metadata_init(AVBSFContext *bsf)
err = 0;
fail:
-ff_cbs_fragment_uninit(ctx->cbc, frag);
+ff_cbs_fragment_reset(ctx->cbc, frag);
return err;
}
static void av1_metadata_close(AVBSFContext *bsf)
{
AV1MetadataContext *ctx = bsf->priv_data;
+
+ff_cbs_fragment_free(ctx->cbc, >access_unit);
ff_cbs_close(>cbc);
}
diff --git a/libavcodec/av1_parser.c b/libavcodec/av1_parser.c
index 8df66498f4..bb8737a393 100644
--- a/libavcodec/av1_parser.c
+++ b/libavcodec/av1_parser.c
@@ -72,7 +72,7 @@ static int av1_parser_parse(AVCodecParserContext *ctx,
goto end;
}
-ff_cbs_fragment_uninit(s->cbc, td);
+ff_cbs_fragment_reset(s->cbc, td);
}
ret = ff_cbs_read(s->cbc, td, data, size);
@@ -159,7 +159,7 @@ static int av1_parser_parse(AVCodecParserContext *ctx,
}
end:
-ff_cbs_fragment_uninit(s->cbc, td);
+ff_cbs_fragment_reset(s->cbc, td);
s->cbc->log_ctx = NULL;
@@ -193,6 +193,7 @@ static void av1_parser_close(AVCodecParserContext *ctx)
{
AV1ParseContext *s = ctx->priv_data;
+ff_cbs_fragment_free(s->cbc, >temporal_unit);
ff_cbs_close(>cbc);
}
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index ecbf57c293..c388be896b 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -136,14 +136,13 @@ static void cbs_unit_uninit(CodedBitstreamContext *ctx,
unit->data_bit_padding = 0;
}
-void ff_cbs_fragment_uninit(CodedBitstreamContext *ctx,
-CodedBitstreamFragment *frag)
+void ff_cbs_fragment_reset(CodedBitstreamContext *ctx,
+ CodedBitstreamFragment *frag)
{
int i;
for (i = 0; i < frag->nb_units; i++)
cbs_unit_uninit(ctx, >units[i]);
-av_freep(>units);
frag->nb_units = 0;
av_buffer_unref(>data_ref);
@@ -152,6 +151,15 @@ void ff_cbs_fragment_uninit(CodedBitstreamContext *ctx,
frag->data_bit_padding = 0;
}
+void ff_cbs_fragment_free(CodedBitstreamContext *ctx,
+ CodedBitstreamFragment *frag)
+{
+ff_cbs_fragment_reset(ctx, frag);
+
+av_freep(>units);
+frag->nb_units_allocated = 0;
+}
+
static int cbs_read_fragment_content(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag)
{
@@ -216,8 +224,6 @@ int ff_cbs_read_extradata(CodedBitstreamContext *ctx,
{
int err;
-memset(frag, 0, sizeof(*frag));
-
err = cbs_fill_fragment_data(ctx, frag, par->extradata,
par->extradata_size);
if (err < 0)
@@ -236,8 +242,6 @@ int ff_cbs_read_packet(CodedBitstreamContext *ctx,
{
int err;
-memset(frag, 0, sizeof(*frag));
-
if (pkt->buf) {
frag->data_ref = av_buffer_ref(pkt->buf);
if (!frag->data_ref)
@@ -265,8 +269,6 @@ int ff_cbs_read(CodedBitstreamContext *ctx,
{
[FFmpeg-devel] [PATCH 1/2] filter_units, trace_headers: Always use fragment from context
This is in preparation for another patch that will stop needless
reallocations of the unit array.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/filter_units_bsf.c | 8
libavcodec/trace_headers_bsf.c | 13 +++--
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/libavcodec/filter_units_bsf.c b/libavcodec/filter_units_bsf.c
index 1ee0afdf2b..0500dea6b2 100644
--- a/libavcodec/filter_units_bsf.c
+++ b/libavcodec/filter_units_bsf.c
@@ -199,18 +199,18 @@ static int filter_units_init(AVBSFContext *bsf)
ctx->cbc->nb_decompose_unit_types = 0;
if (bsf->par_in->extradata) {
-CodedBitstreamFragment ps;
+CodedBitstreamFragment *frag = >fragment;
-err = ff_cbs_read_extradata(ctx->cbc, , bsf->par_in);
+err = ff_cbs_read_extradata(ctx->cbc, frag, bsf->par_in);
if (err < 0) {
av_log(bsf, AV_LOG_ERROR, "Failed to read extradata.\n");
} else {
-err = ff_cbs_write_extradata(ctx->cbc, bsf->par_out, );
+err = ff_cbs_write_extradata(ctx->cbc, bsf->par_out, frag);
if (err < 0)
av_log(bsf, AV_LOG_ERROR, "Failed to write extradata.\n");
}
-ff_cbs_fragment_uninit(ctx->cbc, );
+ff_cbs_fragment_uninit(ctx->cbc, frag);
}
return err;
diff --git a/libavcodec/trace_headers_bsf.c b/libavcodec/trace_headers_bsf.c
index 839d4c..61284e615e 100644
--- a/libavcodec/trace_headers_bsf.c
+++ b/libavcodec/trace_headers_bsf.c
@@ -28,6 +28,7 @@
typedef struct TraceHeadersContext {
CodedBitstreamContext *cbc;
+CodedBitstreamFragment fragment;
} TraceHeadersContext;
@@ -44,13 +45,13 @@ static int trace_headers_init(AVBSFContext *bsf)
ctx->cbc->trace_level = AV_LOG_INFO;
if (bsf->par_in->extradata) {
-CodedBitstreamFragment ps;
+CodedBitstreamFragment *frag = >fragment;
av_log(bsf, AV_LOG_INFO, "Extradata\n");
-err = ff_cbs_read_extradata(ctx->cbc, , bsf->par_in);
+err = ff_cbs_read_extradata(ctx->cbc, frag, bsf->par_in);
-ff_cbs_fragment_uninit(ctx->cbc, );
+ff_cbs_fragment_uninit(ctx->cbc, frag);
}
return err;
@@ -66,7 +67,7 @@ static void trace_headers_close(AVBSFContext *bsf)
static int trace_headers(AVBSFContext *bsf, AVPacket *pkt)
{
TraceHeadersContext *ctx = bsf->priv_data;
-CodedBitstreamFragment au;
+CodedBitstreamFragment *frag = >fragment;
char tmp[256] = { 0 };
int err;
@@ -92,9 +93,9 @@ static int trace_headers(AVBSFContext *bsf, AVPacket *pkt)
av_log(bsf, AV_LOG_INFO, "Packet: %d bytes%s.\n", pkt->size, tmp);
-err = ff_cbs_read_packet(ctx->cbc, , pkt);
+err = ff_cbs_read_packet(ctx->cbc, frag, pkt);
-ff_cbs_fragment_uninit(ctx->cbc, );
+ff_cbs_fragment_uninit(ctx->cbc, frag);
if (err < 0)
av_packet_unref(pkt);
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: parse some stream specifiers recursively
On Tue, 5 Feb 2019, Marton Balint wrote:
This removes lots of code duplication and also allows more complex specifiers,
for example you can use p:204:a:m:language:eng to select the English language
audio stream from program 204.
Ping... Will apply soon.
Thanks,
Marton
Signed-off-by: Marton Balint
---
doc/fftools-common-opts.texi | 30 +++-
libavformat/utils.c | 172 +--
2 files changed, 65 insertions(+), 137 deletions(-)
diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index 84705c0b68..43c1f4d2d6 100644
--- a/doc/fftools-common-opts.texi
+++ b/doc/fftools-common-opts.texi
@@ -34,27 +34,21 @@ Possible forms of stream specifiers are:
@table @option
@item @var{stream_index}
Matches the stream with this index. E.g. @code{-threads:1 4} would set the
-thread count for the second stream to 4.
-@item @var{stream_type}[:@var{stream_index}]
+thread count for the second stream to 4. If @var{stream_index} is used as an
+additional stream specifier (see below), then it selects stream number
+@var{stream_index} from the matching streams.
+@item @var{stream_type}[:@var{additional_stream_specifier}]
@var{stream_type} is one of following: 'v' or 'V' for video, 'a' for audio, 's'
for subtitle, 'd' for data, and 't' for attachments. 'v' matches all video
streams, 'V' only matches video streams which are not attached pictures, video
-thumbnails or cover arts. If @var{stream_index} is given, then it matches
-stream number @var{stream_index} of this type. Otherwise, it matches all
-streams of this type.
-@item p:@var{program_id}[:@var{stream_index}] or
p:@var{program_id}[:@var{stream_type}[:@var{stream_index}]] or
-p:@var{program_id}:m:@var{key}[:@var{value}]
-In first version, if @var{stream_index} is given, then it matches the stream
with number @var{stream_index}
-in the program with the id @var{program_id}. Otherwise, it matches all streams
in the
-program. In the second version, @var{stream_type} is one of following: 'v' for
video, 'a' for audio, 's'
-for subtitle, 'd' for data. If @var{stream_index} is also given, then it
matches
-stream number @var{stream_index} of this type in the program with the id
@var{program_id}.
-Otherwise, if only @var{stream_type} is given, it matches all
-streams of this type in the program with the id @var{program_id}.
-In the third version matches streams in the program with the id
@var{program_id} with the metadata
-tag @var{key} having the specified value. If
-@var{value} is not given, matches streams that contain the given tag with any
-value.
+thumbnails or cover arts. If @var{additional_stream_specifier} is used, then
+it matches streams which both have this type and match the
+@var{additional_stream_specifier}. Otherwise, it matches all streams of the
+specified type.
+@item p:@var{program_id}[:@var{additional_stream_specifier}]
+Matches streams which are in the program with the id @var{program_id}. If
+@var{additional_stream_specifier} is used, then it matches streams which both
+are part of the program and match the @var{additional_stream_specifier}.
@item #@var{stream_id} or i:@var{stream_id}
Match the stream by stream id (e.g. PID in MPEG-TS container).
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 7afef545fe..b3c30fe14c 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5097,13 +5097,21 @@ AVRational av_guess_frame_rate(AVFormatContext *format,
AVStream *st, AVFrame *f
return fr;
}
-int avformat_match_stream_specifier(AVFormatContext *s, AVStream *st,
-const char *spec)
-{
-if (*spec <= '9' && *spec >= '0') /* opt:index */
-return strtol(spec, NULL, 0) == st->index;
-else if (*spec == 'v' || *spec == 'a' || *spec == 's' || *spec == 'd' ||
- *spec == 't' || *spec == 'V') { /* opt:[vasdtV] */
+/* Matches a stream specifier (but ignores requested index)
+ * Returns:
+ * - negative on error
+ * - 0 if st is NOT a matching stream
+ * - >0 if st is a matching stream
+ * *index is set if a specific index is requested from the matching streams. */
+static int match_stream_specifier(AVFormatContext *s, AVStream *st,
+ const char *spec, int *index)
+{
+if (*spec <= '9' && *spec >= '0') { /* opt:index */
+if (index)
+*index = strtol(spec, NULL, 0);
+return 1;
+} else if (*spec == 'v' || *spec == 'a' || *spec == 's' || *spec == 'd' ||
+ *spec == 't' || *spec == 'V') { /* opt:[vasdtV] */
enum AVMediaType type;
int nopic = 0;
@@ -5128,27 +5136,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
#endif
if (nopic && (st->disposition & AV_DISPOSITION_ATTACHED_PIC))
return 0;
-if (*spec++ == ':') { /* possibly followed by :index */
-int i, index = strtol(spec, NULL, 0);
-for (i = 0; i < s->nb_streams; i++) {
-#if FF_API_LAVF_AVCTX
-FF_DISABLE_DEPRECATION_WARNINGS
-
Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar
On Fri, Feb 8, 2019 at 2:37 PM Michael Niedermayer wrote: > ogg allows chaining streams when they have differing serial numbers > https://xiph.org/ogg/doc/oggstream.html > > i think ive seen actual files doing this > > ogg_replace_stream() might assign these into existing avstreams i think > If I'm reading this correctly, I think that should always happen at the boundary of a new ogg page, meaning it wouldn't rely on this multiple headers logic? I found the commit where this was introduced https://github.com/FFmpeg/FFmpeg/commit/81b743eb1026547270b88ac6a5cb451a3907ee94?diff=split With the description: This fixes some old ogm files that had the 3rd vorbis header after a data packet in another stream. This is invalid in ogg, but this change shouldn't affect the behaviour of any valid file. So, I don't think we're going to find spec text for this. No spec for OGM and committer indicates its not valid Ogg. I'm guessing we want to still support these ogm files? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/cdg: unset duration on packets
On Mon, Feb 11, 2019 at 05:59:34PM +0100, Guillaume Desmottes wrote: > CDG doesn't ensure a constant framerate as we can have holes in the CDG > stream. So there is no guarantee of the duration of a single frame, it > will be displayed until a new packet with CDG instruction arrives in the > stream. > > Signed-off-by: Guillaume Desmottes > --- > libavformat/cdg.c | 1 + > 1 file changed, 1 insertion(+) breaks fate-cdgraphics [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avformat/mpegtsenc: add support for service and provider names with utf8 encoding
Signed-off-by: Marton Balint
---
libavformat/mpegtsenc.c | 76 +++--
1 file changed, 49 insertions(+), 27 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 4470b7120c..a600394619 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -54,8 +54,8 @@ typedef struct MpegTSSection {
typedef struct MpegTSService {
MpegTSSection pmt; /* MPEG-2 PMT table context */
int sid; /* service ID */
-char *name;
-char *provider_name;
+uint8_t *name;
+uint8_t *provider_name;
int pcr_pid;
int pcr_packet_count;
int pcr_packet_period;
@@ -264,26 +264,10 @@ static void mpegts_write_pat(AVFormatContext *s)
data, q - data);
}
-/* NOTE: !str is accepted for an empty string */
-static void putstr8(uint8_t **q_ptr, const char *str, int write_len)
+static void putbuf(uint8_t **q_ptr, const uint8_t *buf, int len)
{
-uint8_t *q;
-int len;
-
-q = *q_ptr;
-if (!str)
-len = 0;
-else
-len = strlen(str);
-if (write_len)
-*q++ = len;
-if (!str) {
-*q_ptr = q;
-return;
-}
-memcpy(q, str, len);
-q += len;
-*q_ptr = q;
+memcpy(*q_ptr, buf, len);
+*q_ptr += len;
}
static int mpegts_write_pmt(AVFormatContext *s, MpegTSService *service)
@@ -646,9 +630,9 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
*q++ = 0x26; /* metadata descriptor */
*q++ = 13;
put16(, 0x);/* metadata application format */
-putstr8(, tag, 0);
+putbuf(, tag, strlen(tag));
*q++ = 0xff;/* metadata format */
-putstr8(, tag, 0);
+putbuf(, tag, strlen(tag));
*q++ = 0;/* metadata service ID */
*q++ = 0xF; /*
metadata_locator_record_flag|MPEG_carriage_flags|reserved */
}
@@ -695,8 +679,8 @@ static void mpegts_write_sdt(AVFormatContext *s)
desc_len_ptr = q;
q++;
*q++ = ts->service_type;
-putstr8(, service->provider_name, 1);
-putstr8(, service->name, 1);
+putbuf(, service->provider_name, service->provider_name[0] + 1);
+putbuf(, service->name, service->name[0] + 1);
desc_len_ptr[0] = q - desc_len_ptr - 1;
/* fill descriptor length */
@@ -709,6 +693,44 @@ static void mpegts_write_sdt(AVFormatContext *s)
data, q - data);
}
+/* This allocates a buffer with a string with the correct encoding and also
+ * sets the first byte as the length. !str is accepted for an empty string.
+ *
+ * If the string is already encoded, invalid UTF-8 or has no multibyte sequence
+ * then we keep it as is, otherwise we signal UTF-8 encoding. */
+static uint8_t *encode_str8(const char *str)
+{
+size_t str_len;
+uint8_t *buf = av_malloc(256);
+if (!buf)
+return NULL;
+if (!str)
+str = "";
+str_len = strlen(str);
+if (str[0] && (unsigned)str[0] >= 0x20) { /* Make sure the string is not
already encoded. */
+const uint8_t *q = str;
+int has_multibyte = 0;
+while (*q) {
+uint32_t code;
+GET_UTF8(code, *q++, goto invalid;) /* Is it valid UTF-8? */
+has_multibyte |= (code > 127); /* Does it have multibyte
UTF-8 chars in it? */
+}
+if (has_multibyte) {/* If we have multibyte chars
and valid UTF-8, then encode as such! */
+str_len = FFMIN(str_len, 254);
+buf[0] = str_len + 1;
+buf[1] = 0x15;
+memcpy([2], str, str_len);
+return buf;
+}
+}
+invalid:
+/* Otherwise let's just encode the string as is! */
+str_len = FFMIN(255, str_len);
+buf[0] = str_len;
+memcpy([1], str, str_len);
+return buf;
+}
+
static MpegTSService *mpegts_add_service(MpegTSWrite *ts, int sid,
const char *provider_name,
const char *name)
@@ -721,8 +743,8 @@ static MpegTSService *mpegts_add_service(MpegTSWrite *ts,
int sid,
service->pmt.pid = ts->pmt_start_pid + ts->nb_services;
service->sid = sid;
service->pcr_pid = 0x1fff;
-service->provider_name = av_strdup(provider_name);
-service->name = av_strdup(name);
+service->provider_name = encode_str8(provider_name);
+service->name = encode_str8(name);
if (!service->provider_name || !service->name)
goto fail;
if (av_dynarray_add_nofree(>services, >nb_services, service) < 0)
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avformat/mpegts: fix charset of type 0x11
ISO-10646 alone means UCS-4 for iconv, the specs refers to the Basic Multilingual Plane (BMP), therefore we need UCS-2. VLC also using that. Signed-off-by: Marton Balint --- libavformat/mpegts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c index b347ec1736..2594b1eeb1 100644 --- a/libavformat/mpegts.c +++ b/libavformat/mpegts.c @@ -683,7 +683,7 @@ static char *getstr8(const uint8_t **pp, const uint8_t *p_end) "ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7", "ISO-8859-8", "ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "", "ISO-8859-13", "ISO-8859-14", "ISO-8859-15", "", "", "", "", -"", "ISO-10646", "KSC_5601", "GB2312", "UCS-2BE", "UTF-8", "", "", +"", "UCS-2BE", "KSC_5601", "GB2312", "UCS-2BE", "UTF-8", "", "", "", "", "", "", "", "", "", "" }; iconv_t cd; -- 2.16.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avformat/mpegts: also convert strings without a specified encoding to UTF-8
The default codepage (ISO6937) should be used in this case.
Signed-off-by: Marton Balint
---
libavformat/mpegts.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 2594b1eeb1..e7bbf3e488 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -678,7 +678,7 @@ static char *getstr8(const uint8_t **pp, const uint8_t
*p_end)
if (len > p_end - p)
return NULL;
#if CONFIG_ICONV
-if (len && *p < 0x20) {
+if (len) {
const char *encodings[] = {
"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7",
"ISO-8859-8", "ISO-8859-9", "ISO-8859-10", "ISO-8859-11",
@@ -688,16 +688,20 @@ static char *getstr8(const uint8_t **pp, const uint8_t
*p_end)
};
iconv_t cd;
char *in, *out;
-size_t inlen = len - 1, outlen = inlen * 6 + 1;
+size_t inlen = len, outlen = inlen * 6 + 1;
if (len >= 3 && p[0] == 0x10 && !p[1] && p[2] && p[2] <= 0xf && p[2]
!= 0xc) {
char iso8859[12];
snprintf(iso8859, sizeof(iso8859), "ISO-8859-%d", p[2]);
-inlen -= 2;
+inlen -= 3;
in = (char *)p + 3;
cd = iconv_open("UTF-8", iso8859);
-} else {
+} else if (p[0] < 0x20) {
+inlen -= 1;
in = (char *)p + 1;
cd = iconv_open("UTF-8", encodings[*p]);
+} else {
+in = (char *)p;
+cd = iconv_open("UTF-8", encodings[0]);
}
if (cd == (iconv_t)-1)
goto no_iconv;
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavc/libaribb24: use integer math to calculate font scaling
On Mon, Feb 11, 2019 at 03:06:54AM +0200, Jan Ekström wrote: > --- > libavcodec/libaribb24.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) LGTM thx [...] -- 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 1/4] lavc/libaribb24: add error handling to region handling
On Mon, Feb 11, 2019 at 03:06:51AM +0200, Jan Ekström wrote: > Fixes some rather embarrassing mistakes that somehow passed my > eyes. > > * Now catches if memory allocation has failed during bprint usage > by checking av_bprint_is_complete(). > * Now catches if adding an ASS rectangle into an AVSubtitle failed. > * Returns AVERROR_INVALIDDATA if we get an invalid region buffer > length. > --- > libavcodec/libaribb24.c | 25 ++--- > 1 file changed, 18 insertions(+), 7 deletions(-) probably ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] lavc/libaribb24: protect handled value with parenthesis in RGB_TO_BGR
On Mon, Feb 11, 2019 at 03:06:52AM +0200, Jan Ekström wrote: > --- > libavcodec/libaribb24.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. 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] tests/api/api-h264-test: Add AV_NOPTS_VALUE check for AVFrame.pkt_dts
On Tue, Feb 12, 2019 at 7:38 AM Michael Niedermayer wrote:
>
> On Mon, Feb 11, 2019 at 11:21:27AM +0800, Jun Zhao wrote:
> > Add AV_NOPTS_VALUE check for AVFrame.pkt_dts to avoid print the
> > pkt_dts as negative number like:
> > "0,3616613, -9223372036854775808, 1001, 3110400, 0x75e37a65"
> >
> > Signed-off-by: Jun Zhao
> > ---
> > tests/api/api-h264-test.c | 10 +++---
> > 1 files changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/tests/api/api-h264-test.c b/tests/api/api-h264-test.c
> > index 9fa..55cd6cf 100644
> > --- a/tests/api/api-h264-test.c
> > +++ b/tests/api/api-h264-test.c
> > @@ -131,9 +131,13 @@ static int video_decode_example(const char
> > *input_filename)
> > av_log(NULL, AV_LOG_ERROR, "Can't copy image to
> > buffer\n");
> > return number_of_written_bytes;
> > }
> > -printf("%d, %10"PRId64", %10"PRId64", %8"PRId64", %8d,
> > 0x%08lx\n", video_stream,
> > -fr->pts, fr->pkt_dts, fr->pkt_duration,
> > -number_of_written_bytes, av_adler32_update(0,
> > (const uint8_t*)byte_buffer, number_of_written_bytes));
> > +
> > +if (fr->pkt_dts == AV_NOPTS_VALUE)
> > +printf("%d, %10"PRId64", %s,", video_stream, fr->pts,
> > "N/A");
>
> you can simplify this by replacing %s by N/A
> also the if() else could have {} added so any future additions
> would not require the lines to be changed making future patches cleaner
>
> also av_ts2str() could be used
>
> either way, patch LGTM
>
> thanks
>
Will use av_ts2str() in the V3 patch, Tks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avformat/mpegts: also convert strings without a specified encoding to UTF-8
2019-02-11 23:42 GMT+01:00, Marton Balint : > The default codepage (ISO6937) should be used in this case. lgtm Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
On 11/02/2019 22:41, Shaofei Wang wrote:
Please avoid sending messages from the future - the list received this about
thirteen hours before its supposed send time (received "Mon, 11 Feb 2019
11:42:09 +0200", sent "Mon, 11 Feb 2019 17:41:04 -0500").
Probably the sending machine or some intermediate has an incorrect time or time
zone.
> It enabled multiple filter graph concurrency, which bring above about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
>
> Below are some test cases and comparison as reference.
> (Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
> (Software: Intel iHD driver - 16.9.00100, CentOS 7)
>
> For 1:N transcode by GPU acceleration with vaapi:
> ./ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi \
> -hwaccel_output_format vaapi \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_vaapi=1280:720" -c:v h264_vaapi -f null /dev/null \
> -vf "scale_vaapi=720:480" -c:v h264_vaapi -f null /dev/null
>
> test results:
> 2 encoders 5 encoders 10 encoders
> Improved 6.1%6.9% 5.5%
>
> For 1:N transcode by GPU acceleration with QSV:
> ./ffmpeg -hwaccel qsv -c:v h264_qsv \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_qsv=1280:720:format=nv12" -c:v h264_qsv -f null /dev/null \
> -vf "scale_qsv=720:480:format=nv12" -c:v h264_qsv -f null /dev/null
>
> test results:
> 2 encoders 5 encoders 10 encoders
> Improved 6% 4% 15%
>
> For Intel GPU acceleration case, 1 decode to N scaling, by QSV:
> ./ffmpeg -hwaccel qsv -c:v h264_qsv \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_qsv=1280:720:format=nv12,hwdownload" -pix_fmt nv12 -f null
> /dev/null \
> -vf "scale_qsv=720:480:format=nv12,hwdownload" -pix_fmt nv12 -f null
> /dev/null
>
> test results:
> 2 scale 5 scale 10 scale
> Improved 12% 21%21%
>
> For CPU only 1 decode to N scaling:
> ./ffmpeg -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale=1280:720" -pix_fmt nv12 -f null /dev/null \
> -vf "scale=720:480" -pix_fmt nv12 -f null /dev/null
>
> test results:
> 2 scale 5 scale 10 scale
> Improved 25%107% 148%
>
Some numbers for more use-cases and platforms (with different architectures and
core counts) would be a good idea if you intend to enable this by default.
Presumably it's a bit slower on less powerful machines with fewer cores when it
makes many threads, but by how much? Is that acceptable?
> Signed-off-by: Wang, Shaofei
> Reviewed-by: Zhao, Jun
> ---
> fftools/ffmpeg.c| 112
> +---
> fftools/ffmpeg.h| 14 ++
> fftools/ffmpeg_filter.c | 4 ++
> 3 files changed, 124 insertions(+), 6 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 544f1a1..67b1a2a 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -1419,13 +1419,18 @@ static void finish_output_stream(OutputStream *ost)
> *
> * @return 0 for success, <0 for severe errors
> */
> -static int reap_filters(int flush)
> +static int reap_filters(int flush, InputFilter * ifilter)
> {
> AVFrame *filtered_frame = NULL;
> int i;
>
> -/* Reap all buffers present in the buffer sinks */
> +/* Reap all buffers present in the buffer sinks or just reap specified
> + * input filter buffer */
> for (i = 0; i < nb_output_streams; i++) {
> +if (ifilter) {
> +if (ifilter != output_streams[i]->filter->graph->inputs[0])
> +continue;
> +}
No mixed declarations and code.
> OutputStream *ost = output_streams[i];
> OutputFile*of = output_files[ost->file_index];
> AVFilterContext *filter;
How carefully has this been audited to make sure that there are no data races?
The calls to init_output_stream() and do_video_out() both do /a lot/, and in
particular they interact with the InputStream which might be shared with other
threads (and indeed is in all your examples above).
> @@ -2179,7 +2184,8 @@ static int ifilter_send_frame(InputFilter *ifilter,
> AVFrame *frame)
> }
> }
>
> -ret = reap_filters(1);
> +ret = HAVE_THREADS ? reap_filters(1, ifilter) : reap_filters(1,
> NULL);
> +
> if (ret < 0 && ret != AVERROR_EOF) {
> av_log(NULL, AV_LOG_ERROR, "Error while filtering: %s\n",
> av_err2str(ret));
> return ret;
> @@ -2208,6 +2214,14 @@ static int ifilter_send_eof(InputFilter *ifilter,
> int64_t pts)
>
> ifilter->eof = 1;
>
> +#if HAVE_THREADS
> +ifilter->waited_frm = NULL;
> +pthread_mutex_lock(>process_mutex);
> +ifilter->t_end = 1;
> +pthread_cond_signal(>process_cond);
> +pthread_mutex_unlock(>process_mutex);
> +pthread_join(ifilter->f_thread, NULL);
> +#endif
>
Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark
> Thompson
> Sent: Sunday, February 10, 2019 11:51 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC
> modes
>
> On 05/02/2019 16:51, Eoff, Ullysses A wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> >> Mark Thompson
> >> Sent: Monday, February 04, 2019 1:26 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC
> >> modes
> >>
> >> On 28/01/2019 04:23, Eoff, Ullysses A wrote:
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Sunday, January 27, 2019 3:47 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC
> modes
>
> Allow setting the mode explicitly, and try to make a sensible choice
> given the available parameters if not.
> ---
> doc/encoders.texi | 24 +++
> libavcodec/vaapi_encode.c | 370 +++---
> libavcodec/vaapi_encode.h | 65 +++
> 3 files changed, 351 insertions(+), 108 deletions(-)
>
> ...
> if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
> - "supported rate control modes: assuming
> constant-quality.\n");
> -ctx->va_rc_mode = VA_RC_CQP;
> -return 0;
> ...
> >>>
> >>> With this patch series, mjpeg_vaapi encoder breaks with iHD driver:
> >>>
> >>> LIBVA_DRIVER_NAME=iHD ffmpeg -hwaccel vaapi \
> >>> -vaapi_device /dev/dri/renderD128 -v debug \
> >>> -f rawvideo -pix_fmt yuv420p -s:v 1920x1080 \
> >>> -i input.yuv -vf 'format=nv12,hwupload' -c:v mjpeg_vaapi \
> >>> -global_quality 100 -vframes 10 -y output.mjpg
> >>>
> >>>
> >>> [AVHWDeviceContext @ 0x193c580] Opened VA display via DRM device
> >>> /dev/dri/renderD128.
> >>> [AVHWDeviceContext @ 0x193c580] libva: VA-API version 1.4.0
> >>> [AVHWDeviceContext @ 0x193c580] libva: va_getDriverName() returns 0
> >>> [AVHWDeviceContext @ 0x193c580] libva: User requested driver 'iHD'
> >>> [AVHWDeviceContext @ 0x193c580] libva: Trying to open
> /home/uaeoff/Work/workspace/media/install/lib/dri/iHD_drv_video.so
> >>> [AVHWDeviceContext @ 0x193c580] libva: Found init function
> >>> __vaDriverInit_1_4
> >>> [AVHWDeviceContext @ 0x193c580] libva: va_openDriver() returns 0
> >>> [AVHWDeviceContext @ 0x193c580] Initialised VAAPI connection: version 1.4
> >>>
> >>> [mjpeg_vaapi @ 0x19847c0] Input surface format is nv12.
> >>> [mjpeg_vaapi @ 0x19847c0] Using VAAPI profile VAProfileJPEGBaseline (12).
> >>> [mjpeg_vaapi @ 0x19847c0] Using VAAPI entrypoint VAEntrypointEncPicture
> >>> (7).
> >>> [mjpeg_vaapi @ 0x19847c0] Using VAAPI render target format YUV420 (0x1).
> >>> [mjpeg_vaapi @ 0x19847c0] Driver does not report any supported rate
> >>> control modes: assuming CQP only.
> >>> [mjpeg_vaapi @ 0x19847c0] RC mode: CQP.
> >>> [mjpeg_vaapi @ 0x19847c0] RC quality: 100.
> >>> [mjpeg_vaapi @ 0x19847c0] RC framerate (CFR mode): 25/1 (25.00 fps).
> >>> [mjpeg_vaapi @ 0x19847c0] Using intra frames only.
> >>> [mjpeg_vaapi @ 0x19847c0] All wanted packed headers available (wanted
> >>> 0x10, found 0x10).
> >>> [mjpeg_vaapi @ 0x19847c0] Failed to create encode pipeline configuration:
> >>> 10 (attribute not supported).
> >>> Error initializing output stream 0:0 -- Error while opening encoder for
> >>> output stream #0:0 - maybe incorrect parameters such as
> >> bit_rate, rate, width or height
> >>> [AVIOContext @ 0x1987000] Statistics: 0 seeks, 0 writeouts
> >>> [AVIOContext @ 0x19802c0] Statistics: 3110400 bytes read, 0 seeks
> >>> Conversion failed!
> >>>
> >>> ... it works fine on i965 driver.
> >>
> >> Right, the specific workaround to not set any options on drivers which
> >> report no supported RC modes (highlighted above) needs to
> be
> >> carried forward to this. Added.
> >>
> >> Thank you for testing!
> >>
> >
> > Is there a v3 I can test? Thanks.
>
> New version sent. It now doesn't bail out from that function early because
> it does want to do some other setup there; instead it just
> avoids setting that particular attribute at the end if the driver has
> declared that it doesn't support it.
>
[UAE] Yep, v3 works now. Thanks.
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mpegts: fix charset of type 0x11
2019-02-11 23:42 GMT+01:00, Marton Balint : > ISO-10646 alone means UCS-4 for iconv, the specs refers to the Basic > Multilingual Plane (BMP), therefore we need UCS-2. VLC also using that. > > Signed-off-by: Marton Balint > --- > libavformat/mpegts.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c > index b347ec1736..2594b1eeb1 100644 > --- a/libavformat/mpegts.c > +++ b/libavformat/mpegts.c > @@ -683,7 +683,7 @@ static char *getstr8(const uint8_t **pp, const uint8_t > *p_end) > "ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7", > "ISO-8859-8", "ISO-8859-9", "ISO-8859-10", "ISO-8859-11", > "", "ISO-8859-13", "ISO-8859-14", "ISO-8859-15", "", "", "", > "", > -"", "ISO-10646", "KSC_5601", "GB2312", "UCS-2BE", "UTF-8", "", > "", > +"", "UCS-2BE", "KSC_5601", "GB2312", "UCS-2BE", "UTF-8", "", > "", If you believe this is correct, please commit. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] tests/api/api-h264-test: Add AV_NOPTS_VALUE check for AVFrame.pkt_dts
On Mon, Feb 11, 2019 at 11:21:27AM +0800, Jun Zhao wrote:
> Add AV_NOPTS_VALUE check for AVFrame.pkt_dts to avoid print the
> pkt_dts as negative number like:
> "0,3616613, -9223372036854775808, 1001, 3110400, 0x75e37a65"
>
> Signed-off-by: Jun Zhao
> ---
> tests/api/api-h264-test.c | 10 +++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tests/api/api-h264-test.c b/tests/api/api-h264-test.c
> index 9fa..55cd6cf 100644
> --- a/tests/api/api-h264-test.c
> +++ b/tests/api/api-h264-test.c
> @@ -131,9 +131,13 @@ static int video_decode_example(const char
> *input_filename)
> av_log(NULL, AV_LOG_ERROR, "Can't copy image to
> buffer\n");
> return number_of_written_bytes;
> }
> -printf("%d, %10"PRId64", %10"PRId64", %8"PRId64", %8d,
> 0x%08lx\n", video_stream,
> -fr->pts, fr->pkt_dts, fr->pkt_duration,
> -number_of_written_bytes, av_adler32_update(0, (const
> uint8_t*)byte_buffer, number_of_written_bytes));
> +
> +if (fr->pkt_dts == AV_NOPTS_VALUE)
> +printf("%d, %10"PRId64", %s,", video_stream, fr->pts,
> "N/A");
you can simplify this by replacing %s by N/A
also the if() else could have {} added so any future additions
would not require the lines to be changed making future patches cleaner
also av_ts2str() could be used
either way, patch LGTM
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/tests/integral: Fix build warning after adjust the location
On Tue, Feb 12, 2019 at 1:48 AM Michael Niedermayer wrote: > > On Sun, Feb 10, 2019 at 02:53:57PM +0800, Jun Zhao wrote: > > Fix build warning like "warning: ISO C90 forbids mixed declarations > > and code" after adjust the location for malloc fail check. > > > > Signed-off-by: Jun Zhao > > --- > > libavfilter/tests/integral.c |9 + > > 1 files changed, 5 insertions(+), 4 deletions(-) > > LGTM > > thx > Pushed, Tks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 3/3] avformat/mpegtsenc: add support for service and provider names with utf8 encoding
Signed-off-by: Marton Balint
---
libavformat/mpegtsenc.c | 88 +
1 file changed, 53 insertions(+), 35 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 4470b7120c..523ac65d55 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -54,8 +54,8 @@ typedef struct MpegTSSection {
typedef struct MpegTSService {
MpegTSSection pmt; /* MPEG-2 PMT table context */
int sid; /* service ID */
-char *name;
-char *provider_name;
+uint8_t name[256];
+uint8_t provider_name[256];
int pcr_pid;
int pcr_packet_count;
int pcr_packet_period;
@@ -264,26 +264,10 @@ static void mpegts_write_pat(AVFormatContext *s)
data, q - data);
}
-/* NOTE: !str is accepted for an empty string */
-static void putstr8(uint8_t **q_ptr, const char *str, int write_len)
+static void putbuf(uint8_t **q_ptr, const uint8_t *buf, int len)
{
-uint8_t *q;
-int len;
-
-q = *q_ptr;
-if (!str)
-len = 0;
-else
-len = strlen(str);
-if (write_len)
-*q++ = len;
-if (!str) {
-*q_ptr = q;
-return;
-}
-memcpy(q, str, len);
-q += len;
-*q_ptr = q;
+memcpy(*q_ptr, buf, len);
+*q_ptr += len;
}
static int mpegts_write_pmt(AVFormatContext *s, MpegTSService *service)
@@ -646,9 +630,9 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
*q++ = 0x26; /* metadata descriptor */
*q++ = 13;
put16(, 0x);/* metadata application format */
-putstr8(, tag, 0);
+putbuf(, tag, strlen(tag));
*q++ = 0xff;/* metadata format */
-putstr8(, tag, 0);
+putbuf(, tag, strlen(tag));
*q++ = 0;/* metadata service ID */
*q++ = 0xF; /*
metadata_locator_record_flag|MPEG_carriage_flags|reserved */
}
@@ -695,8 +679,8 @@ static void mpegts_write_sdt(AVFormatContext *s)
desc_len_ptr = q;
q++;
*q++ = ts->service_type;
-putstr8(, service->provider_name, 1);
-putstr8(, service->name, 1);
+putbuf(, service->provider_name, service->provider_name[0] + 1);
+putbuf(, service->name, service->name[0] + 1);
desc_len_ptr[0] = q - desc_len_ptr - 1;
/* fill descriptor length */
@@ -709,10 +693,47 @@ static void mpegts_write_sdt(AVFormatContext *s)
data, q - data);
}
-static MpegTSService *mpegts_add_service(MpegTSWrite *ts, int sid,
+/* This stores a string in buf with the correct encoding and also sets the
+ * first byte as the length. !str is accepted for an empty string.
+ * If the string is already encoded, invalid UTF-8 or has no multibyte sequence
+ * then we keep it as is, otherwise we signal UTF-8 encoding. */
+static int encode_str8(uint8_t *buf, const char *str)
+{
+size_t str_len;
+if (!str)
+str = "";
+str_len = strlen(str);
+if (str[0] && (unsigned)str[0] >= 0x20) { /* Make sure the string is not
already encoded. */
+const uint8_t *q = str;
+int has_multibyte = 0;
+while (*q) {
+uint32_t code;
+GET_UTF8(code, *q++, goto invalid;) /* Is it valid UTF-8? */
+has_multibyte |= (code > 127); /* Does it have multibyte
UTF-8 chars in it? */
+}
+if (has_multibyte) {/* If we have multibyte chars
and valid UTF-8, then encode as such! */
+if (str_len > 254)
+return AVERROR(EINVAL);
+buf[0] = str_len + 1;
+buf[1] = 0x15;
+memcpy([2], str, str_len);
+return 0;
+}
+}
+invalid:
+/* Otherwise let's just encode the string as is! */
+if (str_len > 255)
+return AVERROR(EINVAL);
+buf[0] = str_len;
+memcpy([1], str, str_len);
+return 0;
+}
+
+static MpegTSService *mpegts_add_service(AVFormatContext *s, int sid,
const char *provider_name,
const char *name)
{
+MpegTSWrite *ts = s->priv_data;
MpegTSService *service;
service = av_mallocz(sizeof(MpegTSService));
@@ -721,17 +742,16 @@ static MpegTSService *mpegts_add_service(MpegTSWrite *ts,
int sid,
service->pmt.pid = ts->pmt_start_pid + ts->nb_services;
service->sid = sid;
service->pcr_pid = 0x1fff;
-service->provider_name = av_strdup(provider_name);
-service->name = av_strdup(name);
-if (!service->provider_name || !service->name)
+if (encode_str8(service->provider_name, provider_name) < 0 ||
+encode_str8(service->name, name) < 0) {
+av_log(s, AV_LOG_ERROR, "Too long service or provider name\n");
goto fail;
+}
if
Re: [FFmpeg-devel] [PATCH 3/4] lavc/libaribb24: add missing type struct members to AVOptions
On Mon, Feb 11, 2019 at 03:06:53AM +0200, Jan Ekström wrote: > --- > libavcodec/libaribb24.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/tests/integral: Check malloc fail before using it
On Tue, Feb 12, 2019 at 1:48 AM Michael Niedermayer wrote: > > On Sun, Feb 10, 2019 at 01:07:20PM +0800, Jun Zhao wrote: > > Need to check malloc fail before using it, so adjust the location > > in the code. > > > > Signed-off-by: Jun Zhao > > --- > > libavfilter/tests/integral.c |6 +++--- > > 1 files changed, 3 insertions(+), 3 deletions(-) > > LGTM > > thx > > Pushed, Tks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V3] tests/api/api-h264-test: Add AV_NOPTS_VALUE check for AVFrame.pkt_dts/pts
Use av_ts2str() for AVFrame.pkt_dts/pts to avoid print the
pkt_dts/pts as negative number like:
"0,3616613, -9223372036854775808, 1001, 3110400, 0x75e37a65"
Reviewed-by: Michael Niedermayer
Signed-off-by: Jun Zhao
---
tests/api/api-h264-test.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/api/api-h264-test.c b/tests/api/api-h264-test.c
index 9fa..60a3ae5 100644
--- a/tests/api/api-h264-test.c
+++ b/tests/api/api-h264-test.c
@@ -28,6 +28,7 @@
#include "libavcodec/avcodec.h"
#include "libavformat/avformat.h"
#include "libavutil/imgutils.h"
+#include "libavutil/timestamp.h"
static int video_decode_example(const char *input_filename)
{
@@ -131,9 +132,9 @@ static int video_decode_example(const char *input_filename)
av_log(NULL, AV_LOG_ERROR, "Can't copy image to buffer\n");
return number_of_written_bytes;
}
-printf("%d, %10"PRId64", %10"PRId64", %8"PRId64", %8d,
0x%08lx\n", video_stream,
-fr->pts, fr->pkt_dts, fr->pkt_duration,
-number_of_written_bytes, av_adler32_update(0, (const
uint8_t*)byte_buffer, number_of_written_bytes));
+printf("%d, %s, %s, %8"PRId64", %8d, 0x%08lx\n", video_stream,
+ av_ts2str(fr->pts), av_ts2str(fr->pkt_dts),
fr->pkt_duration,
+ number_of_written_bytes, av_adler32_update(0, (const
uint8_t*)byte_buffer, number_of_written_bytes));
}
av_packet_unref();
av_init_packet();
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx264: update notes to explain the scale chosen for ROI encoding
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Monday, February 04, 2019 5:34 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/libx264: update notes to
> explain the scale chosen for ROI encoding
>
> On 29/01/2019 10:14, Guo, Yejun wrote:
> > Signed-off-by: Guo, Yejun
> > ---
> > libavcodec/libx264.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > index a3493f3..8c96728 100644
> > --- a/libavcodec/libx264.c
> > +++ b/libavcodec/libx264.c
> > @@ -383,7 +383,9 @@ static int X264_frame(AVCodecContext *ctx,
> AVPacket *pkt, const AVFrame *frame,
> > qoffset = roi->qoffset.num * 1.0f /
> > roi->qoffset.den;
> > qoffset = av_clipf(qoffset, -1.0f, 1.0f);
> >
> > -// 25 is a number that I think it is a possible
> > proper scale value.
> > +/* qp range of x264 is from 0 to 51, just choose
> > 25 as the scale
> value,
> > + * so the range of final qoffset is [-25.0, 25.0].
> > + */
> > qoffset = qoffset * 25;
> >
> > for (int y = starty; y < endy; y++) {
> >
>
> I'm not understanding where this number has come from at all. Is 25 purely
From H264 spec: SliceQPY is in the range of −QpBdOffsetY to +51, inclusive. And
lots of documents/papers says the qp range of H264 is [0, 51].
So, I chose 25 (equal with 51/2) roughly to make qpoffset to be [-25.0, 25.0].
> arbitrary? Why does the effect vary by bit depth?
imo, 51 has nothing to do with bit depth, not quite understand your concern.
>
> From the docs explaining the best/worst behaviour on the range, I would
> expect this to map 0 to 0 and 1 to 3 + 6 * bit_depth (positive or negative).
for example if bit_depth=8, do you mean map -1.0 to -51, and map 1.0 to 51?
for example if bit_depth=10, do you mean map -1.0 to -63, and map 1.0 to 63?
If so, I'm not sure if it is better or not.
Imho, there is still a long way from qpoffset to the final quantization value,
I would think a rough qpoffset (with range [-25, 25]) is enough. Anyway, I'm
open to use whatever better method.
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] zmbvenc: don't sum the entropy when blocks are equal
sön 2019-02-10 klockan 22:18 + skrev Matthew Fearnley: > > On Thu, 31 Jan 2019 at 15:00, Tomas Härdin wrote: > > > > > > 1. The entropy calculation in block_cmp() omits the score of histogram[0] > > > from the final sum. > > > It's tempting to do this to bias the scores in favour of 0-bytes, but in > > > reality, blocks with a majority of 0 (or any other byte) will already be > > > naturally favoured by the entropy score anyway, and this bias will fail > > > > to > > > penalise blocks with an "average" (i.e. high entropy) number of 0's in > > > > them. > > > The exact implications are difficult to ponder, but in practical terms > > > > this > > > error does tend to produce worse results in the video compression. Not > > > massively so, but it's still noticeable. > > > > Did you try combining the statistics of the current MV with the > > statistics of the previous block, to bias the choice in favor of > > similar bytes? Could work like a cheap order-1 entropy model. > > > > I've had a go at this, but sadly, it seemed to adversely affect > compression, producing larger files. > Maybe it can be improved with some tweaking, or maybe there's a bug > somewhere. > But it feels to me like this approach on its own isn't enough to improve > scoring. Maybe as part of something larger though.. > Anyway, you can see the results of my efforts here: > https://github.com/countingpine/FFmpeg/commit/prev_histogram. Darn. Interesting result at least /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix sidx loading issues in fragmented files.
On Sat, Feb 09, 2019 at 11:44:52PM -0500, agrecascino...@gmail.com wrote: > From: mptcultist > > fixed issue where if sidx was after another sidx and happened to point to the > same media, it wouldn't be read. > this is done by counting the sidx atoms before they're read. for #7572 > --- > libavformat/isom.h | 2 ++ > libavformat/mov.c | 45 +++-- > 2 files changed, 45 insertions(+), 2 deletions(-) this looks not ok as it effectivly doubles the number of passes over the whole file also there is no need for this, doing a single pass either you are done or you are not so its possible to know if all have been read. If the existing check for the last sidx is wrong then it should be fixed. also this patch only fixes the issue if seeking for a 2nd pass is supported [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
It enabled multiple filter graph concurrency, which bring above about
4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
Below are some test cases and comparison as reference.
(Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
(Software: Intel iHD driver - 16.9.00100, CentOS 7)
For 1:N transcode by GPU acceleration with vaapi:
./ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi \
-hwaccel_output_format vaapi \
-i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale_vaapi=1280:720" -c:v h264_vaapi -f null /dev/null \
-vf "scale_vaapi=720:480" -c:v h264_vaapi -f null /dev/null
test results:
2 encoders 5 encoders 10 encoders
Improved 6.1%6.9% 5.5%
For 1:N transcode by GPU acceleration with QSV:
./ffmpeg -hwaccel qsv -c:v h264_qsv \
-i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale_qsv=1280:720:format=nv12" -c:v h264_qsv -f null /dev/null \
-vf "scale_qsv=720:480:format=nv12" -c:v h264_qsv -f null /dev/null
test results:
2 encoders 5 encoders 10 encoders
Improved 6% 4% 15%
For Intel GPU acceleration case, 1 decode to N scaling, by QSV:
./ffmpeg -hwaccel qsv -c:v h264_qsv \
-i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale_qsv=1280:720:format=nv12,hwdownload" -pix_fmt nv12 -f null
/dev/null \
-vf "scale_qsv=720:480:format=nv12,hwdownload" -pix_fmt nv12 -f null
/dev/null
test results:
2 scale 5 scale 10 scale
Improved 12% 21%21%
For CPU only 1 decode to N scaling:
./ffmpeg -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale=1280:720" -pix_fmt nv12 -f null /dev/null \
-vf "scale=720:480" -pix_fmt nv12 -f null /dev/null
test results:
2 scale 5 scale 10 scale
Improved 25%107% 148%
Signed-off-by: Wang, Shaofei
Reviewed-by: Zhao, Jun
---
fftools/ffmpeg.c| 112 +---
fftools/ffmpeg.h| 14 ++
fftools/ffmpeg_filter.c | 4 ++
3 files changed, 124 insertions(+), 6 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 544f1a1..67b1a2a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1419,13 +1419,18 @@ static void finish_output_stream(OutputStream *ost)
*
* @return 0 for success, <0 for severe errors
*/
-static int reap_filters(int flush)
+static int reap_filters(int flush, InputFilter * ifilter)
{
AVFrame *filtered_frame = NULL;
int i;
-/* Reap all buffers present in the buffer sinks */
+/* Reap all buffers present in the buffer sinks or just reap specified
+ * input filter buffer */
for (i = 0; i < nb_output_streams; i++) {
+if (ifilter) {
+if (ifilter != output_streams[i]->filter->graph->inputs[0])
+continue;
+}
OutputStream *ost = output_streams[i];
OutputFile*of = output_files[ost->file_index];
AVFilterContext *filter;
@@ -2179,7 +2184,8 @@ static int ifilter_send_frame(InputFilter *ifilter,
AVFrame *frame)
}
}
-ret = reap_filters(1);
+ret = HAVE_THREADS ? reap_filters(1, ifilter) : reap_filters(1, NULL);
+
if (ret < 0 && ret != AVERROR_EOF) {
av_log(NULL, AV_LOG_ERROR, "Error while filtering: %s\n",
av_err2str(ret));
return ret;
@@ -2208,6 +2214,14 @@ static int ifilter_send_eof(InputFilter *ifilter,
int64_t pts)
ifilter->eof = 1;
+#if HAVE_THREADS
+ifilter->waited_frm = NULL;
+pthread_mutex_lock(>process_mutex);
+ifilter->t_end = 1;
+pthread_cond_signal(>process_cond);
+pthread_mutex_unlock(>process_mutex);
+pthread_join(ifilter->f_thread, NULL);
+#endif
if (ifilter->filter) {
ret = av_buffersrc_close(ifilter->filter, pts, AV_BUFFERSRC_FLAG_PUSH);
if (ret < 0)
@@ -2252,12 +2266,95 @@ static int decode(AVCodecContext *avctx, AVFrame
*frame, int *got_frame, AVPacke
return 0;
}
+#if HAVE_THREADS
+static void *filter_pipeline(void *arg)
+{
+InputFilter *fl = arg;
+AVFrame *frm;
+int ret;
+while(1) {
+pthread_mutex_lock(>process_mutex);
+while (fl->waited_frm == NULL && !fl->t_end)
+pthread_cond_wait(>process_cond, >process_mutex);
+pthread_mutex_unlock(>process_mutex);
+
+if (fl->t_end) break;
+
+frm = fl->waited_frm;
+ret = ifilter_send_frame(fl, frm);
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR,
+ "Failed to inject frame into filter network: %s\n",
av_err2str(ret));
+} else {
+ret = reap_filters(0, fl);
+}
+fl->t_error = ret;
+
+pthread_mutex_lock(>finish_mutex);
+fl->waited_frm = NULL;
+pthread_cond_signal(>finish_cond);
+pthread_mutex_unlock(>finish_mutex);
+
+if (ret < 0)
+break;
+}
+
Re: [FFmpeg-devel] [PATCH 3/3] avformat/hlsenc: add var_stream_map LANGUAGE field string parameter
2019-01-23 12:24 GMT+01:00, Steven Liu : > use a:0,agroup:aud_low,default:Yes,language:CHN > a:1,agroup:aud_low,language:ENG > a:2,agroup:aud_high,default:YesYes,language:CHN > a:3,agroup:aud_high,language:ENG I know this is late but shouldn't the language be taken from the metadata if != unknown? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
Code clean and remove the "-abr_pipeline" option, use the perf improved code path by default only if HAVE_THREAD enabled. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
It is lucky that my patch works to ticket 7572. However, #7572 has a deeper
reason.
Mov demuxer consider that fragmented index is completed if a ‘sidx’ point
to the end of the file. But there may be other ‘sidx’ for other tracks. If
we skip the tail from there, we will missing the last ‘sidx’ and ‘moof’.
Then AV_NOPTS_VALUE occurs.
I tried to avoid skipping the tail simply. However, fate-test run failed on
mov-frag-encrypted.mp4.
BTW, I just got back from vacation. I am willing to follow an optimized
solution.
Thanks and Regards,
Chenhui
Carl Eugen Hoyos 于2019年2月11日周一 上午6:24写道：
> 2019-02-10 23:04 GMT+01:00, Marton Balint :
> >
> >
> > On Sun, 3 Feb 2019, Charles Liu wrote:
> >
> >> Binary searching would hang if the fragment items do NOT have timestamp
> >> for the specified stream.
> >>
> >> For example, a fmp4 consists of separated 'moof' boxes for each track,
> and
> >> separated 'sidx' for each segment, but no 'mfra' box.
> >> Then every fragment item only have the timestamp for one of its tracks.
> >>
> >> Signed-off-by: Charles Liu
> >> ---
> >> libavformat/mov.c | 21 -
> >> 1 file changed, 12 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> index 9b9739f788..35cb619e9f 100644
> >> --- a/libavformat/mov.c
> >> +++ b/libavformat/mov.c
> >> @@ -1266,7 +1266,7 @@ static int64_t get_frag_time(MOVFragmentIndex
> >> *frag_index,
> >> static int search_frag_timestamp(MOVFragmentIndex *frag_index,
> >> AVStream *st, int64_t timestamp)
> >> {
> >> -int a, b, m;
> >> +int a, b, m, m0;
> >> int64_t frag_time;
> >> int id = -1;
> >>
> >> @@ -1282,15 +1282,18 @@ static int
> search_frag_timestamp(MOVFragmentIndex
> >> *frag_index,
> >> b = frag_index->nb_items;
> >>
> >> while (b - a > 1) {
> >> -m = (a + b) >> 1;
> >> -frag_time = get_frag_time(frag_index, m, id);
> >> -if (frag_time != AV_NOPTS_VALUE) {
> >> -if (frag_time >= timestamp)
> >> -b = m;
> >> -if (frag_time <= timestamp)
> >> -a = m;
> >> -}
> >> +m0 = m = (a + b) >> 1;
> >> +
> >> +while (m < b &&
> >> + (frag_time = get_frag_time(frag_index, m, id)) ==
> >> AV_NOPTS_VALUE)
> >> +m++;
> >> +
> >> +if (m < b && frag_time <= timestamp)
> >> +a = m;
> >> +else
> >> +b = m0;
> >> }
> >> +
> >> return a;
> >> }
> >>
> >
> > As this fixes a hang, I will push this version soon.
>
> Please mention ticket #7572 in the commit message.
>
> Thank you, Carl Eugen
> ___
> 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] Proposal: Homebrew tap for FFmpeg
On Sun, Feb 10, 2019 at 7:40 PM Jean-Baptiste Kempf wrote: > > On Sun, 10 Feb 2019, at 19:37, Werner Robitza wrote: > > > Those options are just for non-free cases, and to be honest, I don't see > > > why FFmpeg should advertise those. > > > > That is not correct. The following options/dependencies are not > > present in Homebrew core: > > > > chromaprint, fdk-aac, game-music-emu, libbs2b, libcaca, libgsm, > > libmodplug, librsvg, libssh, libvidstab, libvmaf, openh264, openssl, > > srt, two-lame, wavpack, webp, zeromq, zimg > > Fair enough. > I still object to an official recipe activating non-free options. If that is the major concern, I suggest to remove these two options from the formula as a way forward. Of course, anyone would be free to provide their own non-free repository if they desire so. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
