Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Anton Khirnov 
Quoting Nicolas George (2020-02-27 19:44:39)
> Vittorio Giovara (12020-02-27):
> > joking aside, i see nothing wrong in having a bit more granular libraries,
> > subtitle handling could be a good example usecase.
> 
> Seriously?
> 
> $ git grep avpriv | wc -l
> 1648
> 
> This is how much "nothing wrong" we already have because the libraries
> are split. And having to maintain ABI stability for private APIs is only
> one cause of problems among others.

avpriv is not a necessary result of having multiple libraries. It is a
bug caused by bad API design. There is no fundamental reason for having
private interfaces.

In my view, no new private interfaces should be accepted and all of the
existing ones should be gradually removed.

> 
> On the other side, would you be able to quote only one actual, practical
> benefit of having several libraries instead of one that could not be
> achieved more simply with configure options? I suspect not, because I
> have looked for them and not found.

I can give you several:
- it allows callers to use a subset of functionality without depending
  on a giant monsterlibrary; you don't want to depend on the entire
  libavcodec if you just want to resample; you don't want to depend on
  the entire libavformat if you just want some handy IO wrappers
- related to the previous points, it would allow us to use that
  functionality more easily internally without having everything depend
  on everything; people already do IO in libavcodec, but they can't use
  avio for it; if the libraries were split - they could
- having our interfaces public forces us to make them more strict and
  explicit and generally be more careful about their design; that is
  generally a good thing - lavc and lavf would greatly benefit from
  having more internal structure

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

2020-02-27 Thread Andreas Rheinhardt 
On Tue, Feb 25, 2020 at 2:24 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> Andreas Rheinhardt:
> > Andreas Rheinhardt:
> >> Andreas Rheinhardt:
> >>> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
> >>> beginning referencing the main level 1 elements (i.e. not the Clusters)
> >>> and one at the end, referencing the Clusters. This second SeekHead was
> >>> useless and has therefore been removed. Yet the SeekHead-related
> >>> functions and structures are still geared towards this usecase: They
> >>> are built around an allocated array of variable size that gets
> >>> reallocated every time an element is added to it although the maximum
> >>> number of Seek entries is a small compile-time constant, so that one
> should
> >>> rather include the array in the SeekHead structure itself; and said
> >>> structure should be contained in the MatroskaMuxContext instead of
> being
> >>> allocated separately.
> >>>
> >>> The earlier code reserved space for a SeekHead with 10 entries,
> although
> >>> we currently write at most 6. Reducing said number implied that every
> >>> Matroska/Webm file will be 84 bytes smaller and required to adapt
> >>> several FATE tests; furthermore, the reserved amount overestimated the
> >>> amount needed for for the SeekHead's length field and how many bytes
> >>> need to be reserved to write a EBML Void element, bringing the total
> >>> reduction to 89 bytes.
> >>>
> >>> Signed-off-by: Andreas Rheinhardt 
> >>> ---
> >>
> >> Ping.
> >>
> >> - Andreas
> >>
> > Ping (the actual patch (which has been omitted for brevity) is here:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/256997.html).
> >
> > - Andreas
> >
> Another ping.
>
> - Andreas
>

Ping.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/v4l2_context: fix compile warning for incompatible pointer type

2020-02-27 Thread Andriy Gelman 
On Fri, 28. Feb 00:14, Linjie Fu wrote:
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/v4l2_context.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
> index 95a2bfa..8110bbb 100644
> --- a/libavcodec/v4l2_context.c
> +++ b/libavcodec/v4l2_context.c
> @@ -48,7 +48,7 @@ static inline V4L2m2mContext *ctx_to_m2mctx(V4L2Context 
> *ctx)
>  container_of(ctx, V4L2m2mContext, capture);
>  }
>  
> -static inline AVClass *logger(V4L2Context *ctx)
> +static inline AVCodecContext *logger(V4L2Context *ctx)
>  {
>  return ctx_to_m2mctx(ctx)->avctx;
>  }
> -- 

lgtm

Thanks,
-- 
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Anton Khirnov 
Quoting Clément Bœsch (2020-02-27 19:36:24)
> On Thu, Feb 27, 2020 at 12:35:03PM +0100, Anton Khirnov wrote:
> [...]
> > AFAIU one of the still-open questions for the subtitle redesign is what
> > does it mean to decode or encode a subtitle.
> 
> There are multiple markups available for text subtitles, and there are
> multiple ways of representing graphic rectangles for bitmap subtitles.
> 
> So for text subtitles, decoding and encoding respectively means
> transforming them in a common markup to represent them all (currently ASS
> is our "raw" representation) and back into their markup specifications. We
> have a bunch of those already (subrip, microdvd, subviewer, ...).

Is it still true that ASS is a superset of everything? Is that likely to
remain the case for the foreseeable future?

> 
> For bitmap subtitles, decoding and encoding respectively means
> transforming the bitstream into rectangle structures with RAW images
> inside and back into the codec-specific bitstream.
> 
> > And one of the options is putting the AVPacket->"decoded subtitle"
> > (whatever that is) and "decoded subtitle"->AVPacket conversions into a
> > separate library.
> 
> And then you can't have them in libavfilter, so you can't have a sane
> harmony with medias including subtitle streams. It's problematic with many
> basic use cases. One random example: if you're transcoding an audio/video
> and somehow altering the timings within lavfi, you have to give the
> subtitles.

I don't see why that necessarily follows from not using AVFrame.
avfilter does not have to be tied to only using AVFrame forever for all
eternity. It could have a different path for subtitles. Their handling
is going to be pretty different in any case.

Note that I'm not saying it SHOULD be done this way. I'm saying that it
seems like an option that should not be disregarded without
consideration.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mxfenc: Never set codec_ul UID to NULL

2020-02-27 Thread Andreas Rheinhardt 
mxf distinguishes codec profiles by different UIDs and therefore needs
to check that the input is actually compatible with mxf (i.e. if there
is a defined UID for it). If not, then sometimes the UID would be set to
NULL and writing the (video) packet would fail. Yet the following audio
packet would trigger writing the header (which has been postponed because
the UID is not known at the start) and if the UID is NULL, this can lead
to segfaults. This commit therefore stops setting the UID to NULL if the
input is incompatible with mxf (it has initially been set to a generic
value in mxf_write_header()).

Fixes #7993.

