Re: [FFmpeg-devel] [PATCH] avcodec: add jpeg2000_parser
On 12/17/16, Michael Niedermayer wrote: > On Fri, Mar 25, 2016 at 02:07:22AM +0100, Michael Niedermayer wrote: >> On Fri, Mar 25, 2016 at 12:44:49AM +0100, Paul B Mahol wrote: >> > On 3/24/16, Paul B Mahol wrote: >> > > Hi, >> > > >> > > patch attached. >> > > >> > >> > Fixed version attached. >> >> confirmed > > it seems this wasnt applied > > any reason why ? Because flag which this parser depends on when splitting is completely optional by absurd standard of this codec. > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is what and why we do it that matters, not just one of them. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] af_hdcd: more FATE tests
On Sun, Dec 18, 2016 at 8:42 AM, Burt P wrote: > Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%. > > Changed fate-suite sample files: > * filter/hdcd-encoding-errors.flac (1.3M) replaced by > filter/hdcd-encoding-errors2.flac (140K) > * filter/hdcd-mix.flac (2.2M) added > * filter/hdcd-fake20bit.flac (168K) added > * filter/hdcd.flac (910K) removed, although it was a nice tune and > the samples that replace it are terrible sounds. > Net change +290K. > We cannot delete samples because that would break old versions of FATE (which is vital for bisecting etc), so knowing and accounting for that, would that change any of these choices to add/remove samples? Because the net change goes to around +2.5M without any removals. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.
Le primidi 21 frimaire, an CCXXV, Nicolas George a écrit : > I will do so after the end of this week if I see no news. Done. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] af_hdcd: more FATE tests
On Sun, Dec 18, 2016 at 3:30 AM, Hendrik Leppkes wrote: > On Sun, Dec 18, 2016 at 8:42 AM, Burt P wrote: >> Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%. >> >> Changed fate-suite sample files: >> * filter/hdcd-encoding-errors.flac (1.3M) replaced by >> filter/hdcd-encoding-errors2.flac (140K) >> * filter/hdcd-mix.flac (2.2M) added >> * filter/hdcd-fake20bit.flac (168K) added >> * filter/hdcd.flac (910K) removed, although it was a nice tune and >> the samples that replace it are terrible sounds. >> Net change +290K. >> > > We cannot delete samples because that would break old versions of FATE > (which is vital for bisecting etc), so knowing and accounting for > that, would that change any of these choices to add/remove samples? > Because the net change goes to around +2.5M without any removals. > Well, hdcd-encoding-errors2.flac could simply be named hdcd-encoding-errors.flac and it should not affect the test that uses it, even in an old version. There only needs to be a non-zero number of errors, 2 is as good as 4. The sample hdcd.flac is a nice sound, but it isn't a very interesting example of HDCD for testing. hdcd-mix.flac is a concatenation of three different samples, each one interesting in a different way, and it does quite a bit for code coverage. I will, however, try to make it smaller. -- Burt ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/tls: add tls url_get_file_handle
On Sat, 17 Dec 2016 20:17:54 +0100 Michael Niedermayer wrote: > On Sun, Oct 16, 2016 at 10:28:21AM -0400, jayri...@gmail.com wrote: > > From: Jay Ridgeway > > > > Support url_get_file_handle on TLS streams. > > --- > > libavformat/tls_gnutls.c | 7 +++ > > libavformat/tls_openssl.c | 7 +++ > > libavformat/tls_schannel.c| 7 +++ > > libavformat/tls_securetransport.c | 7 +++ > > 4 files changed, 28 insertions(+) > > applied > > thx > > [...] What is this even supposed to be useful for??? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/tls: add tls url_get_file_handle
On Sat, 17 Dec 2016 20:17:54 +0100 Michael Niedermayer wrote: > On Sun, Oct 16, 2016 at 10:28:21AM -0400, jayri...@gmail.com wrote: > > From: Jay Ridgeway > > > > Support url_get_file_handle on TLS streams. > > --- > > libavformat/tls_gnutls.c | 7 +++ > > libavformat/tls_openssl.c | 7 +++ > > libavformat/tls_schannel.c| 7 +++ > > libavformat/tls_securetransport.c | 7 +++ > > 4 files changed, 28 insertions(+) > > applied > > thx > > [...] What is this even supposed to be useful for??? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/6] ffplay: use buffersink accessors.
Signed-off-by: Nicolas George
---
ffplay.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index 911fd7f..90bd97b 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2075,7 +2075,7 @@ static int audio_thread(void *arg)
goto the_end;
while ((ret = av_buffersink_get_frame_flags(is->out_audio_filter,
frame, 0)) >= 0) {
-tb = is->out_audio_filter->inputs[0]->time_base;
+tb = av_buffersink_get_time_base(is->out_audio_filter);
#endif
if (!(af = frame_queue_peek_writable(&is->sampq)))
goto the_end;
@@ -2183,7 +2183,7 @@ static int video_thread(void *arg)
last_format = frame->format;
last_serial = is->viddec.pkt_serial;
last_vfilter_idx = is->vfilter_idx;
-frame_rate = filt_out->inputs[0]->frame_rate;
+frame_rate = av_buffersink_get_frame_rate(filt_out);
}
ret = av_buffersrc_add_frame(filt_in, frame);
@@ -2204,7 +2204,7 @@ static int video_thread(void *arg)
is->frame_last_filter_delay = av_gettime_relative() / 100.0 -
is->frame_last_returned_time;
if (fabs(is->frame_last_filter_delay) > AV_NOSYNC_THRESHOLD / 10.0)
is->frame_last_filter_delay = 0;
-tb = filt_out->inputs[0]->time_base;
+tb = av_buffersink_get_time_base(filt_out);
#endif
duration = (frame_rate.num && frame_rate.den ?
av_q2d((AVRational){frame_rate.den, frame_rate.num}) : 0);
pts = (frame->pts == AV_NOPTS_VALUE) ? NAN : frame->pts *
av_q2d(tb);
@@ -2641,7 +2641,7 @@ static int stream_component_open(VideoState *is, int
stream_index)
case AVMEDIA_TYPE_AUDIO:
#if CONFIG_AVFILTER
{
-AVFilterLink *link;
+AVFilterContext *sink;
is->audio_filter_src.freq = avctx->sample_rate;
is->audio_filter_src.channels = avctx->channels;
@@ -2649,10 +2649,10 @@ static int stream_component_open(VideoState *is, int
stream_index)
is->audio_filter_src.fmt= avctx->sample_fmt;
if ((ret = configure_audio_filters(is, afilters, 0)) < 0)
goto fail;
-link = is->out_audio_filter->inputs[0];
-sample_rate= link->sample_rate;
-nb_channels= avfilter_link_get_channels(link);
-channel_layout = link->channel_layout;
+sink = is->out_audio_filter;
+sample_rate= av_buffersink_get_sample_rate(sink);
+nb_channels= av_buffersink_get_channels(sink);
+channel_layout = av_buffersink_get_channel_layout(sink);
}
#else
sample_rate= avctx->sample_rate;
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.
av_buffersink_get_frame_rate() did already exist; its argument becomes const.
TODO minor version bump
API-Change: libavfilter
Signed-off-by: Nicolas George
---
libavfilter/buffersink.c | 25 +++--
libavfilter/buffersink.h | 22 --
2 files changed, 39 insertions(+), 8 deletions(-)
I think the const change is acceptable.
Note: I am introducing the "API-Change" Git tag: I think it will be much
more convenient than maintaining doc/APIchanges. Later I intend to write a
script using git log --grep to pretty print it.
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 7b7b477..030ca80 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -279,14 +279,27 @@ void av_buffersink_set_frame_size(AVFilterContext *ctx,
unsigned frame_size)
inlink->partial_buf_size = frame_size;
}
-AVRational av_buffersink_get_frame_rate(AVFilterContext *ctx)
-{
-av_assert0( !strcmp(ctx->filter->name, "buffersink")
- || !strcmp(ctx->filter->name, "ffbuffersink"));
-
-return ctx->inputs[0]->frame_rate;
+#define MAKE_AVFILTERLINK_ACCESSOR(type, field) \
+type av_buffersink_get_##field(const AVFilterContext *ctx) { \
+av_assert0(ctx->filter->uninit == uninit); \
+return ctx->inputs[0]->field; \
}
+MAKE_AVFILTERLINK_ACCESSOR(enum AVMediaType , type );
+MAKE_AVFILTERLINK_ACCESSOR(AVRational , time_base );
+MAKE_AVFILTERLINK_ACCESSOR(int , format );
+
+MAKE_AVFILTERLINK_ACCESSOR(AVRational , frame_rate );
+MAKE_AVFILTERLINK_ACCESSOR(int , w );
+MAKE_AVFILTERLINK_ACCESSOR(int , h );
+MAKE_AVFILTERLINK_ACCESSOR(AVRational , sample_aspect_ratio);
+
+MAKE_AVFILTERLINK_ACCESSOR(int , channels );
+MAKE_AVFILTERLINK_ACCESSOR(uint64_t , channel_layout );
+MAKE_AVFILTERLINK_ACCESSOR(int , sample_rate);
+
+MAKE_AVFILTERLINK_ACCESSOR(AVBufferRef *, hw_frames_ctx );
+
static av_cold int vsink_init(AVFilterContext *ctx, void *opaque)
{
BufferSinkContext *buf = ctx->priv;
diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h
index e399b91..f51fa7c 100644
--- a/libavfilter/buffersink.h
+++ b/libavfilter/buffersink.h
@@ -101,9 +101,27 @@ AVABufferSinkParams *av_abuffersink_params_alloc(void);
void av_buffersink_set_frame_size(AVFilterContext *ctx, unsigned frame_size);
/**
- * Get the frame rate of the input.
+ * @defgroup lavfi_buffersink_accessors Buffer sink accessors
+ * Get the properties of the stream
+ * @{
*/
-AVRational av_buffersink_get_frame_rate(AVFilterContext *ctx);
+
+enum AVMediaType av_buffersink_get_type(const AVFilterContext
*ctx);
+AVRational av_buffersink_get_time_base (const AVFilterContext
*ctx);
+int av_buffersink_get_format (const AVFilterContext
*ctx);
+
+AVRational av_buffersink_get_frame_rate (const AVFilterContext
*ctx);
+int av_buffersink_get_w (const AVFilterContext
*ctx);
+int av_buffersink_get_h (const AVFilterContext
*ctx);
+AVRational av_buffersink_get_sample_aspect_ratio (const AVFilterContext
*ctx);
+
+int av_buffersink_get_channels(const AVFilterContext
*ctx);
+uint64_t av_buffersink_get_channel_layout (const AVFilterContext
*ctx);
+int av_buffersink_get_sample_rate (const AVFilterContext
*ctx);
+
+AVBufferRef *av_buffersink_get_hw_frames_ctx (const AVFilterContext
*ctx);
+
+/** @} */
/**
* Get a frame with filtered data from sink and put it in frame.
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/6] ffmpeg: use buffersink accessors.
Signed-off-by: Nicolas George
---
ffmpeg.c| 46 --
ffmpeg_filter.c | 12 ++--
2 files changed, 30 insertions(+), 28 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index e4890a4..ff177e0 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1014,6 +1014,7 @@ static void do_video_out(OutputFile *of,
AVPacket pkt;
AVCodecContext *enc = ost->enc_ctx;
AVCodecParameters *mux_par = ost->st->codecpar;
+AVRational frame_rate;
int nb_frames, nb0_frames, i;
double delta, delta0;
double duration = 0;
@@ -1024,9 +1025,9 @@ static void do_video_out(OutputFile *of,
if (ost->source_index >= 0)
ist = input_streams[ost->source_index];
-if (filter->inputs[0]->frame_rate.num > 0 &&
-filter->inputs[0]->frame_rate.den > 0)
-duration = 1/(av_q2d(filter->inputs[0]->frame_rate) *
av_q2d(enc->time_base));
+frame_rate = av_buffersink_get_frame_rate(filter);
+if (frame_rate.num > 0 && frame_rate.den > 0)
+duration = 1/(av_q2d(frame_rate) * av_q2d(enc->time_base));
if(ist && ist->st->start_time != AV_NOPTS_VALUE && ist->st->first_dts !=
AV_NOPTS_VALUE && ost->frame_rate.num)
duration = FFMIN(duration, 1/(av_q2d(ost->frame_rate) *
av_q2d(enc->time_base)));
@@ -1416,7 +1417,7 @@ static int reap_filters(int flush)
av_log(NULL, AV_LOG_WARNING,
"Error in av_buffersink_get_frame_flags(): %s\n",
av_err2str(ret));
} else if (flush && ret == AVERROR_EOF) {
-if (filter->inputs[0]->type == AVMEDIA_TYPE_VIDEO)
+if (av_buffersink_get_type(filter) == AVMEDIA_TYPE_VIDEO)
do_video_out(of, ost, NULL, AV_NOPTS_VALUE);
}
break;
@@ -1427,25 +1428,26 @@ static int reap_filters(int flush)
}
if (filtered_frame->pts != AV_NOPTS_VALUE) {
int64_t start_time = (of->start_time == AV_NOPTS_VALUE) ? 0 :
of->start_time;
+AVRational filter_tb = av_buffersink_get_time_base(filter);
AVRational tb = enc->time_base;
int extra_bits = av_clip(29 - av_log2(tb.den), 0, 16);
tb.den <<= extra_bits;
float_pts =
-av_rescale_q(filtered_frame->pts,
filter->inputs[0]->time_base, tb) -
+av_rescale_q(filtered_frame->pts, filter_tb, tb) -
av_rescale_q(start_time, AV_TIME_BASE_Q, tb);
float_pts /= 1 << extra_bits;
// avoid exact midoints to reduce the chance of rounding
differences, this can be removed in case the fps code is changed to work with
integers
float_pts += FFSIGN(float_pts) * 1.0 / (1<<17);
filtered_frame->pts =
-av_rescale_q(filtered_frame->pts,
filter->inputs[0]->time_base, enc->time_base) -
+av_rescale_q(filtered_frame->pts, filter_tb,
enc->time_base) -
av_rescale_q(start_time, AV_TIME_BASE_Q, enc->time_base);
}
//if (ost->source_index >= 0)
//*filtered_frame=
*input_streams[ost->source_index]->decoded_frame; //for me_threshold
-switch (filter->inputs[0]->type) {
+switch (av_buffersink_get_type(filter)) {
case AVMEDIA_TYPE_VIDEO:
if (!ost->frame_aspect_ratio.num)
enc->sample_aspect_ratio =
filtered_frame->sample_aspect_ratio;
@@ -3148,19 +3150,19 @@ static int init_output_stream_encode(OutputStream *ost)
switch (enc_ctx->codec_type) {
case AVMEDIA_TYPE_AUDIO:
-enc_ctx->sample_fmt = ost->filter->filter->inputs[0]->format;
+enc_ctx->sample_fmt =
av_buffersink_get_format(ost->filter->filter);
if (dec_ctx)
enc_ctx->bits_per_raw_sample = FFMIN(dec_ctx->bits_per_raw_sample,
av_get_bytes_per_sample(enc_ctx->sample_fmt) << 3);
-enc_ctx->sample_rate= ost->filter->filter->inputs[0]->sample_rate;
-enc_ctx->channel_layout =
ost->filter->filter->inputs[0]->channel_layout;
-enc_ctx->channels =
avfilter_link_get_channels(ost->filter->filter->inputs[0]);
+enc_ctx->sample_rate=
av_buffersink_get_sample_rate(ost->filter->filter);
+enc_ctx->channel_layout =
av_buffersink_get_channel_layout(ost->filter->filter);
+enc_ctx->channels =
av_buffersink_get_channels(ost->filter->filter);
enc_ctx->time_base = (AVRational){ 1, enc_ctx->sample_rate };
break;
case AVMEDIA_TYPE_VIDEO:
enc_ctx->time_base = av_inv_q(ost->frame_rate);
if (!(enc_ctx->time_base.num && enc_ctx->time_base.den))
-enc_ctx->time_base = ost->filter->filter->inputs[0]->time_base;
+enc_ctx->time_base =
av_buffersink_get_time_ba
[FFmpeg-devel] [PATCH 4/6] lavd/lavfi: use buffersink accessors.
Signed-off-by: Nicolas George
---
libavdevice/lavfi.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index f9b2694..eca3f15 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -312,31 +312,32 @@ av_cold static int lavfi_read_header(AVFormatContext
*avctx)
/* fill each stream with the information in the corresponding sink */
for (i = 0; i < lavfi->nb_sinks; i++) {
-AVFilterLink *link =
lavfi->sinks[lavfi->stream_sink_map[i]]->inputs[0];
+AVFilterContext *sink = lavfi->sinks[lavfi->stream_sink_map[i]];
+AVRational time_base = av_buffersink_get_time_base(sink);
AVStream *st = avctx->streams[i];
-st->codecpar->codec_type = link->type;
-avpriv_set_pts_info(st, 64, link->time_base.num, link->time_base.den);
-if (link->type == AVMEDIA_TYPE_VIDEO) {
+st->codecpar->codec_type = av_buffersink_get_type(sink);
+avpriv_set_pts_info(st, 64, time_base.num, time_base.den);
+if (av_buffersink_get_type(sink) == AVMEDIA_TYPE_VIDEO) {
st->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO;
-st->codecpar->format = link->format;
-st->codecpar->width = link->w;
-st->codecpar->height = link->h;
+st->codecpar->format = av_buffersink_get_format(sink);
+st->codecpar->width = av_buffersink_get_w(sink);
+st->codecpar->height = av_buffersink_get_h(sink);
st ->sample_aspect_ratio =
-st->codecpar->sample_aspect_ratio = link->sample_aspect_ratio;
+st->codecpar->sample_aspect_ratio =
av_buffersink_get_sample_aspect_ratio(sink);
avctx->probesize = FFMAX(avctx->probesize,
- link->w * link->h *
-
av_get_padded_bits_per_pixel(av_pix_fmt_desc_get(link->format)) *
+ av_buffersink_get_w(sink) *
av_buffersink_get_h(sink) *
+
av_get_padded_bits_per_pixel(av_pix_fmt_desc_get(av_buffersink_get_format(sink)))
*
30);
-} else if (link->type == AVMEDIA_TYPE_AUDIO) {
-st->codecpar->codec_id= av_get_pcm_codec(link->format, -1);
-st->codecpar->channels= avfilter_link_get_channels(link);
-st->codecpar->format = link->format;
-st->codecpar->sample_rate = link->sample_rate;
-st->codecpar->channel_layout = link->channel_layout;
+} else if (av_buffersink_get_type(sink) == AVMEDIA_TYPE_AUDIO) {
+st->codecpar->codec_id=
av_get_pcm_codec(av_buffersink_get_format(sink), -1);
+st->codecpar->channels= av_buffersink_get_channels(sink);
+st->codecpar->format = av_buffersink_get_format(sink);
+st->codecpar->sample_rate = av_buffersink_get_sample_rate(sink);
+st->codecpar->channel_layout =
av_buffersink_get_channel_layout(sink);
if (st->codecpar->codec_id == AV_CODEC_ID_NONE)
av_log(avctx, AV_LOG_ERROR,
"Could not find PCM codec for sample format %s.\n",
- av_get_sample_fmt_name(link->format));
+ av_get_sample_fmt_name(av_buffersink_get_format(sink)));
}
}
@@ -400,7 +401,7 @@ static int lavfi_read_packet(AVFormatContext *avctx,
AVPacket *pkt)
/* iterate through all the graph sinks. Select the sink with the
* minimum PTS */
for (i = 0; i < lavfi->nb_sinks; i++) {
-AVRational tb = lavfi->sinks[i]->inputs[0]->time_base;
+AVRational tb = av_buffersink_get_time_base(lavfi->sinks[i]);
double d;
int ret;
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.
API-Change: libavfilter
Signed-off-by: Nicolas George
---
libavfilter/avfilter.h | 2 +
libavfilter/internal.h | 199 +
libavfilter/version.h | 3 +
3 files changed, 204 insertions(+)
Not sure what the preferred delay would be. I suspect not many programs use
libavfilter yet. In the meantime, all new fields must be added at both
places and tested.
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 828b270..6109e58 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -377,6 +377,7 @@ struct AVFilterContext {
unsigned ready;
};
+#if FF_API_AVFILTERLINK_PUBLIC
/**
* A link between two filters. This contains pointers to the source and
* destination filters between which this link exists, and the indexes of
@@ -593,6 +594,7 @@ struct AVFilterLink {
#endif /* FF_INTERNAL_FIELDS */
};
+#endif /* FF_API_AVFILTERLINK_PUBLIC */
/**
* Link two filters together.
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index a8b69fd..599be24 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -145,6 +145,205 @@ struct AVFilterPad {
int needs_writable;
};
+#if !FF_API_AVFILTERLINK_PUBLIC
+/**
+ * A link between two filters. This contains pointers to the source and
+ * destination filters between which this link exists, and the indexes of
+ * the pads involved. In addition, this link also contains the parameters
+ * which have been negotiated and agreed upon between the filter, such as
+ * image dimensions, format, etc.
+ */
+struct AVFilterLink {
+AVFilterContext *src; ///< source filter
+AVFilterPad *srcpad;///< output pad on the source filter
+
+AVFilterContext *dst; ///< dest filter
+AVFilterPad *dstpad;///< input pad on the dest filter
+
+enum AVMediaType type; ///< filter media type
+
+/* These parameters apply only to video */
+int w; ///< agreed upon image width
+int h; ///< agreed upon image height
+AVRational sample_aspect_ratio; ///< agreed upon sample aspect ratio
+/* These parameters apply only to audio */
+uint64_t channel_layout;///< channel layout of current buffer (see
libavutil/channel_layout.h)
+int sample_rate;///< samples per second
+
+int format; ///< agreed upon media format
+
+/**
+ * Define the time base used by the PTS of the frames/samples
+ * which will pass through this link.
+ * During the configuration stage, each filter is supposed to
+ * change only the output timebase, while the timebase of the
+ * input link is assumed to be an unchangeable property.
+ */
+AVRational time_base;
+
+/**
+ * Lists of formats and channel layouts supported by the input and output
+ * filters respectively. These lists are used for negotiating the format
+ * to actually be used, which will be loaded into the format and
+ * channel_layout members, above, when chosen.
+ *
+ */
+AVFilterFormats *in_formats;
+AVFilterFormats *out_formats;
+
+/**
+ * Lists of channel layouts and sample rates used for automatic
+ * negotiation.
+ */
+AVFilterFormats *in_samplerates;
+AVFilterFormats *out_samplerates;
+struct AVFilterChannelLayouts *in_channel_layouts;
+struct AVFilterChannelLayouts *out_channel_layouts;
+
+/**
+ * Audio only, the destination filter sets this to a non-zero value to
+ * request that buffers with the given number of samples should be sent to
+ * it. AVFilterPad.needs_fifo must also be set on the corresponding input
+ * pad.
+ * Last buffer before EOF will be padded with silence.
+ */
+int request_samples;
+
+/** stage of the initialization of the link properties (dimensions, etc) */
+enum {
+AVLINK_UNINIT = 0, ///< not started
+AVLINK_STARTINIT, ///< started, but incomplete
+AVLINK_INIT ///< complete
+} init_state;
+
+/**
+ * Graph the filter belongs to.
+ */
+struct AVFilterGraph *graph;
+
+/**
+ * Current timestamp of the link, as defined by the most recent
+ * frame(s), in link time_base units.
+ */
+int64_t current_pts;
+
+/**
+ * Current timestamp of the link, as defined by the most recent
+ * frame(s), in AV_TIME_BASE units.
+ */
+int64_t current_pts_us;
+
+/**
+ * Index in the age array.
+ */
+int age_index;
+
+/**
+ * Frame rate of the stream on the link, or 1/0 if unknown or variable;
+ * if left to 0/0, will be automatically copied from the first input
+ * of the source filter if it exists.
+ *
+ * Sources should set it to the best estimation of the real frame rate.
+ * If the source frame rate is unknown or variable, set this to 1/0.
+ * Filters should update it if necessary depending on their function.
+
[FFmpeg-devel] [PATCH 5/6] lavfi/tests/filtfmts: include internal.h.
Signed-off-by: Nicolas George
---
libavfilter/tests/filtfmts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/tests/filtfmts.c b/libavfilter/tests/filtfmts.c
index f59199c..199d74d 100644
--- a/libavfilter/tests/filtfmts.c
+++ b/libavfilter/tests/filtfmts.c
@@ -30,6 +30,7 @@
#include "libavfilter/avfilter.h"
#include "libavfilter/formats.h"
+#include "libavfilter/internal.h"
static void print_formats(AVFilterContext *filter_ctx)
{
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.
On Sun, 18 Dec 2016 13:22:21 +0100
Nicolas George wrote:
> API-Change: libavfilter
> Signed-off-by: Nicolas George
> ---
> libavfilter/avfilter.h | 2 +
> libavfilter/internal.h | 199
> +
> libavfilter/version.h | 3 +
> 3 files changed, 204 insertions(+)
>
>
> Not sure what the preferred delay would be. I suspect not many programs use
> libavfilter yet. In the meantime, all new fields must be added at both
> places and tested.
>
>
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index 828b270..6109e58 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -377,6 +377,7 @@ struct AVFilterContext {
> unsigned ready;
> };
>
> +#if FF_API_AVFILTERLINK_PUBLIC
> /**
> * A link between two filters. This contains pointers to the source and
> * destination filters between which this link exists, and the indexes of
> @@ -593,6 +594,7 @@ struct AVFilterLink {
> #endif /* FF_INTERNAL_FIELDS */
>
> };
> +#endif /* FF_API_AVFILTERLINK_PUBLIC */
>
> /**
> * Link two filters together.
> diff --git a/libavfilter/internal.h b/libavfilter/internal.h
> index a8b69fd..599be24 100644
> --- a/libavfilter/internal.h
> +++ b/libavfilter/internal.h
> @@ -145,6 +145,205 @@ struct AVFilterPad {
> int needs_writable;
> };
>
> +#if !FF_API_AVFILTERLINK_PUBLIC
> +/**
> + * A link between two filters. This contains pointers to the source and
> + * destination filters between which this link exists, and the indexes of
> + * the pads involved. In addition, this link also contains the parameters
> + * which have been negotiated and agreed upon between the filter, such as
> + * image dimensions, format, etc.
> + */
> +struct AVFilterLink {
> +AVFilterContext *src; ///< source filter
> +AVFilterPad *srcpad;///< output pad on the source filter
> +
> +AVFilterContext *dst; ///< dest filter
> +AVFilterPad *dstpad;///< input pad on the dest filter
> +
> +enum AVMediaType type; ///< filter media type
> +
> +/* These parameters apply only to video */
> +int w; ///< agreed upon image width
> +int h; ///< agreed upon image height
> +AVRational sample_aspect_ratio; ///< agreed upon sample aspect ratio
> +/* These parameters apply only to audio */
> +uint64_t channel_layout;///< channel layout of current buffer (see
> libavutil/channel_layout.h)
> +int sample_rate;///< samples per second
> +
> +int format; ///< agreed upon media format
> +
> +/**
> + * Define the time base used by the PTS of the frames/samples
> + * which will pass through this link.
> + * During the configuration stage, each filter is supposed to
> + * change only the output timebase, while the timebase of the
> + * input link is assumed to be an unchangeable property.
> + */
> +AVRational time_base;
> +
> +/**
> + * Lists of formats and channel layouts supported by the input and output
> + * filters respectively. These lists are used for negotiating the format
> + * to actually be used, which will be loaded into the format and
> + * channel_layout members, above, when chosen.
> + *
> + */
> +AVFilterFormats *in_formats;
> +AVFilterFormats *out_formats;
> +
> +/**
> + * Lists of channel layouts and sample rates used for automatic
> + * negotiation.
> + */
> +AVFilterFormats *in_samplerates;
> +AVFilterFormats *out_samplerates;
> +struct AVFilterChannelLayouts *in_channel_layouts;
> +struct AVFilterChannelLayouts *out_channel_layouts;
> +
> +/**
> + * Audio only, the destination filter sets this to a non-zero value to
> + * request that buffers with the given number of samples should be sent
> to
> + * it. AVFilterPad.needs_fifo must also be set on the corresponding input
> + * pad.
> + * Last buffer before EOF will be padded with silence.
> + */
> +int request_samples;
> +
> +/** stage of the initialization of the link properties (dimensions, etc)
> */
> +enum {
> +AVLINK_UNINIT = 0, ///< not started
> +AVLINK_STARTINIT, ///< started, but incomplete
> +AVLINK_INIT ///< complete
> +} init_state;
> +
> +/**
> + * Graph the filter belongs to.
> + */
> +struct AVFilterGraph *graph;
> +
> +/**
> + * Current timestamp of the link, as defined by the most recent
> + * frame(s), in link time_base units.
> + */
> +int64_t current_pts;
> +
> +/**
> + * Current timestamp of the link, as defined by the most recent
> + * frame(s), in AV_TIME_BASE units.
> + */
> +int64_t current_pts_us;
> +
> +/**
> + * Index in the age array.
> + */
> +int age_index;
> +
> +/**
> + * Frame rate of the stream on the link, or 1/0 if unknown or variable;
> + *
Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.
L'octidi 28 frimaire, an CCXXV, wm4 a écrit : > Did you send the same patches to Libav? This makes the API incompatible > with Libav. Their API has been non-working for a long time, even if technically compatible with ours. Their problem. Regards, -- Nicolas Ge signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.
On Sun, 18 Dec 2016 13:37:44 +0100 Nicolas George wrote: > L'octidi 28 frimaire, an CCXXV, wm4 a écrit : > > Did you send the same patches to Libav? This makes the API incompatible > > with Libav. > > Their API has been non-working for a long time, even if technically > compatible with ours. Their problem. Can't confirm that assessment. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.
On Sun, Dec 18, 2016 at 01:22:21PM +0100, Nicolas George wrote: > API-Change: libavfilter > Signed-off-by: Nicolas George > --- > libavfilter/avfilter.h | 2 + > libavfilter/internal.h | 199 > + > libavfilter/version.h | 3 + > 3 files changed, 204 insertions(+) > > > Not sure what the preferred delay would be. I suspect not many programs use > libavfilter yet. In the meantime, all new fields must be added at both > places and tested. How does this patchset relate to the open-ness of the API ? you arent saying anything about the plans, goals, intend of this (or i missed it or fail to associate it with the patchset) Iam asking as it seems like this is moving libavfilter further away from being "open" and centralizing control over filters more. I most likely misinterpret this as i just see the change in the code and dont know the whole story but IMO we should move toward a clean and stable API that everyone can use. That also implies to allow filters to only use public API. while this patchset seems to make filters use more private api by making more needed API private. I think a open API and external filter support would drive developers and users towards libavfilter while locking it down would likely do the opposit [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.
On 12/18/2016 9:22 AM, Nicolas George wrote: > av_buffersink_get_frame_rate() did already exist; its argument becomes const. > > TODO minor version bump What's the purpose of adding these accessors? The only reason we have done this before was because of the now dropped libav ABI compatibility, since we had to add our own new fields below theirs which meant there was no guarantee of a fixed offset. That's the reason the accessor for frame_rate exists here, as far as i can see. Is this to make AVFilterLink a fully internal struct? What's the reason to do that in that case, instead of simply making its private fields actually internal and private? The idea for next bump was to clean all this mess for once and for all by deprecating all accessors, removing all the "no direct access" notes and moving all the private fields in public structs (Marked with a big "not part of the public API" warning like in the case of with AVFilterLink) into actual internal structs. That way public structs would finally become fully public and user friendly again. This change adds more abstraction and more symbols for what gain? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.
L'octidi 28 frimaire, an CCXXV, James Almer a écrit :
> Is this to make AVFilterLink a fully internal struct?
As you can see in patch 6/6 in this series.
> What's the reason
> to do that in that case, instead of simply making its private fields
> actually internal and private?
Can you suggest a method?
> The idea for next bump was to clean all this mess for once and for all by
Good: after this patch, there is no mess, everything is accessed through
the buffersink API.
> deprecating all accessors, removing all the "no direct access" notes and
> moving all the private fields in public structs (Marked with a big "not
> part of the public API" warning like in the case of with AVFilterLink)
> into actual internal structs.
By "actual internal structs", I suspect you mean something similar to
this:
typedef struct AVFormatContext {
...
AVFormatInternal *internal;
...
};
Introducing these structures was a big mistake. For the reasons, see the
recent discussion about making filter_frame() non-recursive (short of
it: it makes the actual code unreadable), plus another discussion I did
not take part about using options on these structure (short of it: a lot
of work if even possible).
I do not intend to extend that mistake in libavfilter. If possible, I
would rather like to kick it out, but fortunately the current uses are
very limited.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.
L'octidi 28 frimaire, an CCXXV, Michael Niedermayer a écrit : > How does this patchset relate to the open-ness of the API ? > you arent saying anything about the plans, goals, intend of this (or > i missed it or fail to associate it with the patchset) I am doing this to accommodate people who object to having a different view of AVFilterLink for the public API and the internal implementation, mostly Hendrik, Andreas and Clément. As for me, I am pretty happy with the current code that gives a different view of AVFilterLink to the public than the one used for implementation. Something like that is needed because some fields have a type that is not itself public. > Iam asking as it seems like this is moving libavfilter further away > from being "open" and centralizing control over filters more. > I most likely misinterpret this as i just see the change in the code > and dont know the whole story but IMO we should move toward a clean and > stable API that everyone can use. > That also implies to allow filters to only use public API. > while this patchset seems to make filters use more private api by > making more needed API private. I think a open API and external > filter support would drive developers and users towards libavfilter > while locking it down would likely do the opposit I am not sure I understand what you mean by openness. Do you mean applications writing their own filter and inserting it in a filter graph? If so, I can tell you it is not currently possible, and has not been since at least 2012-06-12 (9d0bfc5 lavfi: make AVFilterPad opaque after two major bumps.). Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2] af_hdcd: more FATE tests
Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%. Changed fate-suite sample files: * filter/hdcd-encoding-errors.flac (1.3M) replaced by a smaller version (140K). It can be replaced because the test only looks for a non-zero number of errors, so the existing test will still pass. * filter/hdcd-mix.flac (958K) added. It is a much better test than filter/hdcd.flac (910K), which is now unused, but can't be removed. * filter/hdcd-fake20bit.flac (168K) added. It is the first second of filter/hdcd.flac, with the 16-bit LSB copied into bit 20 of a 24-bit stream. There isn't an actual non-16-bit HDCD sample available to test. Net change -34K. Would be -944K if hdcd.flac could be removed. Signed-off-by: Burt P --- tests/fate/filter-audio.mak | 86 ++--- 1 file changed, 74 insertions(+), 12 deletions(-) diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak index 9c6f7cd..a55e3c9 100644 --- a/tests/fate/filter-audio.mak +++ b/tests/fate/filter-audio.mak @@ -255,17 +255,55 @@ fate-filter-volume: CMD = md5 -i $(SRC) -af aperms=random,volume=precision=fixed fate-filter-volume: CMP = oneline fate-filter-volume: REF = 4d6ba75ef3e32d305d066b9bc771d6f4 -FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd -fate-filter-hdcd: SRC = $(TARGET_SAMPLES)/filter/hdcd.flac -fate-filter-hdcd: CMD = md5 -i $(SRC) -af hdcd -f s24le -fate-filter-hdcd: CMP = oneline -fate-filter-hdcd: REF = 5db465a58d2fd0d06ca944b883b33476 - -FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze -fate-filter-hdcd-analyze: SRC = $(TARGET_SAMPLES)/filter/hdcd.flac -fate-filter-hdcd-analyze: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=pe -f s24le -fate-filter-hdcd-analyze: CMP = oneline -fate-filter-hdcd-analyze: REF = 6e39dc4629c1e84321c0d8bc069b42f6 +# hdcd-mix.flac is a mix of three different sources which are interesting for various reasons: +# first 5 seconds uses packet format A and max LLE of -7.0db +# second 5 seconds uses packet format B and has a gain mismatch between channels +# last 10 seconds is not HDCD but has a coincidental HDCD packet, it needs to be 10 seconds because it also tests the cdt expiration +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-mix +fate-filter-hdcd-mix: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-mix: CMD = md5 -i $(SRC) -af hdcd -f s24le +fate-filter-hdcd-mix: CMP = oneline +fate-filter-hdcd-mix: REF = 6a3cf7f920f419477ada264cc63b40da + +# output will be different because of the gain mismatch in the second and third parts +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-mix-psoff +fate-filter-hdcd-mix-psoff: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-mix-psoff: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false -f s24le +fate-filter-hdcd-mix-psoff: CMP = oneline +fate-filter-hdcd-mix-psoff: REF = b841866d5730852256ca57564c55e0ef + +# test the different analyze modes +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze-pe +fate-filter-hdcd-analyze-pe: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-analyze-pe: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=pe -f s24le +fate-filter-hdcd-analyze-pe: CMP = oneline +fate-filter-hdcd-analyze-pe: REF = 9ddd10dfea756160456e25dd96a752b8 +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze-lle +fate-filter-hdcd-analyze-lle: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-analyze-lle: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=lle -f s24le +fate-filter-hdcd-analyze-lle: CMP = oneline +fate-filter-hdcd-analyze-lle: REF = be353f79d3e653d658a6e6e99d7655c8 +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze-cdt +fate-filter-hdcd-analyze-cdt: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-analyze-cdt: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=cdt -f s24le +fate-filter-hdcd-analyze-cdt: CMP = oneline +fate-filter-hdcd-analyze-cdt: REF = d828abe932e0d2bfc914eaa23c15b7f6 +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze-tgm +fate-filter-hdcd-analyze-tgm: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-analyze-tgm: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=tgm -f s24le +fate-filter-hdcd-analyze-tgm: CMP = oneline +fate-filter-hdcd-analyze-tgm: REF = 407ed0dc8c6fd17cc8c0b53a8b2b0e34 +# the two additional analyze modes from libhdcd +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze-ltgm +fate-filter-hdcd-analyze-ltgm: SRC = $(TA
[FFmpeg-devel] [PATCHv3] af_hdcd: more FATE tests
Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%. Changed fate-suite sample files: * filter/hdcd-encoding-errors.flac (1.3M) replaced by a smaller version (140K). It can be replaced because the test only looks for a non-zero number of errors, so the existing test will still pass. * filter/hdcd-mix.flac (958K) added. It is a much better test than filter/hdcd.flac (910K), which is now unused, but can't be removed. * filter/hdcd-fake20bit.flac (168K) added. It is the first second of filter/hdcd.flac, with the 16-bit LSB copied into bit 20 of a 24-bit stream. There isn't an actual non-16-bit HDCD sample available to test. Net change -34K. Would be -944K if hdcd.flac could be removed. Signed-off-by: Burt P --- tests/fate/filter-audio.mak | 86 ++--- 1 file changed, 74 insertions(+), 12 deletions(-) diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak index 9c6f7cd..b356bcc 100644 --- a/tests/fate/filter-audio.mak +++ b/tests/fate/filter-audio.mak @@ -255,17 +255,55 @@ fate-filter-volume: CMD = md5 -i $(SRC) -af aperms=random,volume=precision=fixed fate-filter-volume: CMP = oneline fate-filter-volume: REF = 4d6ba75ef3e32d305d066b9bc771d6f4 -FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd -fate-filter-hdcd: SRC = $(TARGET_SAMPLES)/filter/hdcd.flac -fate-filter-hdcd: CMD = md5 -i $(SRC) -af hdcd -f s24le -fate-filter-hdcd: CMP = oneline -fate-filter-hdcd: REF = 5db465a58d2fd0d06ca944b883b33476 - -FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze -fate-filter-hdcd-analyze: SRC = $(TARGET_SAMPLES)/filter/hdcd.flac -fate-filter-hdcd-analyze: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=pe -f s24le -fate-filter-hdcd-analyze: CMP = oneline -fate-filter-hdcd-analyze: REF = 6e39dc4629c1e84321c0d8bc069b42f6 +# hdcd-mix.flac is a mix of three different sources which are interesting for various reasons: +# first 5 seconds uses packet format A and max LLE of -7.0db +# second 5 seconds uses packet format B and has a gain mismatch between channels +# last 10 seconds is not HDCD but has a coincidental HDCD packet, it needs to be 10 seconds because it also tests the cdt expiration +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-mix +fate-filter-hdcd-mix: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-mix: CMD = md5 -i $(SRC) -af hdcd -f s24le +fate-filter-hdcd-mix: CMP = oneline +fate-filter-hdcd-mix: REF = e7079913e90c124460cdbc712df5b84c + +# output will be different because of the gain mismatch in the second and third parts +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-mix-psoff +fate-filter-hdcd-mix-psoff: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-mix-psoff: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false -f s24le +fate-filter-hdcd-mix-psoff: CMP = oneline +fate-filter-hdcd-mix-psoff: REF = bd0e81fe17696b825ee3515ab928e6bb + +# test the different analyze modes +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze-pe +fate-filter-hdcd-analyze-pe: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-analyze-pe: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=pe -f s24le +fate-filter-hdcd-analyze-pe: CMP = oneline +fate-filter-hdcd-analyze-pe: REF = bb83e97bbd0064b9b1c0ef2f2c8f0c77 +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze-lle +fate-filter-hdcd-analyze-lle: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-analyze-lle: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=lle -f s24le +fate-filter-hdcd-analyze-lle: CMP = oneline +fate-filter-hdcd-analyze-lle: REF = 121cc4a681aa0caef5c664fece7a3ddc +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze-cdt +fate-filter-hdcd-analyze-cdt: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-analyze-cdt: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=cdt -f s24le +fate-filter-hdcd-analyze-cdt: CMP = oneline +fate-filter-hdcd-analyze-cdt: REF = 12136e6a00dd532994f6edcc347af1d4 +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze-tgm +fate-filter-hdcd-analyze-tgm: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac +fate-filter-hdcd-analyze-tgm: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=tgm -f s24le +fate-filter-hdcd-analyze-tgm: CMP = oneline +fate-filter-hdcd-analyze-tgm: REF = a3c39f62e9b9b42c9c440d0045d5fb2f +# the two additional analyze modes from libhdcd +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, PCM_S24LE) += fate-filter-hdcd-analyze-ltgm +fate-filter-hdcd-analyze-ltgm: SRC = $(TA
Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.
On 12/18/2016 3:32 PM, Nicolas George wrote:
> L'octidi 28 frimaire, an CCXXV, James Almer a écrit :
>> Is this to make AVFilterLink a fully internal struct?
>
> As you can see in patch 6/6 in this series.
>
>> What's the reason
>> to do that in that case, instead of simply making its private fields
>> actually internal and private?
>
> Can you suggest a method?
>
>> The idea for next bump was to clean all this mess for once and for all by
>
> Good: after this patch, there is no mess, everything is accessed through
> the buffersink API.
By breaking the API, adding extra abstraction and a bunch of new symbols.
You didn't answer what's the gain here. How is this better than keeping the
struct public and letting library users keep accessing its fields normally?
Why are you trying to make libavfilter so different than the rest? We have
scheduled the deprecation and removal of /all/ accessors, and now you want
to add more?
If people didn't use lavfi before, they will feel less motivated to do it
now since they can't even expect consistency with lavf or lavc.
And those that currently do will find themselves having to adapt their
programs without being given a reason as to why they are forced to, unlike
with other big API changes.
>
>> deprecating all accessors, removing all the "no direct access" notes and
>> moving all the private fields in public structs (Marked with a big "not
>> part of the public API" warning like in the case of with AVFilterLink)
>> into actual internal structs.
>
> By "actual internal structs", I suspect you mean something similar to
> this:
>
> typedef struct AVFormatContext {
> ...
> AVFormatInternal *internal;
> ...
> };
>
> Introducing these structures was a big mistake. For the reasons, see the
> recent discussion about making filter_frame() non-recursive (short of
> it: it makes the actual code unreadable), plus another discussion I did
Back to what i said above. You're breaking API and bothering lavfi users
to make internal code "more readable"?
> not take part about using options on these structure (short of it: a lot
> of work if even possible).
>
> I do not intend to extend that mistake in libavfilter. If possible, I
> would rather like to kick it out, but fortunately the current uses are
> very limited.
I get you don't like it, but the objective should be to provide a familiar
and user friendly API. Opaque internal structs don't affect users, they
don't ever have to worry about them, it's one field they will never touch.
Making the entire struct internal and bloating the library with accessors
to write or read what has been for years and is expected to be public
fields only because you want another way to hide internal state is a bit
overkill and disruptively user unfriendly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.
L'octidi 28 frimaire, an CCXXV, James Almer a écrit : > You didn't answer what's the gain here. Yes I did: discuss that with Hendrik, Andreas and Clément, not me. >How is this better than keeping the > struct public and letting library users keep accessing its fields normally? > Why are you trying to make libavfilter so different than the rest? We have > scheduled the deprecation and removal of /all/ accessors, and now you want > to add more? I think you did not read the code carefully enough. These accessors, on top of addressing Hendrik, Andreas and Clément's concerns, make the code actually more robust and readable. > If people didn't use lavfi before, they will feel less motivated to do it > now since they can't even expect consistency with lavf or lavc. Once again: consistency is only a means to an end. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/1] Fixing 3GPP Timed Text (TTXT / tx3g / mov_text) encoding for UTF-8 (ticket 6021)
According to the format specification (3GPP TS 26.245, section 5.2) "storage
lengths are specified as byte-counts, wheras highlighting is specified using
character offsets." This patch replaces byte counting with character counting
for highlighting. See the following page for a link to the specification:
https://gpac.wp.mines-telecom.fr/mp4box/ttxt-format-documentation/
---
libavcodec/movtextenc.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
index 20e01e2..3ae015a 100644
--- a/libavcodec/movtextenc.c
+++ b/libavcodec/movtextenc.c
@@ -70,6 +70,7 @@ typedef struct {
uint8_t style_fontsize;
uint32_t style_color;
uint16_t text_pos;
+uint16_t text_pos_chars;
} MovTextContext;
typedef struct {
@@ -216,10 +217,10 @@ static void mov_text_style_cb(void *priv, const char
style, int close)
}
s->style_attributes_temp->style_flag = 0;
-s->style_attributes_temp->style_start = AV_RB16(&s->text_pos);
+s->style_attributes_temp->style_start =
AV_RB16(&s->text_pos_chars);
} else {
if (s->style_attributes_temp->style_flag) { //break the style
record here and start a new one
-s->style_attributes_temp->style_end = AV_RB16(&s->text_pos);
+s->style_attributes_temp->style_end =
AV_RB16(&s->text_pos_chars);
av_dynarray_add(&s->style_attributes, &s->count,
s->style_attributes_temp);
s->style_attributes_temp =
av_malloc(sizeof(*s->style_attributes_temp));
if (!s->style_attributes_temp) {
@@ -230,10 +231,10 @@ static void mov_text_style_cb(void *priv, const char
style, int close)
}
s->style_attributes_temp->style_flag =
s->style_attributes[s->count - 1]->style_flag;
-s->style_attributes_temp->style_start = AV_RB16(&s->text_pos);
+s->style_attributes_temp->style_start =
AV_RB16(&s->text_pos_chars);
} else {
s->style_attributes_temp->style_flag = 0;
-s->style_attributes_temp->style_start = AV_RB16(&s->text_pos);
+s->style_attributes_temp->style_start =
AV_RB16(&s->text_pos_chars);
}
}
switch (style){
@@ -248,7 +249,7 @@ static void mov_text_style_cb(void *priv, const char style,
int close)
break;
}
} else {
-s->style_attributes_temp->style_end = AV_RB16(&s->text_pos);
+s->style_attributes_temp->style_end = AV_RB16(&s->text_pos_chars);
av_dynarray_add(&s->style_attributes, &s->count,
s->style_attributes_temp);
s->style_attributes_temp =
av_malloc(sizeof(*s->style_attributes_temp));
@@ -273,7 +274,7 @@ static void mov_text_style_cb(void *priv, const char style,
int close)
break;
}
if (s->style_attributes_temp->style_flag) { //start of new style record
-s->style_attributes_temp->style_start = AV_RB16(&s->text_pos);
+s->style_attributes_temp->style_start =
AV_RB16(&s->text_pos_chars);
}
}
s->box_flags |= STYL_BOX;
@@ -284,11 +285,11 @@ static void mov_text_color_cb(void *priv, unsigned int
color, unsigned int color
MovTextContext *s = priv;
if (color_id == 2) {//secondary color changes
if (s->box_flags & HLIT_BOX) { //close tag
-s->hlit.end = AV_RB16(&s->text_pos);
+s->hlit.end = AV_RB16(&s->text_pos_chars);
} else {
s->box_flags |= HCLR_BOX;
s->box_flags |= HLIT_BOX;
-s->hlit.start = AV_RB16(&s->text_pos);
+s->hlit.start = AV_RB16(&s->text_pos_chars);
s->hclr.color = color | (0xFF << 24); //set alpha value to FF
}
}
@@ -302,7 +303,10 @@ static void mov_text_text_cb(void *priv, const char *text,
int len)
{
MovTextContext *s = priv;
av_bprint_append_data(&s->buffer, text, len);
-s->text_pos += len;
+s->text_pos += len; // length of text in bytes
+for (int i = 0; i < len; i++) // length of text in UTF-8 characters
+if ((text[i] & 0xC0) != 0x80)
+s->text_pos_chars++;
}
static void mov_text_new_line_cb(void *priv, int forced)
@@ -310,6 +314,7 @@ static void mov_text_new_line_cb(void *priv, int forced)
MovTextContext *s = priv;
av_bprint_append_data(&s->buffer, "\n", 1);
s->text_pos += 1;
+s->text_pos_chars += 1;
}
static const ASSCodesCallbacks mov_text_callbacks = {
@@ -328,6 +333,7 @@ static int mov_text_encode_frame(AVCodecContext *avctx,
unsigned char *buf,
size_t j;
s->text_pos = 0;
+s->text_pos_chars = 0;
s->count = 0;
s->box_flags = 0;
s->style_entries = 0;
--
1.9.5 (Apple Git-50.3)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/l
Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.
On Sun, 18 Dec 2016 19:32:16 +0100
Nicolas George wrote:
> By "actual internal structs", I suspect you mean something similar to
> this:
>
> typedef struct AVFormatContext {
> ...
> AVFormatInternal *internal;
> ...
> };
>
> Introducing these structures was a big mistake. For the reasons, see the
> recent discussion about making filter_frame() non-recursive (short of
> it: it makes the actual code unreadable), plus another discussion I did
> not take part about using options on these structure (short of it: a lot
> of work if even possible).
>
> I do not intend to extend that mistake in libavfilter. If possible, I
> would rather like to kick it out, but fortunately the current uses are
> very limited.
For buffersink, you could simply return a struct with the parameters.
As a value type, it'd be a copy and wouldn't need accessors.
Since you moved the discussion to general API issues...
Using public fields and such "internal" structs is functionally
equivalent to having an opaque struct with trivial accessors. It's
basically a style issue.
(The former approach, internal structs, is used and preferred for
AVCodecContext etc. because it has no impact on the API.)
The difference between them is essentially syntax only. Both of them
have multiple disadvantages:
- too much to deal with at once (whether it's fields or
setters/getters), no logical separation of functionality that is
lesser needed or doesn't make sense in some contexts. (Consider all
these AVCodecContext fields for tuning encoders - what do they do for
decoding? What do fields, which are audio-only, do if video is
encoded or decoded?)
- it's unclear when these fields can be set or not. (Why _can_ you set
a field if the graph is already "configured"? What happens then? How
is the user supposed to know when it's ok to set them?)
- even if you argue that the previous point can be fixed by having the
setters check the state and return an error value on misuse, it's
complex for both API implementer and user
- many uses of this hide internal fields from the public API user,
which is good. But at the same time, this moves away from the
(probably worthy) goal of allowing outside implementation of
codecs, (de)muxers, filters.
So I would suggest that instead of changing the whole API to use
accessors, we should make the API more "transactional", and force
correct use by API design. For example, we could make AVCodecContext
opaque, and provide instantiation functions that take specialized
structs (such as AVCodecParameters) to open the decoder. Making
creation and use of an API would be a good step into improving the API
IMHO. I found myself confused over what fields are always immutable in
an AVHWFramesContext, and which are mutable until "init", and that's an
example of the more classic mixed init/use API concept in ffmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] libavcodec/movtextdec.c: fixing decoding for UTF-8 (ticket 6021)
Yes, it was supposed to be box_types, not ox_types. I must have removed the b by mistake after I tested the code. Should I resubmit the patch? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.
On Sun, Dec 18, 2016 at 07:41:14PM +0100, Nicolas George wrote: > L'octidi 28 frimaire, an CCXXV, Michael Niedermayer a écrit : > > How does this patchset relate to the open-ness of the API ? > > you arent saying anything about the plans, goals, intend of this (or > > i missed it or fail to associate it with the patchset) > > I am doing this to accommodate people who object to having a different > view of AVFilterLink for the public API and the internal implementation, > mostly Hendrik, Andreas and Clément. > > As for me, I am pretty happy with the current code that gives a > different view of AVFilterLink to the public than the one used for > implementation. Something like that is needed because some fields have a > type that is not itself public. > > > Iam asking as it seems like this is moving libavfilter further away > > from being "open" and centralizing control over filters more. > > I most likely misinterpret this as i just see the change in the code > > and dont know the whole story but IMO we should move toward a clean and > > stable API that everyone can use. > > That also implies to allow filters to only use public API. > > while this patchset seems to make filters use more private api by > > making more needed API private. I think a open API and external > > filter support would drive developers and users towards libavfilter > > while locking it down would likely do the opposit > > I am not sure I understand what you mean by openness. Do you mean > applications writing their own filter and inserting it in a filter > graph? yes and ideally also installable filters like plugins but really plugins are IMHO not hard, having an API that one can access is the imortant part. Even without a true plugin API other apps or users could link in filters build from a seperate package quite easily > If so, I can tell you it is not currently possible, and has not > been since at least 2012-06-12 (9d0bfc5 lavfi: make AVFilterPad opaque > after two major bumps.). i know, but at the time all this closing down of the API happened it was said that this was temporary (not by you and i dont remember who said so and not limited to libavfilter) and now over 4 years later temporary seems to be changing into the permanent end. IMHO if you want libavfilter to be a success in the long term it needs to be a open system with clean API that anyone can use and add filters to. As it is libavfilter is limited to what ffmpeg developers want INSIDE ffmpeg. If a filter doesnt fit into that it will likely be rejected. Which makes sense if there are external filters / plugins. But if the only way to use a filter in libavfilter is through it being accepted into main ffmpeg git that just makes libavfilter unfit as a _general_ filter framework. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] Fixing 3GPP Timed Text (TTXT / tx3g / mov_text) encoding for UTF-8 (ticket 6021)
Good question. Since text_pos_chars never exceeds the existing variable text_pos, I did not think about this. No, there are no checks. The spec says that "Authors should limit the string in each text sample to not more than 2048 bytes, for maximum terminal interoperability", but the code does not enforce this limit (or the maximum uint16_t value of 65535 for that matter). The likeli- hood of exceeding this limit is very small, but it does not hurt to add a check. In any case text_pos >= text_pos_chars, so it should be sufficient to check just text_pos. In mov_text_new_line_cb we only increment by 1, so checking if s->text_pos == 0 after that is enough. In mov_text_text_cb this check can be used instead, placed before the length len is added to text_pos: if (len > UINT16_MAX || (s->text_pos > UINT16_MAX - len)) // Overflow I am new to the project's source code and do not know how errors and warnings should be handled, but could it be an idea to print a warning if text_pos > 2048, and print an error message and abort in case of overflow? Or should the rest of the text just be truncated? PS. Please excuse the duplicate patch that was sent an hour or two ago. It is identical to the one I submitted a couple of days ago and I have no idea why or how that happened. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] live_start_index & ignoring "options not found"
Hey, I use live_start_index to control which segment ffmpeg starts with on a HLS live stream. This is working as expected. However, when the input file is NOT a HLS live stream then using "live_start_index" of course gives you a "Option live_start_index not found" and then quits ffmpeg. I'd like to use "live_start_index" whenever the input is HLS and ignore it when it is not HLS without knowing beforehand what I am using as input. Is there a way to safely ignore "options not found" and continue? Thanks, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] af_hdcd: more FATE tests
On Sun, Dec 18, 2016 at 12:48:45PM -0600, Burt P wrote: > Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%. > > Changed fate-suite sample files: > * filter/hdcd-encoding-errors.flac (1.3M) replaced by > a smaller version (140K). It can be replaced because the test > only looks for a non-zero number of errors, so the existing test > will still pass. IMO replacing files is not ok it would change all past instances of the related fate test a bug report refering to a fate failure could become unreproduceable or otherwise working fate tests could start failing ... as much as i prefer to safe a few bytes in this case i prefer to waste some space over the potential problems you can add files, but not remove or replace unless they are truly unused by every past checkout [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] libavcodec/movtextdec.c: fixing decoding for UTF-8 (ticket 6021)
On Sun, Dec 18, 2016 at 08:44:29PM +, Erik Bråthen Solem wrote: > Yes, it was supposed to be box_types, not ox_types. I must have removed the b > by mistake after I tested the code. Should I resubmit the patch? the change is trivial but the code that was tested should be submted exactly, so please test and submit a corrected patch 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/atempo: Avoid false triggering an assertion failure
On Sat, 17 Dec 2016, pkoshe...@gmail.com wrote:
From: Pavel Koshevoy
Steps to reproduce:
./ffmpeg_g -f s16be -i /dev/null -af atempo=0.5 -y /tmp/atempo.wav
---
libavfilter/af_atempo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 59b08ec..a487882 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -914,8 +914,8 @@ static int yae_flush(ATempoContext *atempo,
atempo->state = YAE_FLUSH_OUTPUT;
-if (atempo->position[0] == frag->position[0] + frag->nsamples &&
-atempo->position[1] == frag->position[1] + frag->nsamples) {
+if (atempo->position[0] >= frag->position[0] + frag->nsamples &&
+atempo->position[1] >= frag->position[1] + frag->nsamples) {
// the current fragment is already flushed:
return 0;
}
Thanks, this indeed fixes the assertion I came accross. Do you want me to
apply?
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/1] Updated version of patch 1840 (ticket 6021)
Between testing and patch generation a character was deleted by mistake, which
broke the patch. This updated version fixes this.
Original patch description:
Character offsets were interpreted as byte offsets, resulting in misplaced
styling tags where multibyte characters were involved. The entire subtitle
stream would even be rendered invalid if such a misplaced tag happened to
split a multibyte character. This patch fixes this for UTF-8; UTF-16 was and
still is broken. These are the only supported encodings according to the spec.
---
libavcodec/movtextdec.c | 95 +++--
1 file changed, 53 insertions(+), 42 deletions(-)
diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index 7b5b161..4cffacf 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -328,6 +328,7 @@ static int text_to_ass(AVBPrint *buf, const char *text,
const char *text_end,
int i = 0;
int j = 0;
int text_pos = 0;
+int text_pos_chars = 0;
if (text < text_end && m->box_flags & TWRP_BOX) {
if (m->w.wrap_flag == 1) {
@@ -338,50 +339,59 @@ static int text_to_ass(AVBPrint *buf, const char *text,
const char *text_end,
}
while (text < text_end) {
-if (m->box_flags & STYL_BOX) {
-for (i = 0; i < m->style_entries; i++) {
-if (m->s[i]->style_flag && text_pos == m->s[i]->style_end) {
-av_bprintf(buf, "{\\r}");
+if ((*text & 0xC0) != 0x80) { // Boxes never split multibyte characters
+if (m->box_flags & STYL_BOX) {
+for (i = 0; i < m->style_entries; i++) {
+if (m->s[i]->style_flag &&
+text_pos_chars == m->s[i]->style_end)
+{
+av_bprintf(buf, "{\\r}");
+}
}
-}
-for (i = 0; i < m->style_entries; i++) {
-if (m->s[i]->style_flag && text_pos == m->s[i]->style_start) {
-if (m->s[i]->style_flag & STYLE_FLAG_BOLD)
-av_bprintf(buf, "{\\b1}");
-if (m->s[i]->style_flag & STYLE_FLAG_ITALIC)
-av_bprintf(buf, "{\\i1}");
-if (m->s[i]->style_flag & STYLE_FLAG_UNDERLINE)
-av_bprintf(buf, "{\\u1}");
-av_bprintf(buf, "{\\fs%d}", m->s[i]->fontsize);
-for (j = 0; j < m->ftab_entries; j++) {
-if (m->s[i]->style_fontID == m->ftab[j]->fontID)
-av_bprintf(buf, "{\\fn%s}", m->ftab[j]->font);
+for (i = 0; i < m->style_entries; i++) {
+if (m->s[i]->style_flag
+&& text_pos_chars == m->s[i]->style_start)
+{
+if (m->s[i]->style_flag & STYLE_FLAG_BOLD)
+av_bprintf(buf, "{\\b1}");
+if (m->s[i]->style_flag & STYLE_FLAG_ITALIC)
+av_bprintf(buf, "{\\i1}");
+if (m->s[i]->style_flag & STYLE_FLAG_UNDERLINE)
+av_bprintf(buf, "{\\u1}");
+/* (No need to print font style if equal to default?)
*/
+av_bprintf(buf, "{\\fs%d}", m->s[i]->fontsize);
+for (j = 0; j < m->ftab_entries; j++) {
+if (m->s[i]->style_fontID == m->ftab[j]->fontID)
+av_bprintf(buf, "{\\fn%s}", m->ftab[j]->font);
+}
}
}
}
-}
-if (m->box_flags & HLIT_BOX) {
-if (text_pos == m->h.hlit_start) {
-/* If hclr box is present, set the secondary color to the color
- * specified. Otherwise, set primary color to white and
secondary
- * color to black. These colors will come from
TextSampleModifier
- * boxes in future and inverse video technique for highlight
will
- * be implemented.
- */
-if (m->box_flags & HCLR_BOX) {
-av_bprintf(buf, "{\\2c&H%02x%02x%02x&}",
m->c.hlit_color[2],
-m->c.hlit_color[1], m->c.hlit_color[0]);
-} else {
-av_bprintf(buf, "{\\1c&H00&}{\\2c&HFF&}");
+if (m->box_flags & HLIT_BOX) {
+if (text_pos_chars == m->h.hlit_start) {
+/* If hclr box is present, set the secondary color to the
+ * color specified. Otherwise, set primary color to white
+ * and secondary color to black. These colors will come
from
+ * TextSampleModifier boxes in future and inverse video
+ * technique for highlight will be implemented.
+ */
Re: [FFmpeg-devel] [FFmpeg-devel, 1/1] libavcodec/movtextdec.c: fixing decoding for UTF-8 (ticket 6021)
Done. It was assigned its own patch number (1860), so I am changing the state of this one to "Superseded". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] Fixing 3GPP Timed Text (TTXT / tx3g / mov_text) encoding for UTF-8 (ticket 6021)
Accidental duplicate of patch 1818. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi/framequeue: avoid empty structs.
Fix compilation on MSVC.
Signed-off-by: Nicolas George
---
libavfilter/framequeue.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/framequeue.h b/libavfilter/framequeue.h
index 558ea3..f5ef744638 100644
--- a/libavfilter/framequeue.h
+++ b/libavfilter/framequeue.h
@@ -44,6 +44,7 @@ typedef struct FFFrameBucket {
* It is currently empty.
*/
typedef struct FFFrameQueueGlobal {
+char dummy; /* C does not allow empty structs */
} FFFrameQueueGlobal;
/**
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/framequeue: avoid empty structs.
Le nonidi 29 frimaire, an CCXXV, Nicolas George a écrit : > Fix compilation on MSVC. Forgot to write in the comment beore sending: this is obviously untested. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