Signed-off-by: Andreas Rheinhardt 
---
a) #7993 is actually a segfault even if its description suggests
otherwise.
b) My actually preferred way to fix this was to error out if an audio
packet is encountered and the header has not been written yet, thereby
ensuring that only a video packet can trigger writing the header and
said code is only reached when the video is actually compatible with mxf
(or with this muxer?). Yet I was surprised to find out that the
FATE-test mxf-d10-user-comments would fail with this, because right now
writing the header in this test is triggered by an audio packet (the
video packets aren't written because they are not of the right size) and
if these aren't written either, there will be zero bytes of output.
c) It seems that mxf_write_header() doesn't actually write anything and
could be converted into an init function.

 libavformat/mxfenc.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 7ea47d7311..c00ab9d1c3 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1952,7 +1952,6 @@ static int mxf_parse_prores_frame(AVFormatContext *s, 
AVStream *st, AVPacket *pk
 if (mxf->header_written)
 return 1;
 
-sc->codec_ul = NULL;
 profile = st->codecpar->profile;
 for (i = 0; i < FF_ARRAY_ELEMS(mxf_prores_codec_uls); i++) {
 if (profile == mxf_prores_codec_uls[i].profile) {
@@ -1960,7 +1959,7 @@ static int mxf_parse_prores_frame(AVFormatContext *s, 
AVStream *st, AVPacket *pk
 break;
 }
 }
-if (!sc->codec_ul)
+if (i == FF_ARRAY_ELEMS(mxf_prores_codec_uls))
 return 0;
 
 sc->frame_size = pkt->size;
@@ -2006,7 +2005,6 @@ static int mxf_parse_dnxhd_frame(AVFormatContext *s, 
AVStream *st, AVPacket *pkt
 if (pkt->size < 43)
 return 0;
 
-sc->codec_ul = NULL;
 cid = AV_RB32(pkt->data + 0x28);
 for (i = 0; i < FF_ARRAY_ELEMS(mxf_dnxhd_codec_uls); i++) {
 if (cid == mxf_dnxhd_codec_uls[i].cid) {
@@ -2014,7 +2012,7 @@ static int mxf_parse_dnxhd_frame(AVFormatContext *s, 
AVStream *st, AVPacket *pkt
 break;
 }
 }
-if (!sc->codec_ul)
+if (i == FF_ARRAY_ELEMS(mxf_dnxhd_codec_uls))
 return 0;
 
 sc->component_depth = 0;
@@ -2177,6 +2175,7 @@ static int mxf_parse_h264_frame(AVFormatContext *s, 
AVStream *st,
 const uint8_t *buf = pkt->data;
 const uint8_t *buf_end = pkt->data + pkt->size;
 const uint8_t *nal_end;
+const UID *codec_ul = NULL;
 uint32_t state = -1;
 int extra_size = 512; // support AVC Intra files without SPS/PPS header
 int i, frame_size, slice_type, intra_only = 0;
@@ -2246,12 +2245,11 @@ static int mxf_parse_h264_frame(AVFormatContext *s, 
AVStream *st,
 
 if (!sps)
 sc->interlaced = st->codecpar->field_order != AV_FIELD_PROGRESSIVE ? 1 
: 0;
-sc->codec_ul = NULL;
 frame_size = pkt->size + extra_size;
 
 for (i = 0; i < FF_ARRAY_ELEMS(mxf_h264_codec_uls); i++) {
 if (frame_size == mxf_h264_codec_uls[i].frame_size && sc->interlaced 
== mxf_h264_codec_uls[i].interlaced) {
-sc->codec_ul = _h264_codec_uls[i].uid;
+codec_ul = _h264_codec_uls[i].uid;
 sc->component_depth = 10; // AVC Intra is always 10 Bit
 sc->aspect_ratio = (AVRational){ 16, 9 }; // 16:9 is mandatory for 
broadcast HD
 st->codecpar->profile = mxf_h264_codec_uls[i].profile;
@@ -2265,7 +2263,7 @@ static int mxf_parse_h264_frame(AVFormatContext *s, 
AVStream *st,
mxf_h264_codec_uls[i].profile == sps->profile_idc &&
(mxf_h264_codec_uls[i].intra_only < 0 ||
 mxf_h264_codec_uls[i].intra_only == intra_only)) {
-sc->codec_ul = _h264_codec_uls[i].uid;
+codec_ul = _h264_codec_uls[i].uid;
 st->codecpar->profile = sps->profile_idc;
 st->codecpar->level = sps->level_idc;
 // continue to check for avc intra
@@ -2274,10 +2272,11 @@ static int mxf_parse_h264_frame(AVFormatContext *s, 
AVStream *st,
 
 av_free(sps);
 
-if (!sc->codec_ul) {
+if (!codec_ul) {
 av_log(s, AV_LOG_ERROR, "h264 profile not supported\n");
 return 0;
 }
+sc->codec_ul = codec_ul;
 
 return 1;
 }
@@ -2374,9 +2373,13 @@

[FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: add some missing content package rates

2020-02-27 Thread Marton Balint 
Fixes ticket #8523.

Signed-off-by: Marton Balint 
---
 libavformat/mxf.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 14056647c5..987410258a 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -135,10 +135,23 @@ static const MXFContentPackageRate 
mxf_content_package_rates[] = {
 {  2, { 1,24} },
 {  3, { 1001, 24000 } },
 {  4, { 1,25} },
+{  6, { 1,30} },
 {  7, { 1001, 3 } },
+{  8, { 1   , 48} },
+{  9, { 1001, 48000 } },
 { 10, { 1,50} },
 { 12, { 1,60} },
 { 13, { 1001, 6 } },
+{ 14, { 1,72} },
+{ 15, { 1001, 72000 } },
+{ 16, { 1,75} },
+{ 18, { 1,90} },
+{ 19, { 1001, 9 } },
+{ 20, { 1,96} },
+{ 21, { 1001, 96000 } },
+{ 22, { 1,100   } },
+{ 24, { 1,120   } },
+{ 25, { 1001, 12} },
 {0}
 };
 
-- 
2.16.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/4] avformat/mxfenc: move content package rates and timebase combinations to a separate struct

2020-02-27 Thread Marton Balint 
Signed-off-by: Marton Balint 
---
 libavformat/mxf.c | 28 
 libavformat/mxf.h |  5 +
 2 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 10ccd770e3..14056647c5 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -131,25 +131,21 @@ int ff_mxf_decode_pixel_layout(const char 
pixel_layout[16], enum AVPixelFormat *
 return -1;
 }
 
-static const AVRational mxf_time_base[] = {
-{ 1001, 24000 },
-{ 1, 24},
-{ 1001, 3 },
-{ 1001, 6 },
-{ 1, 25 },
-{ 1, 50 },
-{ 1, 60 },
-{ 0, 0}
-};
-
-static const int mxf_content_package_rates[] = {
-3, 2, 7, 13, 4, 10, 12,
+static const MXFContentPackageRate mxf_content_package_rates[] = {
+{  2, { 1,24} },
+{  3, { 1001, 24000 } },
+{  4, { 1,25} },
+{  7, { 1001, 3 } },
+{ 10, { 1,50} },
+{ 12, { 1,60} },
+{ 13, { 1001, 6 } },
+{0}
 };
 
 int ff_mxf_get_content_package_rate(AVRational time_base)
 {
-for (int i = 0; mxf_time_base[i].num; i++)
-if (!av_cmp_q(time_base, mxf_time_base[i]))
-return mxf_content_package_rates[i];
+for (int i = 0; mxf_content_package_rates[i].rate; i++)
+if (!av_cmp_q(time_base, mxf_content_package_rates[i].tb))
+return mxf_content_package_rates[i].rate;
 return 0;
 }
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index 2669269830..f2fff2781e 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -59,6 +59,11 @@ enum MXFFrameLayout {
 SegmentedFrame,
 };
 
+typedef struct MXFContentPackageRate {
+int rate;
+AVRational tb;
+} MXFContentPackageRate;
+
 typedef struct KLVPacket {
 UID key;
 int64_t offset;
-- 
2.16.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/4] avformat/mxf: get rid of samples per frame array usage

2020-02-27 Thread Marton Balint 
Signed-off-by: Marton Balint 
---
 libavformat/mxf.c| 44 
 libavformat/mxf.h|  6 --
 libavformat/mxfdec.c | 23 +++
 libavformat/mxfenc.c | 24 ++--
 4 files changed, 13 insertions(+), 84 deletions(-)

diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 451cbcfb2c..10ccd770e3 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -131,16 +131,6 @@ int ff_mxf_decode_pixel_layout(const char 
pixel_layout[16], enum AVPixelFormat *
 return -1;
 }
 
-static const MXFSamplesPerFrame mxf_spf[] = {
-{ { 1001, 24000 }, { 2002, 0,0,0,0,0 } }, // FILM 23.976
-{ { 1, 24},{ 2000, 0,0,0,0,0 } }, // FILM 24
-{ { 1001, 3 }, { 1602, 1601, 1602, 1601, 1602, 0 } }, // NTSC 29.97
-{ { 1001, 6 }, { 801,  801,  800,  801,  801,  0 } }, // NTSC 59.94
-{ { 1, 25 },   { 1920, 0,0,0,0,0 } }, // PAL 25
-{ { 1, 50 },   { 960,  0,0,0,0,0 } }, // PAL 50
-{ { 1, 60 },   { 800,  0,0,0,0,0 } },
-};
-
 static const AVRational mxf_time_base[] = {
 { 1001, 24000 },
 { 1, 24},
@@ -152,40 +142,14 @@ static const AVRational mxf_time_base[] = {
 { 0, 0}
 };
 
-const MXFSamplesPerFrame *ff_mxf_get_samples_per_frame(AVFormatContext *s,
-   AVRational time_base)
-{
-int idx = av_find_nearest_q_idx(time_base, mxf_time_base);
-AVRational diff = av_sub_q(time_base, mxf_time_base[idx]);
-
-diff.num = FFABS(diff.num);
-
-if (av_cmp_q(diff, (AVRational){1, 1000}) >= 0)
-return NULL;
-
-if (av_cmp_q(time_base, mxf_time_base[idx]))
-av_log(s, AV_LOG_WARNING,
-   "%d/%d input time base matched %d/%d container time base\n",
-   time_base.num, time_base.den,
-   mxf_spf[idx].time_base.num,
-   mxf_spf[idx].time_base.den);
-
-return _spf[idx];
-}
-
 static const int mxf_content_package_rates[] = {
 3, 2, 7, 13, 4, 10, 12,
 };
 
 int ff_mxf_get_content_package_rate(AVRational time_base)
 {
-int idx = av_find_nearest_q_idx(time_base, mxf_time_base);
-AVRational diff = av_sub_q(time_base, mxf_time_base[idx]);
-
-diff.num = FFABS(diff.num);
-
-if (av_cmp_q(diff, (AVRational){1, 1000}) >= 0)
-return -1;
-
-return mxf_content_package_rates[idx];
+for (int i = 0; mxf_time_base[i].num; i++)
+if (!av_cmp_q(time_base, mxf_time_base[i]))
+return mxf_content_package_rates[i];
+return 0;
 }
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index f32124f772..2669269830 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -82,18 +82,12 @@ typedef struct MXFCodecUL {
 MXFWrappingIndicatorType wrapping_indicator_type;
 } MXFCodecUL;
 
-typedef struct {
-struct AVRational time_base;
-int samples_per_frame[6];
-} MXFSamplesPerFrame;
-
 extern const MXFCodecUL ff_mxf_data_definition_uls[];
 extern const MXFCodecUL ff_mxf_codec_uls[];
 extern const MXFCodecUL ff_mxf_pixel_format_uls[];
 extern const MXFCodecUL ff_mxf_codec_tag_uls[];
 
 int ff_mxf_decode_pixel_layout(const char pixel_layout[16], enum AVPixelFormat 
*pix_fmt);
-const MXFSamplesPerFrame *ff_mxf_get_samples_per_frame(AVFormatContext *s, 
AVRational time_base);
 int ff_mxf_get_content_package_rate(AVRational time_base);
 
 
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 9a48e2d2d1..9113e2a09c 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -3307,20 +3307,17 @@ static int mxf_get_next_track_edit_unit(MXFContext 
*mxf, MXFTrack *track, int64_
 static int64_t mxf_compute_sample_count(MXFContext *mxf, AVStream *st,
 int64_t edit_unit)
 {
-int i, total = 0, size = 0;
 MXFTrack *track = st->priv_data;
 AVRational time_base = av_inv_q(track->edit_rate);
 AVRational sample_rate = av_inv_q(st->time_base);
-const MXFSamplesPerFrame *spf = NULL;
-int64_t sample_count;
 
 // For non-audio sample_count equals current edit unit
 if (st->codecpar->codec_type != AVMEDIA_TYPE_AUDIO)
 return edit_unit;
 
-if ((sample_rate.num / sample_rate.den) == 48000)
-spf = ff_mxf_get_samples_per_frame(mxf->fc, time_base);
-if (!spf) {
+if ((sample_rate.num / sample_rate.den) == 48000) {
+return av_rescale_q(edit_unit, sample_rate, track->edit_rate);
+} else {
 int remainder = (sample_rate.num * time_base.num) %
 (time_base.den * sample_rate.den);
 if (remainder)
@@ -3331,20 +3328,6 @@ static int64_t mxf_compute_sample_count(MXFContext *mxf, 
AVStream *st,
sample_rate.num, sample_rate.den);
 return av_rescale_q(edit_unit, sample_rate, track->edit_rate);
 }
-
-while (spf->samples_per_frame[size]) {
-total += spf->samples_per_frame[size];
-size++;
-}

[FFmpeg-devel] [PATCH 1/4] avformat/audiointerleave: disallow using a samples_per_frame array

2020-02-27 Thread Marton Balint 
Only MXF used an actual sample array, and that is unneeded there because simple
rounding rules can be used instead.

Signed-off-by: Marton Balint 
---
 libavformat/audiointerleave.c | 24 ++--
 libavformat/audiointerleave.h |  7 ---
 libavformat/gxfenc.c  |  2 +-
 libavformat/mxfenc.c  |  7 ++-
 4 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/libavformat/audiointerleave.c b/libavformat/audiointerleave.c
index 6797546a44..f9887c1f4a 100644
--- a/libavformat/audiointerleave.c
+++ b/libavformat/audiointerleave.c
@@ -39,14 +39,11 @@ void ff_audio_interleave_close(AVFormatContext *s)
 }
 
 int ff_audio_interleave_init(AVFormatContext *s,
- const int *samples_per_frame,
+ const int samples_per_frame,
  AVRational time_base)
 {
 int i;
 
-if (!samples_per_frame)
-return AVERROR(EINVAL);
-
 if (!time_base.num) {
 av_log(s, AV_LOG_ERROR, "timebase not set for audio interleave\n");
 return AVERROR(EINVAL);
@@ -56,18 +53,18 @@ int ff_audio_interleave_init(AVFormatContext *s,
 AudioInterleaveContext *aic = st->priv_data;
 
 if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
+int max_samples = samples_per_frame ? samples_per_frame : 
av_rescale_rnd(st->codecpar->sample_rate, time_base.num, time_base.den, 
AV_ROUND_UP);
 aic->sample_size = (st->codecpar->channels *
 
av_get_bits_per_sample(st->codecpar->codec_id)) / 8;
 if (!aic->sample_size) {
 av_log(s, AV_LOG_ERROR, "could not compute sample size\n");
 return AVERROR(EINVAL);
 }
-aic->samples_per_frame = samples_per_frame;
-aic->samples = aic->samples_per_frame;
 aic->time_base = time_base;
+aic->samples_per_frame = samples_per_frame;
 
-aic->fifo_size = 100* *aic->samples;
-if (!(aic->fifo= av_fifo_alloc_array(100, *aic->samples)))
+aic->fifo_size = 100 * max_samples;
+if (!(aic->fifo = av_fifo_alloc_array(100, max_samples)))
 return AVERROR(ENOMEM);
 }
 }
@@ -81,7 +78,8 @@ static int interleave_new_audio_packet(AVFormatContext *s, 
AVPacket *pkt,
 AVStream *st = s->streams[stream_index];
 AudioInterleaveContext *aic = st->priv_data;
 int ret;
-int frame_size = *aic->samples * aic->sample_size;
+int nb_samples = aic->samples_per_frame ? aic->samples_per_frame : 
(av_rescale_q(aic->n + 1, av_make_q(st->codecpar->sample_rate, 1), 
av_inv_q(aic->time_base)) - aic->nb_samples);
+int frame_size = nb_samples * aic->sample_size;
 int size = FFMIN(av_fifo_size(aic->fifo), frame_size);
 if (!size || (!flush && size == av_fifo_size(aic->fifo)))
 return 0;
@@ -95,13 +93,11 @@ static int interleave_new_audio_packet(AVFormatContext *s, 
AVPacket *pkt,
 memset(pkt->data + size, 0, pkt->size - size);
 
 pkt->dts = pkt->pts = aic->dts;
-pkt->duration = av_rescale_q(*aic->samples, st->time_base, aic->time_base);
+pkt->duration = av_rescale_q(nb_samples, st->time_base, aic->time_base);
 pkt->stream_index = stream_index;
 aic->dts += pkt->duration;
-
-aic->samples++;
-if (!*aic->samples)
-aic->samples = aic->samples_per_frame;
+aic->nb_samples += nb_samples;
+aic->n++;
 
 return pkt->size;
 }
diff --git a/libavformat/audiointerleave.h b/libavformat/audiointerleave.h
index f28d5fefcc..0933310f4c 100644
--- a/libavformat/audiointerleave.h
+++ b/libavformat/audiointerleave.h
@@ -29,14 +29,15 @@
 typedef struct AudioInterleaveContext {
 AVFifoBuffer *fifo;
 unsigned fifo_size;   ///< size of currently allocated FIFO
+int64_t n;///< number of generated packets
+int64_t nb_samples;   ///< number of generated samples
 uint64_t dts; ///< current dts
 int sample_size;  ///< size of one sample all channels included
-const int *samples_per_frame; ///< must be 0-terminated
-const int *samples;   ///< current samples per frame, pointer to 
samples_per_frame
+int samples_per_frame;///< samples per frame if fixed, 0 otherwise
 AVRational time_base; ///< time base of output audio packets
 } AudioInterleaveContext;
 
-int ff_audio_interleave_init(AVFormatContext *s, const int *samples_per_frame, 
AVRational time_base);
+int ff_audio_interleave_init(AVFormatContext *s, const int samples_per_frame, 
AVRational time_base);
 void ff_audio_interleave_close(AVFormatContext *s);
 
 /**
diff --git a/libavformat/gxfenc.c b/libavformat/gxfenc.c
index 9eebefc683..e7536a6a7e 100644
--- a/libavformat/gxfenc.c
+++ b/libavformat/gxfenc.c
@@ -663,7 +663,7 @@ static int gxf_write_umf_packet(AVFormatContext *s)
 return updatePacketSize(pb, pos);
 }
 
-static const int

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Jean-Baptiste Kempf 
On Thu, Feb 27, 2020, at 19:44, Nicolas George wrote:
> On the other side, would you be able to quote only one actual, practical
> benefit of having several libraries instead of one that could not be
> achieved more simply with configure options? I suspect not, because I
> have looked for them and not found.

Separating I/O from demuxers would bring a lot of interesting things for 
security and for custom protocols.

But I agree on subtitles decoders, which is the topic here.

--
Jean-Baptiste Kempf - President
+33 672 704 734


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: Improve the position determination for avpriv_mpegts_parse_packet()

2020-02-27 Thread Michael Niedermayer 
On Mon, Jan 27, 2020 at 07:21:16PM +0100, Michael Niedermayer wrote:
> Fixes: assertion failure
> Fixes: Ticket 8005
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mpegts.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/avienc: Check bits per sample for PAL8

2020-02-27 Thread Michael Niedermayer 
On Sun, Jan 26, 2020 at 11:06:53PM +0100, Michael Niedermayer wrote:
> Fixes: assertion failure
> Fixes: Ticket 8172
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/avienc.c | 8 
>  1 file changed, 8 insertions(+)

will apply


[...]
-- 
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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpegaudioenc_template: fix invalid shift of sample

2020-02-27 Thread Michael Niedermayer 
On Thu, Jan 23, 2020 at 01:03:11PM +0100, Michael Niedermayer wrote:
> Fixes: Ticket8010
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mpegaudioenc_template.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply patchset

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [WIP][PATCH 0/4] Encoding API code restructuration

2020-02-27 Thread James Almer 
On 2/27/2020 3:45 PM, Carl Eugen Hoyos wrote:
> Am Do., 27. Feb. 2020 um 19:32 Uhr schrieb James Almer :
>>
>> On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote:
>>> Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer :

 This set follows the same logic as 061a0c14bb, but for the encode API: The
 new public API will no longer be a wrapper around the old deprecated one, 
 and
 the internal API used by the encoders now consists of a single 
 receive_packet()
 callback that pulls frames as required.

 Because of the above, PATCH 2/4 can't be applied until all the relevant 
 encoders
 have been adapted, and said changes squashed into it. This means librav1e, 
 nvenc,
 amfenc, v4l2_m2m, and vaapi_enc.
 I have ported librav1e both to test this set and for it to work as an 
 example
 for the maintainers of the other three encoders in order to get an idea of 
 what
 they should do.
>>>
>>> How does performance change with these patches?
>>
>> I didn't notice any performance hit.
> 
> I had hoped for a performance gain...
> 
> Sorry for asking: Did you test? They are rumours we once upon a time
> changed something in libavcodec which had a huge speed impact that
> was simply ignored here...

I did with librav1e which uses the new API callback internally, but i
just tried quickly again using mpeg2video which uses the old API
callback internally just to confirm:
./ffmpeg -framerate 24 -i ~/ToS/00%3d.png -pix_fmt yuv420p -benchmark
-c:v mpeg2video -f null -t 10 -

Before
frame=  240 fps= 88 q=31.0 Lsize=N/A time=00:00:09.95 bitrate=N/A
speed=3.65x
video:1822kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=9.922s stime=0.312s rtime=2.745s
bench: maxrss=97532kB

After
frame=  240 fps= 88 q=31.0 Lsize=N/A time=00:00:09.95 bitrate=N/A
speed=3.64x
video:1822kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=9.656s stime=0.453s rtime=2.761s
bench: maxrss=93892kB

> 
>>> Am I correct that this changes the "new" api which so many
>>> users complained about?
>>
>> I'm not sure what users complained about, but this doesn't change the
>> public API as far as library users are concerned. It changes how it
>> works internally, removing the dependency it had on the old deprecated API.
> 
> Thank you for the explanation!
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [WIP][PATCH 0/4] Encoding API code restructuration

2020-02-27 Thread Carl Eugen Hoyos 
Am Do., 27. Feb. 2020 um 19:32 Uhr schrieb James Almer :
>
> On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote:
> > Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer :
> >>
> >> This set follows the same logic as 061a0c14bb, but for the encode API: The
> >> new public API will no longer be a wrapper around the old deprecated one, 
> >> and
> >> the internal API used by the encoders now consists of a single 
> >> receive_packet()
> >> callback that pulls frames as required.
> >>
> >> Because of the above, PATCH 2/4 can't be applied until all the relevant 
> >> encoders
> >> have been adapted, and said changes squashed into it. This means librav1e, 
> >> nvenc,
> >> amfenc, v4l2_m2m, and vaapi_enc.
> >> I have ported librav1e both to test this set and for it to work as an 
> >> example
> >> for the maintainers of the other three encoders in order to get an idea of 
> >> what
> >> they should do.
> >
> > How does performance change with these patches?
>
> I didn't notice any performance hit.

I had hoped for a performance gain...

Sorry for asking: Did you test? They are rumours we once upon a time
changed something in libavcodec which had a huge speed impact that
was simply ignored here...

> > Am I correct that this changes the "new" api which so many
> > users complained about?
>
> I'm not sure what users complained about, but this doesn't change the
> public API as far as library users are concerned. It changes how it
> works internally, removing the dependency it had on the old deprecated API.

Thank you for the explanation!

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Nicolas George 
Vittorio Giovara (12020-02-27):
> joking aside, i see nothing wrong in having a bit more granular libraries,
> subtitle handling could be a good example usecase.

Seriously?

$ git grep avpriv | wc -l
1648

This is how much "nothing wrong" we already have because the libraries
are split. And having to maintain ABI stability for private APIs is only
one cause of problems among others.

On the other side, would you be able to quote only one actual, practical
benefit of having several libraries instead of one that could not be
achieved more simply with configure options? I suspect not, because I
have looked for them and not found.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Clément Bœsch 
On Thu, Feb 27, 2020 at 07:36:24PM +0100, Clément Bœsch wrote:
[...]
> And then you can't have them in libavfilter, so you can't have a sane
> harmony with medias including subtitle streams. It's problematic with many
> basic use cases. One random example: if you're transcoding an audio/video
> and somehow altering the timings within lavfi, you have to give the

give up*

> subtitles.
> 

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Clément Bœsch 
On Thu, Feb 27, 2020 at 12:35:03PM +0100, Anton Khirnov wrote:
[...]
> AFAIU one of the still-open questions for the subtitle redesign is what
> does it mean to decode or encode a subtitle.

There are multiple markups available for text subtitles, and there are
multiple ways of representing graphic rectangles for bitmap subtitles.

So for text subtitles, decoding and encoding respectively means
transforming them in a common markup to represent them all (currently ASS
is our "raw" representation) and back into their markup specifications. We
have a bunch of those already (subrip, microdvd, subviewer, ...).

For bitmap subtitles, decoding and encoding respectively means
transforming the bitstream into rectangle structures with RAW images
inside and back into the codec-specific bitstream.

> And one of the options is putting the AVPacket->"decoded subtitle"
> (whatever that is) and "decoded subtitle"->AVPacket conversions into a
> separate library.

And then you can't have them in libavfilter, so you can't have a sane
harmony with medias including subtitle streams. It's problematic with many
basic use cases. One random example: if you're transcoding an audio/video
and somehow altering the timings within lavfi, you have to give the
subtitles.

Having subtitles within libavfilter is not a fancy utopia to give
ourselves a reason to write a bunch of random filters, it actually helps
addressing real limitations in the current model.

What you are suggesting is basically what we already have: the few
subtitles specific API already present in lavc is what you would want out
of it, but it won't solve the core issues.

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [WIP][PATCH 0/4] Encoding API code restructuration

2020-02-27 Thread James Almer 
On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote:
> Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer :
>>
>> This set follows the same logic as 061a0c14bb, but for the encode API: The
>> new public API will no longer be a wrapper around the old deprecated one, and
>> the internal API used by the encoders now consists of a single 
>> receive_packet()
>> callback that pulls frames as required.
>>
>> Because of the above, PATCH 2/4 can't be applied until all the relevant 
>> encoders
>> have been adapted, and said changes squashed into it. This means librav1e, 
>> nvenc,
>> amfenc, v4l2_m2m, and vaapi_enc.
>> I have ported librav1e both to test this set and for it to work as an example
>> for the maintainers of the other three encoders in order to get an idea of 
>> what
>> they should do.
> 
> How does performance change with these patches?

I didn't notice any performance hit.

> 
> Am I correct that this changes the "new" api which so many
> users complained about?

I'm not sure what users complained about, but this doesn't change the
public API as far as library users are concerned. It changes how it
works internally, removing the dependency it had on the old deprecated API.

> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [WIP][PATCH 0/4] Encoding API code restructuration

2020-02-27 Thread Carl Eugen Hoyos 
Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer :
>
> This set follows the same logic as 061a0c14bb, but for the encode API: The
> new public API will no longer be a wrapper around the old deprecated one, and
> the internal API used by the encoders now consists of a single 
> receive_packet()
> callback that pulls frames as required.
>
> Because of the above, PATCH 2/4 can't be applied until all the relevant 
> encoders
> have been adapted, and said changes squashed into it. This means librav1e, 
> nvenc,
> amfenc, v4l2_m2m, and vaapi_enc.
> I have ported librav1e both to test this set and for it to work as an example
> for the maintainers of the other three encoders in order to get an idea of 
> what
> they should do.

How does performance change with these patches?

Am I correct that this changes the "new" api which so many
users complained about?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] [PATCH] avcodec: Fix h264_videotoolbox writing b-frames (fix ticket #8353)

2020-02-27 Thread Nomis101 
Signed-off-by: Nomis101 
---
 libavcodec/videotoolboxenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index cc08cf6a50..32d893e485 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -1355,6 +1355,7 @@ static int vtenc_configure_encoder(AVCodecContext *avctx)
 vtctx->get_param_set_func = 
compat_keys.CMVideoFormatDescriptionGetHEVCParameterSetAtIndex;
 if (!vtctx->get_param_set_func) return AVERROR(EINVAL);
 if (!get_vt_hevc_profile_level(avctx, _level)) return 
AVERROR(EINVAL);
+vtctx->has_b_frames = avctx->max_b_frames > 0;
 }

 enc_info = CFDictionaryCreateMutable(
--
2.21.1 (Apple Git-122.3)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [WIP][PATCH 0/4] Encoding API code restructuration

2020-02-27 Thread James Almer 
This set follows the same logic as 061a0c14bb, but for the encode API: The
new public API will no longer be a wrapper around the old deprecated one, and
the internal API used by the encoders now consists of a single receive_packet()
callback that pulls frames as required.

Because of the above, PATCH 2/4 can't be applied until all the relevant encoders
have been adapted, and said changes squashed into it. This means librav1e, 
nvenc,
amfenc, v4l2_m2m, and vaapi_enc.
I have ported librav1e both to test this set and for it to work as an example
for the maintainers of the other three encoders in order to get an idea of what
they should do.

James Almer (4):
  avcodec: move avcodec_flush_buffers from decode.c to utils.c
  avcodec/encode: restructure the core encoding code
  avcodec/encode: restructure the old encode API
  avcodec/librav1e: adapt to the new internal encode API

 libavcodec/avcodec.h  |  12 +-
 libavcodec/decode.c   |  36 ---
 libavcodec/encode.c   | 497 +-
 libavcodec/encode.h   |  39 
 libavcodec/internal.h |   8 +-
 libavcodec/librav1e.c |  65 +++---
 libavcodec/utils.c|  52 -
 7 files changed, 384 insertions(+), 325 deletions(-)
 create mode 100644 libavcodec/encode.h

-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/4] avcodec/encode: restructure the old encode API

2020-02-27 Thread James Almer 
Following the same logic as 061a0c14bb, this commit turns the old encode API
into a wrapper for the new one.

Signed-off-by: James Almer 
---
This could be squashed with the previous commit, like it was done in 061a0c14bb,
but i figured it would be easier to review this way.

 libavcodec/encode.c   | 353 --
 libavcodec/internal.h |   1 +
 libavcodec/utils.c|   9 ++
 3 files changed, 110 insertions(+), 253 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index a887a0ab55..420eeba45f 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -32,43 +32,28 @@
 
 int ff_alloc_packet2(AVCodecContext *avctx, AVPacket *avpkt, int64_t size, 
int64_t min_size)
 {
-if (avpkt->size < 0) {
-av_log(avctx, AV_LOG_ERROR, "Invalid negative user packet size %d\n", 
avpkt->size);
-return AVERROR(EINVAL);
-}
 if (size < 0 || size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
 av_log(avctx, AV_LOG_ERROR, "Invalid minimum required packet size 
%"PRId64" (max allowed is %d)\n",
size, INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE);
 return AVERROR(EINVAL);
 }
 
+av_assert0(!avpkt->data);
+
 if (avctx && 2*min_size < size) { // FIXME The factor needs to be finetuned
-av_assert0(!avpkt->data || avpkt->data != 
avctx->internal->byte_buffer);
-if (!avpkt->data || avpkt->size < size) {
-av_fast_padded_malloc(>internal->byte_buffer, 
>internal->byte_buffer_size, size);
-avpkt->data = avctx->internal->byte_buffer;
-avpkt->size = avctx->internal->byte_buffer_size;
-}
+av_fast_padded_malloc(>internal->byte_buffer, 
>internal->byte_buffer_size, size);
+avpkt->data = avctx->internal->byte_buffer;
+avpkt->size = size;
 }
 
-if (avpkt->data) {
-AVBufferRef *buf = avpkt->buf;
-
-if (avpkt->size < size) {
-av_log(avctx, AV_LOG_ERROR, "User packet is too small (%d < 
%"PRId64")\n", avpkt->size, size);
-return AVERROR(EINVAL);
-}
-
-av_init_packet(avpkt);
-avpkt->buf  = buf;
-avpkt->size = size;
-return 0;
-} else {
+if (!avpkt->data) {
 int ret = av_new_packet(avpkt, size);
 if (ret < 0)
 av_log(avctx, AV_LOG_ERROR, "Failed to allocate packet of size 
%"PRId64"\n", size);
 return ret;
 }
+
+return 0;
 }
 
 int ff_alloc_packet(AVPacket *avpkt, int size)
@@ -116,236 +101,6 @@ fail:
 return ret;
 }
 
-int attribute_align_arg avcodec_encode_audio2(AVCodecContext *avctx,
-  AVPacket *avpkt,
-  const AVFrame *frame,
-  int *got_packet_ptr)
-{
-AVFrame *extended_frame = NULL;
-AVFrame *padded_frame = NULL;
-int ret;
-AVPacket user_pkt = *avpkt;
-int needs_realloc = !user_pkt.data;
-
-*got_packet_ptr = 0;
-
-if (!avctx->codec->encode2) {
-av_log(avctx, AV_LOG_ERROR, "This encoder requires using the 
avcodec_send_frame() API.\n");
-return AVERROR(ENOSYS);
-}
-
-if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY) && !frame) {
-av_packet_unref(avpkt);
-return 0;
-}
-
-/* ensure that extended_data is properly set */
-if (frame && !frame->extended_data) {
-if (av_sample_fmt_is_planar(avctx->sample_fmt) &&
-avctx->channels > AV_NUM_DATA_POINTERS) {
-av_log(avctx, AV_LOG_ERROR, "Encoding to a planar sample format, "
-"with more than %d channels, but 
extended_data is not set.\n",
-   AV_NUM_DATA_POINTERS);
-return AVERROR(EINVAL);
-}
-av_log(avctx, AV_LOG_WARNING, "extended_data is not set.\n");
-
-extended_frame = av_frame_alloc();
-if (!extended_frame)
-return AVERROR(ENOMEM);
-
-memcpy(extended_frame, frame, sizeof(AVFrame));
-extended_frame->extended_data = extended_frame->data;
-frame = extended_frame;
-}
-
-/* extract audio service type metadata */
-if (frame) {
-AVFrameSideData *sd = av_frame_get_side_data(frame, 
AV_FRAME_DATA_AUDIO_SERVICE_TYPE);
-if (sd && sd->size >= sizeof(enum AVAudioServiceType))
-avctx->audio_service_type = *(enum AVAudioServiceType*)sd->data;
-}
-
-/* check for valid frame size */
-if (frame) {
-if (avctx->codec->capabilities & AV_CODEC_CAP_SMALL_LAST_FRAME) {
-if (frame->nb_samples > avctx->frame_size) {
-av_log(avctx, AV_LOG_ERROR, "more samples than frame size 
(avcodec_encode_audio2)\n");
-ret = AVERROR(EINVAL);
-goto end;
-}
-} else if (!(avctx->codec->capabilities & 
AV_CODEC_CAP_VARIABLE_FRAME_SIZE)) {
-/* if we already got an

[FFmpeg-devel] [PATCH 4/4] avcodec/librav1e: adapt to the new internal encode API

2020-02-27 Thread James Almer 
Signed-off-by: James Almer 
---
Must be squashed into PATCH 2/2

 libavcodec/librav1e.c | 65 ---
 1 file changed, 36 insertions(+), 29 deletions(-)

diff --git a/libavcodec/librav1e.c b/libavcodec/librav1e.c
index b8b1b4f8f1..02e9c0902f 100644
--- a/libavcodec/librav1e.c
+++ b/libavcodec/librav1e.c
@@ -30,12 +30,14 @@
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "avcodec.h"
+#include "encode.h"
 #include "internal.h"
 
 typedef struct librav1eContext {
 const AVClass *class;
 
 RaContext *ctx;
+AVFrame *frame;
 AVBSFContext *bsf;
 
 uint8_t *pass_data;
@@ -166,6 +168,7 @@ static av_cold int librav1e_encode_close(AVCodecContext 
*avctx)
 ctx->ctx = NULL;
 }
 
+av_frame_free(>frame);
 av_bsf_free(>bsf);
 av_freep(>pass_data);
 
@@ -180,6 +183,10 @@ static av_cold int librav1e_encode_init(AVCodecContext 
*avctx)
 int rret;
 int ret = 0;
 
+ctx->frame = av_frame_alloc();
+if (!ctx->frame)
+return AVERROR(ENOMEM);
+
 cfg = rav1e_config_default();
 if (!cfg) {
 av_log(avctx, AV_LOG_ERROR, "Could not allocate rav1e config.\n");
@@ -399,27 +406,36 @@ end:
 return ret;
 }
 
-static int librav1e_send_frame(AVCodecContext *avctx, const AVFrame *frame)
+static int librav1e_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
 {
 librav1eContext *ctx = avctx->priv_data;
+AVFrame *frame = ctx->frame;
 RaFrame *rframe = NULL;
+RaPacket *rpkt = NULL;
 int ret;
 
-if (frame) {
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+if (!frame->buf[0]) {
+const AVPixFmtDescriptor *desc;
 
-rframe = rav1e_frame_new(ctx->ctx);
-if (!rframe) {
-av_log(avctx, AV_LOG_ERROR, "Could not allocate new rav1e 
frame.\n");
-return AVERROR(ENOMEM);
-}
+ret = ff_encode_get_frame(avctx, frame);
+if (ret < 0 && ret != AVERROR_EOF)
+return ret;
 
-for (int i = 0; i < desc->nb_components; i++) {
-int shift = i ? desc->log2_chroma_h : 0;
-int bytes = desc->comp[0].depth == 8 ? 1 : 2;
-rav1e_frame_fill_plane(rframe, i, frame->data[i],
-   (frame->height >> shift) * 
frame->linesize[i],
-   frame->linesize[i], bytes);
+if (frame->buf[0]) {
+rframe = rav1e_frame_new(ctx->ctx);
+if (!rframe) {
+av_log(avctx, AV_LOG_ERROR, "Could not allocate new rav1e 
frame.\n");
+return AVERROR(ENOMEM);
+}
+
+desc = av_pix_fmt_desc_get(frame->format);
+for (int i = 0; i < desc->nb_components; i++) {
+int shift = i ? desc->log2_chroma_h : 0;
+int bytes = desc->comp[0].depth == 8 ? 1 : 2;
+rav1e_frame_fill_plane(rframe, i, frame->data[i],
+   (frame->height >> shift) * 
frame->linesize[i],
+   frame->linesize[i], bytes);
+}
 }
 }
 
@@ -427,28 +443,22 @@ static int librav1e_send_frame(AVCodecContext *avctx, 
const AVFrame *frame)
 if (rframe)
  rav1e_frame_unref(rframe); /* No need to unref if flushing. */
 
-switch (ret) {
+switch(ret) {
 case RA_ENCODER_STATUS_SUCCESS:
+av_frame_unref(frame);
 break;
 case RA_ENCODER_STATUS_ENOUGH_DATA:
-return AVERROR(EAGAIN);
+break;
 case RA_ENCODER_STATUS_FAILURE:
 av_log(avctx, AV_LOG_ERROR, "Could not send frame: %s\n", 
rav1e_status_to_str(ret));
+av_frame_unref(frame);
 return AVERROR_EXTERNAL;
 default:
 av_log(avctx, AV_LOG_ERROR, "Unknown return code %d from 
rav1e_send_frame: %s\n", ret, rav1e_status_to_str(ret));
+av_frame_unref(frame);
 return AVERROR_UNKNOWN;
 }
 
-return 0;
-}
-
-static int librav1e_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
-{
-librav1eContext *ctx = avctx->priv_data;
-RaPacket *rpkt = NULL;
-int ret;
-
 retry:
 
 if (avctx->flags & AV_CODEC_FLAG_PASS1) {
@@ -473,9 +483,7 @@ retry:
 }
 return AVERROR_EOF;
 case RA_ENCODER_STATUS_ENCODED:
-if (avctx->internal->draining)
-goto retry;
-return AVERROR(EAGAIN);
+goto retry;
 case RA_ENCODER_STATUS_NEED_MORE_DATA:
 if (avctx->internal->draining) {
 av_log(avctx, AV_LOG_ERROR, "Unexpected error when receiving 
packet after EOF.\n");
@@ -575,7 +583,6 @@ AVCodec ff_librav1e_encoder = {
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_AV1,
 .init   = librav1e_encode_init,
-.send_frame = librav1e_send_frame,
 .receive_packet = librav1e_receive_packet,
 .close  = librav1e_encode_close,
 .priv_data_size = sizeof(librav1eContext),
--

[FFmpeg-devel] [PATCH 2/4] avcodec/encode: restructure the core encoding code

2020-02-27 Thread James Almer 
This commit follows the same logic as 061a0c14bb, but for the encode API: The
new public encoding API will no longer be a wrapper around the old deprecated
one, and the internal API used by the encoders now consists of a single
receive_packet() callback that pulls frames as required.

Signed-off-by: James Almer 
---
 libavcodec/avcodec.h  |  12 +-
 libavcodec/encode.c   | 268 --
 libavcodec/encode.h   |  39 ++
 libavcodec/internal.h |   7 +-
 libavcodec/utils.c|  12 +-
 5 files changed, 268 insertions(+), 70 deletions(-)
 create mode 100644 libavcodec/encode.h

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 894a9e5565..9d22390dd3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3641,14 +3641,10 @@ typedef struct AVCodec {
 int (*decode)(AVCodecContext *, void *outdata, int *outdata_size, AVPacket 
*avpkt);
 int (*close)(AVCodecContext *);
 /**
- * Encode API with decoupled packet/frame dataflow. The API is the
- * same as the avcodec_ prefixed APIs (avcodec_send_frame() etc.), except
- * that:
- * - never called if the codec is closed or the wrong type,
- * - if AV_CODEC_CAP_DELAY is not set, drain frames are never sent,
- * - only one drain frame is ever passed down,
- */
-int (*send_frame)(AVCodecContext *avctx, const AVFrame *frame);
+ * Encode API with decoupled frame/packet dataflow. This function is called
+ * to get one output packet. It should call ff_encode_get_packet() to 
obtain
+ * input data.
+ */
 int (*receive_packet)(AVCodecContext *avctx, AVPacket *avpkt);
 
 /**
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 9ed2cf0f59..a887a0ab55 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -26,6 +26,7 @@
 #include "libavutil/samplefmt.h"
 
 #include "avcodec.h"
+#include "encode.h"
 #include "frame_thread_encoder.h"
 #include "internal.h"
 
@@ -359,101 +360,250 @@ int avcodec_encode_subtitle(AVCodecContext *avctx, 
uint8_t *buf, int buf_size,
 return ret;
 }
 
-static int do_encode(AVCodecContext *avctx, const AVFrame *frame, int 
*got_packet)
+int ff_encode_get_frame(AVCodecContext *avctx, AVFrame *frame)
 {
+AVCodecInternal *avci = avctx->internal;
+
+if (avci->draining)
+return AVERROR_EOF;
+
+if (!avci->buffer_frame->buf[0])
+return AVERROR(EAGAIN);
+
+av_frame_move_ref(frame, avci->buffer_frame);
+
+return 0;
+}
+
+static int encode_simple_internal(AVCodecContext *avctx, AVPacket *avpkt)
+{
+AVCodecInternal   *avci = avctx->internal;
+EncodeSimpleContext *es = >es;
+AVFrame  *frame = es->in_frame;
+AVFrame   *padded_frame = NULL;
+int got_packet;
 int ret;
-*got_packet = 0;
 
-av_packet_unref(avctx->internal->buffer_pkt);
-avctx->internal->buffer_pkt_valid = 0;
+if (!frame->buf[0] && !avci->draining) {
+av_frame_unref(frame);
+ret = ff_encode_get_frame(avctx, frame);
+if (ret < 0 && ret != AVERROR_EOF)
+return ret;
+}
 
-if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
-ret = avcodec_encode_video2(avctx, avctx->internal->buffer_pkt,
-frame, got_packet);
-} else if (avctx->codec_type == AVMEDIA_TYPE_AUDIO) {
-ret = avcodec_encode_audio2(avctx, avctx->internal->buffer_pkt,
-frame, got_packet);
-} else {
-ret = AVERROR(EINVAL);
+if (avci->draining_done)
+return AVERROR_EOF;
+
+if (!frame->buf[0]) {
+if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY ||
+  avctx->active_thread_type & FF_THREAD_FRAME))
+return AVERROR_EOF;
+
+// Flushing is signaled with a NULL frame
+frame = NULL;
+}
+
+got_packet = 0;
+
+if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
+if ((avctx->flags & AV_CODEC_FLAG_PASS1) && avctx->stats_out)
+avctx->stats_out[0] = '\0';
+
+if (av_image_check_size2(avctx->width, avctx->height, 
avctx->max_pixels, AV_PIX_FMT_NONE, 0, avctx)) {
+ret = AVERROR(EINVAL);
+goto end;
+}
+if (frame) {
+if (frame->format == AV_PIX_FMT_NONE)
+av_log(avctx, AV_LOG_WARNING, "AVFrame.format is not set\n");
+if (frame->width == 0 || frame->height == 0)
+av_log(avctx, AV_LOG_WARNING, "AVFrame.width or height is not 
set\n");
+}
+} else if (frame && avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
+/* extract audio service type metadata */
+AVFrameSideData *sd = av_frame_get_side_data(frame, 
AV_FRAME_DATA_AUDIO_SERVICE_TYPE);
+if (sd && sd->size >= sizeof(enum AVAudioServiceType))
+avctx->audio_service_type = *(enum AVAudioServiceType*)sd->data;
+
+/* check for valid frame size */
+if (avctx->codec->capabilities & AV_CODEC_CAP_SMALL_LAST_FRAME) {
+

[FFmpeg-devel] [PATCH 1/4] avcodec: move avcodec_flush_buffers from decode.c to utils.c

2020-02-27 Thread James Almer 
It's not a decoding exclusive function.

Signed-off-by: James Almer 
---
 libavcodec/decode.c | 36 
 libavcodec/utils.c  | 33 +
 2 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 03b9da25f9..93b0db7ef8 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -2020,42 +2020,6 @@ int ff_reget_buffer(AVCodecContext *avctx, AVFrame 
*frame, int flags)
 return ret;
 }
 
-static void bsfs_flush(AVCodecContext *avctx)
-{
-DecodeFilterContext *s = >internal->filter;
-
-for (int i = 0; i < s->nb_bsfs; i++)
-av_bsf_flush(s->bsfs[i]);
-}
-
-void avcodec_flush_buffers(AVCodecContext *avctx)
-{
-AVCodecInternal *avci = avctx->internal;
-
-avci->draining  = 0;
-avci->draining_done = 0;
-avci->nb_draining_errors = 0;
-av_frame_unref(avci->buffer_frame);
-av_frame_unref(avci->compat_decode_frame);
-av_packet_unref(avci->buffer_pkt);
-avci->buffer_pkt_valid = 0;
-
-av_packet_unref(avci->ds.in_pkt);
-
-if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
-ff_thread_flush(avctx);
-else if (avctx->codec->flush)
-avctx->codec->flush(avctx);
-
-avctx->pts_correction_last_pts =
-avctx->pts_correction_last_dts = INT64_MIN;
-
-bsfs_flush(avctx);
-
-if (!avctx->refcounted_frames)
-av_frame_unref(avci->to_free);
-}
-
 void ff_decode_bsfs_uninit(AVCodecContext *avctx)
 {
 DecodeFilterContext *s = >internal->filter;
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index c4dc136d3c..5257a1c627 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1084,6 +1084,39 @@ FF_ENABLE_DEPRECATION_WARNINGS
 goto end;
 }
 
+void avcodec_flush_buffers(AVCodecContext *avctx)
+{
+AVCodecInternal *avci = avctx->internal;
+
+avci->draining  = 0;
+avci->draining_done = 0;
+avci->nb_draining_errors = 0;
+av_frame_unref(avci->buffer_frame);
+av_frame_unref(avci->compat_decode_frame);
+av_packet_unref(avci->buffer_pkt);
+avci->buffer_pkt_valid = 0;
+
+av_packet_unref(avci->ds.in_pkt);
+
+if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
+ff_thread_flush(avctx);
+else if (avctx->codec->flush)
+avctx->codec->flush(avctx);
+
+avctx->pts_correction_last_pts =
+avctx->pts_correction_last_dts = INT64_MIN;
+
+if (av_codec_is_decoder(avctx->codec)) {
+DecodeFilterContext *s = >internal->filter;
+
+for (int i = 0; i < s->nb_bsfs; i++)
+av_bsf_flush(s->bsfs[i]);
+}
+
+if (!avctx->refcounted_frames)
+av_frame_unref(avci->to_free);
+}
+
 void avsubtitle_free(AVSubtitle *sub)
 {
 int i;
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

2020-02-27 Thread Jean-Baptiste Kempf 
On Thu, Feb 27, 2020, at 18:33, Michael Niedermayer wrote:
> > > I agree that the current QP code (not feature) should be deprecated as it
> > > does not work with newer codec.
> > > But before removing the deprecated code, it will be nice to have the same
> > > feature available with a newer API, so the features of
> > > extracting/analyzing/overlaying QP still work.
> > 
> > Yes, it does indeed sound reasonable to push this new API and convert
> > the old code to it. The question remains if any of the people arguing
> > for keeping those filters are also willing to do the conversion.
> 
> I am willing to help, the time ATM is not great though because theres

Thanks.

I think the next major API bump is months away, so I'm not sure there is any 
urgency here :)

--
Jean-Baptiste Kempf - President
+33 672 704 734


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

2020-02-27 Thread Michael Niedermayer 
On Thu, Feb 27, 2020 at 12:30:22PM +0100, Anton Khirnov wrote:
> Quoting Thierry Foucu (2020-02-26 19:04:57)
> > First of all, thanks for trying to clean up deprecated API
> > 
> > On Wed, Feb 26, 2020 at 6:03 AM Jean-Baptiste Kempf  
> > wrote:
> > 
> > > Yo,
> > >
> > > On Wed, Feb 26, 2020, at 14:27, Thilo Borgmann wrote:
> > > > > The patch in your link is not using this API. Precisely because this
> > > API
> > > > > is inadequate for anything newer than MPEG4 ASP. If anything, it's an
> > > > > additional argument in favor of my patches.
> > > >
> > > > My actual point about that patch was that there is a use case to
> > > > extract QP tables for more current codecs. Suggests this use case is
> > > > also there for less current ones which says we should not just remove
> > > > this possibility.
> > >
> > > I think this is the right question:
> > > "Are there actual valid use cases to do it?"
> > >
> > 
> > yes, there is a use case for extracting QP per block:
> > To analyze and visualize QP to validate/analyze Rate Control when we enable
> > Adaptive QP and ROI for example.
> > Most people who works on Rate Control know that the choice of the right
> > MV/QP/block type is really important for quality.
> > In today world, you will have to license existing software to visualize the
> > QP, but if you want to do this over +10k video, and analyze QP based on
> > some stats we expect to have, you need some libraries to do it.
> > People could write some codec parser to extract the QP per block, but this
> > is almost re-implementing part of libavcodec.
> > Today, for example, when we want to visualize QP, we use libavcodec to
> > decode the frame, use another piece of code to extract the QP and overlay
> > both of them. This is almost (and i say ALMOST) decoding the frame twice.
> > (BTW, we can do that already with libavcodec for MV, so why not for QP)
> 
> Thank you, finally there is a clear use case.
> 

> > 
> > Last summer, an intern from google tried to come up with a metadata
> > structure to store information per block.
> > This would have allow to store per block, the MV, QP, block type, etc.. And
> > it could have work for any codec with any different block size.
> > He was trying to implement what was done for MV and replace the QP with
> > this new metadata.
> > 
> > I agree that the current QP code (not feature) should be deprecated as it
> > does not work with newer codec.
> > But before removing the deprecated code, it will be nice to have the same
> > feature available with a newer API, so the features of
> > extracting/analyzing/overlaying QP still work.
> 
> Yes, it does indeed sound reasonable to push this new API and convert
> the old code to it. The question remains if any of the people arguing
> for keeping those filters are also willing to do the conversion.

I am willing to help, the time ATM is not great though because theres
alot i want/need to do both related to FFmpeg and unrelated.
(for example iam behind with making a new release which should happen
 before the bump ...)

so i suspect by the time i get around to look into qp API updating
someone else probably will already have done it ...

Thanks

 [...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Vittorio Giovara 
On Thu, Feb 27, 2020 at 10:41 AM Hendrik Leppkes 
wrote:

> On Thu, Feb 27, 2020 at 12:35 PM Anton Khirnov  wrote:
> >
> > Quoting Hendrik Leppkes (2020-02-27 12:27:09)
> > > On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov 
> wrote:
> > > > Why does it need to be within AVFrame? I am still unconvinced that
> is a
> > > > good idea. What do we gain from storing them in the same struct?
> > > > It makes sense for audio and video, because they are similar in many
> > > > important aspects (and even then there are people saying that they
> > > > should be separate). Subtitles are even more different.
> > > >
> > >
> > > You gain a unified API, which we already have now, intead of a
> > > secondary API just for subtitles thats practically the same but
> > > accepts different structs.
> > > This makes everything a lot easier imho. You can decode whatever input
> > > data into an AVFrame, you can filter your AVFrame, still without
> > > needing special data paths, and only at the last step after all of
> > > that do you need to possibly care when it comes to output. If you're
> > > encoding again, you might not even have that.
> >
> > AFAIU one of the still-open questions for the subtitle redesign is what
> > does it mean to decode or encode a subtitle. And one of the options is
> > putting the AVPacket->"decoded subtitle" (whatever that is) and "decoded
> > subtitle"->AVPacket conversions into a separate library.
>
>
> FFmpeg really doesn't need *more* libraries.
>

libavio says hi

joking aside, i see nothing wrong in having a bit more granular libraries,
subtitle handling could be a good example usecase.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag

2020-02-27 Thread Fu, Linjie 
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Fu,
> Linjie
> Sent: Tuesday, February 18, 2020 23:06
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add
> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Anton Khirnov
> > Sent: Tuesday, February 18, 2020 21:32
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add
> > AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> >
> > Quoting Michael Niedermayer (2020-02-17 23:38:31)
> > > On Mon, Feb 17, 2020 at 06:28:23PM +, Fu, Linjie wrote:
> > >
> > > > > > > https://patchwork.ffmpeg.org/patch/14122/
> > >
> > > iam hesitating because it feeds encoders with changing resolution
> resulting
> > > in potentially undefined behavior ...
> > >
> 
> Any suggestions?
> 
> > > > > > > https://patchwork.ffmpeg.org/patch/14139/
> > >
> > > long discussion here its not immedeatly clear if anyone was against it
> 
> Please help to give some inputs if this would leads to some unexpected
> results from your point of view.
> 
> > > Also there is the question about the API, is there anything in the API
> > > documentation that restricts the user app from changing the encoder
> > > input frame dimensions?
> > > This should be documented somewhere if its not ...
> > >
> > > If a flag is added that affects this, it would have to
> > > be documented so someone writing a user app using the encoders
> > > would know if they are allowed to change the resolution.
> > > With just the flag and its documentation a developer could miss
> > > the flag entirely
> 
> Since I didn't find the descriptions in doxygen:
> https://ffmpeg.org/doxygen/trunk/group__lavc__encoding.html#ga4fde50
> e2cad4cf3d66d882a7078aeab4
> 
> The things should be done seem to be:
> 
> [1]. Documentation in API, to declare that encoders require input frame to
> be in constant dimensions, unless the encoders have the capability of
> dynamic resolution encoding [2].
> 
> [2]. Documentation in API, to declare this codec flag would affect the 
> restrict
> in [1].
> 
> If it's ok, I'll update the patch with the documentations added.
> 

Update the patch with API documentations added.
And add checks to make sure it won't result into undefined behavior.

As to the support for more encoders, flush/destroy/reinit the encoder would 
work,
will investigate more to do this inside specific encoder or in more general 
ways. 

Please help to review, thanks.

- Linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavc/v4l2_context: fix compile warning for incompatible pointer type

2020-02-27 Thread Linjie Fu 
Signed-off-by: Linjie Fu 
---
 libavcodec/v4l2_context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index 95a2bfa..8110bbb 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -48,7 +48,7 @@ static inline V4L2m2mContext *ctx_to_m2mctx(V4L2Context *ctx)
 container_of(ctx, V4L2m2mContext, capture);
 }
 
-static inline AVClass *logger(V4L2Context *ctx)
+static inline AVCodecContext *logger(V4L2Context *ctx)
 {
 return ctx_to_m2mctx(ctx)->avctx;
 }
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/3] fftools/ffmpeg: check caps of encoders for encoding frame with variable dimension

2020-02-27 Thread Linjie Fu 
This ensures that an encoder is able to cope with input frames with changing
resolution only if it declares the capability of 
AV_CODEC_CAP_VARIABLE_DIMENSIONS.

Signed-off-by: Linjie Fu 
---
 fftools/ffmpeg.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e5fbd47..5c4cf03 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1068,6 +1068,15 @@ static void do_video_out(OutputFile *of,
 InputStream *ist = NULL;
 AVFilterContext *filter = ost->filter->filter;
 
+if (next_picture && (enc->width != next_picture->width ||
+ enc->height != next_picture->height)) {
+if (!(enc->codec->capabilities & AV_CODEC_CAP_VARIABLE_DIMENSIONS)) {
+av_log(NULL, AV_LOG_ERROR, "Variable dimension encoding "
+"is not supported by %s.\n", enc->codec->name);
+goto error;
+}
+}
+
 if (ost->source_index >= 0)
 ist = input_streams[ost->source_index];
 
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/3] lavc/avcodec.h: add an AVCodecContext flag to indicate caps of encoding

2020-02-27 Thread Linjie Fu 
Signed-off-by: Linjie Fu 
---
 doc/APIchanges   | 3 +++
 fftools/cmdutils.c   | 2 ++
 libavcodec/avcodec.h | 9 -
 libavcodec/rawenc.c  | 1 +
 libavcodec/version.h | 2 +-
 5 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 5bfb0a6..ec4531f 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2020-xx-xx - xx - lavc 58.73.103 - avcodec.h
+  Add AV_CODEC_CAP_VARIABLE_DIMENSIONS.
+
 2020-02-21 - xx - lavc 58.73.101 - avcodec.h
   Add AV_CODEC_EXPORT_DATA_PRFT.
 
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index f0f2b4f..30bbbcc 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1431,6 +1431,8 @@ static void print_codec(const AVCodec *c)
 printf("hardware ");
 if (c->capabilities & AV_CODEC_CAP_HYBRID)
 printf("hybrid ");
+if (c->capabilities & AV_CODEC_CAP_VARIABLE_DIMENSIONS)
+printf("multidimension ");
 if (!c->capabilities)
 printf("none");
 printf("\n");
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5a0fc34..87ca79f 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -91,7 +91,9 @@
  *   - For decoding, call avcodec_send_packet() to give the decoder raw
  * compressed data in an AVPacket.
  *   - For encoding, call avcodec_send_frame() to give the encoder an AVFrame
- * containing uncompressed audio or video.
+ * containing uncompressed audio or video. Video encoder requires input
+ * frames to be in constant dimensions unless it declare the capability
+ * of AV_CODEC_CAP_VARIABLE_DIMENSIONS.
  *
  *   In both cases, it is recommended that AVPackets and AVFrames are
  *   refcounted, or libavcodec might have to copy the input data. (libavformat
@@ -1116,6 +1118,11 @@ typedef struct RcOverride{
  * Export encoder Producer Reference Time through packet side data
  */
 #define AV_CODEC_EXPORT_DATA_PRFT(1 << 1)
+/**
+ * Codec supports variable dimensions encoding. This indicates that input 
frames are
+ * allowed to be in variable dimensions/resolutions, otherwise they have to 
keep constant.
+ */
+#define AV_CODEC_CAP_VARIABLE_DIMENSIONS (1 << 21)
 
 /**
  * Pan Scan area.
diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
index d181b74..486c0d7 100644
--- a/libavcodec/rawenc.c
+++ b/libavcodec/rawenc.c
@@ -92,4 +92,5 @@ AVCodec ff_rawvideo_encoder = {
 .id = AV_CODEC_ID_RAWVIDEO,
 .init   = raw_encode_init,
 .encode2= raw_encode,
+.capabilities   = AV_CODEC_CAP_VARIABLE_DIMENSIONS,
 };
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 36536c3..03d7f32 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR  73
-#define LIBAVCODEC_VERSION_MICRO 102
+#define LIBAVCODEC_VERSION_MICRO 103
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] lavc/avcodec.h: fix missing line breaks in API documentation

2020-02-27 Thread Linjie Fu 
"In both cases.." and "Repeat this call until.." would be better to
be in a separate line.

http://ffmpeg.org/doxygen/trunk/group__lavc__encdec.html

Signed-off-by: Linjie Fu 
---
 libavcodec/avcodec.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 894a9e5..5a0fc34 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -92,6 +92,7 @@
  * compressed data in an AVPacket.
  *   - For encoding, call avcodec_send_frame() to give the encoder an AVFrame
  * containing uncompressed audio or video.
+ *
  *   In both cases, it is recommended that AVPackets and AVFrames are
  *   refcounted, or libavcodec might have to copy the input data. (libavformat
  *   always returns refcounted AVPackets, and av_frame_get_buffer() allocates
@@ -102,6 +103,7 @@
  * an AVFrame containing uncompressed audio or video data.
  *   - For encoding, call avcodec_receive_packet(). On success, it will return
  * an AVPacket with a compressed frame.
+ *
  *   Repeat this call until it returns AVERROR(EAGAIN) or an error. The
  *   AVERROR(EAGAIN) return value means that new input data is required to
  *   return new output. In this case, continue with sending input. For each
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Hendrik Leppkes 
On Thu, Feb 27, 2020 at 12:35 PM Anton Khirnov  wrote:
>
> Quoting Hendrik Leppkes (2020-02-27 12:27:09)
> > On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov  wrote:
> > > Why does it need to be within AVFrame? I am still unconvinced that is a
> > > good idea. What do we gain from storing them in the same struct?
> > > It makes sense for audio and video, because they are similar in many
> > > important aspects (and even then there are people saying that they
> > > should be separate). Subtitles are even more different.
> > >
> >
> > You gain a unified API, which we already have now, intead of a
> > secondary API just for subtitles thats practically the same but
> > accepts different structs.
> > This makes everything a lot easier imho. You can decode whatever input
> > data into an AVFrame, you can filter your AVFrame, still without
> > needing special data paths, and only at the last step after all of
> > that do you need to possibly care when it comes to output. If you're
> > encoding again, you might not even have that.
>
> AFAIU one of the still-open questions for the subtitle redesign is what
> does it mean to decode or encode a subtitle. And one of the options is
> putting the AVPacket->"decoded subtitle" (whatever that is) and "decoded
> subtitle"->AVPacket conversions into a separate library.


FFmpeg really doesn't need *more* libraries.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Check for Tiled and Stripped TIFFs

2020-02-27 Thread James Almer 
On 2/27/2020 11:10 AM, Carl Eugen Hoyos wrote:
> Am Do., 27. Feb. 2020 um 15:05 Uhr schrieb Anton Khirnov :
>>
>> Quoting Michael Niedermayer (2020-02-19 16:49:51)
>>> TIFF 6 spec: "Do not use both strip-oriented and tile-oriented fields in 
>>> the same TIFF file."
>>>
>>> Fixes: null pointer use, crash
>>> Fixes: crash-762680f9d1b27f9b9085e12887ad44893fb2b020
>>>
>>> Found-by: Shiziru 
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavcodec/tiff.c | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
>>> index e8357114de..fd50b1cbfa 100644
>>> --- a/libavcodec/tiff.c
>>> +++ b/libavcodec/tiff.c
>>> @@ -1873,6 +1873,12 @@ again:
>>>  return AVERROR_INVALIDDATA;
>>>  }
>>>
>>> +if (   (s->is_tiled || s->tile_byte_counts_offset || 
>>> s->tile_offsets_offset || s->tile_width || s->tile_length || s->tile_count)
>>> +&& (s->strippos || s->strips || s->stripoff || s->rps || s->sot || 
>>> s->sstype || s->stripsize || s->stripsizesoff)) {
>>
>> This is horribly unreadable. Putting those checks into macros, like
>> HAVE_TILES(s) and HAVE_STRIPS(s) would make it a lot better.
> 
> Were else in the file could the macros be used?
> I fear that adding macros that are only used in one place will make the
> code much more unreadable.

I don't agree. An "if (HAVE_TILES(s) && HAVE_STRIPS(s))" check is easy
to understand at first glance, regardless of the internals of each of
those macros. It achieves the same effect as adding a comment in the
code to explain what all those checks do.

See IS_IRAP_NAL(nal) and IS_IDR_NAL(nal) in hevc_parser for another
example of this simplification, which are also used in a single place.

> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Check for Tiled and Stripped TIFFs

2020-02-27 Thread Carl Eugen Hoyos 
Am Do., 27. Feb. 2020 um 15:05 Uhr schrieb Anton Khirnov :
>
> Quoting Michael Niedermayer (2020-02-19 16:49:51)
> > TIFF 6 spec: "Do not use both strip-oriented and tile-oriented fields in 
> > the same TIFF file."
> >
> > Fixes: null pointer use, crash
> > Fixes: crash-762680f9d1b27f9b9085e12887ad44893fb2b020
> >
> > Found-by: Shiziru 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/tiff.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> > index e8357114de..fd50b1cbfa 100644
> > --- a/libavcodec/tiff.c
> > +++ b/libavcodec/tiff.c
> > @@ -1873,6 +1873,12 @@ again:
> >  return AVERROR_INVALIDDATA;
> >  }
> >
> > +if (   (s->is_tiled || s->tile_byte_counts_offset || 
> > s->tile_offsets_offset || s->tile_width || s->tile_length || s->tile_count)
> > +&& (s->strippos || s->strips || s->stripoff || s->rps || s->sot || 
> > s->sstype || s->stripsize || s->stripsizesoff)) {
>
> This is horribly unreadable. Putting those checks into macros, like
> HAVE_TILES(s) and HAVE_STRIPS(s) would make it a lot better.

Were else in the file could the macros be used?
I fear that adding macros that are only used in one place will make the
code much more unreadable.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Check for Tiled and Stripped TIFFs

2020-02-27 Thread Anton Khirnov 
Quoting Michael Niedermayer (2020-02-19 16:49:51)
> TIFF 6 spec: "Do not use both strip-oriented and tile-oriented fields in the 
> same TIFF file."
> 
> Fixes: null pointer use, crash
> Fixes: crash-762680f9d1b27f9b9085e12887ad44893fb2b020
> 
> Found-by: Shiziru 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/tiff.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index e8357114de..fd50b1cbfa 100644
> --- a/libavcodec/tiff.c
> +++ b/libavcodec/tiff.c
> @@ -1873,6 +1873,12 @@ again:
>  return AVERROR_INVALIDDATA;
>  }
>  
> +if (   (s->is_tiled || s->tile_byte_counts_offset || 
> s->tile_offsets_offset || s->tile_width || s->tile_length || s->tile_count)
> +&& (s->strippos || s->strips || s->stripoff || s->rps || s->sot || 
> s->sstype || s->stripsize || s->stripsizesoff)) {

This is horribly unreadable. Putting those checks into macros, like
HAVE_TILES(s) and HAVE_STRIPS(s) would make it a lot better.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

2020-02-27 Thread Anamitra Ghorui 
February 27, 2020 6:15 PM, "Moritz Barsnick"  wrote:

>> OBJS-$(CONFIG_FLAC_PARSER) += flac_parser.o flacdata.o flac.o \
>> vorbis_data.o
>> +OBJS-$(CONFIG_FLAC_PARSER) += flif16_parser.o
> 
> 
> 
> This looks wrong. You are adding this object to a compile of the FLAC
> parser, not your new parser. (Probably a copy/paste mistake.)
> 

Thanks for pointing it out

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v8] avfilter/avf_aphasemeter: Add out of phase and mono detection

2020-02-27 Thread Romane Lafon 
Le mar. 24 déc. 2019 à 17:36, Romane Lafon  a écrit :

> I rewrote the patch I submitted a few months ago.
> This patch extends aphasemeter to detect out of phase or mono sequences in
> stereo streams.
>
> Regards,
> Romane
>


Ping for review.

Thanks,
Romane
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

2020-02-27 Thread Moritz Barsnick 
Welcome to ffmpeg!

Since review has now started, I want to point out what was missed:

On Wed, Feb 26, 2020 at 12:26:37 +0530, Anamitra Ghorui wrote:

> a. Please tell me if I am right or wrong here:
> 1. Each audio/video/image file format has a parser for converting the
>file data into a format that can be understood by a decoder.
>
> 2. A Decoder converts a given, recogised encoded data stream into a
>form that can be processed by physical hardware.
>
> 3. File formats can be independent of what sort of encoding it uses.
>Eg: WebM

Welcome to the world of multimedia. For many (but not all)
contributions, it is important to understand these concepts. Do play
around with ffmpeg and perhaps some examples from the ffmpeg wiki. And
feel free to ask. :-)

Also observe the contribution flow on this mailing list. Your mentor
will assist you though, because not everything may be obvious enough.

>  libavcodec/Makefile|  1 +
>  libavcodec/avcodec.h   |  1 +
>  libavcodec/flif16_parser.c | 51 ++
>  libavcodec/parsers.c   |  1 +
>  libavformat/img2.c |  1 +
>  5 files changed, 55 insertions(+)
>  create mode 100644 libavcodec/flif16_parser.c

Just to jump ahead: As soon as you start an actual decoder and demuxer,
you will ultimately (i.e. in a future version, before push) require:

- a Changelog entry (as soo
- documentation in doc/*.texi
- a minor version bump of libavcodec (or libavformat, with the commit
  in which each gains a new codec/format), resetting micro to 100

>  OBJS-$(CONFIG_FLAC_PARSER) += flac_parser.o flacdata.o flac.o \
>vorbis_data.o
> +OBJS-$(CONFIG_FLAC_PARSER) += flif16_parser.o
 

This looks wrong. You are adding this object to a compile of the FLAC
parser, not your new parser. (Probably a copy/paste mistake.)

Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mux: allow non-monotonic ts with AVFMT_NOTIMESTAMPS

2020-02-27 Thread Anton Khirnov 
Quoting Andreas Rheinhardt (2020-02-26 16:06:00)
> Anssi Hannula:
> > Allow non-monotonic input timestamps for muxers with no timestamps at
> > all (AVFMT_NOTIMESTAMPS).
> > 
> > This is frequently hit when muxing TrueHD with spdifenc as many MKV
> > files use 1ms timestamps while TrueHD frames are shorter than that
> > (1/1200 sec for 48kHz-based and 1/1102.5 sec for 44.1kHz-based rates).
> > ---
> >  libavformat/mux.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mux.c b/libavformat/mux.c
> > index 3533932a58..ba6695badb 100644
> > --- a/libavformat/mux.c
> > +++ b/libavformat/mux.c
> > @@ -622,7 +622,7 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, 
> > AVStream *st, AVPacket *
> >  }
> >  
> >  if (st->cur_dts && st->cur_dts != AV_NOPTS_VALUE &&
> > -((!(s->oformat->flags & AVFMT_TS_NONSTRICT) &&
> > +((!(s->oformat->flags & (AVFMT_NOTIMESTAMPS | AVFMT_TS_NONSTRICT)) 
> > &&
> >st->codecpar->codec_type != AVMEDIA_TYPE_SUBTITLE &&
> >st->codecpar->codec_type != AVMEDIA_TYPE_DATA &&
> >st->cur_dts >= pkt->dts) || st->cur_dts > pkt->dts)) {
> > 
> The change looks good, but the description is suboptimal: Your change
> does not blindly allow non-monotonic timestamps. It just drops the
> requirement of strictly monotonic dts for muxers with

You mean 'strictly increasing'. The timestamps should still always be
monotonic - i.e. non-decreasing, but possibly staying the same in
adjacent packets.

Unrelated to the patch - that if() blocks is starting to look utterly
unreadable and should be split.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: Count last partial frame in probe.

2020-02-27 Thread Anton Khirnov 
Quoting Michael Niedermayer (2020-02-26 19:15:03)
> Fixes: regression
> Fixes: Ticket8511
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mp3dec.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 71a4ed706d..70cceb79f8 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -87,20 +87,26 @@ static int mp3_read_probe(const AVProbeData *p)
>  for (framesizes = frames = 0; buf2 < end; frames++) {
>  MPADecodeHeader h;
>  int header_emu = 0;
> +int available;
>  
>  header = AV_RB32(buf2);
>  ret = avpriv_mpegaudio_decode_header(, header);
> -if (ret != 0 || end - buf2 < h.frame_size)
> +if (ret != 0)
>  break;
>  
> -for (buf3 = buf2 + 4; buf3 < buf2 + h.frame_size; buf3++) {
> +available = FFMIN(h.frame_size, end - buf2);
> +for (buf3 = buf2 + 4; buf3 < buf2 + available; buf3++) {
>  uint32_t next_sync = AV_RB32(buf3);
>  header_emu += (next_sync & MP3_MASK) == (header & MP3_MASK);
>  }
>  if (header_emu > 2)
>  break;
> -buf2 += h.frame_size;
>  framesizes += h.frame_size;
> +if (end - buf2 < h.frame_size) {
   ^^
I think replacing that with 'available' would be more readable.
Otherwise looks ok.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/3 v2] avformat/dashenc: always attempt to enable prft on ldash mode

2020-02-27 Thread Anton Khirnov 
Quoting James Almer (2020-02-26 01:28:48)
> On 2/24/2020 6:54 AM, Anton Khirnov wrote:
> > Quoting James Almer (2020-02-20 17:26:00)
> >> Signed-off-by: James Almer 
> > 
> > Commit message is now misleading since it will only enable prft if it's
> > not disabled.
> 
> Sorry, i pushed this during the weekend. And, true. It's still
> attempting but technically not always...
> 
> Which makes me realize i should mention this undocumented behavior in
> the doxy.
> 
> >> ---
> >> Now it can be overriden if you explicitly set write_prft to 0.
> >>
> >>  libavformat/dashenc.c | 8 +++-
> >>  1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> >> index a52cbc9113..7032adc84d 100644
> >> --- a/libavformat/dashenc.c
> >> +++ b/libavformat/dashenc.c
> >> @@ -1394,6 +1394,12 @@ static int dash_init(AVFormatContext *s)
> >>  c->frag_type = FRAG_TYPE_EVERY_FRAME;
> >>  }
> >>  
> >> +if (c->write_prft < 0) {
> >> +c->write_prft = c->ldash;
> > 
> > nit: !!, in case ldash becomes something else than a bool in the future
> 
> The chances for that are pretty slim, since turning a bool into an int
> would be an API break (true/false would stop working from the command
> line, afaik). But i can change it anyway.

I mean someone could do exactly the thing you are doing here - use -1
for default/unset.

> > 
> > Otherwise LGTM.
> > 
> 
> Thanks, and apologies for not waiting a bit more.

No problem, I should have looked more closely before replying. They were
minor comments anyway.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Anton Khirnov 
Quoting Hendrik Leppkes (2020-02-27 12:27:09)
> On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov  wrote:
> > Why does it need to be within AVFrame? I am still unconvinced that is a
> > good idea. What do we gain from storing them in the same struct?
> > It makes sense for audio and video, because they are similar in many
> > important aspects (and even then there are people saying that they
> > should be separate). Subtitles are even more different.
> >
> 
> You gain a unified API, which we already have now, intead of a
> secondary API just for subtitles thats practically the same but
> accepts different structs.
> This makes everything a lot easier imho. You can decode whatever input
> data into an AVFrame, you can filter your AVFrame, still without
> needing special data paths, and only at the last step after all of
> that do you need to possibly care when it comes to output. If you're
> encoding again, you might not even have that.

AFAIU one of the still-open questions for the subtitle redesign is what
does it mean to decode or encode a subtitle. And one of the options is
putting the AVPacket->"decoded subtitle" (whatever that is) and "decoded
subtitle"->AVPacket conversions into a separate library.
> 
> - Hendrik
> 

-- 
Anton Khirnov

> - Hendrik

-- 
elenril
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

2020-02-27 Thread Jean-Baptiste Kempf 
On Thu, Feb 27, 2020, at 12:30, Anton Khirnov wrote:
> > Today, for example, when we want to visualize QP, we use libavcodec to
> > decode the frame, use another piece of code to extract the QP and overlay
> > both of them. This is almost (and i say ALMOST) decoding the frame twice.
> > (BTW, we can do that already with libavcodec for MV, so why not for QP)
> 
> Thank you, finally there is a clear use case.

Thanks Thierry!

> > I agree that the current QP code (not feature) should be deprecated as it
> > does not work with newer codec.
> > But before removing the deprecated code, it will be nice to have the same
> > feature available with a newer API, so the features of
> > extracting/analyzing/overlaying QP still work.
> 
> Yes, it does indeed sound reasonable to push this new API and convert
> the old code to it. The question remains if any of the people arguing
> for keeping those filters are also willing to do the conversion.

Lynne? Juan? Can it be done with the new API patches?

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

2020-02-27 Thread Anton Khirnov 
Quoting Thierry Foucu (2020-02-26 19:04:57)
> First of all, thanks for trying to clean up deprecated API
> 
> On Wed, Feb 26, 2020 at 6:03 AM Jean-Baptiste Kempf  wrote:
> 
> > Yo,
> >
> > On Wed, Feb 26, 2020, at 14:27, Thilo Borgmann wrote:
> > > > The patch in your link is not using this API. Precisely because this
> > API
> > > > is inadequate for anything newer than MPEG4 ASP. If anything, it's an
> > > > additional argument in favor of my patches.
> > >
> > > My actual point about that patch was that there is a use case to
> > > extract QP tables for more current codecs. Suggests this use case is
> > > also there for less current ones which says we should not just remove
> > > this possibility.
> >
> > I think this is the right question:
> > "Are there actual valid use cases to do it?"
> >
> 
> yes, there is a use case for extracting QP per block:
> To analyze and visualize QP to validate/analyze Rate Control when we enable
> Adaptive QP and ROI for example.
> Most people who works on Rate Control know that the choice of the right
> MV/QP/block type is really important for quality.
> In today world, you will have to license existing software to visualize the
> QP, but if you want to do this over +10k video, and analyze QP based on
> some stats we expect to have, you need some libraries to do it.
> People could write some codec parser to extract the QP per block, but this
> is almost re-implementing part of libavcodec.
> Today, for example, when we want to visualize QP, we use libavcodec to
> decode the frame, use another piece of code to extract the QP and overlay
> both of them. This is almost (and i say ALMOST) decoding the frame twice.
> (BTW, we can do that already with libavcodec for MV, so why not for QP)

Thank you, finally there is a clear use case.

> 
> Last summer, an intern from google tried to come up with a metadata
> structure to store information per block.
> This would have allow to store per block, the MV, QP, block type, etc.. And
> it could have work for any codec with any different block size.
> He was trying to implement what was done for MV and replace the QP with
> this new metadata.
> 
> I agree that the current QP code (not feature) should be deprecated as it
> does not work with newer codec.
> But before removing the deprecated code, it will be nice to have the same
> feature available with a newer API, so the features of
> extracting/analyzing/overlaying QP still work.

Yes, it does indeed sound reasonable to push this new API and convert
the old code to it. The question remains if any of the people arguing
for keeping those filters are also willing to do the conversion.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Hendrik Leppkes 
On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov  wrote:
>
> Quoting Clément Bœsch (2020-02-25 18:40:13)
> > On Sun, Feb 23, 2020 at 09:59:59PM +0100, Michael Niedermayer wrote:
> > [...]
> > > > The subtitles refactor requires to see the big picture and all the 
> > > > problems at
> > > > once.
> > >
> > > really ?
> > > just hypothetically, and playing the devils advocat here.
> > > what would happen if one problem or set of problems is solved at a time ?
> >
> > The first requirement of everything following is to define a new
> > structure/API for holding the subtitles within the AVFrame (which has to
> > live in lavu and not lavc like current API). So you have to address all
> > the current limitations in that new API first, unless you're ready to
> > change that new API 10x in the near future. And even if you keep most of
> > the current design, you still have to at least come up with ways to remove
> > all the current hacks that would go away while moving to the new design.
>
> Why does it need to be within AVFrame? I am still unconvinced that is a
> good idea. What do we gain from storing them in the same struct?
> It makes sense for audio and video, because they are similar in many
> important aspects (and even then there are people saying that they
> should be separate). Subtitles are even more different.
>

You gain a unified API, which we already have now, intead of a
secondary API just for subtitles thats practically the same but
accepts different structs.
This makes everything a lot easier imho. You can decode whatever input
data into an AVFrame, you can filter your AVFrame, still without
needing special data paths, and only at the last step after all of
that do you need to possibly care when it comes to output. If you're
encoding again, you might not even have that.

- Hendrik

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 01/12] fifo: uninline av_fifo_peek2() on the next major bump

2020-02-27 Thread Anton Khirnov 
Quoting James Almer (2020-02-25 22:28:57)
> On 2/24/2020 9:37 AM, Anton Khirnov wrote:
> 
> This patch will need a following one after the bump to remove dead code,
> so IMO might as well just do this in one commit after the bump and save
> all the ifdeffery.

Sure, that makes sense.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

2020-02-27 Thread Anton Khirnov 
Quoting Clément Bœsch (2020-02-25 18:40:13)
> On Sun, Feb 23, 2020 at 09:59:59PM +0100, Michael Niedermayer wrote:
> [...]
> > > The subtitles refactor requires to see the big picture and all the 
> > > problems at
> > > once. 
> > 
> > really ?
> > just hypothetically, and playing the devils advocat here.
> > what would happen if one problem or set of problems is solved at a time ?
> 
> The first requirement of everything following is to define a new
> structure/API for holding the subtitles within the AVFrame (which has to
> live in lavu and not lavc like current API). So you have to address all
> the current limitations in that new API first, unless you're ready to
> change that new API 10x in the near future. And even if you keep most of
> the current design, you still have to at least come up with ways to remove
> all the current hacks that would go away while moving to the new design.

Why does it need to be within AVFrame? I am still unconvinced that is a
good idea. What do we gain from storing them in the same struct?
It makes sense for audio and video, because they are similar in many
important aspects (and even then there are people saying that they
should be separate). Subtitles are even more different.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

2020-02-27 Thread Jai Luthra 

Hi Anamitra,

On Wed, Feb 26, 2020 at 12:26:37PM +0530, Anamitra Ghorui wrote:

This is a buildable "skeleton" of my component (the FLIF16 parser)
i.e. everything is present aside from the logic itself.

***

Hello, I am trying to implement a parser for the FLIF16 file format as
a GSoC 2020 qualification project. So far I think I have managed to
register the parser (alongwith the format) and the basic structure
of the parser code.

I have now reached a point where moving forward is going to be quite
difficult without outside help and references, and so I have a number
of questions regarding the conceptual understanding of FFmpeg:

a. Please tell me if I am right or wrong here:
1. Each audio/video/image file format has a parser for converting the
  file data into a format that can be understood by a decoder.


Yes



2. A Decoder converts a given, recogised encoded data stream into a
  form that can be processed by physical hardware.


Yes. To be exact, decoder turns the encoded data packets to raw frames or 
samples, which can then be transcoded to some other codec or displayed/played.




3. File formats can be independent of what sort of encoding it uses.
  Eg: WebM


Yes a single container format can support diff codecs.



4. The general Audio parsing/decoding process is as follows:
i. Allocate space for a packet of data
   ii. Try to find a hit for the codec of  given data format
  iii. Now, with the codec id, attempt to init a parser
   iv. Allocate a context for the codec
v. Initialize the codec context
   vi. Initialize the codec
  vii. Allocate space for frame data
 viii. Open the imput file
   ix. While file pointer isn't EOF:
   Read data into buffer
   Parse data into a single frame
   Decode the data
x. Flush the file and free stuff.


Yes, there may also be some form of probing taking place, i.e. checking the 
first few packets to find what file format and codec is used. 



5. Every parser has its own parser context extended from the default parser
  context. The byte offsets/positions in the file are kept by the parser
  context.

6. An image can be thought of as a video with a single frame


For some purposes this high level distinction may work. But many image formats 
also support multiple frames and animations like GIF and even FLIF. 



b. In libavcodec/parser.h:

   typedef struct ParseContext{
   ...
   int frame_start_found;
   ...
   } ParseContext;

Is frame_start_found the determined position of the start of the frame
in the data stream?


c. I have been looking at the decoder/encoder/parser of the BMP format
  (which is one of the simplest image formats), the actual decoding work
  (according to me), i.e. Finding the magic numbers, seeing the various
  segments is being done by the decoder function and not the parser.

  The parser function from what I can see from the png_parser and
  bmp_parser, simply manipulates the ParseConstext for appropriate
  values, and does not much else. What is it exactly doing over here?


You are correct. The parser is usally used for video formats, to read and 
iterate over encoded packets/frames in a bitstream. Main decoding part and 
filling contexts for a particular packet is done within the decoder module 
usually.


FLIF does have multiple frames so having a parser is a good idea. But you may 
choose to read the other information through header into the decoder context, 
that is up to you whatever you find better.




If there are any books or articles I should read, please tell me.
---
libavcodec/Makefile|  1 +
libavcodec/avcodec.h   |  1 +
libavcodec/flif16_parser.c | 51 ++
libavcodec/parsers.c   |  1 +
libavformat/img2.c |  1 +
5 files changed, 55 insertions(+)
create mode 100644 libavcodec/flif16_parser.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1e894c8049..ce18632d2c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1045,6 +1045,7 @@ OBJS-$(CONFIG_DVD_NAV_PARSER)  += dvd_nav_parser.o
OBJS-$(CONFIG_DVDSUB_PARSER)   += dvdsub_parser.o
OBJS-$(CONFIG_FLAC_PARSER) += flac_parser.o flacdata.o flac.o \
  vorbis_data.o
+OBJS-$(CONFIG_FLAC_PARSER) += flif16_parser.o
OBJS-$(CONFIG_G723_1_PARSER)   += g723_1_parser.o
OBJS-$(CONFIG_G729_PARSER) += g729_parser.o
OBJS-$(CONFIG_GIF_PARSER)  += gif_parser.o
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 978f36d12a..c6b8c6a1eb 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -461,6 +461,7 @@ enum AVCodecID {
AV_CODEC_ID_MVDV,
AV_CODEC_ID_MVHA,
AV_CODEC_ID_CDTOONS,
+AV_CODEC_ID_FLIF16,

/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
start of audio codecs
diff --git a/libavcodec/flif16_parser.c b/libavcodec/flif16_parser.c
new file mode 100644
index

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

2020-02-27 Thread Thilo Borgmann 
Am 27.02.20 um 11:56 schrieb Lynne:
> Feb 27, 2020, 09:09 by agho...@teknik.io:
> 
>> February 26, 2020 12:27 PM, "Anamitra Ghorui"  wrote:
>>
>>> c. I have been looking at the decoder/encoder/parser of the BMP format
>>> (which is one of the simplest image formats), the actual decoding work
>>> (according to me), i.e. Finding the magic numbers, seeing the various
>>> segments is being done by the decoder function and not the parser.
>>>
>>
>> I meant to say, "the actual 'parsing' work, according to me, is
>> being done by the decoder"
>>
>> I'm sorry if I had come off as rude in my post. It wasn't my intention.
>>
> 
> AFAIK, flif isn't stable (no spec, bitstream may change) and is kind of dead 
> since the author
> moved on to work on JPEG XL to my knowledge.
> 
> I don't think we should be implementing this decoder.

We had have this discussion before creating a project out of it.
They proclaimed it stable themselves. What do we care if their author now works 
on something else?

Anamitra, please don't get confused about that.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

2020-02-27 Thread Lynne 
Feb 27, 2020, 09:09 by agho...@teknik.io:

> February 26, 2020 12:27 PM, "Anamitra Ghorui"  wrote:
>
>> c. I have been looking at the decoder/encoder/parser of the BMP format
>> (which is one of the simplest image formats), the actual decoding work
>> (according to me), i.e. Finding the magic numbers, seeing the various
>> segments is being done by the decoder function and not the parser.
>>
>
> I meant to say, "the actual 'parsing' work, according to me, is
> being done by the decoder"
>
> I'm sorry if I had come off as rude in my post. It wasn't my intention.
>

AFAIK, flif isn't stable (no spec, bitstream may change) and is kind of dead 
since the author
moved on to work on JPEG XL to my knowledge.

I don't think we should be implementing this decoder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Two weird requests

2020-02-27 Thread Tomas Härdin 
tor 2020-02-27 klockan 00:03 -0800 skrev Unidef Defshrizzle:
> Could you integrate this code into ffmpeg?
> 
> 
> https://unidef.org/wp-content/uploads/2019/12/qlib.zip <
> https://unidef.org/wp-content/uploads/2019/12/qlib.zip>

It doesn't compile. Additionally:

> General Purpose Quantum Paralellization Library


> Wednesday, 4:35AM
> May 15th, 2019
> Home
> 
> THIS SOFTWARE IS PROTECTED UNDER FEDERAL LAW
> 
> PROTECTED BY FREE SPEECH


> struct neural_node {
>   ID id;
>   DOC description[GLOBAL_DESCRIPTION_BACKLOG];
>   ERROR (*exception) (NODE,DOC,SYS);
>   NODE *up;
>   NODE **down;
>   NODE ***left;
>   NODE *right;
>   NODE *direction[NEURAL_ARRAY];
>   NODE *direction_2d[NEURAL_ARRAY][NEURAL_ARRAY];
>   NODE *direction_3d[NEURAL_ARRAY][NEURAL_ARRAY][NEURAL_ARRAY];
>   NODE
> *direction_4d[NEURAL_ARRAY][NEURAL_ARRAY][NEURAL_ARRAY][NEURAL_ARRAY]
> ;
>   NODE
> *direction_5d[NEURAL_ARRAY][NEURAL_ARRAY][NEURAL_ARRAY][NEURAL_ARRAY]
> [NEURAL_ARRAY];
>   NODE *directionA[NEURAL_ARRAY];
>   NODE **directionB[NEURAL_ARRAY]; 
>   NODE ***directionC[NEURAL_ARRAY];
>   // more stuff to do
> // direction a-c 
> } ;
> 

I don't even..

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

2020-02-27 Thread aghorui 
February 26, 2020 12:27 PM, "Anamitra Ghorui"  wrote:

> c. I have been looking at the decoder/encoder/parser of the BMP format
> (which is one of the simplest image formats), the actual decoding work
> (according to me), i.e. Finding the magic numbers, seeing the various
> segments is being done by the decoder function and not the parser.

I meant to say, "the actual 'parsing' work, according to me, is
being done by the decoder"

I'm sorry if I had come off as rude in my post. It wasn't my intention.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avformat/ivfenc: Don't use size_t for size of file

2020-02-27 Thread Paul B Mahol 
lgtm

On 2/27/20, Andreas Rheinhardt  wrote:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/ivfenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> index eb70421c44..45e5b238dc 100644
> --- a/libavformat/ivfenc.c
> +++ b/libavformat/ivfenc.c
> @@ -80,7 +80,7 @@ static int ivf_write_trailer(AVFormatContext *s)
>  IVFEncContext *ctx = s->priv_data;
>
>  if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && ctx->frame_cnt > 1) {
> -size_t end = avio_tell(pb);
> +int64_t end = avio_tell(pb);
>
>  avio_seek(pb, 24, SEEK_SET);
>  // overwrite the "length" field (duration)
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Two weird requests

2020-02-27 Thread Unidef Defshrizzle 
Could you integrate this code into ffmpeg?


https://unidef.org/wp-content/uploads/2019/12/qlib.zip 



And with bitshifting, there needs to be a master function

I dont know the bit shifting code well, but I can try


Void frame(FSTRUCT *frame){
master_bitshifting_function(*frame >> 1001, “command”, ARGUMENTS[])
// code
}

Ill try to learn bit shifting and tool around with it, basically it computes 
additional arguments in the master function for dynamics

The reason im posting this is one day I want to implement a ffmpeg frontend to 
qlib

Thank you, please dont flame me, and have a great encoding day..

unidef

Ps be sure to use master copies of encoding sources
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".