[FFmpeg-devel] Example filter that process video and audio
Was looking to create a filter to process video and audio in a filter graph, can find examples in movie or a source that has both video and audio but not anything that takes both, any pointers to something to use as a reference? David ___ 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] Add init_program_date_time so start time can be specified
On Tue, Oct 17, 2023 at 7:09 PM wrote:
>
>
> On 17 Oct 2023, at 17:51, Dave Johansen wrote:
>
> > ---
> > doc/muxers.texi | 3 +++
> > libavformat/hlsenc.c | 7 ++-
> > 2 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/muxers.texi b/doc/muxers.texi
> > index f6071484ff..87c19a5cb9 100644
> > --- a/doc/muxers.texi
> > +++ b/doc/muxers.texi
> > @@ -1086,6 +1086,9 @@ seeking. This flag should be used with the
> @code{hls_time} option.
> > @item program_date_time
> > Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
> >
> > +@item init_program_date_time
> > +Time to start program date time at.
> > +
> > @item second_level_segment_index
> > Makes it possible to use segment indexes as %%d in hls_segment_filename
> expression
> > besides date/time values when strftime is on.
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index 4ef84c05c1..474322cc21 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -28,6 +28,8 @@
> > #include
> > #endif
> >
> > +#include "float.h"
> > +
> > #include "libavutil/avassert.h"
> > #include "libavutil/mathematics.h"
> > #include "libavutil/avstring.h"
> > @@ -212,6 +214,8 @@ typedef struct HLSContext {
> > int64_t recording_time;
> > int64_t max_seg_size; // every segment file max size
> >
> > +double init_program_date_time;
> > +
> > char *baseurl;
> > char *vtt_format_options_str;
> > char *subtitle_filename;
> > @@ -2867,7 +2871,7 @@ static int hls_init(AVFormatContext *s)
> > char *p = NULL;
> > int http_base_proto = ff_is_http_proto(s->url);
> > int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
> > -double initial_program_date_time = av_gettime() / 100.0;
> > +double initial_program_date_time = hls->init_program_date_time ?
> hls->init_program_date_time : av_gettime() / 100.0;
> >
> > if (hls->use_localtime) {
> > pattern = get_default_pattern_localtime_fmt(s);
> > @@ -3141,6 +3145,7 @@ static const AVOption options[] = {
> > {"split_by_time", "split the hls segment by time which user set by
> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
> E, "flags"},
> > {"append_list", "append the new segments into old hls segment
> list", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E,
> "flags"},
> > {"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX, E,
> "flags"},
> > +{"init_program_date_time", "Time to start program date time at",
> OFFSET(init_program_date_time), AV_OPT_TYPE_DOUBLE, {.dbl = 0 }, 0,
> DBL_MAX, E},
>
> This should probably not be mixed into the flags options list.
>
> It seems odd to have the user provide a double here instead of a ISO 8601
> datetime, which is what the spec requires / ends up in the playlist.
> If you do not want to handle the datetime string parsing, at least it
> would be good to give a hint what exactly the double value is expected to
> be here.
>
> However usability-wise I would prefer to accept a proper date/time here…
>
Is there an example of how to accept a string as the option and then do the
parsing that I could base the code on?
___
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] Add init_program_date_time so start time can be specified
On Thu, Oct 26, 2023 at 7:12 PM Dave Johansen wrote: > --- > doc/muxers.texi | 3 +++ > libavformat/hlsenc.c | 41 + > 2 files changed, 28 insertions(+), 16 deletions(-) > I submitted a revised set of patches with additional features with this as the first ___ 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/hlsenc: Add CHANNELS to EXT-X-MEDIA for Audio
> > LGTM > > > Thanks > Steven > I'm new to ffmpeg development so what's the process for this to be merged? Do I need to do something or is it taken care of by a different process/someone else? Thanks, Dave ___ 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] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
libavutil/hwcontext_vaapi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..c3ecd90077 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -882,7 +882,16 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
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 v2] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v2: Fix warning
libavutil/hwcontext_vaapi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..0d16699f66 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,7 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+uint32_t vaflags = 0;
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +883,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
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 v3] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v3: Fix another warning
libavutil/hwcontext_vaapi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..86b0852c12 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+#endif
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +885,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
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 v3] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
On Fri, Oct 27, 2023 at 7:14 PM Mark Thompson wrote:
>
> On 27/10/2023 11:00, David Rosca wrote:
> > This allows some optimizations in driver, such as not having to read
> > back the data if write-only mapping is requested.
> > ---
> > v3: Fix another warning
> >
> > libavutil/hwcontext_vaapi.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index 558fed94c6..86b0852c12 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > VAStatus vas;
> > void *address = NULL;
> > int err, i;
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +uint32_t vaflags = 0;
> > +#endif
> >
> > surface_id = (VASurfaceID)(uintptr_t)src->data[3];
> > av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
> > @@ -882,7 +885,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > }
> > }
> >
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
> > +vaflags |= VA_MAPBUFFER_FLAG_READ;
>
> I don't understand where the !overwrite has come from in this condition?
This logic is a couple lines ahead in the vaCreateImage path. If
AV_HWFRAME_MAP_OVERWRITE isn't set, it will call vaGetImage to read
the image data. And as vaDeriveImage + vaMapBuffer is read+write
mapping, I think the same logic needs to be applied to vaMapBuffer2
too.
>
> If the user requested write-only but not overwrite then they're expecting to
> write some pixels within the image (such as adding an overlay), but don't
> want to read anything.
Exactly for this case the read is needed. If the user writes only some
(not all) pixels of the image, then the rest of the image will be
invalid if a driver implements the mapping using staging texture
(which is what Mesa does).
>
> > +if (flags & AV_HWFRAME_MAP_WRITE)
> > +vaflags |= VA_MAPBUFFER_FLAG_WRITE;
> > +vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
> > +#else
> > vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
> > +#endif
> > if (vas != VA_STATUS_SUCCESS) {
> > av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
> > "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
>
> Please add a note that there is a compatibility layer in libva so that
> MapBuffer2 calls MapBuffer if the driver doesn't expose it directly, so this
> does work with older drivers. (The patch looked wrong before I realised
> that.)
>
> Thanks,
>
> - Mark
> ___
> 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] avformat/hlsenc: Add CHANNELS to EXT-X-MEDIA for Audio
On Fri, Oct 27, 2023 at 1:33 AM Steven Liu wrote: > David Johansen 于2023年10月27日周五 12:03写道： > > > > > > > > LGTM > > > > > > > > > Thanks > > > Steven > > > > > > > I'm new to ffmpeg development so what's the process for this to be > merged? > > Do I need to do something or is it taken care of by a different > > process/someone else? > > Nothing, just leave enough time for more developers review, and will > push this if no more comments. > Don't worry David, this is valuable patch, you did a great job. > Great! Just wanted to make sure I was doing everything needed to get it merged in. Thanks, Dave ___ 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 v4] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v4: overwrite + note about vaMapBuffer libva fallback
libavutil/hwcontext_vaapi.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..435f10a7f3 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+#endif
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +885,16 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ)
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+// On drivers not implementing vaMapBuffer2 libva calls vaMapBuffer
instead.
+vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
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/4] avformat/hlsenc: Add init_program_date_time so start time can be specified
On Fri, Oct 27, 2023 at 4:58 AM wrote:
> On 27 Oct 2023, at 5:59, Dave Johansen wrote:
> > @item second_level_segment_index
> > Makes it possible to use segment indexes as %%d in hls_segment_filename
> expression
> > besides date/time values when strftime is on.
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index 4ef84c05c1..5dfff6b2b6 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -212,6 +212,8 @@ typedef struct HLSContext {
> > int64_t recording_time;
> > int64_t max_seg_size; // every segment file max size
> >
> > +char *init_program_date_time;
> > +
> > char *baseurl;
> > char *vtt_format_options_str;
> > char *subtitle_filename;
> > @@ -1192,6 +1194,25 @@ static int hls_append_segment(struct
> AVFormatContext *s, HLSContext *hls,
> > return 0;
> > }
> >
> > +static double parse_iso8601(const char *ptr) {
> > +struct tm program_date_time;
> > +int y,M,d,h,m,s;
> > +double ms;
> > +if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", &y, &M, &d, &h, &m, &s,
> &ms) != 7) {
> > +return -1;
> > +}
> > +
> > +program_date_time.tm_year = y - 1900;
> > +program_date_time.tm_mon = M - 1;
> > +program_date_time.tm_mday = d;
> > +program_date_time.tm_hour = h;
> > +program_date_time.tm_min = m;
> > +program_date_time.tm_sec = s;
> > +program_date_time.tm_isdst = -1;
> > +
> > +return mktime(&program_date_time) + (double)(ms / 1000);
> > +}
> > +
> > static int parse_playlist(AVFormatContext *s, const char *url,
> VariantStream *vs)
> > {
> > HLSContext *hls = s->priv_data;
> > @@ -1257,24 +1278,11 @@ static int parse_playlist(AVFormatContext *s,
> const char *url, VariantStream *vs
> > }
> > }
> > } else if (av_strstart(line, "#EXT-X-PROGRAM-DATE-TIME:",
> &ptr)) {
> > -struct tm program_date_time;
> > -int y,M,d,h,m,s;
> > -double ms;
> > -if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", &y, &M, &d, &h,
> &m, &s, &ms) != 7) {
> > +discont_program_date_time = parse_iso8601(ptr);
> > +if (discont_program_date_time < 0) {
> > ret = AVERROR_INVALIDDATA;
> > goto fail;
> > }
> > -
> > -program_date_time.tm_year = y - 1900;
> > -program_date_time.tm_mon = M - 1;
> > -program_date_time.tm_mday = d;
> > -program_date_time.tm_hour = h;
> > -program_date_time.tm_min = m;
> > -program_date_time.tm_sec = s;
> > -program_date_time.tm_isdst = -1;
> > -
> > -discont_program_date_time = mktime(&program_date_time);
> > -discont_program_date_time += (double)(ms / 1000);
> > } else if (av_strstart(line, "#", NULL)) {
> > continue;
> > } else if (line[0]) {
> > @@ -2867,7 +2875,7 @@ static int hls_init(AVFormatContext *s)
> > char *p = NULL;
> > int http_base_proto = ff_is_http_proto(s->url);
> > int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
> > -double initial_program_date_time = av_gettime() / 100.0;
> > +double initial_program_date_time = hls->init_program_date_time ?
> parse_iso8601(hls->init_program_date_time) : av_gettime() / 100.0;
>
> As parse_iso8601 parsing user input can fail, it should properly report
> the error and fail. Especially given that it does not accept all variations
> of ISO-8601 date/time IIUC.
>
> It might be confusing if the user specifies a time, forgets the
> milliseconds and it will just silently not use the option at all?
>
I added improved parsing and error reporting. I sent in the patch, but is
there a way for me to tie it to this patchset in the future?
___
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] Separate stream for subtitles in HLS?
Currently, I have to put the subtitles on the video stream and when I make the subtitles their own stream, I get this error: No streams to mux were specified Would it be possible to have the subtitles as their own stream or is too engrained of an assumption that there's an output stream tied to each of the streams? (this appears to be from the call to avformat_init_output) Thanks, Dave ___ 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/4] avformat/hlsenc: Add init_program_date_time so start time can be specified
On Sun, Nov 5, 2023 at 1:21 AM Marton Balint wrote:
>
>
> On Fri, 27 Oct 2023, David Johansen wrote:
>
> > On Fri, Oct 27, 2023 at 4:58 AM wrote:
> >
> >> On 27 Oct 2023, at 5:59, Dave Johansen wrote:
> >> > @item second_level_segment_index
> >> > Makes it possible to use segment indexes as %%d in
> hls_segment_filename
> >> expression
> >> > besides date/time values when strftime is on.
> >> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> > index 4ef84c05c1..5dfff6b2b6 100644
> >> > --- a/libavformat/hlsenc.c
> >> > +++ b/libavformat/hlsenc.c
> >> > @@ -212,6 +212,8 @@ typedef struct HLSContext {
> >> > int64_t recording_time;
> >> > int64_t max_seg_size; // every segment file max size
> >> >
> >> > +char *init_program_date_time;
> >> > +
> >> > char *baseurl;
> >> > char *vtt_format_options_str;
> >> > char *subtitle_filename;
> >> > @@ -1192,6 +1194,25 @@ static int hls_append_segment(struct
> >> AVFormatContext *s, HLSContext *hls,
> >> > return 0;
> >> > }
> >> >
> >> > +static double parse_iso8601(const char *ptr) {
>
> Please use the existing function av_parse_time(). That can more completely
> handle ISO8601 and even more.
>
I made a patch for this an submitted it with --in-reply-to with the Message
ID from this email, but it doesn't appear that it linked it to the existing
patches I sent. What's the proper way that I should submit follow on
patches like this in the future?
___
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/hlsenc: Add CHANNELS to EXT-X-MEDIA for Audio
On Fri, Oct 27, 2023 at 1:33 AM Steven Liu wrote: > David Johansen 于2023年10月27日周五 12:03写道： > > > > > > > > LGTM > > > > > > > > > Thanks > > > Steven > > > > > > > I'm new to ffmpeg development so what's the process for this to be > merged? > > Do I need to do something or is it taken care of by a different > > process/someone else? > > Nothing, just leave enough time for more developers review, and will > push this if no more comments. > Don't worry David, this is valuable patch, you did a great job. > I submitted a handful of patches and I believe I've addressed all of the feedback I've seen, so is there anything I need to do to follow up on them and get them merged? Thanks, Dave ___ 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] libavcodec/videotoolboxenc.c: Only log the EncoderID on macOS >= 10.13.
This is to fix a build failure on macOS < 10.13.
This is a build failure in release 6.1. The issue also exists at the
top of the master branch, and the patch applies there.
---
libavcodec/videotoolboxenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index b0e827d14a..b72eb470fd 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -1172,7 +1172,6 @@ static int vtenc_create_encoder(AVCodecContext *avctx,
return AVERROR_EXTERNAL;
}
}
-#endif
// Dump the init encoder
{
@@ -1201,6 +1200,7 @@ static int vtenc_create_encoder(AVCodecContext *avctx,
if (encoderID != NULL)
CFRelease(encoderID);
}
+#endif
if (avctx->flags & AV_CODEC_FLAG_QSCALE && !vtenc_qscale_enabled()) {
av_log(avctx, AV_LOG_ERROR, "Error: -q:v qscale not available
for encoder. Use -b:v bitrate instead.\n");
--
2.43.0
___
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] libavcodec/videotoolboxenc.c: Only log the EncoderID on macOS >= 10.13.
On Fri, Nov 24, 2023 at 9:01 AM Zhao Zhili wrote: > > > On Nov 24, 2023, at 23:40, David Bohman wrote: > > > > This is to fix a build failure on macOS < 10.13. > > > It looks like kVTCompressionPropertyKey_EncoderID is the root cause of build > failure. > I prefer use compat_keys, so it can be build on macOS < 10.13, get the key at > runtime > and run on macOS >= 10.13. Correct, kVTCompressionPropertyKey_EncoderID appeared in 10.13, according to the Apple Developer documentation. Are you going to do your own fix? ___ 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] libavcodec/videotoolboxenc.c: Only log the EncoderID on macOS >= 10.13.
On Fri, Nov 24, 2023 at 8:09 PM Zhao Zhili wrote: > > > > > On Nov 25, 2023, at 05:32, David Bohman wrote: > > > > On Fri, Nov 24, 2023 at 9:01 AM Zhao Zhili wrote: > >> > >>> On Nov 24, 2023, at 23:40, David Bohman wrote: > >>> > >>> This is to fix a build failure on macOS < 10.13. > >>> > >> It looks like kVTCompressionPropertyKey_EncoderID is the root cause of > >> build failure. > >> I prefer use compat_keys, so it can be build on macOS < 10.13, get the key > >> at runtime > >> and run on macOS >= 10.13. > > > > Correct, kVTCompressionPropertyKey_EncoderID appeared in 10.13, > > according to the Apple Developer documentation. > > > > Are you going to do your own fix? > > Could you test the following patch? Thanks. > > https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/317366.html Looks good. ___ 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] prompeg_write() must report data all was written
Previously, prompeg_write() would only report to caller that bytes we
written when a FEC packet was actually created. Not all RTP packets are
expected to generate a FEC packet however, so this behavior was causing
avio to retry writing the RTP packet, eventually forcing the FEC state
machine to send a FEC packet erroneously (and so breaking out of the
retry loop).
This was resulting in incorrect FEC data being generated, and far too
many FEC packets to be sent (~100% FEC overhead).
---
libavformat/prompeg.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
index 94b556d5f1..c3bd5f1249 100644
--- a/libavformat/prompeg.c
+++ b/libavformat/prompeg.c
@@ -387,7 +387,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf,
int size) {
PrompegContext *s = h->priv_data;
uint8_t *bitstring = NULL;
int col_idx, col_out_idx, row_idx;
-int ret, written = 0;
+int ret = 0;
if (s->init && ((ret = prompeg_init(h, buf, size)) < 0))
goto end;
@@ -403,7 +403,6 @@ static int prompeg_write(URLContext *h, const uint8_t *buf,
int size) {
if (!s->first || s->packet_idx > 0) {
if ((ret = prompeg_write_fec(h, s->fec_row, PROMPEG_FEC_ROW)) < 0)
goto end;
-written += ret;
}
memcpy(s->fec_row->bitstring, bitstring, s->bitstring_size);
s->fec_row->sn = AV_RB16(buf + 2);
@@ -431,7 +430,6 @@ static int prompeg_write(URLContext *h, const uint8_t *buf,
int size) {
col_out_idx = s->packet_idx / s->d;
if ((ret = prompeg_write_fec(h, s->fec_col[col_out_idx],
PROMPEG_FEC_COL)) < 0)
goto end;
-written += ret;
}
if (++s->packet_idx >= s->packet_idx_max) {
@@ -440,7 +438,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf,
int size) {
s->first = 0;
}
-ret = written;
+ret = size;
end:
av_free(bitstring);
--
2.19.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] avcodec: add a WavPack DSD decoder
Hi,
As I promised late last year, here is a patch to add a WavPack DSD decoder.
Thanks!
-David Bryant
From d80f4fb59e4afec1e2c539391a7b4484f5ae8436 Mon Sep 17 00:00:00 2001
From: David Bryant
Date: Sun, 21 Jul 2019 15:43:25 -0700
Subject: [PATCH] avcodec: add a WavPack DSD decoder
Signed-off-by: David Bryant
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h | 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/wavpack.h | 2 +
libavcodec/wavpack_dsd.c | 792 +++
libavformat/wvdec.c | 32 +-
7 files changed, 824 insertions(+), 12 deletions(-)
create mode 100644 libavcodec/wavpack_dsd.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3cd73fb..b94327e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -686,6 +686,7 @@ OBJS-$(CONFIG_VPLAYER_DECODER) += textdec.o ass.o
OBJS-$(CONFIG_VP9_V4L2M2M_DECODER) += v4l2_m2m_dec.o
OBJS-$(CONFIG_VQA_DECODER) += vqavideo.o
OBJS-$(CONFIG_WAVPACK_DECODER) += wavpack.o
+OBJS-$(CONFIG_WAVPACK_DSD_DECODER) += wavpack_dsd.o dsd.o
OBJS-$(CONFIG_WAVPACK_ENCODER) += wavpackenc.o
OBJS-$(CONFIG_WCMV_DECODER)+= wcmv.o
OBJS-$(CONFIG_WEBP_DECODER)+= webp.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d2f9a39..a2f414b 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -485,6 +485,7 @@ extern AVCodec ff_vorbis_encoder;
extern AVCodec ff_vorbis_decoder;
extern AVCodec ff_wavpack_encoder;
extern AVCodec ff_wavpack_decoder;
+extern AVCodec ff_wavpack_dsd_decoder;
extern AVCodec ff_wmalossless_decoder;
extern AVCodec ff_wmapro_decoder;
extern AVCodec ff_wmav1_encoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index d234271..8d3a551 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -652,6 +652,7 @@ enum AVCodecID {
AV_CODEC_ID_SBC,
AV_CODEC_ID_ATRAC9,
AV_CODEC_ID_HCOM,
+AV_CODEC_ID_WAVPACK_DSD,
/* subtitle codecs */
AV_CODEC_ID_FIRST_SUBTITLE = 0x17000, ///< A dummy ID pointing at
the start of subtitle codecs.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 4d033c2..bee88b8 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2985,6 +2985,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("HCOM Audio"),
.props = AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_WAVPACK_DSD,
+.type = AVMEDIA_TYPE_AUDIO,
+.name = "wavpack_dsd",
+.long_name = NULL_IF_CONFIG_SMALL("WavPack DSD"),
+.props = AV_CODEC_PROP_LOSSLESS,
+},
/* subtitle codecs */
{
diff --git a/libavcodec/wavpack.h b/libavcodec/wavpack.h
index 6caad03..43aaac8 100644
--- a/libavcodec/wavpack.h
+++ b/libavcodec/wavpack.h
@@ -35,6 +35,7 @@
#define WV_FLOAT_DATA 0x0080
#define WV_INT32_DATA 0x0100
#define WV_FALSE_STEREO 0x4000
+#define WV_DSD_DATA 0x8000
#define WV_HYBRID_MODE0x0008
#define WV_HYBRID_SHAPE 0x0008
@@ -77,6 +78,7 @@ enum WP_ID {
WP_ID_CORR,
WP_ID_EXTRABITS,
WP_ID_CHANINFO,
+WP_ID_DSD_DATA,
WP_ID_SAMPLE_RATE = 0x27,
};
diff --git a/libavcodec/wavpack_dsd.c b/libavcodec/wavpack_dsd.c
new file mode 100644
index 000..0754314
--- /dev/null
+++ b/libavcodec/wavpack_dsd.c
@@ -0,0 +1,792 @@
+/*
+ * WavPack lossless DSD audio decoder
+ * Copyright (c) 2006,2011 Konstantin Shishkov
+ * Copyright (c) 2019 David Bryant
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/channel_layout.h"
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+#include "wavpack.h"
+#include "dsd.h"
+
+/**
+ * @file
+ * WavPack lossless DSD audio decoder
+ */
+
+#define DSD_BYTE_READY(low,high) (!(((low) ^ (high)) & 0xff00))
+
+#define PTABLE_BITS 8
+#define PTABLE_BINS (1<CRC) {
+av_log(s->avctx, AV_LOG_ERROR, "CRC error\n");
+return AVERROR_INVALIDDATA;
+}
+
+return 0;
+}
+
Re: [FFmpeg-devel] avcodec: add a WavPack DSD decoder
On 7/21/19 11:23 PM, Paul B Mahol wrote: > On 7/22/19, David Bryant wrote: >> Hi, >> >> As I promised late last year, here is a patch to add a WavPack DSD decoder. >> >> Thanks! >> >> -David Bryant >> >> > Please correct me if I'm wrong, but why this uses new codec id? > Apparently is also copies some logic from other files. Yes, I created a new codec ID for WavPack DSD. It would be possible to just piggyback on the existing WavPack codec by silently decimating the DSD to PCM, but that seemed weird and wrong to me. For one thing, the user would have no idea that the file was actually DSD and not high sample-rate PCM. Also, since regular WavPack has threading enabled but WavPack DSD can't (because of the dsd2pcm conversion) I would have to turn off threading for all WavPack (unless there's some way of making that conditional at runtime). It would also mean that regular WavPack would be dependent on the dsd2pcm component even if DSD was not required (not everyone needs DSD). And of course I was looking closely at the only other DSD codec in FFmpeg (DST) which has its own codec ID. Because regular WavPack PCM and DSD share the same block format and metadata structure, there is a little code that is shared between the two codecs (although they are no longer identical because of the threading difference). Is this a problem? I could combine the two codecs into one file and sprinkle in a few conditionals, but I don't think it would be as clean or clear (but might save a little duplicate code). That's my thinking, but obviously I am not as familiar with the FFmpeg philosophy as you guys. -David > ___ > 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] avcodec: add a WavPack DSD decoder
On 7/23/19 12:47 AM, Paul B Mahol wrote: > On 7/23/19, David Bryant wrote: >> On 7/21/19 11:23 PM, Paul B Mahol wrote: >>> On 7/22/19, David Bryant wrote: >>>> Hi, >>>> >>>> As I promised late last year, here is a patch to add a WavPack DSD >>>> decoder. >>>> >>>> Thanks! >>>> >>>> -David Bryant >>>> >>>> >>> Please correct me if I'm wrong, but why this uses new codec id? >>> Apparently is also copies some logic from other files. >> Yes, I created a new codec ID for WavPack DSD. It would be possible to just >> piggyback on the existing WavPack codec by silently >> decimating the DSD to PCM, but that seemed weird and wrong to me. For one >> thing, the user would have no idea that the file was >> actually DSD and not high sample-rate PCM. >> >> Also, since regular WavPack has threading enabled but WavPack DSD can't >> (because of the dsd2pcm conversion) I would have to turn >> off threading for all WavPack (unless there's some way of making that >> conditional at runtime). It would also mean that regular >> WavPack would be dependent on the dsd2pcm component even if DSD was not >> required (not everyone needs DSD). And of course I was >> looking closely at the only other DSD codec in FFmpeg (DST) which has its >> own codec ID. >> >> Because regular WavPack PCM and DSD share the same block format and metadata >> structure, there is a little code that is shared >> between the two codecs (although they are no longer identical because of the >> threading difference). Is this a problem? I could >> combine the two codecs into one file and sprinkle in a few conditionals, but >> I don't think it would be as clean or clear (but >> might save a little duplicate code). >> >> That's my thinking, but obviously I am not as familiar with the FFmpeg >> philosophy as you guys. > Looking carefully at dsd2pcm code in your patch, it appears it would > work only with 1 or 2 channels. > Is this correct? Individual WavPack blocks can only be 1 or 2 channels. Multichannel files contains sequences of blocks which ends up creating multiple frame contexts. This was originally implemented for PCM WavPack years ago and so it "just works" for DSD WavPack because I didn't touch any of that. I have tested this extensively with multichannel DSD files and it works great, including seeking. > > About multi-threading, as dsd2pcm can not be made multi-threaded then > just do locking when doing dsd2pcm to make it single threaded and > update other code as necessary. It's not really that dsd2pcm cannot be multi-threaded, it's that the audio frames cannot be converted to PCM independently or you'll get a click at the frame boundaries. Maybe we're talking about the same thing, but I don't see how a lock would fix this. In any event, could you please show me an example of doing that? > > I still see no valid reason to add separate codec id. Add another > wavpack profile if you wish to help users know the difference between > the two. Again I apologize for not being too familiar with FFmpeg internals. What would another wavpack "profile" be? As long as the user (or caller) has some way to differentiate between DSD and PCM files without parsing the file themselves I'm happy, but what exactly is the hesitation here? Are codec IDs a limited resource? It seems like an obvious win to me. -David > ___ > 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] avcodec: add a WavPack DSD decoder
On 7/21/19 5:57 PM, Lynne wrote:
> Jul 22, 2019, 12:03 AM by da...@wavpack.com:
>
>> Hi,
>>
>> As I promised late last year, here is a patch to add a WavPack DSD decoder.
>>
>> Thanks!
>>
>> -David Bryant
>>
>> + unsigned char probabilities [MAX_HISTORY_BINS] [256];
>> + unsigned char *value_lookup [MAX_HISTORY_BINS];
> Use uint8_t throughout the patch.
> Also don't add spaces between array declarations or lookups.
Done. New patch attached for all changes (hope that's the right way to do it).
>
>
>> +static void init_ptable (int *table, int rate_i, int rate_s)
>> +{
>> + int value = 0x808000, rate = rate_i << 8, c, i;
>> +
>> + for (c = (rate + 128) >> 8; c--;)
>> + value += (DOWN - value) >> DECAY;
>> +
>> + for (i = 0; i < PTABLE_BINS/2; ++i) {
> What's up with the random increment position in loops? It changes to before
> and after the variable throughout. Make it consistent and after the variable.
> Also we support declarative for (int loops. Can save lines.
Fixed random increment position and put in declarative int loops (even when
they didn't save a line).
>
>
>> + DSDfilters filters [2], *sp = filters;
> Same, spaces after variables for arrays, all throughout the file.
Done. Also fixed spaces after function names.
>
>
>> + if (code > max_probability) {
>> + int zcount = code - max_probability;
>> +
>> + while (outptr < outend && zcount--)
>> + *outptr++ = 0;
>> + }
>> + else if (code)
>> + *outptr++ = code;
>> + else
>> + break;
> We don't put else on a new line, and prefer to have each branch wrapped in
> bracket unless all branches are single lines.
Fixed.
>
>
>> + for (p0 = 0; p0 < history_bins; ++p0) {
>> + int32_t sum_values;
>> + unsigned char *vp;
>> +
>> + for (sum_values = i = 0; i < 256; ++i)
>> + s->summed_probabilities [p0] [i] = sum_values +=
>> s->probabilities [p0] [i];
> sum_values is uninitialized. Does you compiler not warn about this?
This was pointed out already as actually initialized, but I made it clearer
(obviously it wasn't).
>
>
>> + if (sum_values) {
>> + total_summed_probabilities += sum_values;
>> + vp = s->value_lookup [p0] = av_malloc (sum_values);
> I don't like the per-frame alloc. The maximum sum_values can be is 255*255 =
> UINT16_MAX.
> 60k of memory isn't much at all, just define value_lookup[255*255] in the
> context and you'll probably plug a few out of bounds accesses too.
It's actually up to 32 allocs per frame because there's one for each history
bin (value_lookup is an array of pointers, not
uint8s), and I didn't like it either because I had to worry about de-allocing
on error. Refactored to use a single array in the
context as a pool. Thanks for the suggestion!
>
>
>> +mult = high / s->summed_probabilities [p0] [255];
> s->summed_probabilities [p0] [255]; can be zero, you already check if its
> zero when allocating currently. You should probably check for divide by zero
> unless you're very sure it can't happen.
I'm very sure. The checks are within a few lines above each of the three
divides.
>
>
>> + crc += (crc << 1) + code;
> Don't NIH CRCs, we have av_crc in lavu. See below how to use it.
It's not a standard crc, but more of a recirculating checksum, so the NIH code
is required.
>
>
>> +static int wv_unpack_dsd_copy(WavpackFrameContext *s, void *dst_l, void
>> *dst_r)
>> +{
>> + uint8_t *dsd_l = dst_l;
>> + uint8_t *dsd_r = dst_r;
> You're shadowing arguments. Your compiler doesn't warn on this either?
> You're calling the function with uint8_ts anyway, just change the type.
They're not shadowed (dsd vs. dst) which is why my compiler didn't complain,
but I took your suggestion of just changing the types.
>
>
>> + while (total_samples--) {
>> + crc += (crc << 1) + (*dsd_l = bytestream2_get_byte(&s->gb));
>> + dsd_l += 4;
>> +
>> + if (dst_r) {
>> + crc += (crc << 1) + (*dsd_r = bytestream2_get_byte(&s->gb));
>> + dsd_r += 4;
>> + }
>> + }
> av_crc(av_crc_get_table(AV_CRC_32_IEEE/LE), UINT32_MAX, dsd_start_r/l,
> dsd_r/l - dsd_start_r/l) should work and
Re: [FFmpeg-devel] avcodec: add a WavPack DSD decoder
On 7/25/19 8:36 AM, Lynne wrote:
> Jul 25, 2019, 6:12 AM by da...@wavpack.com:
>
>>>> + crc += (crc << 1) + code;
>>>>
>>> Don't NIH CRCs, we have av_crc in lavu. See below how to use it.
>>>
>> It's not a standard crc, but more of a recirculating checksum, so the NIH
>> code is required.
>>
> Could you not call it a CRC then? "checksum" is more appropriate.
> Wish a CRC was used, its so much better than a checksum and only slightly
> slower.
Changed variable name to "checksum".
Yes, I too wish I had used a real CRC, but 21 years ago it was not so obvious.
What I came up with is a position-dependent
checksum that's actually pretty close to a CRC in real-world robustness (and
certainly much better than a simple checksum).
>
>
>
>>>> + frame->nb_samples = s->samples + 1;
>>>> + if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
>>>> + return ret;
>>>> + frame->nb_samples = s->samples;
>>>>
>>> ?. Is the extra sample used as temporary buffer or something?
>>>
>> Your guess is as good as mine. This was part of the code "borrowed" from the
>> PCM version (with the threading removed) so maybe
>> there is (or was) a situation that was writing one extra sample off the end.
>> The code here certainly doesn't, but it seemed
>> pretty innocuous and I don't like just ripping out things I don't understand.
>>
> Just change it and run it through valgrind, I can't see the code using it.
Did that, and also discovered that I had mistakenly removed the freeing of the
frame contexts, which I put back. Oops!
>
>
> Rest looks fine to me.
Thanks for your feedback.
It turns out that this patch has been categorically rejected because it creates
a new codec ID for the new DSD codec. I don't
have time at this point to refactor it appropriately, but I wanted to leave it
in a working state in case someone wanted to test
it or use it as is in the interim. It has been exhaustively tested and I
believe that it is complete and safe.
Kind regards,
David
> ___
> 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".
From afce89f76c1472a7f2632f335d79caf274a16ad7 Mon Sep 17 00:00:00 2001
From: David Bryant
Date: Sat, 27 Jul 2019 18:50:46 -0700
Subject: [PATCH] avcodec: add a WavPack DSD decoder
Signed-off-by: David Bryant
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h | 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/wavpack.h | 2 +
libavcodec/wavpack_dsd.c | 780 +++
libavformat/wvdec.c | 32 +-
7 files changed, 812 insertions(+), 12 deletions(-)
create mode 100644 libavcodec/wavpack_dsd.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3cd73fb..b94327e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -686,6 +686,7 @@ OBJS-$(CONFIG_VPLAYER_DECODER) += textdec.o ass.o
OBJS-$(CONFIG_VP9_V4L2M2M_DECODER) += v4l2_m2m_dec.o
OBJS-$(CONFIG_VQA_DECODER) += vqavideo.o
OBJS-$(CONFIG_WAVPACK_DECODER) += wavpack.o
+OBJS-$(CONFIG_WAVPACK_DSD_DECODER) += wavpack_dsd.o dsd.o
OBJS-$(CONFIG_WAVPACK_ENCODER) += wavpackenc.o
OBJS-$(CONFIG_WCMV_DECODER)+= wcmv.o
OBJS-$(CONFIG_WEBP_DECODER)+= webp.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d2f9a39..a2f414b 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -485,6 +485,7 @@ extern AVCodec ff_vorbis_encoder;
extern AVCodec ff_vorbis_decoder;
extern AVCodec ff_wavpack_encoder;
extern AVCodec ff_wavpack_decoder;
+extern AVCodec ff_wavpack_dsd_decoder;
extern AVCodec ff_wmalossless_decoder;
extern AVCodec ff_wmapro_decoder;
extern AVCodec ff_wmav1_encoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index d234271..8d3a551 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -652,6 +652,7 @@ enum AVCodecID {
AV_CODEC_ID_SBC,
AV_CODEC_ID_ATRAC9,
AV_CODEC_ID_HCOM,
+AV_CODEC_ID_WAVPACK_DSD,
/* subtitle codecs */
AV_CODEC_ID_FIRST_SUBTITLE = 0x17000, ///< A dummy ID pointing at
the start of subtitle codecs.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 4d033c2..bee88b8 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2985,6 +2985,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("HCOM Audio"),
Re: [FFmpeg-devel] avcodec: add a WavPack DSD decoder
On 7/24/19 12:26 AM, Paul B Mahol wrote: > On 7/23/19, David Bryant wrote: >> On 7/23/19 12:47 AM, Paul B Mahol wrote: >>> On 7/23/19, David Bryant wrote: >>>> On 7/21/19 11:23 PM, Paul B Mahol wrote: >>>>> On 7/22/19, David Bryant wrote: >>>>>> Hi, >>>>>> >>>>>> As I promised late last year, here is a patch to add a WavPack DSD >>>>>> decoder. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -David Bryant >>>>>> >>>>>> >>>>> Please correct me if I'm wrong, but why this uses new codec id? >>>>> Apparently is also copies some logic from other files. >>>> Yes, I created a new codec ID for WavPack DSD. It would be possible to >>>> just >>>> piggyback on the existing WavPack codec by silently >>>> decimating the DSD to PCM, but that seemed weird and wrong to me. For one >>>> thing, the user would have no idea that the file was >>>> actually DSD and not high sample-rate PCM. >>>> >>>> Also, since regular WavPack has threading enabled but WavPack DSD can't >>>> (because of the dsd2pcm conversion) I would have to turn >>>> off threading for all WavPack (unless there's some way of making that >>>> conditional at runtime). It would also mean that regular >>>> WavPack would be dependent on the dsd2pcm component even if DSD was not >>>> required (not everyone needs DSD). And of course I was >>>> looking closely at the only other DSD codec in FFmpeg (DST) which has its >>>> own codec ID. >>>> >>>> Because regular WavPack PCM and DSD share the same block format and >>>> metadata >>>> structure, there is a little code that is shared >>>> between the two codecs (although they are no longer identical because of >>>> the >>>> threading difference). Is this a problem? I could >>>> combine the two codecs into one file and sprinkle in a few conditionals, >>>> but >>>> I don't think it would be as clean or clear (but >>>> might save a little duplicate code). >>>> >>>> That's my thinking, but obviously I am not as familiar with the FFmpeg >>>> philosophy as you guys. >>> Looking carefully at dsd2pcm code in your patch, it appears it would >>> work only with 1 or 2 channels. >>> Is this correct? >> Individual WavPack blocks can only be 1 or 2 channels. Multichannel files >> contains sequences of blocks which ends up creating >> multiple frame contexts. This was originally implemented for PCM WavPack >> years ago and so it "just works" for DSD WavPack >> because I didn't touch any of that. >> >> I have tested this extensively with multichannel DSD files and it works >> great, including seeking. > Than I fail to see why it could not work for multi-threading too. Really? Because I just looked back at the FFmpeg devel archives (May 2016) and you supplied the patch for the DST codec, the only other DSD compression codec in existence before my recent development. And dstdec.c does not enable multi-threading because, of course, you get clicks. This seems like an unlikely oversight since DST is a well-documented CPU hog and would benefit greatly from multi-threading. > >> >>> About multi-threading, as dsd2pcm can not be made multi-threaded then >>> just do locking when doing dsd2pcm to make it single threaded and >>> update other code as necessary. >> It's not really that dsd2pcm cannot be multi-threaded, it's that the audio >> frames cannot be converted to PCM independently or >> you'll get a click at the frame boundaries. Maybe we're talking about the >> same thing, but I don't see how a lock would fix this. >> In any event, could you please show me an example of doing that? > The ffmpeg have functionality to await progress of some work, which > allows doing some stuff single threaded. > For example look at apng decoder in libavcodec/pngdec.c > See ff_thread_await/report_progress and > .update_thread_context/.init_thread_copy > and relevant documentation of mentioned functions. Okay, I've looked over that stuff and I agree that it might be usable for this, although it is currently only used for video codecs and pictures, and it might be tricky getting it right (at least for someone not intimate with FFmpeg internals). What would be cool is if you could implement this in dstdec.c and I'll copy that... ;-) O
Re: [FFmpeg-devel] avcodec: add a WavPack DSD decoder
On 7/28/19 10:27 AM, Paul B Mahol wrote: > On Sun, Jul 28, 2019 at 6:02 AM David Bryant wrote: > >> On 7/24/19 12:26 AM, Paul B Mahol wrote: >>> On 7/23/19, David Bryant wrote: >>>> On 7/23/19 12:47 AM, Paul B Mahol wrote: >>>>> On 7/23/19, David Bryant wrote: >>>>>> On 7/21/19 11:23 PM, Paul B Mahol wrote: >>>>>>> On 7/22/19, David Bryant wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> As I promised late last year, here is a patch to add a WavPack DSD >>>>>>>> decoder. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> -David Bryant >>>>>>>> >>>>>>>> >>>>>>> Please correct me if I'm wrong, but why this uses new codec id? >>>>>>> Apparently is also copies some logic from other files. >>>>>> Yes, I created a new codec ID for WavPack DSD. It would be possible to >>>>>> just >>>>>> piggyback on the existing WavPack codec by silently >>>>>> decimating the DSD to PCM, but that seemed weird and wrong to me. For >> one >>>>>> thing, the user would have no idea that the file was >>>>>> actually DSD and not high sample-rate PCM. >>>>>> >>>>>> Also, since regular WavPack has threading enabled but WavPack DSD >> can't >>>>>> (because of the dsd2pcm conversion) I would have to turn >>>>>> off threading for all WavPack (unless there's some way of making that >>>>>> conditional at runtime). It would also mean that regular >>>>>> WavPack would be dependent on the dsd2pcm component even if DSD was >> not >>>>>> required (not everyone needs DSD). And of course I was >>>>>> looking closely at the only other DSD codec in FFmpeg (DST) which has >> its >>>>>> own codec ID. >>>>>> >>>>>> Because regular WavPack PCM and DSD share the same block format and >>>>>> metadata >>>>>> structure, there is a little code that is shared >>>>>> between the two codecs (although they are no longer identical because >> of >>>>>> the >>>>>> threading difference). Is this a problem? I could >>>>>> combine the two codecs into one file and sprinkle in a few >> conditionals, >>>>>> but >>>>>> I don't think it would be as clean or clear (but >>>>>> might save a little duplicate code). >>>>>> >>>>>> That's my thinking, but obviously I am not as familiar with the FFmpeg >>>>>> philosophy as you guys. >>>>> Looking carefully at dsd2pcm code in your patch, it appears it would >>>>> work only with 1 or 2 channels. >>>>> Is this correct? >>>> Individual WavPack blocks can only be 1 or 2 channels. Multichannel >> files >>>> contains sequences of blocks which ends up creating >>>> multiple frame contexts. This was originally implemented for PCM WavPack >>>> years ago and so it "just works" for DSD WavPack >>>> because I didn't touch any of that. >>>> >>>> I have tested this extensively with multichannel DSD files and it works >>>> great, including seeking. >>> Than I fail to see why it could not work for multi-threading too. >> Really? Because I just looked back at the FFmpeg devel archives (May 2016) >> and you supplied the patch for the DST codec, the >> only other DSD compression codec in existence before my recent >> development. And dstdec.c does not enable multi-threading >> because, of course, you get clicks. This seems like an unlikely oversight >> since DST is a well-documented CPU hog and would >> benefit greatly from multi-threading. >> > You are right, it can not use frame-multi-threading. But can use > slice-multi-threading as each channel is independent. > Thanks for pointing this for DST, I will implement this slice-threading > soon, unless someone beat me first. My thought was that the CPU-hungry DSD decoding would be multi-threaded, but each thread would have to wait when it got to the dsd2pcm step to make sure the previous had finished, and then it would copy the dsd2pcm-specific context from the previous thread. So there would be dsd2pcm contexts allocated for each thread, but the actual content would be copied from one to the next. Or you could just always use the dsd2pcm contexts from the "first" thread, if it was possible to access that. I would need to look at it a lot more to be sure. > ___ > 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/dsddec: add slice threading support
On 7/30/19 1:43 AM, Carl Eugen Hoyos wrote: > Am So., 28. Juli 2019 um 23:35 Uhr schrieb Paul B Mahol : >> Hi, >> >> patch attached. > As just posted on irc: > On an 8-core Intel cpu, this makes decoding slower by a factor two, > heating the cpu > ten times as much, on a multi-core powerpc, decoding is nearly two > times slower, and > heats nearly eight times as much. I can verify the greatly increased CPU load on a dual core system also. I also verified that the outputted audio data is correct (identical to unmodified code) and that there are no more samples being processed, indicating it's probably just threading overhead. The dsd2pcm conversion is pretty optimized and I suspect that's just way too fast to be worth multi-threading. As I suggested earlier, it's the DST decompression that is worth looking into for threading. -David > > 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] DSD and DST speed improvements
On 7/31/19 11:49 PM, Paul B Mahol wrote: > Hi, > > patches attached. > > This time DSD decoding is approx %50 faster on old Celeron N3050 CPUs and 2 > threads. I see about 42% speedup on Core Duo E8400 (36x to 52x) for a 5-channel file. On the same file encoded in DST, the improvement almost disappears (2.47x to 2.54x) because the DST part takes about 15x more CPU than the dsd2pcm part; would be extremely valuable to multi-thread that instead and leave the dsd2pcm alone. And this breaks my WavPack DSD decoder, but I guess I can't complain about that yet. :) > > ___ > 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] patch for failing on WavPack DSD files
Hi,
Was made aware of this problem on Kodi:
https://github.com/xbmc/xbmc/issues/14771
I'm going to try to add full WavPack DSD support, but thought in the meantime
it would be a good idea to detect and error out early.
Thanks!
David
>From c86aacdf98c3d34a3f8d63233e01c4a3ab55577e Mon Sep 17 00:00:00 2001
From: David Bryant
Date: Tue, 20 Nov 2018 21:00:47 -0800
Subject: [PATCH] detect and error out on WavPack DSD files (which are not
currently supported)
---
libavformat/wvdec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/wvdec.c b/libavformat/wvdec.c
index 8252656..2060523 100644
--- a/libavformat/wvdec.c
+++ b/libavformat/wvdec.c
@@ -40,6 +40,7 @@ enum WV_FLAGS {
WV_HBAL = 0x0400,
WV_MCINIT = 0x0800,
WV_MCEND = 0x1000,
+WV_DSD= 0x8000,
};
static const int wv_rates[16] = {
@@ -97,6 +98,11 @@ static int wv_read_block_header(AVFormatContext *ctx, AVIOContext *pb)
return ret;
}
+if (wc->header.flags & WV_DSD) {
+avpriv_report_missing_feature(ctx, "WV DSD");
+return AVERROR_PATCHWELCOME;
+}
+
if (wc->header.version < 0x402 || wc->header.version > 0x410) {
avpriv_report_missing_feature(ctx, "WV version 0x%03X",
wc->header.version);
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch for failing on WavPack DSD files
On 11/20/18 10:58 PM, Peter Ross wrote: > On Tue, Nov 20, 2018 at 09:23:03PM -0800, David Bryant wrote: >> Hi, >> >> Was made aware of this problem on Kodi: >> >> https://github.com/xbmc/xbmc/issues/14771 >> >> I'm going to try to add full WavPack DSD support, but thought in the >> meantime it would be a good idea to detect and error out early. >> >> Thanks! > cool. is this dst-based, or your own algorithm? > > -- Peter > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel This is my own algorithm. Actually there are two: one is a byte-based algorithm that is very fast and the other is bit-based (like DST) that is slower but compresses better (and still uses less CPU than DST). If I had to make a rough estimation of the average compression ratios, it would be about 0.6 for the fast mode, 0.5 for the high mode, and 0.4 for DST. -David ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: Do not abort when cross-compiling to the native CPU
Using a compiler with a different host triplet is considered
cross-compiling, even when it is for the same architecture as the
build system. With such a cross-compiler, it is still valid to
optimize builds with --cpu=host. Drop the condition that aborts in
this case, since a cross-compiler for an incompatible architecture
will fail with -mtune=native anyway.
Signed-off-by: David Michael
---
Hi,
I am building software in a ChromeOS-style environment where the native
build system creates a cross-compiler with a different vendor string for
each supported architecture, and cross-compiled packages are installed
into their own root directory. The build system's architecture is not
handled any differently, so packages compatible with the native
architecture are still technically being cross-compiled.
When I changed settings to tune for the native CPU so I can produce an
installation optimized to run on the build system hardware, FFmpeg fails
from this seemingly redundant test. Can it just be dropped?
Thanks.
David
configure | 3 ---
1 file changed, 3 deletions(-)
diff --git a/configure b/configure
index 06e3a7b2a8..69ffdeb3ed 100755
--- a/configure
+++ b/configure
@@ -4785,9 +4785,6 @@ if test -n "$sysroot"; then
fi
if test "$cpu" = host; then
-enabled cross_compile &&
-die "--cpu=host makes no sense when cross-compiling."
-
case "$cc_type" in
gcc|llvm_gcc)
check_native(){
--
2.21.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] avcodec/wavpack: add DSD support
Hi,
My patch from last July to add WavPack DSD support was rejected because I
created another codec ID for WavPack DSD audio and
duplicated some existing WavPack code.
This patch simply adds the DSD support to the existing wavpack.c file. As
suggested, I now use ff_thread_report/await_progress()
to keep the final dsd2pcm operation serialized between frame threads, and I
also put in slice threading for that because the
channels can be independently converted.
This has been tested extensively on both X64 and ARM and appears quite stable.
I have also tested it on various sanitizers and
valgrind. Also, essentially the same DSD decoder has been extensively fuzzed on
OSS-Fuzz because WavPack is also part of that
project now.
Kind regards,
David
From 5d033a4628bdaa13694c5df88b185e7b099bfea5 Mon Sep 17 00:00:00 2001
From: David Bryant
Date: Mon, 9 Mar 2020 15:23:53 -0700
Subject: [PATCH] avcodec/wavpack: add support for DSD files
Add support for WavPack DSD files to the existing WavPack decoder using
avcodec/dsd to perform the 8:1 decimation to 32-bit float samples. We must
serialize the dsd2pcm operation (cross-boundary filtering) but would like
to use frame-level multithreading for the CPU-intensive DSD decompression,
and this is accomplished with ff_thread_report/await_progress(). Because
the dsd2pcm operation is independent across channels we use slice-based
multithreading for that part.
Also a few things were removed from the existing WavPack decoder that
weren't being used (primarily the SavedContext stuff) and the WavPack
demuxer was enhanced to correctly determine the sampling rate of DSD
files (and of course to no longer reject them).
Signed-off-by: David Bryant
---
libavcodec/Makefile | 2 +-
libavcodec/wavpack.c | 692 ---
libavcodec/wavpack.h | 2 +
libavformat/wvdec.c | 28 ++-
4 files changed, 616 insertions(+), 108 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 0fd374f..a3326a4 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -693,7 +693,7 @@ OBJS-$(CONFIG_VP9_QSV_ENCODER) += qsvenc_vp9.o
OBJS-$(CONFIG_VPLAYER_DECODER) += textdec.o ass.o
OBJS-$(CONFIG_VP9_V4L2M2M_DECODER) += v4l2_m2m_dec.o
OBJS-$(CONFIG_VQA_DECODER) += vqavideo.o
-OBJS-$(CONFIG_WAVPACK_DECODER) += wavpack.o
+OBJS-$(CONFIG_WAVPACK_DECODER) += wavpack.o dsd.o
OBJS-$(CONFIG_WAVPACK_ENCODER) += wavpackenc.o
OBJS-$(CONFIG_WCMV_DECODER)+= wcmv.o
OBJS-$(CONFIG_WEBP_DECODER)+= webp.o
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index edc0f79..bb36f43 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -1,6 +1,7 @@
/*
* WavPack lossless audio decoder
* Copyright (c) 2006,2011 Konstantin Shishkov
+ * Copyright (c) 2020 David Bryant
*
* This file is part of FFmpeg.
*
@@ -29,18 +30,37 @@
#include "thread.h"
#include "unary.h"
#include "wavpack.h"
+#include "dsd.h"
/**
* @file
* WavPack lossless audio decoder
*/
-typedef struct SavedContext {
-int offset;
-int size;
-int bits_used;
-uint32_t crc;
-} SavedContext;
+#define DSD_BYTE_READY(low,high) (!(((low) ^ (high)) & 0xff00))
+
+#define PTABLE_BITS 8
+#define PTABLE_BINS (1<> 8)
@@ -365,12 +394,6 @@ static float wv_get_value_float(WavpackFrameContext *s,
uint32_t *crc, int S)
return value.f;
}
-static void wv_reset_saved_context(WavpackFrameContext *s)
-{
-s->pos= 0;
-s->sc.crc = s->extra_sc.crc = 0x;
-}
-
static inline int wv_check_crc(WavpackFrameContext *s, uint32_t crc,
uint32_t crc_extra_bits)
{
@@ -386,15 +409,372 @@ static inline int wv_check_crc(WavpackFrameContext *s,
uint32_t crc,
return 0;
}
+static void init_ptable(int *table, int rate_i, int rate_s)
+{
+int value = 0x808000, rate = rate_i << 8;
+
+for (int c = (rate + 128) >> 8; c--;)
+value += (DOWN - value) >> DECAY;
+
+for (int i = 0; i < PTABLE_BINS/2; i++) {
+table[i] = value;
+table[PTABLE_BINS-1-i] = 0x100 - value;
+
+if (value > 0x01) {
+rate += (rate * rate_s + 128) >> 8;
+
+for (int c = (rate + 64) >> 7; c--;)
+value += (DOWN - value) >> DECAY;
+}
+}
+}
+
+typedef struct {
+int32_t value, fltr0, fltr1, fltr2, fltr3, fltr4, fltr5, fltr6, factor;
+unsigned int byte;
+} DSDfilters;
+
+static int wv_unpack_dsd_high(WavpackFrameContext *s, uint8_t *dst_left,
uint8_t *dst_right)
+{
+uint32_t checksum = 0x;
+uint8_t *dst_l = dst_left, *dst_r = dst_right;
+int total_samples = s->samples, stereo = dst_r ? 1 : 0;
+DSDfilters filters[2], *sp = filters;
+int rate_i, rate_s;
+uint32_t low, high, value;
+
+if (bytestream2_get_bytes_left(&s-
[FFmpeg-devel] [PATCH] lavf/dashenc: add dash SegmentBase manifest generator
Support to generate dash SegmentBase manifests, by adding
"use_segmentbase" option to dash muxer. SegmentBase manifest
is defined in ISO DASH Specification section 5.3.9.2 and has as
prerequisite the option "global_sidx" as players will use this box
to have a reference to all fragments in the media.
---
doc/muxers.texi | 5 +
libavformat/dashenc.c | 35 ++-
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d304181671..fbaa357f2d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -309,6 +309,11 @@ escaped.
@item global_sidx @var{global_sidx}
Write global SIDX atom. Applicable only for single file, mp4 output,
non-streaming mode.
+@item use_segmentbase @var{use_segmentbase}
+Generates a dash SegmentBase manifest as defined in section 5.3.9.2 of the ISO
+DASH specification. Only applicable when global sidx is enabled since the
player
+uses it to have a reference of all the segments in the media
+
@item dash_segment_type @var{dash_segment_type}
Possible values:
@table @option
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 94d463972a..e8b418e74c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -193,6 +193,8 @@ typedef struct DASHContext {
int profile;
int64_t target_latency;
int target_latency_refid;
+int use_segmentbase;
+int64_t sidx_size;
} DASHContext;
static struct codec_string {
@@ -696,16 +698,23 @@ static void output_segment_list(OutputStream *os,
AVIOContext *out, AVFormatCont
avio_printf(out, "\t\t\t\t\n");
} else if (c->single_file) {
avio_printf(out, "\t\t\t\t%s\n", os->initfile);
-avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
-avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, os->init_start_pos +
os->init_range_length - 1);
-for (i = start_index; i < os->nb_segments; i++) {
-Segment *seg = os->segments[i];
-avio_printf(out, "\t\t\t\t\tstart_pos, seg->start_pos +
seg->range_length - 1);
-if (seg->index_length)
-avio_printf(out, "indexRange=\"%"PRId64"-%"PRId64"\" ",
seg->start_pos, seg->start_pos + seg->index_length - 1);
-avio_printf(out, "/>\n");
+int64_t init_segment_size = os->init_start_pos + os->init_range_length;
+if (c->use_segmentbase && final) {
+avio_printf(out, "\t\t\t\t\n", init_segment_size - c->sidx_size, init_segment_size - 1,
AV_TIME_BASE);
+avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, init_segment_size -
c->sidx_size - 1);
+avio_printf(out, "\t\t\t\t\n");
+} else {
+avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
+avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, init_segment_size - 1);
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+avio_printf(out, "\t\t\t\t\tstart_pos, seg->start_pos +
seg->range_length - 1);
+if (seg->index_length)
+avio_printf(out, "indexRange=\"%"PRId64"-%"PRId64"\" ",
seg->start_pos, seg->start_pos + seg->index_length - 1);
+avio_printf(out, "/>\n");
+}
+avio_printf(out, "\t\t\t\t\n");
}
-avio_printf(out, "\t\t\t\t\n");
} else {
avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
avio_printf(out, "\t\t\t\t\t\n",
os->initfile);
@@ -1389,6 +1398,12 @@ static int dash_init(AVFormatContext *s)
av_log(s, AV_LOG_WARNING, "Global SIDX option will be ignored as
streaming is enabled\n");
c->global_sidx = 0;
}
+
+if (c->use_segmentbase && !c->global_sidx) {
+av_log(s, AV_LOG_WARNING, "SegmentBase manifest signaling option will
be ignored as global SIDX is not enabled\n");
+c->use_segmentbase = 0;
+}
+
if (c->frag_type == FRAG_TYPE_NONE && c->streaming) {
av_log(s, AV_LOG_VERBOSE, "Changing frag_type from none to every_frame
as streaming is enabled\n");
c->frag_type = FRAG_TYPE_EVERY_FRAME;
@@ -1981,6 +1996,7 @@ static int dash_flush(AVFormatContext *s, int final, int
stream)
if (c->global_sidx) {
int j, start_index, start_number;
int64_t sidx_size = avio_tell(os->ctx->pb) - file_size;
+c->sidx_size = sidx_size;
get_start_index_number(os, c, &start_index, &start_number);
if (start_index >= os->nb_segments ||
os->segment_type != SEGMENT_TYPE_MP4)
@@ -2350,6 +2366,7 @@ static const AVOption options[] = {
{ "index_correction", "Enable/Disable segment index correction logic",
OFFSET(index_correction), AV_OPT_T
[FFmpeg-devel] [PATCH] lavf/dashenc: add dash SegmentBase manifest generator
Support to generate dash SegmentBase manifests, by adding
"use_segmentbase" option to dash muxer. SegmentBase manifest
is defined in ISO DASH Specification section 5.3.9.2 and has as
prerequisite the option "global_sidx" as players will use this box
to have a reference to all fragments in the media.
---
doc/muxers.texi | 5 +
libavformat/dashenc.c | 35 ++-
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d304181671..fbaa357f2d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -309,6 +309,11 @@ escaped.
@item global_sidx @var{global_sidx}
Write global SIDX atom. Applicable only for single file, mp4 output,
non-streaming mode.
+@item use_segmentbase @var{use_segmentbase}
+Generates a dash SegmentBase manifest as defined in section 5.3.9.2 of the ISO
+DASH specification. Only applicable when global sidx is enabled since the
player
+uses it to have a reference of all the segments in the media
+
@item dash_segment_type @var{dash_segment_type}
Possible values:
@table @option
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 94d463972a..e8b418e74c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -193,6 +193,8 @@ typedef struct DASHContext {
int profile;
int64_t target_latency;
int target_latency_refid;
+int use_segmentbase;
+int64_t sidx_size;
} DASHContext;
static struct codec_string {
@@ -696,16 +698,23 @@ static void output_segment_list(OutputStream *os,
AVIOContext *out, AVFormatCont
avio_printf(out, "\t\t\t\t\n");
} else if (c->single_file) {
avio_printf(out, "\t\t\t\t%s\n", os->initfile);
-avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
-avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, os->init_start_pos +
os->init_range_length - 1);
-for (i = start_index; i < os->nb_segments; i++) {
-Segment *seg = os->segments[i];
-avio_printf(out, "\t\t\t\t\tstart_pos, seg->start_pos +
seg->range_length - 1);
-if (seg->index_length)
-avio_printf(out, "indexRange=\"%"PRId64"-%"PRId64"\" ",
seg->start_pos, seg->start_pos + seg->index_length - 1);
-avio_printf(out, "/>\n");
+int64_t init_segment_size = os->init_start_pos + os->init_range_length;
+if (c->use_segmentbase && final) {
+avio_printf(out, "\t\t\t\t\n", init_segment_size - c->sidx_size, init_segment_size - 1,
AV_TIME_BASE);
+avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, init_segment_size -
c->sidx_size - 1);
+avio_printf(out, "\t\t\t\t\n");
+} else {
+avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
+avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, init_segment_size - 1);
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+avio_printf(out, "\t\t\t\t\tstart_pos, seg->start_pos +
seg->range_length - 1);
+if (seg->index_length)
+avio_printf(out, "indexRange=\"%"PRId64"-%"PRId64"\" ",
seg->start_pos, seg->start_pos + seg->index_length - 1);
+avio_printf(out, "/>\n");
+}
+avio_printf(out, "\t\t\t\t\n");
}
-avio_printf(out, "\t\t\t\t\n");
} else {
avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
avio_printf(out, "\t\t\t\t\t\n",
os->initfile);
@@ -1389,6 +1398,12 @@ static int dash_init(AVFormatContext *s)
av_log(s, AV_LOG_WARNING, "Global SIDX option will be ignored as
streaming is enabled\n");
c->global_sidx = 0;
}
+
+if (c->use_segmentbase && !c->global_sidx) {
+av_log(s, AV_LOG_WARNING, "SegmentBase manifest signaling option will
be ignored as global SIDX is not enabled\n");
+c->use_segmentbase = 0;
+}
+
if (c->frag_type == FRAG_TYPE_NONE && c->streaming) {
av_log(s, AV_LOG_VERBOSE, "Changing frag_type from none to every_frame
as streaming is enabled\n");
c->frag_type = FRAG_TYPE_EVERY_FRAME;
@@ -1981,6 +1996,7 @@ static int dash_flush(AVFormatContext *s, int final, int
stream)
if (c->global_sidx) {
int j, start_index, start_number;
int64_t sidx_size = avio_tell(os->ctx->pb) - file_size;
+c->sidx_size = sidx_size;
get_start_index_number(os, c, &start_index, &start_number);
if (start_index >= os->nb_segments ||
os->segment_type != SEGMENT_TYPE_MP4)
@@ -2350,6 +2366,7 @@ static const AVOption options[] = {
{ "index_correction", "Enable/Disable segment index correction logic",
OFFSET(index_correction), AV_OPT_T
[FFmpeg-devel] [PATCH v2] lavf/dashenc: add dash SegmentBase manifest generator
Support to generate dash SegmentBase manifests, by adding
"use_segmentbase" option to dash muxer. SegmentBase manifest
is defined in ISO DASH Specification section 5.3.9.2 and has as
prerequisite the option "global_sidx" as players will use this
box to have a reference to all fragments in the media.
Signed-off-by: David Martin
---
doc/muxers.texi | 5 +
libavformat/dashenc.c | 16
2 files changed, 21 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d304181671..fbaa357f2d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -309,6 +309,11 @@ escaped.
@item global_sidx @var{global_sidx}
Write global SIDX atom. Applicable only for single file, mp4 output,
non-streaming mode.
+@item use_segmentbase @var{use_segmentbase}
+Generates a dash SegmentBase manifest as defined in section 5.3.9.2 of the ISO
+DASH specification. Only applicable when global sidx is enabled since the
player
+uses it to have a reference of all the segments in the media
+
@item dash_segment_type @var{dash_segment_type}
Possible values:
@table @option
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 94d463972a..39286e9e11 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -193,6 +193,8 @@ typedef struct DASHContext {
int profile;
int64_t target_latency;
int target_latency_refid;
+int use_segmentbase;
+int64_t sidx_size;
} DASHContext;
static struct codec_string {
@@ -694,6 +696,12 @@ static void output_segment_list(OutputStream *os,
AVIOContext *out, AVFormatCont
avio_printf(out, "\t\t\t\t\t\n");
}
avio_printf(out, "\t\t\t\t\n");
+} else if (c->single_file && c->use_segmentbase && final) {
+avio_printf(out, "\t\t\t\t%s\n", os->initfile);
+int64_t init_segment_size = os->init_start_pos + os->init_range_length;
+avio_printf(out, "\t\t\t\t\n", init_segment_size -
c->sidx_size, init_segment_size - 1, AV_TIME_BASE);
+avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, init_segment_size -
c->sidx_size - 1);
+avio_printf(out, "\t\t\t\t\n");
} else if (c->single_file) {
avio_printf(out, "\t\t\t\t%s\n", os->initfile);
avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
@@ -1389,6 +1397,12 @@ static int dash_init(AVFormatContext *s)
av_log(s, AV_LOG_WARNING, "Global SIDX option will be ignored as
streaming is enabled\n");
c->global_sidx = 0;
}
+
+if (c->use_segmentbase && !c->global_sidx) {
+av_log(s, AV_LOG_WARNING, "SegmentBase manifest signaling option will
be ignored as global SIDX is not enabled\n");
+c->use_segmentbase = 0;
+}
+
if (c->frag_type == FRAG_TYPE_NONE && c->streaming) {
av_log(s, AV_LOG_VERBOSE, "Changing frag_type from none to every_frame
as streaming is enabled\n");
c->frag_type = FRAG_TYPE_EVERY_FRAME;
@@ -1981,6 +1995,7 @@ static int dash_flush(AVFormatContext *s, int final, int
stream)
if (c->global_sidx) {
int j, start_index, start_number;
int64_t sidx_size = avio_tell(os->ctx->pb) - file_size;
+c->sidx_size = sidx_size;
get_start_index_number(os, c, &start_index, &start_number);
if (start_index >= os->nb_segments ||
os->segment_type != SEGMENT_TYPE_MP4)
@@ -2350,6 +2365,7 @@ static const AVOption options[] = {
{ "index_correction", "Enable/Disable segment index correction logic",
OFFSET(index_correction), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
{ "format_options","set list of options for the container format
(mp4/webm) used for dash", OFFSET(format_options), AV_OPT_TYPE_DICT, {.str =
NULL}, 0, 0, E},
{ "global_sidx", "Write global SIDX atom. Applicable only for single file,
mp4 output, non-streaming mode", OFFSET(global_sidx), AV_OPT_TYPE_BOOL, { .i64
= 0 }, 0, 1, E },
+{ "use_segmentbase", "Use SegmentBase in Representation",
OFFSET(use_segmentbase), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
{ "dash_segment_type", "set dash segment files type",
OFFSET(segment_type_option), AV_OPT_TYPE_INT, {.i64 = SEGMENT_TYPE_AUTO }, 0,
SEGMENT_TYPE_NB - 1, E, "segment_type"},
{ "auto", "select segment file format based on codec", 0,
AV_OPT_TYPE_CONST, {.i64 = SEGMENT_TYPE_AUTO }, 0, UINT_MAX, E,
"segment_type"},
{ "mp4", "make segment file in ISOBMFF format", 0, AV_OPT_TYPE_CONST,
{.i64 = SEGMENT_TYPE_MP4 }, 0, UINT_MAX, E, "segment_type"},
--
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] configure: Do not abort when cross-compiling to the native CPU
On Sat, Mar 7, 2020 at 10:32 AM David Michael wrote:
> Using a compiler with a different host triplet is considered
> cross-compiling, even when it is for the same architecture as the
> build system. With such a cross-compiler, it is still valid to
> optimize builds with --cpu=host. Drop the condition that aborts in
> this case, since a cross-compiler for an incompatible architecture
> will fail with -mtune=native anyway.
>
> Signed-off-by: David Michael
> ---
>
> Hi,
>
> I am building software in a ChromeOS-style environment where the native
> build system creates a cross-compiler with a different vendor string for
> each supported architecture, and cross-compiled packages are installed
> into their own root directory. The build system's architecture is not
> handled any differently, so packages compatible with the native
> architecture are still technically being cross-compiled.
>
> When I changed settings to tune for the native CPU so I can produce an
> installation optimized to run on the build system hardware, FFmpeg fails
> from this seemingly redundant test. Can it just be dropped?
>
> Thanks.
>
> David
>
> configure | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/configure b/configure
> index 06e3a7b2a8..69ffdeb3ed 100755
> --- a/configure
> +++ b/configure
> @@ -4785,9 +4785,6 @@ if test -n "$sysroot"; then
> fi
>
> if test "$cpu" = host; then
> -enabled cross_compile &&
> -die "--cpu=host makes no sense when cross-compiling."
> -
> case "$cc_type" in
> gcc|llvm_gcc)
> check_native(){
> --
> 2.21.1
Ping.
___
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 2/2] avcodec/wavpack: Prevent frame format from being wrong
On 3/20/20 1:54 AM, Paul B Mahol wrote: > lgtm Looks good to me too, sorry about that! > > On 3/20/20, Michael Niedermayer wrote: >> Fixes: out of array access >> Fixes: >> 21193/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5125168956702720 >> >> Found-by: continuous fuzzing process >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> Signed-off-by: Michael Niedermayer >> --- >> libavcodec/wavpack.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c >> index b27262b94e..e9c870e41e 100644 >> --- a/libavcodec/wavpack.c >> +++ b/libavcodec/wavpack.c >> @@ -1488,6 +1488,7 @@ static int wavpack_decode_block(AVCodecContext *avctx, >> int block_no, >> >> /* get output buffer */ >> wc->curr_frame.f->nb_samples = s->samples; >> +wc->curr_frame.f->format = avctx->sample_fmt; >> if ((ret = ff_thread_get_buffer(avctx, &wc->curr_frame, >> AV_GET_BUFFER_FLAG_REF)) < 0) >> return ret; >> >> -- >> 2.17.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 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] configure: Do not abort when cross-compiling to the native CPU
On Mon, Mar 16, 2020 at 9:16 AM David Michael wrote:
> On Sat, Mar 7, 2020 at 10:32 AM David Michael wrote:
> > Using a compiler with a different host triplet is considered
> > cross-compiling, even when it is for the same architecture as the
> > build system. With such a cross-compiler, it is still valid to
> > optimize builds with --cpu=host. Drop the condition that aborts in
> > this case, since a cross-compiler for an incompatible architecture
> > will fail with -mtune=native anyway.
> >
> > Signed-off-by: David Michael
> > ---
> >
> > Hi,
> >
> > I am building software in a ChromeOS-style environment where the native
> > build system creates a cross-compiler with a different vendor string for
> > each supported architecture, and cross-compiled packages are installed
> > into their own root directory. The build system's architecture is not
> > handled any differently, so packages compatible with the native
> > architecture are still technically being cross-compiled.
> >
> > When I changed settings to tune for the native CPU so I can produce an
> > installation optimized to run on the build system hardware, FFmpeg fails
> > from this seemingly redundant test. Can it just be dropped?
> >
> > Thanks.
> >
> > David
> >
> > configure | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/configure b/configure
> > index 06e3a7b2a8..69ffdeb3ed 100755
> > --- a/configure
> > +++ b/configure
> > @@ -4785,9 +4785,6 @@ if test -n "$sysroot"; then
> > fi
> >
> > if test "$cpu" = host; then
> > -enabled cross_compile &&
> > -die "--cpu=host makes no sense when cross-compiling."
> > -
> > case "$cc_type" in
> > gcc|llvm_gcc)
> > check_native(){
> > --
> > 2.21.1
>
> Ping.
Ping.
___
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 2/2] avcodec/wavpack: Prevent frame format from being wrong
On 3/23/20 9:49 AM, Anton Khirnov wrote: > Quoting Michael Niedermayer (2020-03-20 21:50:18) >> On Fri, Mar 20, 2020 at 10:18:49AM +0100, Anton Khirnov wrote: >>> Quoting Michael Niedermayer (2020-03-20 01:03:36) Fixes: out of array access Fixes: 21193/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5125168956702720 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/wavpack.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c index b27262b94e..e9c870e41e 100644 --- a/libavcodec/wavpack.c +++ b/libavcodec/wavpack.c @@ -1488,6 +1488,7 @@ static int wavpack_decode_block(AVCodecContext *avctx, int block_no, /* get output buffer */ wc->curr_frame.f->nb_samples = s->samples; +wc->curr_frame.f->format = avctx->sample_fmt; >>> How does this have any effect? curr_frame.f should now be clean and get >>> initialized from avctx->sample_fmt. >> IIRC >> The format changes between frames, so the struct is still set to the one >> from the previous frame and that overrides the use of the avctx value >> >> setting it to NONE (here or somewhere else) should work too. > ff_thread_release_buffer() is called on that frame immediately before, > which should reset it to defaults (setting format to FMT_NONE). > I don't think the format should change between frames, so I don't understand how the format is getting set to a wacky value. Would it be possible for me the get the triggering test case and try this myself? I searched and couldn't find it, so I assume it's not public yet. I assume that just decoding the file should trigger the assertion, right? Thanks! ___ 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/14] pthread_frame: merge the functionality for normal decoder init and init_thread_copy
On 3/27/20 5:57 AM, Anton Khirnov wrote: > The current design, where > - proper init is called for the first per-thread context > - first thread's private data is copied into private data for all the > other threads > - a "fixup" function is called for all the other threads to e.g. > allocate dynamically allocated data > is very fragile and hard to follow, so it is abandoned. Instead, the > same init function is used to init each per-thread context. Where > necessary, AVCodecInternal.is_copy can be used to differentiate between > the first thread and the other ones (e.g. for decoding the extradata > just once). > --- I'm not sure I fully understand this change. You mention that AVCodecInternal.is_copy can be used where different treatment might be necessary for subsequent threads, and I see that done in a couple places, but in most cases you have simply deleted the init_thread_copy() function even when it's not at all obvious (to me anyway) that that won't break the codec. Specifically this will break WavPack because now it will be allocating a new dsdctx for every thread instead of sharing one between all threads. I am happy to fix and test this case once the patch goes in, but is the intent of this patch that the respective authors will find and fix all the breakages? Or did I just happen to catch the one case you missed? Cheers! -David ___ 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/14] pthread_frame: merge the functionality for normal decoder init and init_thread_copy
On 3/28/20 6:23 AM, Anton Khirnov wrote: > Quoting David Bryant (2020-03-27 23:51:19) >> On 3/27/20 5:57 AM, Anton Khirnov wrote: >>> The current design, where >>> - proper init is called for the first per-thread context >>> - first thread's private data is copied into private data for all the >>> other threads >>> - a "fixup" function is called for all the other threads to e.g. >>> allocate dynamically allocated data >>> is very fragile and hard to follow, so it is abandoned. Instead, the >>> same init function is used to init each per-thread context. Where >>> necessary, AVCodecInternal.is_copy can be used to differentiate between >>> the first thread and the other ones (e.g. for decoding the extradata >>> just once). >>> --- >> I'm not sure I fully understand this change. You mention that >> AVCodecInternal.is_copy can be used where different treatment >> might be necessary for subsequent threads, and I see that done in a couple >> places, but in most cases you have simply deleted the >> init_thread_copy() function even when it's not at all obvious (to me anyway) >> that that won't break the codec. > In most cases, just deleting init_thread_copy() is the right thing to > do. E.g. all decoders that do not implement update_thread_context() have > to be intra-only, so every frame thread is effectively a completely > standalone decoder. And in most of the more complex decoders (like h264) > the important parameters are dynamically changeable during decoding, so > not that much is done in decoder init beyond allocating some stuff that > does not depend on the bistream properties. > > My intent is for each frame-thread worker to be treated inasmuch as > possible as a standalone decoder, and where it has to share data with > other threads to make this sharing explicit (rather than implicit as is > the case now). Yes, this makes sense. The confusing part is when the decode_init() function looks completely different than the init_thread_copy() function. This is often because the decode_init() function is generating things (tables, etc.) from scratch and the init_thread_copy() is just copying the necessary things from the original. In cases where the original generation might be time consuming this might make sense, but usually it's probably just making the code more complex and difficult to follow (which I believe was your original point). One possible interim solution for complex cases that break would be to leave the init_thread_copy() function there, but instead of having it in the AVCodec struct and called from outside (which is no longer possible), it simply gets called first thing from decode_init() if AVCodecInternal.is_copy is set. That way the architecture is cleaned up now, and the codec won't break and can be cleaned up when time permits. Just a thought. > >> Specifically this will break WavPack because now it will be allocating a new >> dsdctx for every thread instead of sharing one >> between all threads. I am happy to fix and test this case once the patch >> goes in, but is the intent of this patch that the >> respective authors will find and fix all the breakages? Or did I just happen >> to catch the one case you missed? > I certainly intended to convert the decoders correctly myself, > apparently I didn't pay enough attention to the recent wavpack changes. > Hopefully the other conversions are correct, but I will go through the > changes again to check. > > Looking at wavpack, the code looks suspicious to me. You allocate one > dsdctx per channel at init, but AFAIU the number of channels can change > at each frame. > Multichannel WavPack consists of sequences of stereo or mono WavPack blocks that include flags indicating whether they are the beginning or end of a "frame" or "packet". This allows the number of channels available to be essentially unlimited, however the total number of channels in a stream may not change. When decoding, if a sequence of blocks generates more or less than the correct number of channels, this is flagged as an error and overrun is prevented (see libavcodec/wavpack.c, line 1499 and line 1621). If you are curious, the WavPack format is described in detail here: https://github.com/dbry/WavPack/blob/master/doc/WavPack5FileFormat.pdf Thanks! -David ___ 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] configure: Do not abort when cross-compiling to the native CPU
On Sun, Mar 22, 2020 at 11:01 PM David Michael wrote:
> On Mon, Mar 16, 2020 at 9:16 AM David Michael wrote:
> > On Sat, Mar 7, 2020 at 10:32 AM David Michael wrote:
> > > Using a compiler with a different host triplet is considered
> > > cross-compiling, even when it is for the same architecture as the
> > > build system. With such a cross-compiler, it is still valid to
> > > optimize builds with --cpu=host. Drop the condition that aborts in
> > > this case, since a cross-compiler for an incompatible architecture
> > > will fail with -mtune=native anyway.
> > >
> > > Signed-off-by: David Michael
> > > ---
> > >
> > > Hi,
> > >
> > > I am building software in a ChromeOS-style environment where the native
> > > build system creates a cross-compiler with a different vendor string for
> > > each supported architecture, and cross-compiled packages are installed
> > > into their own root directory. The build system's architecture is not
> > > handled any differently, so packages compatible with the native
> > > architecture are still technically being cross-compiled.
> > >
> > > When I changed settings to tune for the native CPU so I can produce an
> > > installation optimized to run on the build system hardware, FFmpeg fails
> > > from this seemingly redundant test. Can it just be dropped?
> > >
> > > Thanks.
> > >
> > > David
> > >
> > > configure | 3 ---
> > > 1 file changed, 3 deletions(-)
> > >
> > > diff --git a/configure b/configure
> > > index 06e3a7b2a8..69ffdeb3ed 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -4785,9 +4785,6 @@ if test -n "$sysroot"; then
> > > fi
> > >
> > > if test "$cpu" = host; then
> > > -enabled cross_compile &&
> > > -die "--cpu=host makes no sense when cross-compiling."
> > > -
> > > case "$cc_type" in
> > > gcc|llvm_gcc)
> > > check_native(){
> > > --
> > > 2.21.1
> >
> > Ping.
>
> Ping.
Ping.
___
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] configure: Do not abort when cross-compiling to the native CPU
On Mon, Mar 30, 2020 at 1:00 PM Derek Buitenhuis wrote: > On 07/03/2020 15:32, David Michael wrote: > > Using a compiler with a different host triplet is considered > > cross-compiling, even when it is for the same architecture as the > > build system. With such a cross-compiler, it is still valid to > > optimize builds with --cpu=host. Drop the condition that aborts in > > this case, since a cross-compiler for an incompatible architecture > > will fail with -mtune=native anyway. > > Is there a reason you would set the cross-prefix instead of just the --cc, > etc. > when compiling natively? I want everything to use the cross-prefixed versions since those tools are configured to build software in a sysroot using a different set of compiler features than software in the minimal build root. I am using the same process as when cross-compiling OS images for other incompatible architectures; configuring tuning for the build system's CPU is just another valid use of this setup. Thanks. David ___ 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 v2] configure: Do not abort when cross-compiling to the native CPU
Using a compiler with a different host triplet is considered cross-compiling, even when it is for the same architecture as the build system. With such a cross-compiler, it is still valid to optimize builds with --cpu=host. Make the condition that aborts in this case into a warning instead, since a cross-compiler for an incompatible architecture will fail with -mtune=native anyway. Signed-off-by: David Michael --- Changes since v1: * Use a warning instead of dropping the condition altogether configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 21827eeb45..251b6a977a 100755 --- a/configure +++ b/configure @@ -4797,7 +4797,7 @@ fi if test "$cpu" = host; then enabled cross_compile && -die "--cpu=host makes no sense when cross-compiling." +warn "--cpu=host makes no sense when cross-compiling." case "$cc_type" in gcc|llvm_gcc) -- 2.21.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 1/3] avformat/matroskadec: Add a workaround for missing WavPack extradata
On 4/1/20 12:53 AM, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
>> mkvmerge versions 6.2 to 40.0 had a bug that made it not propagate the
>> WavPack extradata (containing the WavPack version) during remuxing from
>> a Matroska file; currently our demuxer would treat every WavPack block
>> encountered as invalid data (unless the WavPack stream is to be
>> discarded (i.e. the streams discard is >= AVDISCARD_ALL)) and try to
>> resync to the next level 1 element.
>>
>> Luckily, the WavPack version is currently not really important; so we
>> fix this problem by assuming a version. David Bryant, the creator of
>> WavPack, recommended using version 0x410 (the most recent version) for
>> this. And this is what this commit does.
>>
>> A FATE-test for this has been added.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> James has already uploaded the sample. Thanks for this.
>>
>> libavformat/matroskadec.c| 11 ++-
>> tests/fate/matroska.mak | 5 +
>> tests/ref/fate/matroska-wavpack-missing-codecprivate | 9 +
>> 3 files changed, 24 insertions(+), 1 deletion(-)
>> create mode 100644 tests/ref/fate/matroska-wavpack-missing-codecprivate
>>
>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> index 4d7fdab99f..5b55606b98 100644
>> --- a/libavformat/matroskadec.c
>> +++ b/libavformat/matroskadec.c
>> @@ -2613,6 +2613,14 @@ static int matroska_parse_tracks(AVFormatContext *s)
>> ret = matroska_parse_flac(s, track, &extradata_offset);
>> if (ret < 0)
>> return ret;
>> +} else if (codec_id == AV_CODEC_ID_WAVPACK &&
>> track->codec_priv.size < 2) {
>> +av_log(matroska->ctx, AV_LOG_INFO, "Assuming WavPack version
>> 4.10 "
>> + "in absence of valid CodecPrivate.\n");
>> +extradata_size = 2;
>> +extradata = av_mallocz(2 + AV_INPUT_BUFFER_PADDING_SIZE);
>> +if (!extradata)
>> +return AVERROR(ENOMEM);
>> +AV_WL16(extradata, 0x410);
>> } else if (codec_id == AV_CODEC_ID_PRORES && track->codec_priv.size
>> == 4) {
>> fourcc = AV_RL32(track->codec_priv.data);
>> } else if (codec_id == AV_CODEC_ID_VP9 && track->codec_priv.size) {
>> @@ -3165,9 +3173,10 @@ static int matroska_parse_wavpack(MatroskaTrack
>> *track, uint8_t *src,
>> uint16_t ver;
>> int ret, offset = 0;
>>
>> -if (srclen < 12 || track->stream->codecpar->extradata_size < 2)
>> +if (srclen < 12)
>> return AVERROR_INVALIDDATA;
>>
>> +av_assert1(track->stream->codecpar->extradata_size >= 2);
>> ver = AV_RL16(track->stream->codecpar->extradata);
>>
>> samples = AV_RL32(src);
>> diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak
>> index b9ed7322fd..93b5bff89a 100644
>> --- a/tests/fate/matroska.mak
>> +++ b/tests/fate/matroska.mak
>> @@ -17,6 +17,11 @@ fate-matroska-remux: REF =
>> 49a60ef91cf7302ab7276f9373f8a429
>> FATE_MATROSKA-$(call ALLYES, MATROSKA_DEMUXER VORBIS_PARSER) +=
>> fate-matroska-xiph-lacing
>> fate-matroska-xiph-lacing: CMD = framecrc -i
>> $(TARGET_SAMPLES)/mkv/xiph_lacing.mka -c:a copy
>>
>> +# This tests that the Matroska demuxer correctly demuxes WavPack
>> +# without CodecPrivate; it also tests zlib compressed WavPack.
>> +FATE_MATROSKA-$(call ALLYES, MATROSKA_DEMUXER ZLIB) +=
>> fate-matroska-wavpack-missing-codecprivate
>> +fate-matroska-wavpack-missing-codecprivate: CMD = framecrc -i
>> $(TARGET_SAMPLES)/mkv/wavpack_missing_codecprivate.mka -c copy
>> +
>> # This tests that the matroska demuxer supports decompressing
>> # zlib compressed tracks (both the CodecPrivate as well as the actual
>> frames).
>> FATE_MATROSKA-$(call ALLYES, MATROSKA_DEMUXER ZLIB) +=
>> fate-matroska-zlib-decompression
>> diff --git a/tests/ref/fate/matroska-wavpack-missing-codecprivate
>> b/tests/ref/fate/matroska-wavpack-missing-codecprivate
>> new file mode 100644
>> index 00..4645a86ff6
>> --- /dev/null
>> +++ b/tests/ref/fate/matroska-wavpack-missing-codecprivate
>> @@ -0,0 +1,9 @@
>> +#extradata 0:2, 0x00240014
>> +#tb 0: 11337/5
>> +#media_type 0: audio
>> +#codec_id 0: wavpack
>> +#sample_rate 0: 44100
>> +#channel_layout 0: 3
>> +#channel_layout_name 0: stereo
>> +0, 0, 0,22051,14778, 0x02819286
>> +0, 22051, 22051,22052,14756, 0x21976243
>>
> Any comments on this patchset? If not, I'd like to apply it tomorrow.
This looks good to me. Thanks!
-David
___
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/14] pthread_frame: merge the functionality for normal decoder init and init_thread_copy
On 3/31/20 2:47 AM, Anton Khirnov wrote: > Quoting David Bryant (2020-03-28 21:22:40) >> On 3/28/20 6:23 AM, Anton Khirnov wrote: >>> Quoting David Bryant (2020-03-27 23:51:19) >>>> On 3/27/20 5:57 AM, Anton Khirnov wrote: >>>>> The current design, where >>>>> - proper init is called for the first per-thread context >>>>> - first thread's private data is copied into private data for all the >>>>> other threads >>>>> - a "fixup" function is called for all the other threads to e.g. >>>>> allocate dynamically allocated data >>>>> is very fragile and hard to follow, so it is abandoned. Instead, the >>>>> same init function is used to init each per-thread context. Where >>>>> necessary, AVCodecInternal.is_copy can be used to differentiate between >>>>> the first thread and the other ones (e.g. for decoding the extradata >>>>> just once). >>>>> --- >>>> I'm not sure I fully understand this change. You mention that >>>> AVCodecInternal.is_copy can be used where different treatment >>>> might be necessary for subsequent threads, and I see that done in a couple >>>> places, but in most cases you have simply deleted the >>>> init_thread_copy() function even when it's not at all obvious (to me >>>> anyway) that that won't break the codec. >>> In most cases, just deleting init_thread_copy() is the right thing to >>> do. E.g. all decoders that do not implement update_thread_context() have >>> to be intra-only, so every frame thread is effectively a completely >>> standalone decoder. And in most of the more complex decoders (like h264) >>> the important parameters are dynamically changeable during decoding, so >>> not that much is done in decoder init beyond allocating some stuff that >>> does not depend on the bistream properties. >>> >>> My intent is for each frame-thread worker to be treated inasmuch as >>> possible as a standalone decoder, and where it has to share data with >>> other threads to make this sharing explicit (rather than implicit as is >>> the case now). >> Yes, this makes sense. The confusing part is when the decode_init() function >> looks completely different than the >> init_thread_copy() function. This is often because the decode_init() >> function is generating things (tables, etc.) from scratch >> and the init_thread_copy() is just copying the necessary things from the >> original. In cases where the original generation might >> be time consuming this might make sense, but usually it's probably just >> making the code more complex and difficult to follow >> (which I believe was your original point). > Yes, precisely. I believe for obscure codecs it's better to waste a > little memory when doing threaded decoding, in return for simpler code. > And if people really care about being as memory-efficient as possible > then doing explicit refcounting on allocated buffers is still possible. > >> One possible interim solution for complex cases that break would be to leave >> the init_thread_copy() function there, but instead >> of having it in the AVCodec struct and called from outside (which is no >> longer possible), it simply gets called first thing from >> decode_init() if AVCodecInternal.is_copy is set. That way the architecture >> is cleaned up now, and the codec won't break and can >> be cleaned up when time permits. Just a thought. > I don't really see much point in any interim solutions, since no codecs > should break. You found a problem with wavpack, that's going to be fixed > in the next iteration of this patch. > Speaking of which, ideally we should have a FATE test for DSD files so > that I would have found the failure myself when running test. I have created a WavPack DSD test file that exercises all three of the DSD modes (fast, high, and copy). I have also verified that it would have caught this change, although I had to specify fate multithreading once I discovered it wasn't the default. If someone can add this to the fate suite (in the wavpack/lossless folder) then I can supply a patch to add the test: file: http://www.wavpack.com/dsd.wv (MD5: 74b2181f3e9829d9a5b98edd037984ac) decoded MD5 (f32le): a3a88bba95f809025dce01ecb9064091 >>>> Specifically this will break WavPack because now it will be allocating a >>>> new dsdctx for every thread instead of sharing one >>>> between all threads. I am happy to fix and test this case once the patch >>>> goes i
Re: [FFmpeg-devel] [PATCH v2] configure: Do not abort when cross-compiling to the native CPU
On Thu, Apr 2, 2020 at 5:38 PM Michael Niedermayer wrote: > On Wed, Apr 01, 2020 at 12:07:55AM -0400, David Michael wrote: > > Using a compiler with a different host triplet is considered > > cross-compiling, even when it is for the same architecture as the > > build system. With such a cross-compiler, it is still valid to > > optimize builds with --cpu=host. Make the condition that aborts in > > this case into a warning instead, since a cross-compiler for an > > incompatible architecture will fail with -mtune=native anyway. > > > > Signed-off-by: David Michael > > --- > > > > Changes since v1: > > * Use a warning instead of dropping the condition altogether > > > > configure | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > will apply Thanks! ___ 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/14] pthread_frame: merge the functionality for normal decoder init and init_thread_copy
On 4/2/20 2:13 AM, Anton Khirnov wrote: > Quoting David Bryant (2020-04-01 23:35:13) >> On 3/31/20 2:47 AM, Anton Khirnov wrote: >>>>> Looking at wavpack, the code looks suspicious to me. You allocate one >>>>> dsdctx per channel at init, but AFAIU the number of channels can change >>>>> at each frame. >>>>> >>>> Multichannel WavPack consists of sequences of stereo or mono WavPack >>>> blocks that include flags indicating whether they are the >>>> beginning or end of a "frame" or "packet". This allows the number of >>>> channels available to be essentially unlimited, however the >>>> total number of channels in a stream may not change. When decoding, if a >>>> sequence of blocks generates more or less than the >>>> correct number of channels, this is flagged as an error and overrun is >>>> prevented (see libavcodec/wavpack.c, line 1499 and line >>>> 1621). >>> If my reading of the code is correct, line 1499 only checks for overflow >>> of the channel count read for the current sequence. That channel count >>> is exported to AVCodeContext in the block starting on line 1464 and >>> I don't see any checks for whether it is equal to the initial one. >>> >> Full disclosure: I did not write the WavPack decoder. I understand _how_ it >> works, but I don't necessarily understand _why_ it >> was written the way it was due to gaps in my knowledge of the FFmpeg >> internals, and there are certainly things in there that >> don't look quite right to me. >> >> That said, I have tested it thoroughly and it handles everything I throw at >> it, and I have extended it to handle the DSD mode >> without anything unexpected happening. And of course it seems to handle >> extensive fuzzing, and the recent error was related to >> my DSD change, suggesting that the core it pretty robust. My inclination has >> been to not "fix" anything that wasn't broken. >> >> Yes, that channel count stuff is a little difficult to follow. I could >> experiment with streams that abruptly change channel >> configuration, but again I'm hesitant to change code that's worked so well >> so long. > I can easily get the decoder to crash even in single-threaded mode. Just > make the demuxer always say the stream is mono, then try decoding your > DSD sample. Okay, I reproduced that. However, I'm not sure it's really that serious because the demuxer and the decoder use basically the same logic to determine that number of channels, so it would be tricky to craft a file that caused the demuxer to calculate 1 channel and the decoder to reach a different result, which is probably why the fuzzers have not been able to do so. That said, it would not be hard to have the decoder save away the initial channel count from avctx, never overwrite it, and verify that all superblocks match that count. I don't know off hand whether that would break anything though. Is it guaranteed that avctx->channels is correct during the call to decode_init(), even if it's being demuxed from Matroska, for example? If so, why is the WavPack decoder _ever_ writing to the avctx channel count? > > Also, I looked at the specification PDF you linked in the previous email > and I see nothing in it that explicitly forbids the channel count from > changing from one "superblock" to the next. It seems to me like you > could just concatenate wavpack files with different channel counts and > get a valid wavpack file. > You're right, I could not find that being explicitly forbidden. Nevertheless, it _is_ forbidden for any stream parameters to change (e.g. data format, sampling rate, channel count or mapping) and both libwavpack and the FFmpeg demuxer enforce this (see libavformat/wvdec.c starting at line 211), or at least gracefully fail without crashing. The reason it's never mentioned is probably just because it never occurred to me. None of the source file formats for WavPack (e.g., wav, caf, dsdiff) allow format changes and neither do any of the other lossless compressors I am aware of. I can't imagine how that would work, and extensive fuzzing has ensured that pathological files like you suggest are unlikely to be the source of exploits. Kind regards, David ___ 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/4] wavpack: fully support stream parameter changes
On 4/5/20 1:32 PM, Anton Khirnov wrote:
> Fix invalid memory access on DSD streams with changing channel count.
> ---
> libavcodec/wavpack.c | 122 +++
> 1 file changed, 90 insertions(+), 32 deletions(-)
>
> diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
> index b27262b94e..9cc4104dd0 100644
> --- a/libavcodec/wavpack.c
> +++ b/libavcodec/wavpack.c
> @@ -20,6 +20,7 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> */
>
> +#include "libavutil/buffer.h"
> #include "libavutil/channel_layout.h"
>
> #define BITSTREAM_READER_LE
> @@ -109,7 +110,10 @@ typedef struct WavpackContext {
> AVFrame *frame;
> ThreadFrame curr_frame, prev_frame;
> Modulation modulation;
> +
> +AVBufferRef *dsd_ref;
> DSDContext *dsdctx;
> +int dsd_channels;
> } WavpackContext;
>
> #define LEVEL_DECAY(a) (((a) + 0x80) >> 8)
> @@ -978,6 +982,32 @@ static av_cold int wv_alloc_frame_context(WavpackContext
> *c)
> return 0;
> }
>
> +static int wv_dsd_reset(WavpackContext *s, int channels)
> +{
> +int i;
> +
> +s->dsdctx = NULL;
> +s->dsd_channels = 0;
> +av_buffer_unref(&s->dsd_ref);
> +
> +if (!channels)
> +return 0;
> +
> +if (channels > INT_MAX / sizeof(*s->dsdctx))
> +return AVERROR(EINVAL);
> +
> +s->dsd_ref = av_buffer_allocz(channels * sizeof(*s->dsdctx));
> +if (!s->dsd_ref)
> +return AVERROR(ENOMEM);
> +s->dsdctx = (DSDContext*)s->dsd_ref->data;
> +s->dsd_channels = channels;
> +
> +for (i = 0; i < channels; i++)
> +memset(s->dsdctx[i].buf, 0x69, sizeof(s->dsdctx[i].buf));
> +
> +return 0;
> +}
> +
> #if HAVE_THREADS
> static int init_thread_copy(AVCodecContext *avctx)
> {
> @@ -1008,6 +1038,17 @@ static int update_thread_context(AVCodecContext *dst,
> const AVCodecContext *src)
> return ret;
> }
>
> +av_buffer_unref(&fdst->dsd_ref);
> +fdst->dsdctx = NULL;
> +fdst->dsd_channels = 0;
> +if (fsrc->dsd_ref) {
> +fdst->dsd_ref = av_buffer_ref(fsrc->dsd_ref);
> +if (!fdst->dsd_ref)
> +return AVERROR(ENOMEM);
> +fdst->dsdctx = (DSDContext*)fdst->dsd_ref->data;
> +fdst->dsd_channels = fsrc->dsd_channels;
> +}
> +
> return 0;
> }
> #endif
> @@ -1025,15 +1066,9 @@ static av_cold int wavpack_decode_init(AVCodecContext
> *avctx)
> s->curr_frame.f = av_frame_alloc();
> s->prev_frame.f = av_frame_alloc();
>
> -// the DSD to PCM context is shared (and used serially) between all
> decoding threads
> -s->dsdctx = av_calloc(avctx->channels, sizeof(DSDContext));
> -
> -if (!s->curr_frame.f || !s->prev_frame.f || !s->dsdctx)
> +if (!s->curr_frame.f || !s->prev_frame.f)
> return AVERROR(ENOMEM);
>
> -for (int i = 0; i < avctx->channels; i++)
> -memset(s->dsdctx[i].buf, 0x69, sizeof(s->dsdctx[i].buf));
> -
> ff_init_dsd_data();
>
> return 0;
> @@ -1053,8 +1088,7 @@ static av_cold int wavpack_decode_end(AVCodecContext
> *avctx)
> ff_thread_release_buffer(avctx, &s->prev_frame);
> av_frame_free(&s->prev_frame.f);
>
> -if (!avctx->internal->is_copy)
> -av_freep(&s->dsdctx);
> +av_buffer_unref(&s->dsd_ref);
>
> return 0;
> }
> @@ -1065,6 +1099,7 @@ static int wavpack_decode_block(AVCodecContext *avctx,
> int block_no,
> WavpackContext *wc = avctx->priv_data;
> WavpackFrameContext *s;
> GetByteContext gb;
> +enum AVSampleFormat sample_fmt;
> void *samples_l = NULL, *samples_r = NULL;
> int ret;
> int got_terms = 0, got_weights = 0, got_samples = 0,
> @@ -1102,7 +1137,15 @@ static int wavpack_decode_block(AVCodecContext *avctx,
> int block_no,
> return AVERROR_INVALIDDATA;
> }
> s->frame_flags = bytestream2_get_le32(&gb);
> -bpp= av_get_bytes_per_sample(avctx->sample_fmt);
> +
> +if (s->frame_flags & (WV_FLOAT_DATA | WV_DSD_DATA))
> +sample_fmt = AV_SAMPLE_FMT_FLTP;
> +else if ((s->frame_flags & 0x03) <= 1)
> +sample_fmt = AV_SAMPLE_FMT_S16P;
> +else
> +sample_fmt = AV_SAMPLE_FMT_S32P;
> +
> +bpp= av_get_bytes_per_sample(sample_fmt);
> orig_bpp = ((s->frame_flags & 0x03) + 1) << 3;
> multiblock = (s->frame_flags & WV_SINGLE_BLOCK) != WV_SINGLE_BLOCK;
>
> @@ -1436,11 +1479,11 @@ static int wavpack_decode_block(AVCodecContext
> *avctx, int block_no,
> av_log(avctx, AV_LOG_ERROR, "Hybrid config not found\n");
> return AVERROR_INVALIDDATA;
> }
> -if (!got_float && avctx->sample_fmt == AV_SAMPLE_FMT_FLTP) {
> +if (!got_float && sample_fmt == AV_SAMPLE_FMT_FLTP) {
> av_log(avctx, AV_LOG_ERROR, "Float information not found\n");
> return AVERROR_INVALIDDATA;
> }
> -if (s->got_extra_bits && avctx->sample_fmt !=
Re: [FFmpeg-devel] [PATCH 03/14] pthread_frame: merge the functionality for normal decoder init and init_thread_copy
On 4/2/20 11:32 PM, Anton Khirnov wrote: > Quoting David Bryant (2020-04-03 07:14:21) >> On 4/2/20 2:13 AM, Anton Khirnov wrote: >>> Quoting David Bryant (2020-04-01 23:35:13) >>>> On 3/31/20 2:47 AM, Anton Khirnov wrote: >>>>>>> Looking at wavpack, the code looks suspicious to me. You allocate one >>>>>>> dsdctx per channel at init, but AFAIU the number of channels can change >>>>>>> at each frame. >>>>>>> >>>>>> Multichannel WavPack consists of sequences of stereo or mono WavPack >>>>>> blocks that include flags indicating whether they are the >>>>>> beginning or end of a "frame" or "packet". This allows the number of >>>>>> channels available to be essentially unlimited, however the >>>>>> total number of channels in a stream may not change. When decoding, if a >>>>>> sequence of blocks generates more or less than the >>>>>> correct number of channels, this is flagged as an error and overrun is >>>>>> prevented (see libavcodec/wavpack.c, line 1499 and line >>>>>> 1621). >>>>> If my reading of the code is correct, line 1499 only checks for overflow >>>>> of the channel count read for the current sequence. That channel count >>>>> is exported to AVCodeContext in the block starting on line 1464 and >>>>> I don't see any checks for whether it is equal to the initial one. >>>>> >>>> Full disclosure: I did not write the WavPack decoder. I understand _how_ >>>> it works, but I don't necessarily understand _why_ it >>>> was written the way it was due to gaps in my knowledge of the FFmpeg >>>> internals, and there are certainly things in there that >>>> don't look quite right to me. >>>> >>>> That said, I have tested it thoroughly and it handles everything I throw >>>> at it, and I have extended it to handle the DSD mode >>>> without anything unexpected happening. And of course it seems to handle >>>> extensive fuzzing, and the recent error was related to >>>> my DSD change, suggesting that the core it pretty robust. My inclination >>>> has been to not "fix" anything that wasn't broken. >>>> >>>> Yes, that channel count stuff is a little difficult to follow. I could >>>> experiment with streams that abruptly change channel >>>> configuration, but again I'm hesitant to change code that's worked so well >>>> so long. >>> I can easily get the decoder to crash even in single-threaded mode. Just >>> make the demuxer always say the stream is mono, then try decoding your >>> DSD sample. >> Okay, I reproduced that. However, I'm not sure it's really that serious >> because the demuxer and the decoder use basically the >> same logic to determine that number of channels, so it would be tricky to >> craft a file that caused the demuxer to calculate 1 >> channel and the decoder to reach a different result, which is probably why >> the fuzzers have not been able to do so. > I disagree - this is just as serious as any other crash on invalid data. > > The decoder must not ever crash for arbitrary input data. It cannot > assume that it's always going to be provided valid input or that it's > always used with some specific demuxer. The caller might not be using > libavformat at all, libavcodec should work with any source of data. > > Besides, I can reproduce the crash with no code modification necessary > by muxing your sample into Matroska and then hex-editing the file to say > it has only one channel. Yes, I have reproduced this crash even without Matroska. I was working on a solution but you beat me to it. Thanks! > >> That said, it would not be hard to have the decoder save away the initial >> channel count from avctx, never overwrite it, and >> verify that all superblocks match that count. I don't know off hand whether >> that would break anything though. Is it guaranteed >> that avctx->channels is correct during the call to decode_init(), even if >> it's being demuxed from Matroska, for example? If so, >> why is the WavPack decoder _ever_ writing to the avctx channel count? > The question is what you define as correct. The initial value provided > by the caller is supposed to be the caller's best guess at the correct > (initial) value. It may come from a demuxer, or from the Delphic Oracle. > The decoder does
Re: [FFmpeg-devel] [PATCH 4/4] lavf/wvdec: remove artificial restrictions on stream parameter changes
On 4/5/20 1:32 PM, Anton Khirnov wrote:
> They are not forbidden by the specification.
> ---
> libavformat/wvdec.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/libavformat/wvdec.c b/libavformat/wvdec.c
> index b9fc6a59f9..4159bf1253 100644
> --- a/libavformat/wvdec.c
> +++ b/libavformat/wvdec.c
> @@ -208,24 +208,6 @@ static int wv_read_block_header(AVFormatContext *ctx,
> AVIOContext *pb)
> if (!wc->rate)
> wc->rate = rate * rate_x;
>
> -if (flags && bpp != wc->bpp) {
> -av_log(ctx, AV_LOG_ERROR,
> - "Bits per sample differ, this block: %i, header block: %i\n",
> - bpp, wc->bpp);
> -return AVERROR_INVALIDDATA;
> -}
> -if (flags && !wc->multichannel && chan != wc->chan) {
> -av_log(ctx, AV_LOG_ERROR,
> - "Channels differ, this block: %i, header block: %i\n",
> - chan, wc->chan);
> -return AVERROR_INVALIDDATA;
> -}
> -if (flags && rate != -1 && !(flags & WV_DSD) && rate * rate_x !=
> wc->rate) {
> -av_log(ctx, AV_LOG_ERROR,
> - "Sampling rate differ, this block: %i, header block: %i\n",
> - rate * rate_x, wc->rate);
> -return AVERROR_INVALIDDATA;
> -}
> return 0;
> }
>
The specification does not explicitly mention that the data format, the channel
count (and layout), and the sample rate cannot
change inside of a WavPack file, but they can't. The first block of a WavPack
file that contains audio determines the format of
the entire file, and the documentation will be updated shortly to reflect that.
And obviously Konstantin Shishkov was aware of
this, even referring to the first block containing audio as the "header block".
I have no issue with the decoder handling these changes as it might be
receiving a WavPack stream from a container that allows
this, but the native WavPack container doesn't. And I actually don't have any
problem with this specific change going in because
it doesn't actually break anything. However, it should not be possible to
create a WavPack file with format changes such as these.
___
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] tests/fate/wavpack: add a lossless DSD file
As suggested in another thread, I have created a WavPack DSD test file that exercises all three of the DSD modes (fast, high, and copy). If someone would be kind enough to add this to the fate suite (in the wavpack/lossless folder) then this patch can go in. file: wavpack.com/dsd.wv (MD5: 74b2181f3e9829d9a5b98edd037984ac) decoded MD5 (f32le): a3a88bba95f809025dce01ecb9064091 Thanks! -David Bryant From 8e11e2068f1e763c46903d52da6489cb360b8f8e Mon Sep 17 00:00:00 2001 From: David Bryant Date: Fri, 17 Apr 2020 15:48:05 -0700 Subject: [PATCH] tests/fate/wavpack: add a lossless DSD file Signed-off-by: David Bryant --- tests/fate/wavpack.mak | 3 +++ tests/ref/fate/wavpack-lossless-dsd | 1 + 2 files changed, 4 insertions(+) create mode 100644 tests/ref/fate/wavpack-lossless-dsd diff --git a/tests/fate/wavpack.mak b/tests/fate/wavpack.mak index e3cf4ec..65b54c2 100644 --- a/tests/fate/wavpack.mak +++ b/tests/fate/wavpack.mak @@ -20,6 +20,9 @@ fate-wavpack-lossless-32bit: CMD = md5 -i $(TARGET_SAMPLES)/wavpack/lossless/32b FATE_WAVPACK-$(call DEMDEC, WV, WAVPACK) += fate-wavpack-lossless-float fate-wavpack-lossless-float: CMD = md5 -i $(TARGET_SAMPLES)/wavpack/lossless/32bit_float-partial.wv -f f32le +FATE_WAVPACK-$(call DEMDEC, WV, WAVPACK) += fate-wavpack-lossless-dsd +fate-wavpack-lossless-dsd: CMD = md5 -i $(TARGET_SAMPLES)/wavpack/lossless/dsd.wv -f f32le + # lossy FATE_WAVPACK-$(call DEMDEC, WV, WAVPACK) += fate-wavpack-lossy-8bit diff --git a/tests/ref/fate/wavpack-lossless-dsd b/tests/ref/fate/wavpack-lossless-dsd new file mode 100644 index 000..46ffaf7 --- /dev/null +++ b/tests/ref/fate/wavpack-lossless-dsd @@ -0,0 +1 @@ +a3a88bba95f809025dce01ecb9064091 -- 1.9.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] tests/fate/wavpack: add a lossless DSD file
On 4/18/20 9:49 AM, Carl Eugen Hoyos wrote: > Am Sa., 18. Apr. 2020 um 17:36 Uhr schrieb David Bryant : >> As suggested in another thread, I have created a WavPack DSD test file that >> exercises all three of the DSD modes (fast, high, and copy). >> >> If someone would be kind enough to add this to the fate suite (in the >> wavpack/lossless folder) then this patch can go in. >> >> file: wavpack.com/dsd.wv (MD5: 74b2181f3e9829d9a5b98edd037984ac) > I uploaded it but I wonder if 1MB wouldn't be enough? It probably would, but because DSD is so inefficient this file is still only 5 seconds long, and because I combined all three modes, this is really replacing three files. If space or bandwidth is a concern, I would rather pare down a few other larger WavPack files. There is one 14 MB file that really is a waste of space (and takes a long time to decode also). Kind regards, David > > 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] tests/fate/wavpack: add a lossless DSD file
On 4/18/20 10:32 AM, Carl Eugen Hoyos wrote: > Am Sa., 18. Apr. 2020 um 19:31 Uhr schrieb David Bryant : >> On 4/18/20 9:49 AM, Carl Eugen Hoyos wrote: >>> Am Sa., 18. Apr. 2020 um 17:36 Uhr schrieb David Bryant : >>>> As suggested in another thread, I have created a WavPack DSD test file >>>> that exercises all three of the DSD modes (fast, high, and copy). >>>> >>>> If someone would be kind enough to add this to the fate suite (in the >>>> wavpack/lossless folder) then this patch can go in. >>>> >>>> file: wavpack.com/dsd.wv (MD5: 74b2181f3e9829d9a5b98edd037984ac) >>> I uploaded it but I wonder if 1MB wouldn't be enough? >> It probably would, but because DSD is so inefficient this file is still only >> 5 seconds long, and because I combined all three >> modes, this is really replacing three files. > Just asking... > >> If space or bandwidth is a concern, I would rather pare down a few other >> larger WavPack files. There is one 14 MB file that >> really is a waste of space (and takes a long time to decode also). > This is not possible as we also want to run fate with old versions of FFmpeg. Oh, right, I had not thought of that. I guess it could be done if you generate the same MD5 result with a different input file, but that's probably not very useful. Thanks! - David Bryant > > 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".
[FFmpeg-devel] [PATCH] avdevice/v4l2enc: Allow writing non-rawvideos to v4l2
This patch allows you to output non-rawvideos to V4L2, which can be quite
helpful at times when you'd like to offer a compressed source (see example
usage below).
ffmpeg -vaapi_device /dev/dri/renderD129 -f v4l2 -input_format yuyv422 -i
/dev/video2 -f v4l2 -vf 'format=nv12,hwupload' -c:v h264_vaapi /dev/video4
From ce5f0ebd8e1d40b0f876b0d1b0b0cf564389b874 Mon Sep 17 00:00:00 2001
From: Roger
Date: Sat, 4 Nov 2017 16:32:41 -0400
Subject: [PATCH] avdevice/v4l2enc: Allow writing h264 to v4l2.
Signed-off-by: David Manouchehri
---
libavdevice/v4l2enc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavdevice/v4l2enc.c b/libavdevice/v4l2enc.c
index 1c36f81f90..afbd94f8da 100644
--- a/libavdevice/v4l2enc.c
+++ b/libavdevice/v4l2enc.c
@@ -47,8 +47,7 @@ static av_cold int write_header(AVFormatContext *s1)
}
if (s1->nb_streams != 1 ||
-s1->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO ||
-s1->streams[0]->codecpar->codec_id != AV_CODEC_ID_RAWVIDEO) {
+s1->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) {
av_log(s1, AV_LOG_ERROR,
"V4L2 output device supports only a single raw video stream\n");
return AVERROR(EINVAL);
@@ -56,7 +55,7 @@ static av_cold int write_header(AVFormatContext *s1)
par = s1->streams[0]->codecpar;
-v4l2_pixfmt = ff_fmt_ff2v4l(par->format, AV_CODEC_ID_RAWVIDEO);
+v4l2_pixfmt = ff_fmt_ff2v4l(AV_PIX_FMT_NONE, s1->streams[0]->codecpar->codec_id);
if (!v4l2_pixfmt) { // XXX: try to force them one by one?
av_log(s1, AV_LOG_ERROR, "Unknown V4L2 pixel format equivalent for %s\n",
av_get_pix_fmt_name(par->format));
--
2.17.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] avdevice/v4l2enc: Allow writing non-rawvideos to v4l2
Thanks for catching that bug! I tested rawvideo again this time, and
it works as expected with this new patch.
From d125fea410dea1c2d4bd791a7472a72822de54a3 Mon Sep 17 00:00:00 2001
From: David Manouchehri
Date: Sat, 4 Nov 2017 16:32:41 -0400
Subject: [PATCH] avdevice/v4l2enc: Allow writing non-rawvideos to v4l2.
Signed-off-by: David Manouchehri
---
libavdevice/v4l2enc.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavdevice/v4l2enc.c b/libavdevice/v4l2enc.c
index 1c36f81f90..f89ff50dbb 100644
--- a/libavdevice/v4l2enc.c
+++ b/libavdevice/v4l2enc.c
@@ -47,8 +47,7 @@ static av_cold int write_header(AVFormatContext *s1)
}
if (s1->nb_streams != 1 ||
-s1->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO ||
-s1->streams[0]->codecpar->codec_id != AV_CODEC_ID_RAWVIDEO) {
+s1->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) {
av_log(s1, AV_LOG_ERROR,
"V4L2 output device supports only a single raw video stream\n");
return AVERROR(EINVAL);
@@ -56,7 +55,13 @@ static av_cold int write_header(AVFormatContext *s1)
par = s1->streams[0]->codecpar;
-v4l2_pixfmt = ff_fmt_ff2v4l(par->format, AV_CODEC_ID_RAWVIDEO);
+if(s1->streams[0]->codecpar->codec_id == AV_CODEC_ID_RAWVIDEO) {
+v4l2_pixfmt = ff_fmt_ff2v4l(par->format, AV_CODEC_ID_RAWVIDEO);
+}
+else {
+v4l2_pixfmt = ff_fmt_ff2v4l(AV_PIX_FMT_NONE, s1->streams[0]->codecpar->codec_id);
+}
+
if (!v4l2_pixfmt) { // XXX: try to force them one by one?
av_log(s1, AV_LOG_ERROR, "Unknown V4L2 pixel format equivalent for %s\n",
av_get_pix_fmt_name(par->format));
--
2.17.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] avdevice/v4l2enc: Allow writing non-rawvideos to v4l2
Resubmit of a previous patch, not sure why the diff didn't come through.
From d125fea410dea1c2d4bd791a7472a72822de54a3 Mon Sep 17 00:00:00 2001
From: David Manouchehri
Date: Sat, 4 Nov 2017 16:32:41 -0400
Subject: [PATCH] avdevice/v4l2enc: Allow writing non-rawvideos to v4l2.
Signed-off-by: David Manouchehri
---
libavdevice/v4l2enc.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavdevice/v4l2enc.c b/libavdevice/v4l2enc.c
index 1c36f81f90..f89ff50dbb 100644
--- a/libavdevice/v4l2enc.c
+++ b/libavdevice/v4l2enc.c
@@ -47,8 +47,7 @@ static av_cold int write_header(AVFormatContext *s1)
}
if (s1->nb_streams != 1 ||
-s1->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO ||
-s1->streams[0]->codecpar->codec_id != AV_CODEC_ID_RAWVIDEO) {
+s1->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) {
av_log(s1, AV_LOG_ERROR,
"V4L2 output device supports only a single raw video stream\n");
return AVERROR(EINVAL);
@@ -56,7 +55,13 @@ static av_cold int write_header(AVFormatContext *s1)
par = s1->streams[0]->codecpar;
-v4l2_pixfmt = ff_fmt_ff2v4l(par->format, AV_CODEC_ID_RAWVIDEO);
+if(s1->streams[0]->codecpar->codec_id == AV_CODEC_ID_RAWVIDEO) {
+v4l2_pixfmt = ff_fmt_ff2v4l(par->format, AV_CODEC_ID_RAWVIDEO);
+}
+else {
+v4l2_pixfmt = ff_fmt_ff2v4l(AV_PIX_FMT_NONE, s1->streams[0]->codecpar->codec_id);
+}
+
if (!v4l2_pixfmt) { // XXX: try to force them one by one?
av_log(s1, AV_LOG_ERROR, "Unknown V4L2 pixel format equivalent for %s\n",
av_get_pix_fmt_name(par->format));
--
2.17.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 1/2] avcodec/wavpack: Check rate_x and sample rate for overflow
On 5/2/20 2:08 PM, Michael Niedermayer wrote:
> Fixes: shift exponent 32 is too large for 32-bit type 'int'
> Fixes:
> 21647/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5686168323883008
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/wavpack.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
> index 58ab561a15..ead57063c8 100644
> --- a/libavcodec/wavpack.c
> +++ b/libavcodec/wavpack.c
> @@ -1359,7 +1359,10 @@ static int wavpack_decode_block(AVCodecContext *avctx,
> int block_no,
> bytestream2_skip(&gb, ssize);
> continue;
> }
> -rate_x = 1 << bytestream2_get_byte(&gb);
> +rate_x = bytestream2_get_byte(&gb);
> +if (rate_x > 30)
> +return AVERROR_INVALIDDATA;
> +rate_x = 1 << rate_x;
> dsd_mode = bytestream2_get_byte(&gb);
> if (dsd_mode && dsd_mode != 1 && dsd_mode != 3) {
> av_log(avctx, AV_LOG_ERROR, "Invalid DSD encoding mode:
> %d\n",
> @@ -1498,9 +1501,13 @@ static int wavpack_decode_block(AVCodecContext *avctx,
> int block_no,
> av_log(avctx, AV_LOG_ERROR, "Custom sample rate missing.\n");
> return AVERROR_INVALIDDATA;
> }
> -new_samplerate = sample_rate * rate_x;
> +new_samplerate = sample_rate;
> } else
> -new_samplerate = wv_rates[sr] * rate_x;
> +new_samplerate = wv_rates[sr];
> +
> +if (new_samplerate * (uint64_t)rate_x > INT_MAX)
> +return AVERROR_INVALIDDATA;
> +new_samplerate *= rate_x;
>
> if (multiblock) {
> if (chan)
Looks correct to me. Thanks.
___
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] drawtext: Allow textfile path to be expanded (and then reloaded) every frame
Signed-off-by: David Andreoletti
---
doc/filters.texi | 16 +---
libavfilter/vf_drawtext.c | 19 ---
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index d19fd346ae..3a127369ea 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9659,13 +9659,13 @@ The default value of @var{borderw} is 0.
Set the color to be used for drawing border around text. For the syntax of this
option, check the @ref{color syntax,,"Color" section in the ffmpeg-utils
manual,ffmpeg-utils}.
The default value of @var{bordercolor} is "black".
@item expansion
-Select how the @var{text} is expanded. Can be either @code{none},
+Select how the @var{text} and @var{textfile} are expanded. Can be either
@code{none},
@code{strftime} (deprecated) or
@code{normal} (default). See the @ref{drawtext_expansion, Text expansion}
section
below for details.
@item basetime
Set a start time for the count. Value is in microseconds. Only applied
@@ -9786,15 +9786,19 @@ of UTF-8 encoded characters.
This parameter is mandatory if no text string is specified with the
parameter @var{text}.
If both @var{text} and @var{textfile} are specified, an error is thrown.
+This parameter supports (per frame) variable expansion. Per frame variable
+expansion requires @code{reload=1}. See @var{expansion} for details.
+
+
@item reload
-If set to 1, the @var{textfile} will be reloaded before each frame.
-Be sure to update it atomically, or it may be read partially, or even fail.
+If set to 1, then before each frame, @var{textfile} file path will be expanded
and then the file at said path will be reloaded.
+Be sure to update the file atomically, or it may be read partially, or even
fail.
@item x
@item y
The expressions which specify the offsets where text will be drawn
within the video frame. They are relative to the top/left border of the
output image.
@@ -10060,12 +10064,18 @@
drawtext="fontsize=15:fontfile=FreeSerif.ttf:text=LONG_LINE:y=h-line_h:x=-50*t"
@item
Show the content of file @file{CREDITS} off the bottom of the frame and scroll
up.
@example
drawtext="fontsize=20:fontfile=FreeSerif.ttf:textfile=CREDITS:y=h-20*t"
@end example
+@item
+Each frame, reload a different text file at /path/to/frameX.txt, where X is
replaced with the frame number being processed by the filter
+@example
+drawtext="expansion:normal:textfile=/path/to/frame%{frame_num}.txt:reload=1"
+@end example
+
@item
Draw a single green letter "g", at the center of the input video.
The glyph baseline is placed at half screen height.
@example
drawtext="fontsize=60:fontfile=FreeSerif.ttf:fontcolor=green:text=g:x=(w-max_glyph_w)/2:y=h/2-ascent"
@end example
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index abe1ca6c35..ffb1ff2330 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -152,13 +152,14 @@ typedef struct DrawTextContext {
AVBPrint expanded_text; ///< used to contain the expanded text
uint8_t *fontcolor_expr;///< fontcolor expression to evaluate
AVBPrint expanded_fontcolor;///< used to contain the expanded
fontcolor spec
int ft_load_flags; ///< flags used for loading fonts, see
FT_LOAD_*
FT_Vector *positions; ///< positions for each element in the text
size_t nb_positions;///< number of elements of positions array
-char *textfile; ///< file with text to be drawn
+char *textfile; ///< filename with text to be drawn
+AVBPrint expanded_textfile; ///< Same as textfile, except the filename
can be expanded
int x; ///< x position to start drawing text
int y; ///< y position to start drawing text
int max_glyph_w;///< max glyph width
int max_glyph_h;///< max glyph height
int shadowx, shadowy;
int borderw;///< border width
@@ -565,24 +566,33 @@ static int load_font(AVFilterContext *ctx)
if (!err)
return 0;
#endif
return err;
}
+static int expand_text(AVFilterContext *ctx, char *text, AVBPrint *bp);
static int load_textfile(AVFilterContext *ctx)
{
DrawTextContext *s = ctx->priv;
int err;
uint8_t *textbuf;
uint8_t *tmp;
size_t textbuf_size;
-if ((err = av_file_map(s->textfile, &textbuf, &textbuf_size, 0, ctx)) < 0)
{
+if ((err = expand_text(ctx, s->textfile, &s->expanded_textfile)) < 0) {
+av_log(ctx, AV_LOG_ERROR, "The text file path '%s' is not
expandable\n",
+s->textfile);
+return err;
+}
+
+av_log(ctx, AV_LOG_DEBUG, "expanded_textfile:%s\n",
s->expanded_textfile.str);
+
+if ((er
[FFmpeg-devel] [PATCH] drawtext: Allow textfile path to be expanded per frame
drawtext allows a file to be reloaded per frame. However,
the file to be reloaded is constant across frame. With
textfile now supporting text expansion, a different file can
be reloaded per frame. Eg: textfile=/path/fo/file{frame_num}.txt
Signed-off-by: David Andreoletti
---
doc/filters.texi | 16 +---
libavfilter/vf_drawtext.c | 19 ---
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index d19fd346ae..460d65dd88 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9659,13 +9659,13 @@ The default value of @var{borderw} is 0.
Set the color to be used for drawing border around text. For the syntax of this
option, check the @ref{color syntax,,"Color" section in the ffmpeg-utils
manual,ffmpeg-utils}.
The default value of @var{bordercolor} is "black".
@item expansion
-Select how the @var{text} is expanded. Can be either @code{none},
+Select how the @var{text} and @var{textfile} are expanded. Can be either
@code{none},
@code{strftime} (deprecated) or
@code{normal} (default). See the @ref{drawtext_expansion, Text expansion}
section
below for details.
@item basetime
Set a start time for the count. Value is in microseconds. Only applied
@@ -9786,15 +9786,19 @@ of UTF-8 encoded characters.
This parameter is mandatory if no text string is specified with the
parameter @var{text}.
If both @var{text} and @var{textfile} are specified, an error is thrown.
+This parameter supports (per frame) variable expansion. Per frame variable
+expansion requires @code{reload=1}. See @var{expansion} for details.
+
+
@item reload
-If set to 1, the @var{textfile} will be reloaded before each frame.
-Be sure to update it atomically, or it may be read partially, or even fail.
+If set to 1, then before each frame, @var{textfile} file path will be expanded
and then the file at said path will be reloaded.
+Be sure to update the file atomically, or it may be read partially, or even
fail.
@item x
@item y
The expressions which specify the offsets where text will be drawn
within the video frame. They are relative to the top/left border of the
output image.
@@ -10060,12 +10064,18 @@
drawtext="fontsize=15:fontfile=FreeSerif.ttf:text=LONG_LINE:y=h-line_h:x=-50*t"
@item
Show the content of file @file{CREDITS} off the bottom of the frame and scroll
up.
@example
drawtext="fontsize=20:fontfile=FreeSerif.ttf:textfile=CREDITS:y=h-20*t"
@end example
+@item
+Each frame, reload a different text file at /path/to/frameX.txt, where X is
replaced with the frame number being processed by the filter
+@example
+drawtext="expansion:normal:textfile=/path/to/frame%@{frame_num@}.txt:reload=1"
+@end example
+
@item
Draw a single green letter "g", at the center of the input video.
The glyph baseline is placed at half screen height.
@example
drawtext="fontsize=60:fontfile=FreeSerif.ttf:fontcolor=green:text=g:x=(w-max_glyph_w)/2:y=h/2-ascent"
@end example
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index abe1ca6c35..ffb1ff2330 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -152,13 +152,14 @@ typedef struct DrawTextContext {
AVBPrint expanded_text; ///< used to contain the expanded text
uint8_t *fontcolor_expr;///< fontcolor expression to evaluate
AVBPrint expanded_fontcolor;///< used to contain the expanded
fontcolor spec
int ft_load_flags; ///< flags used for loading fonts, see
FT_LOAD_*
FT_Vector *positions; ///< positions for each element in the text
size_t nb_positions;///< number of elements of positions array
-char *textfile; ///< file with text to be drawn
+char *textfile; ///< filename with text to be drawn
+AVBPrint expanded_textfile; ///< Same as textfile, except the filename
can be expanded
int x; ///< x position to start drawing text
int y; ///< y position to start drawing text
int max_glyph_w;///< max glyph width
int max_glyph_h;///< max glyph height
int shadowx, shadowy;
int borderw;///< border width
@@ -565,24 +566,33 @@ static int load_font(AVFilterContext *ctx)
if (!err)
return 0;
#endif
return err;
}
+static int expand_text(AVFilterContext *ctx, char *text, AVBPrint *bp);
static int load_textfile(AVFilterContext *ctx)
{
DrawTextContext *s = ctx->priv;
int err;
uint8_t *textbuf;
uint8_t *tmp;
size_t textbuf_size;
-if ((err = av_file_map(s->textfile, &textbuf, &textbuf_size, 0, ctx)) < 0)
{
+if ((err = expand_text(ctx, s->textfile, &s->expanded_textfile)) < 0) {
+av_log(ctx, AV_LOG
Re: [FFmpeg-devel] [PATCH] drawtext: Allow textfile path to be expanded per frame
Hi ffmpeg maintainers / community,
New contributor here. The patch [0] for the drawtext filter was submitted some
time ago now but has been reviewed yet. It seems there is no official maintainer
for this filter (as per the MAINTAINERS file)
What should be done to have it reviewed ?
[0]
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200511143159.19390-1-da...@andreoletti.net/
Regards,
David Andreoletti
On Mon, May 11, 2020 2:31 PM, David Andreoletti da...@andreoletti.net wrote:
drawtext allows a file to be reloaded per frame. However,
the file to be reloaded is constant across frame. With
textfile now supporting text expansion, a different file can
be reloaded per frame. Eg: textfile=/path/fo/file{frame_num}.txt
Signed-off-by: David Andreoletti
---
doc/filters.texi | 16 +---
libavfilter/vf_drawtext.c | 19 ---
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index d19fd346ae..460d65dd88 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9659,13 +9659,13 @@ The default value of @var{borderw} is 0.
Set the color to be used for drawing border around text. For the syntax of
this
option, check the @ref{color syntax,,"Color" section in the ffmpeg-utils
manual,ffmpeg-utils}.
The default value of @var{bordercolor} is "black".
@item expansion
-Select how the @var{text} is expanded. Can be either @code{none},
+Select how the @var{text} and @var{textfile} are expanded. Can be either
@code{none},
@code{strftime} (deprecated) or
@code{normal} (default). See the @ref{drawtext_expansion, Text expansion}
section
below for details.
@item basetime
Set a start time for the count. Value is in microseconds. Only applied
@@ -9786,15 +9786,19 @@ of UTF-8 encoded characters.
This parameter is mandatory if no text string is specified with the
parameter @var{text}.
If both @var{text} and @var{textfile} are specified, an error is thrown.
+This parameter supports (per frame) variable expansion. Per frame variable
+expansion requires @code{reload=1}. See @var{expansion} for details.
+
+
@item reload
-If set to 1, the @var{textfile} will be reloaded before each frame.
-Be sure to update it atomically, or it may be read partially, or even fail.
+If set to 1, then before each frame, @var{textfile} file path will be expanded
and then the file at said path will be reloaded.
+Be sure to update the file atomically, or it may be read partially, or even
fail.
@item x
@item y
The expressions which specify the offsets where text will be drawn
within the video frame. They are relative to the top/left border of the
output image.
@@ -10060,12 +10064,18 @@
drawtext="fontsize=15:fontfile=FreeSerif.ttf:text=LONG_LINE:y=h-line_h:x=-50*t"
@item
Show the content of file @file{CREDITS} off the bottom of the frame and scroll
up.
@example
drawtext="fontsize=20:fontfile=FreeSerif.ttf:textfile=CREDITS:y=h-20*t"
@end example
+@item
+Each frame, reload a different text file at /path/to/frameX.txt, where X is
replaced with the frame number being processed by the filter
+@example
+drawtext="expansion:normal:textfile=/path/to/frame%@{frame_num@}.txt:reload=1"
+@end example
+
@item
Draw a single green letter "g", at the center of the input video.
The glyph baseline is placed at half screen height.
@example
drawtext="fontsize=60:fontfile=FreeSerif.ttf:fontcolor=green:text=g:x=(w-max_glyph_w)/2:y=h/2-ascent"
@end example
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index abe1ca6c35..ffb1ff2330 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -152,13 +152,14 @@ typedef struct DrawTextContext {
AVBPrint expanded_text; ///< used to contain the expanded text
uint8_t *fontcolor_expr; ///< fontcolor expression to evaluate
AVBPrint expanded_fontcolor; ///< used to contain the expanded fontcolor spec
int ft_load_flags; ///< flags used for loading fonts, see FT_LOAD_*
FT_Vector *positions; ///< positions for each element in the text
size_t nb_positions; ///< number of elements of positions array
- char *textfile; ///< file with text to be drawn
+ char *textfile; ///< filename with text to be drawn
+ AVBPrint expanded_textfile; ///< Same as textfile, except the filename can be
expanded
int x; ///< x position to start drawing text
int y; ///< y position to start drawing text
int max_glyph_w; ///< max glyph width
int max_glyph_h; ///< max glyph height
int shadowx, shadowy;
int borderw; ///< border width
@@ -565,24 +566,33 @@ static int load_font(AVFilterContext *ctx)
if (!err)
return 0;
#endif
return err;
}
+static int expand_text(AVFilterContext *ctx, char *text, AVBPrint *bp);
static int load_te
Re: [FFmpeg-devel] [PATCH] drawtext: Allow textfile path to be expanded per frame
Manolis: drawtext's text expansion section [0] does not mention the special
variable %{frame_num} has 0 paddable. When I tested locally (on master), it is
not 0 padded.
Running through different scenario, I recommend the expanded file path to not
contain 0 padded frame number:- if automatic padding is specified, then video
with no total frame known (live stream) would be problematic- if manually
padding is specified, it would complicate drawtext's textfile options parsing:
support for 0 padded %{frame_num} and possibly other custom formatting when
other supported %{} variables are expanded.
For a first improvement to an existing functionality, I would prefer to keep it
simple and focused :-)
[0]https://ffmpeg.org/ffmpeg-filters.html#Text-expansion
On Tue, May 19, 2020 9:34 AM, Manolis Stamatogiannakis msta...@gmail.com wrote:
Hi David,
Not a full review, but a minor point that popped in mind.
It is common to pad serially numbered files with 0. E.g. if you have <1000
files, the 9th file will be named file009.txt.
Is this case handled by the expansion? Or is it assumed that the text file
numbers are not zero-padded?
If it the latter is the case, it would be good to make that explicit in the
documentation.
Of course, accounting for padding would be better, but this may not be
straightforward without adding more code.
Regards,
Manolis
On Tue, 19 May 2020 at 06:10, David Andreoletti
wrote:
> Hi ffmpeg maintainers / community,
> New contributor here. The patch [0] for the drawtext filter was submitted
> some
> time ago now but has been reviewed yet. It seems there is no official
> maintainer
> for this filter (as per the MAINTAINERS file)
> What should be done to have it reviewed ?
>
> [0]
>
>
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200511143159.19390-1-da...@andreoletti.net/
>
> Regards,
> David Andreoletti
>
>
>
___
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] drawtext: Allow textfile path to be expanded per frame
FFmpeg team,
Is there any other discussion/changes needed to get this contribution merged in
?
Regards,
On Tue, May 19, 2020 12:36 PM, David Andreoletti da...@andreoletti.net wrote:
Manolis: drawtext's text expansion section [0] does not mention the special
variable %{frame_num} has 0 paddable. When I tested locally (on master), it is
not 0 padded.
Running through different scenario, I recommend the expanded file path to not
contain 0 padded frame number:- if automatic padding is specified, then video
with no total frame known (live stream) would be problematic- if manually
padding is specified, it would complicate drawtext's textfile options parsing:
support for 0 padded %{frame_num} and possibly other custom formatting when
other supported %{} variables are expanded.
For a first improvement to an existing functionality, I would prefer to keep it
simple and focused :-)
[0]https://ffmpeg.org/ffmpeg-filters.html#Text-expansion
On Tue, May 19, 2020 9:34 AM, Manolis Stamatogiannakis msta...@gmail.com wrote:
Hi David,
Not a full review, but a minor point that popped in mind.
It is common to pad serially numbered files with 0. E.g. if you have <1000
files, the 9th file will be named file009.txt.
Is this case handled by the expansion? Or is it assumed that the text file
numbers are not zero-padded?
If it the latter is the case, it would be good to make that explicit in the
documentation.
Of course, accounting for padding would be better, but this may not be
straightforward without adding more code.
Regards,
Manolis
On Tue, 19 May 2020 at 06:10, David Andreoletti
wrote:
> Hi ffmpeg maintainers / community,
> New contributor here. The patch [0] for the drawtext filter was submitted
> some
> time ago now but has been reviewed yet. It seems there is no official
> maintainer
> for this filter (as per the MAINTAINERS file)
> What should be done to have it reviewed ?
>
> [0]
>
>
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200511143159.19390-1-da...@andreoletti.net/
>
> Regards,
> David Andreoletti
>
>
>
___
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 3/3] avcodec/wavpack: Do not allow the sample format to change between channels
On 6/3/20 4:19 PM, Michael Niedermayer wrote: > Fixes: out of array access > Fixes: > 22692/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5678686190960640 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/wavpack.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c > index ead57063c8..f77548e5a5 100644 > --- a/libavcodec/wavpack.c > +++ b/libavcodec/wavpack.c > @@ -1129,6 +1129,9 @@ static int wavpack_decode_block(AVCodecContext *avctx, > int block_no, > else > sample_fmt = AV_SAMPLE_FMT_S32P; > > +if (wc->ch_offset && avctx->sample_fmt != sample_fmt) > +return AVERROR_INVALIDDATA; > + > bpp= av_get_bytes_per_sample(sample_fmt); > orig_bpp = ((s->frame_flags & 0x03) + 1) << 3; > multiblock = (s->frame_flags & WV_SINGLE_BLOCK) != WV_SINGLE_BLOCK; Looks reasonable to me and passes my local test suite. Thanks! -David ___ 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 for failing on WavPack DSD files
On 11/21/18 9:50 PM, David Bryant wrote: > On 11/20/18 10:58 PM, Peter Ross wrote: >> On Tue, Nov 20, 2018 at 09:23:03PM -0800, David Bryant wrote: >>> Hi, >>> >>> Was made aware of this problem on Kodi: >>> >>> https://github.com/xbmc/xbmc/issues/14771 >>> >>> I'm going to try to add full WavPack DSD support, but thought in the >>> meantime it would be a good idea to detect and error out early. >>> >>> Thanks! >> cool. is this dst-based, or your own algorithm? >> >> -- Peter >> (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > This is my own algorithm. Actually there are two: one is a byte-based > algorithm that is very fast and the other is bit-based > (like DST) that is slower but compresses better (and still uses less CPU than > DST). If I had to make a rough estimation of the > average compression ratios, it would be about 0.6 for the fast mode, 0.5 for > the high mode, and 0.4 for DST. > > -David > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Hi. Is there anything else I can provide to help this along? The behavior of FFmpeg encountering WavPack DSD files without this patch is pretty ugly... -David ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch for failing on WavPack DSD files
On 12/24/18 12:21 AM, Paul B Mahol wrote: > On 12/24/18, David Bryant wrote: >> On 11/21/18 9:50 PM, David Bryant wrote: >>> On 11/20/18 10:58 PM, Peter Ross wrote: >>>> On Tue, Nov 20, 2018 at 09:23:03PM -0800, David Bryant wrote: >>>>> Hi, >>>>> >>>>> Was made aware of this problem on Kodi: >>>>> >>>>> https://github.com/xbmc/xbmc/issues/14771 >>>>> >>>>> I'm going to try to add full WavPack DSD support, but thought in the >>>>> meantime it would be a good idea to detect and error out early. >>>>> >>>>> Thanks! >>>> cool. is this dst-based, or your own algorithm? >>>> >>>> -- Peter >>>> (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) >>>> >>>> ___ >>>> ffmpeg-devel mailing list >>>> ffmpeg-devel@ffmpeg.org >>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> This is my own algorithm. Actually there are two: one is a byte-based >>> algorithm that is very fast and the other is bit-based >>> (like DST) that is slower but compresses better (and still uses less CPU >>> than DST). If I had to make a rough estimation of the >>> average compression ratios, it would be about 0.6 for the fast mode, 0.5 >>> for the high mode, and 0.4 for DST. >>> >>> -David >>> >>> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> Hi. Is there anything else I can provide to help this along? >> >> The behavior of FFmpeg encountering WavPack DSD files without this patch is >> pretty ugly... > Yes, post full patch that adds DSD support in WavPack. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I want to do that, but am swamped at work right now, so it will probably be a few months before I can get to that. In the meantime, I think this patch would be a safe stopgap (and prevent the Kodi crash). Thanks! -David ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch for failing on WavPack DSD files
On 12/28/18 3:56 AM, Paul B Mahol wrote: > On 12/24/18, Derek Buitenhuis wrote: >> On 24/12/2018 17:47, David Bryant wrote: >>> I want to do that, but am swamped at work right now, so it will probably >>> be a few months before I can get to that. >>> >>> In the meantime, I think this patch would be a safe stopgap (and prevent >>> the Kodi crash). >> I think it's OK for the meantime (my opinion). > Applied. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Thanks! The guys at Kodi asked me to request that this patch be backported to 4.0. I don't really know if that's a thing, but if it is then that would be great. -David ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: ignore scte20 captions when a53 data is also present
On Thu, Mar 08, 2018 at 07:13:57AM +, Aman Gupta wrote: > On Wed, Mar 7, 2018 at 10:35 AM Devin Heitmueller < > dheitmueller at ltnglobal.com> wrote: > > > > > > From what I've seen in US broadcast television, scte20 is only used on > > > standard-def content and everything else uses normal a53. > > > > A53 is definitely the more popular standard, and all that is approved for > > distribution in digital over the air broadcasts. SCTE-20 would only be > > found further up the distribution chain, and perhaps in distribution to > > some cable boxes (although it’s becoming less and less common that it can > > be decoded since most of the content is encrypted nowadays). > > > > > > > > > > I'm not sure how we would export both since there's only one type of side > > > data. > > > > We would have to add a new side data type, and encoders would have to be > > changed to look for both. > > > > > > >> > > >> also turning one off for ever seems problematic for concatenated > > >> sequences. not every sequence would need to contain both I guess > > > > Funny enough, I spent my entire morning debugging some issues with playing > > concatenated TS streams. If anyone thinks that’s supposed to be working > > today in ffmpeg, there’s a ton of work to be done in that area. > > > > > > > > > > > > > Yea that's theoreticaly possible, but I'd rather wait to add support > > until > > > someone actually sees it in the wild. > > > > > > Before I added scte20 support a few months ago no one even noticed it was > > > missing. It doesn't seem to have wide spread use. > > > > It’s not really that nobody noticed - it’s that most people in the > > broadcast space until recently had ruled out the ability to use ffmpeg for > > production because of it’s lack of good support for ancillary data such as > > captions. That situation is improving of course, but it’s not so much that > > “no one even noticed it was missing”. > > > > > > If changing the framework to support the extra side data format isn’t > > viable, then certainly prefering A53 over SCTE-20 would be the right way to > > go. I would make it configurable though. > > > Thanks for the background on SCTE-20. I don't really know much about it. > > I'm not opposed to adding new side data, but it doesn't sound like it's > worth it in this particular case. Atleast to me; if someone else wants to > pursue that approach I will happily help review and test any patches. > > > > To make my patch configurable, I could change the ignore flag I added into > a new option called parse_scte20: default to "prefer a53" like I have now, > but can be set explicitly to "always" or "never". Wdyt? I tried to use ffmpeg to transcode some TV recordings I have where I need to keep the closed captions. When I finally got the ffmpeg options right to copy the captions, the captions were a garbled, unrecognizable mess. I eventually worked around the problem with ffmpeg be using ccextractor to first extract the captions separately. I then muxed them back in later with the transcoded video and audio using ffmpeg. With ccextractor, I initially got garbled captions too until I used the --noscte20 option. After that, I got perfectly clean captions. When I looked to see if ffmpeg had a comparable switch, I found this thread. I build ffmpeg myself with this patch and sure enough I got perfectly clean captions too without having to use ccextractor. I see this patch hasn't been included in ffmpeg yet. Please reconsider including it in some form as it is definitely needed out here in the real world. Please note that I am not subscribed to the ffmpeg-devel list. Please copy me on any replies that you need me to see. David -- David Engel da...@istwok.net ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch for failing on WavPack DSD files
On 1/6/19 4:43 AM, Carl Eugen Hoyos wrote: > 2019-01-03 6:19 GMT+01:00, David Bryant : >> On 12/28/18 3:56 AM, Paul B Mahol wrote: >>> On 12/24/18, Derek Buitenhuis wrote: >>>> On 24/12/2018 17:47, David Bryant wrote: >>>>> I want to do that, but am swamped at work right now, so it will probably >>>>> be a few months before I can get to that. >>>>> >>>>> In the meantime, I think this patch would be a safe stopgap (and prevent >>>>> the Kodi crash). >>>> I think it's OK for the meantime (my opinion). >>> Applied. >> The guys at Kodi asked me to request that this patch be backported to 4.0. > While this may be ok, somebody should tell the Kodi developers > to fix the crash as I would expect it's possible to create files > that are still tried to be decoded but produce identical output > as before. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I agree. In fact, take a WavPack DSD file and clear the bit that this patch checks for, and I'll bet you'll get exactly the old behavior. It should be investigated as to why Kodi crashes with these files while FFmpeg just spews a bunch of error messages. -David ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [job] trim based on pic_timing SEI
Hi there, I have been looking at using ffmpeg to trim and reencode some source content, and to use the clockTimestamp fields from the pic_timing SEI header as the basis of finding the correct start frame for the trimmed output. If I am correct in thinking this is not currently possible with ffmpeg, would anybody be interested in taking on a contract to make this work? If so, please contact me directly with an indication of your availability. Many thanks, David Holroyd ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avformat/mov: improve qt metadata reading and writing
Hi all, this has been brought up before, the MOV muxer/demuxer currently does not support all possible datatypes that are allowed in keys/mdta style metadata. This is specified here: https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/Metadata/Metadata.html#//apple_ref/doc/uid/TP4939-CH1-SW35 At the moment only data types 1 (UTF-8) and 23 (Float32) work. I have a patch that adds support for 21 and 22, as I have found those in actual files produced by ARRI cameras. I have a second patch that adds a flag to the muxer to output keys/mdta style metadata, to be able to keep the metadata while transcoding camera files. This patch tries to do something similar, but is mine is shorter (though not as complete) so hopefully easy to review: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178347.html (I actually found this only after writing my patches.) Patchset is in the next mails. till then, David. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/mov: add more datatypes in metadata handling
0001-avformat-mov-add-more-datatypes-in-metadata-handling.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/movenc: add option to use keys/mdta atoms for metadata
0002-avformat-movenc-add-option-to-use-keys-mdta-atoms-fo.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add wayland support for VAAPI
Wayland environment became quite popular with gnome 3. This patch adds the
ability to
initialize the VAAPI accelerator from a wayland display.
Signed-off-by: David Fort
---
configure | 4
libavutil/hwcontext_vaapi.c | 33 +
2 files changed, 37 insertions(+)
diff --git a/configure b/configure
index 6ca919b..b2e8b1c 100755
--- a/configure
+++ b/configure
@@ -2072,6 +2072,7 @@ HAVE_LIST="
threads
vaapi_drm
vaapi_x11
+vaapi_wayland
vdpau_x11
winrt
"
@@ -6132,6 +6133,9 @@ enabled vaapi &&
disable vaapi
enabled vaapi &&
+check_lib vaapi_wayland "va/va.h va/va_wayland.h" vaGetDisplayWl -lva
-lva-wayland -lwayland-client
+
+enabled vaapi &&
check_lib vaapi_drm "va/va.h va/va_drm.h" vaGetDisplayDRM -lva -lva-drm
enabled vaapi &&
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 3970726..5fb607f 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -24,6 +24,9 @@
#if HAVE_VAAPI_DRM
# include
#endif
+#if HAVE_VAAPI_WAYLAND
+# include
+#endif
#include
#if HAVE_UNISTD_H
@@ -47,6 +50,9 @@ typedef struct VAAPIDevicePriv {
#endif
int drm_fd;
+#if HAVE_VAAPI_WAYLAND
+struct wl_display *wl_display;
+#endif
} VAAPIDevicePriv;
typedef struct VAAPISurfaceFormat {
@@ -905,6 +911,10 @@ static void vaapi_device_free(AVHWDeviceContext *ctx)
if (hwctx->display)
vaTerminate(hwctx->display);
+#if HAVE_VAAPI_WAYLAND
+if (priv->wl_display)
+wl_display_disconnect(priv->wl_display);
+#endif
#if HAVE_VAAPI_X11
if (priv->x11_display)
XCloseDisplay(priv->x11_display);
@@ -934,6 +944,29 @@ static int vaapi_device_create(AVHWDeviceContext *ctx,
const char *device,
ctx->user_opaque = priv;
ctx->free= vaapi_device_free;
+#if HAVE_VAAPI_WAYLAND
+// Try to open the device as a wayland display.
+if (!display && !(device && device[0] == '/')) {
+ priv->wl_display = wl_display_connect(device);
+ if (!priv->wl_display) {
+ av_log(ctx, AV_LOG_VERBOSE, "Cannot open wayland
display "
+ "%s.\n", device);
+ } else {
+ wl_display_roundtrip (priv->wl_display);
+
+ display = vaGetDisplayWl(priv->wl_display);
+ if (!display) {
+ av_log(ctx, AV_LOG_ERROR, "Cannot open a VA
display "
+ "from wayland display %s.\n",
device);
+ return AVERROR_UNKNOWN;
+ }
+
+ av_log(ctx, AV_LOG_VERBOSE, "Opened VA display via "
+ "wayland display %s.\n", device);
+ }
+ }
+#endif
+
#if HAVE_VAAPI_X11
if (!display && !(device && device[0] == '/')) {
// Try to open the device as an X11 display.
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add new MPEG bitstream filter
Given an MPEG1/2 stream, this bitstream filter can be used to modify
the sequence headers. The most common use would be to change the
aspect ration without the need for re-encoding. Some MOD files have
the aspect ratio incorrectly set to 4:3
(see https://en.wikipedia.org/wiki/MOD_and_TOD).
---
doc/bitstream_filters.texi | 21
libavcodec/Makefile | 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/mod_mpeg_seq_header_bsf.c | 102 +++
4 files changed, 125 insertions(+)
create mode 100644 libavcodec/mod_mpeg_seq_header_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 2dffe021f9..c9801f966c 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -186,6 +186,27 @@ ffmpeg -i frame_%d.jpg -c:v copy rotated.avi
Add an MJPEG A header to the bitstream, to enable decoding by
Quicktime.
+@section mod_mpeg_seq_header
+
+Given an MPEG1/2 stream, this bitstream filter can be used to modify
+the sequence headers. The most common use would be to change the
+aspect ration without the need for re-encoding. Some MOD files have
+the aspect ratio incorrectly set to 4:3 (see
+@url{https://en.wikipedia.org/wiki/MOD_and_TOD}).
+
+To set widescreen format in a mod file do this:
+
+@example
+ffmpeg -i in.mod -bsf:v mod_mpeg_seq_header=aspect_ratio=3 -codec copy out.mpeg
+@end example
+
+@table @option
+@item aspect_ratio
+Common values are 2 for 4:3 format and 3 for 16:9 (widescreen).
+@item frame_rate
+Use 2 for 24 fps and 3 for 25 fps.
+@end table
+
@anchor{mov2textsub}
@section mov2textsub
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 357fa1a361..e275eb6062 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1002,6 +1002,7 @@ OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
OBJS-$(CONFIG_VP9_RAW_REORDER_BSF)+= vp9_raw_reorder_bsf.o
OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += vp9_superframe_bsf.o
OBJS-$(CONFIG_VP9_SUPERFRAME_SPLIT_BSF) += vp9_superframe_split_bsf.o
+OBJS-$(CONFIG_MOD_MPEG_SEQ_HEADER_BSF)+= mod_mpeg_seq_header_bsf.o
# thread libraries
OBJS-$(HAVE_LIBC_MSVCRT) += file_open.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index ce34de640d..dfe46e3e0c 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -44,6 +44,7 @@ extern const AVBitStreamFilter ff_text2movsub_bsf;
extern const AVBitStreamFilter ff_vp9_raw_reorder_bsf;
extern const AVBitStreamFilter ff_vp9_superframe_bsf;
extern const AVBitStreamFilter ff_vp9_superframe_split_bsf;
+extern const AVBitStreamFilter ff_mod_mpeg_seq_header_bsf;
#include "libavcodec/bsf_list.c"
diff --git a/libavcodec/mod_mpeg_seq_header_bsf.c
b/libavcodec/mod_mpeg_seq_header_bsf.c
new file mode 100644
index 00..824197746b
--- /dev/null
+++ b/libavcodec/mod_mpeg_seq_header_bsf.c
@@ -0,0 +1,102 @@
+/*
+ * Modify MPEG Sequence Headers bitstream filter
+ * Copyright (c) 2017 David Griffiths
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Modify MPEG Sequence Headers bitstream filter
+ */
+
+#include "avcodec.h"
+#include "bsf.h"
+#include "internal.h"
+
+#include "libavutil/opt.h"
+
+typedef struct ModifySeqHeaderContext {
+const AVClass *class;
+int aspect_ratio;
+int frame_rate;
+int done_log;
+} ModifySeqHeaderContext;
+
+/**
+ * This filter can be used to modify the sequence headers for aspect ratio
+ * and/or frame rate without the need for transcoding.
+ */
+static int mod_mpeg_seq_header_filter(AVBSFContext *ctx, AVPacket *out)
+{
+ModifySeqHeaderContext *s = ctx->priv_data;
+AVPacket *in;
+int ret;
+
+ret = ff_bsf_get_packet(ctx, &in);
+if (ret < 0)
+return ret;
+
+if (in->data[0] == 0 && in->data[1] == 0 && in->data[2] == 1 &&
+ in->data[3] == 0xb3) {
+if (!s->done_log)
+av_log(ctx, AV_LOG_INFO, "old aspect byte was %x\n", in->data[7]);
+if (s->aspect_ratio != 0) {
+in->data[7] = (s->aspect_ratio << 4) | (in->data[7] & 0xf);
Re: [FFmpeg-devel] [PATCH] Add new MPEG bitstream filter
Hi, I was not aware of that. I'm not that familiar with the differences between ffmpeg and libav. Do you know if the libav "coded bitstream editing" framework you mention is documented anywhere? Cheers, David On 1 August 2017 at 19:05, Jan Ekstrom wrote: > Hi, > > On Tue, Aug 1, 2017 at 3:22 PM, David Griffiths > wrote: >> Given an MPEG1/2 stream, this bitstream filter can be used to modify >> the sequence headers. The most common use would be to change the >> aspect ration without the need for re-encoding. Some MOD files have >> the aspect ratio incorrectly set to 4:3 >> (see https://en.wikipedia.org/wiki/MOD_and_TOD). > > Thanks for the contribution, but this looks like a limited version of > https://lists.libav.org/pipermail/libav-devel/2017-July/084528.html , > which seems to contain support for MPEG-2 bit stream filtering as > well. > > Please see if you can cherry-pick this patch set and test with it. The > framework posted on libav-devel seems more complete and seems to > support other formats than just MPEG-2 video. If it works for you, > feel free to post the patch set here as well. > > Best regards, > Jan > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add new MPEG bitstream filter
Hi, that certainly does sound as though it does the same as my patch plus more. I will download libav and have a play. Cheers, David On Tue, 1 Aug 2017 at 20:59, Mark Thompson wrote: > On 01/08/17 19:05, Jan Ekstrom wrote: > > Hi, > > > > On Tue, Aug 1, 2017 at 3:22 PM, David Griffiths > > wrote: > >> Given an MPEG1/2 stream, this bitstream filter can be used to modify > >> the sequence headers. The most common use would be to change the > >> aspect ration without the need for re-encoding. Some MOD files have > >> the aspect ratio incorrectly set to 4:3 > >> (see https://en.wikipedia.org/wiki/MOD_and_TOD). > > > > Thanks for the contribution, but this looks like a limited version of > > https://lists.libav.org/pipermail/libav-devel/2017-July/084528.html , > > which seems to contain support for MPEG-2 bit stream filtering as > > well. > I'm intending to bring this across myself soon. It's slightly awkward > because it's all written against Alexandra's bitstream API and would need > to be changed to get_bits here. (I was hoping the API would come at some > point, but apparently people here are generally against it. Oh well.) > > Anyway, I finished off a half-written MPEG-2 metadata filter which will do > the stuff described here: < > https://lists.libav.org/pipermail/libav-devel/2017-August/084563.html>. > I've ignored MPEG-1 so far, but it would probably be easy to add if anyone > cares. > > - Mark > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Andreas Cadhalpun wrote: Hi all, some of you may have noticed a weird ffmpeg package in the NEW queue[1]. Let me explain: ... ... ... and make kittens cry... ... ... ... Primary reason for Debian kittens crying right now... is ffmpeg being missing... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Mac/OSX question about clang + avfoundation + indev support
Summary: No clang or gcc invocation incantation seems to produce avfoundation indev support. Need someone smarter than me to suggest how I can debug this, to produce a Portfile fix for MacPorts. Thanks. ___ Yesterday I fired up ffmpeg to capture a MacBook Pro iSight Webcam stream. Sounds easy... Ugh... Not so... Here's the problem... (All examples using latest git pull.) David-Favor-iMac# git describe n2.0-10562-g229a1e8 First... let's see if configure knows enough to ferret out avfoundation... David-Favor-iMac# ./configure --list-indevs alsaiec61883pulse avfoundationjackqtkit bktrlavfi sndio dshow libcdio v4l2 dv1394 libdc1394 vfwcap fbdev openal x11grab gdigrab oss Great... configure discovers both avfoundation + old deprecated qtkit... So far so good... When configure runs... still looks good... Enabled indevs: avfoundationlavfi qtkit And compilation passes... ... CC libavdevice/avfoundation.o CC libavdevice/lavfi.o CC libavdevice/qtkit.o ... Adding or leaving out specific indev enabling has no effect on final executable... --enable-indev=qtkit --enable-indev=avfoundation The only effect is if clang is used, qtkit indev available + if gcc-4.8.2 used, then qtkit indev is missing. Neither clang or gcc-4.8.2 produces avfoundation indev. Compile system is latest OSX + XCode + MacPorts. David-Favor-iMac> xcodebuild -version Xcode 5.1.1 Build version 5B1008 David-Favor-iMac> clang --version clang version 3.4.2 (tags/RELEASE_34/dot2-final) Target: x86_64-apple-darwin13.3.0 Thread model: posix David-Favor-iMac> gcc --version gcc (MacPorts gcc48 4.8.2_2) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ___ David-Favor-iMac# ffmpeg -devices ffmpeg version 2.3.1-2014-08-01-65165-g229a1e8 Copyright (c) 2000-2014 the FFmpeg developers built on Aug 1 2014 10:13:00 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) configuration: --cc=/usr/bin/clang --prefix=/david-favor-tools/osx-10.9 --mandir=/david-favor-tools/osx-10.9/share/man --enable-gpl --enable-yasm --arch=x86_64 --enable-version3 --enable-pthreads --enable-shared --disable-static --disable-debug --extra-cflags='-I/david-favor-tools/osx-10.9/include -I/opt/local/include -I/usr/local/include -I/usr/include' --extra-ldflags='-Wl,-rpath,/david-favor-tools/osx-10.9/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/lib -L/david-favor-tools/osx-10.9/lib -L/opt/local/lib -L/usr/local/lib -L/usr/lib' --enable-ffplay --enable-ffprobe --enable-ffserver --enable-indev=qtkit --enable-indev=avfoundation --enable-runtime-cpudetect --enable-nonfree --enable-zlib --enable-bzlib --enable-openssl --enable-gnutls --enable-swscale --enable-avfilter --enable-avresample --enable-postproc --enable-vda --enable-libfribidi --enable-libmp3lame --enable-libfaac --enable-libfdk_aac --enable-libvpx --enable-libtheora --enable-libvorbis --enable-libxvid --enable-libopus --enable-libopenjpeg --enable-libschroedinger --enable-libspeex --enable-libbluray --enable-libx264 --enable-libx265 --enable-postproc --enable-frei0r --enable-libopencore-amrnb --enable-fontconfig --enable-libfreetype --enable-libmodplug --enable-libass libavutil 52. 94.100 / 52. 94.100 libavcodec 55. 71.100 / 55. 71.100 libavformat55. 50.100 / 55. 50.100 libavdevice55. 13.102 / 55. 13.102 libavfilter 4. 11.102 / 4. 11.102 libavresample 1. 3. 0 / 1. 3. 0 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 libpostproc52. 3.100 / 52. 3.100 Devices: D. = Demuxing supported .E = Muxing supported -- D lavfi Libavfilter virtual input device D qtkit QTKit input device E sdl SDL output device E xv XV (XVideo) output device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Mac/OSX question about clang + avfoundation + indev support
Additional information related to my first message. Building with gcc produces no trace of avfoundation support in full help. Building with clang shows... AVFoundation input device AVOptions: -list_devices .D.. list available devices (from 0 to 1) (default 0) true .D.. false.D.. -video_device_index .D.. select video device by index for devices with same name (starts at 0) (from -1 to INT_MAX) (default -1) -pixel_format .D.. set pixel format (default yuv420p) So many avfoundation is referenced through some sort of Libavfilter incantation. https://trac.ffmpeg.org/wiki/Capture/Webcam suggest no + maybe the docs are just missing some vital bit of information to use avfoundation. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/avfoundation: Add device category.
Thilo Borgmann wrote: Hi, as reported by David Favor, the AVFoundation device is not yet listed by "ffmpeg -devices". This patch fixes that. Please Apply. -Thilo Many thanks for the patch... ffmpeg -devices looks to be working now... David-Favor-iMac> ffmpeg -devices ffmpeg version 2.3.2-2014-08-15-65657-gedd0dc8 Copyright (c) 2000-2014 the FFmpeg developers built on Aug 15 2014 08:16:07 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) configuration: --cc=/usr/bin/clang --prefix=/david-favor-tools/osx-10.9 --mandir=/david-favor-tools/osx-10.9/share/man --enable-gpl --enable-yasm --arch=x86_64 --enable-version3 --enable-pthreads --enable-shared --disable-static --disable-debug --extra-cflags='-I/david-favor-tools/osx-10.9/include -I/opt/local/include -I/usr/local/include -I/usr/include' --extra-ldflags='-Wl,-rpath,/david-favor-tools/osx-10.9/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/lib -L/david-favor-tools/osx-10.9/lib -L/opt/local/lib -L/usr/local/lib -L/usr/lib' --enable-ffplay --enable-ffprobe --enable-ffserver --enable-indev=qtkit --enable-indev=avfoundation --enable-runtime-cpudetect --enable-nonfree --enable-zlib --enable-bzlib --enable-openssl --enable-gnutls --enable-swscale --enable-avfilter --enable-avresample --enable-postproc --enable-vda --enable-libfribidi --enable-libmp3lame --enable-libfaac --enable-libfdk_aac --enable-libvpx --enable-libtheora --enable-libvorbis --enable-libxvid --enable-libopus --enable-libopenjpeg --enable-libschroedinger --enable-libspeex --enable-libbluray --enable-libx264 --enable-libx265 --enable-postproc --enable-frei0r --enable-libopencore-amrnb --enable-fontconfig --enable-libfreetype --enable-libmodplug --enable-libass libavutil 54. 3.100 / 54. 3.100 libavcodec 56. 0.101 / 56. 0.101 libavformat56. 1.100 / 56. 1.100 libavdevice56. 0.100 / 56. 0.100 libavfilter 5. 0.100 / 5. 0.100 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 0.100 / 3. 0.100 libswresample 1. 0.100 / 1. 0.100 libpostproc53. 0.100 / 53. 0.100 Devices: D. = Demuxing supported .E = Muxing supported -- D avfoundationAVFoundation input device D lavfi Libavfilter virtual input device D qtkit QTKit input device E sdl SDL output device E xv XV (XVideo) output device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/vaapi_encode_av1: Set roi_quant_range
--- libavcodec/vaapi_encode_av1.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c index a46b882ab9..02a31b894d 100644 --- a/libavcodec/vaapi_encode_av1.c +++ b/libavcodec/vaapi_encode_av1.c @@ -155,6 +155,8 @@ static av_cold int vaapi_encode_av1_configure(AVCodecContext *avctx) priv->q_idx_idr = priv->q_idx_p = priv->q_idx_b = 128; } +ctx->roi_quant_range = AV1_MAX_QUANT; + return 0; } -- 2.44.0 ___ 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 v4] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
On Fri, Nov 24, 2023 at 8:27 AM Xiang, Haihao wrote:
>
> On Vr, 2023-10-27 at 22:25 +0200, David Rosca wrote:
> > This allows some optimizations in driver, such as not having to read
> > back the data if write-only mapping is requested.
> > ---
> > v4: overwrite + note about vaMapBuffer libva fallback
> >
> > libavutil/hwcontext_vaapi.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index 558fed94c6..435f10a7f3 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > VAStatus vas;
> > void *address = NULL;
> > int err, i;
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +uint32_t vaflags = 0;
> > +#endif
> >
> > surface_id = (VASurfaceID)(uintptr_t)src->data[3];
> > av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
> > @@ -882,7 +885,16 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > }
> > }
> >
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +if (flags & AV_HWFRAME_MAP_READ)
> > +vaflags |= VA_MAPBUFFER_FLAG_READ;
> > +if (flags & AV_HWFRAME_MAP_WRITE)
> > +vaflags |= VA_MAPBUFFER_FLAG_WRITE;
> > +// On drivers not implementing vaMapBuffer2 libva calls vaMapBuffer
> > instead.
> > +vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
> > +#else
> > vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
> > +#endif
> > if (vas != VA_STATUS_SUCCESS) {
> > av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
> > "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
>
> LGTM, and will apply it when the official libva 2.21 is released.
Ping, libva 2.21 has now been released.
Thanks,
David
>
> Thanks
> Haihao
>
>
___
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/2] lavc/vaapi_decode: Make it possible to send multiple slice params buffers
---
libavcodec/vaapi_av1.c| 2 +-
libavcodec/vaapi_decode.c | 3 ++-
libavcodec/vaapi_decode.h | 1 +
libavcodec/vaapi_h264.c | 2 +-
libavcodec/vaapi_hevc.c | 4 ++--
libavcodec/vaapi_mjpeg.c | 2 +-
libavcodec/vaapi_mpeg2.c | 2 +-
libavcodec/vaapi_mpeg4.c | 2 +-
libavcodec/vaapi_vc1.c| 2 +-
libavcodec/vaapi_vp8.c| 2 +-
libavcodec/vaapi_vp9.c| 2 +-
11 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 1f563483b9..4a90db1e09 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -409,7 +409,7 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
.tg_end= s->tg_end,
};
-err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param,
+err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param, 1,
sizeof(VASliceParameterBufferAV1),
buffer,
size);
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 21b273cd0f..8e9f647c20 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -63,6 +63,7 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
VAAPIDecodePicture *pic,
const void *params_data,
+ int nb_params,
size_t params_size,
const void *slice_data,
size_t slice_size)
@@ -88,7 +89,7 @@ int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
VASliceParameterBufferType,
- params_size, 1, (void*)params_data,
+ params_size, nb_params, (void*)params_data,
&pic->slice_buffers[index]);
if (vas != VA_STATUS_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to create slice "
diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h
index 6beda14e52..702171e108 100644
--- a/libavcodec/vaapi_decode.h
+++ b/libavcodec/vaapi_decode.h
@@ -73,6 +73,7 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
VAAPIDecodePicture *pic,
const void *params_data,
+ int nb_params,
size_t params_size,
const void *slice_data,
size_t slice_size);
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index 55cf5a05ee..b47531ce1c 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -375,7 +375,7 @@ static int vaapi_h264_decode_slice(AVCodecContext *avctx,
slice_param.chroma_offset_l1);
err = ff_vaapi_decode_make_slice_buffer(avctx, pic,
-&slice_param, sizeof(slice_param),
+&slice_param, 1,
sizeof(slice_param),
buffer, size);
if (err) {
ff_vaapi_decode_cancel(avctx, pic);
diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index 3bdd2dd1b8..3937b7574a 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/vaapi_hevc.c
@@ -353,7 +353,7 @@ static int vaapi_hevc_end_frame(AVCodecContext *avctx)
if (pic->last_size) {
last_slice_param->LongSliceFlags.fields.LastSliceOfPic = 1;
ret = ff_vaapi_decode_make_slice_buffer(avctx, &pic->pic,
-&pic->last_slice_param,
slice_param_size,
+&pic->last_slice_param, 1,
slice_param_size,
pic->last_buffer,
pic->last_size);
if (ret < 0)
goto fail;
@@ -471,7 +471,7 @@ static int vaapi_hevc_decode_slice(AVCodecContext *avctx,
if (!sh->first_slice_in_pic_flag) {
err = ff_vaapi_decode_make_slice_buffer(avctx, &pic->pic,
-&pic->last_slice_param,
slice_param_size,
+&pic->last_slice_param, 1,
slice_param_size,
pic->last_buffer,
pic->last_size);
pic->last_buffer = NULL;
pic->last_size = 0;
diff --git a/libavcodec/vaapi_mjpeg.c b/libavcodec/vaapi_mjpeg.c
index 5b8d47bb2a..9557cf5f9b 100644
--- a/libavcodec/vaapi_mjpeg.c
+++ b/libavcodec/vaapi_mjpeg.c
@@ -131,7 +131,7 @@ static int vaapi_mjpe
[FFmpeg-devel] [PATCH 2/2] lavc/vaapi_av1: Avoid sending the same slice buffer multiple times
When there are multiple tiles in one slice buffer, use multiple slice
params to avoid sending the same slice buffer multiple times and thus
increasing the bitstream size the driver will need to upload to hw.
---
libavcodec/vaapi_av1.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 4a90db1e09..567f505fbd 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -19,6 +19,7 @@
*/
#include "libavutil/frame.h"
+#include "libavutil/mem.h"
#include "hwaccel_internal.h"
#include "vaapi_decode.h"
#include "internal.h"
@@ -393,13 +394,17 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
{
const AV1DecContext *s = avctx->priv_data;
VAAPIDecodePicture *pic = s->cur_frame.hwaccel_picture_private;
-VASliceParameterBufferAV1 slice_param;
-int err = 0;
+VASliceParameterBufferAV1 *slice_params;
+int err = 0, nb_params = 0;
-for (int i = s->tg_start; i <= s->tg_end; i++) {
-memset(&slice_param, 0, sizeof(VASliceParameterBufferAV1));
+slice_params = av_calloc(s->tg_end - s->tg_start + 1,
sizeof(*slice_params));
+if (!slice_params) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
-slice_param = (VASliceParameterBufferAV1) {
+for (int i = s->tg_start; i <= s->tg_end; i++) {
+slice_params[nb_params++] = (VASliceParameterBufferAV1) {
.slice_data_size = s->tile_group_info[i].tile_size,
.slice_data_offset = s->tile_group_info[i].tile_offset,
.slice_data_flag = VA_SLICE_DATA_FLAG_ALL,
@@ -408,18 +413,22 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
.tg_start = s->tg_start,
.tg_end= s->tg_end,
};
-
-err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param, 1,
-
sizeof(VASliceParameterBufferAV1),
-buffer,
-size);
-if (err) {
-ff_vaapi_decode_cancel(avctx, pic);
-return err;
-}
}
+err = ff_vaapi_decode_make_slice_buffer(avctx, pic, slice_params,
nb_params,
+sizeof(VASliceParameterBufferAV1),
+buffer,
+size);
+av_free(slice_params);
+
+if (err)
+goto fail;
+
return 0;
+
+fail:
+ff_vaapi_decode_cancel(avctx, pic);
+return err;
}
const FFHWAccel ff_av1_vaapi_hwaccel = {
--
2.44.0
___
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/vaapi_h264: Don't try to merge fields in DPB for non-field pics
This path can be hit when there are missing references while decoding
progressive stream and would completely break the DPB contents.
---
libavcodec/vaapi_h264.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index b47531ce1c..ca0076f57a 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -98,22 +98,24 @@ static int dpb_add(DPB *dpb, const H264Picture *pic)
if (dpb->size >= dpb->max_size)
return -1;
-for (i = 0; i < dpb->size; i++) {
-VAPictureH264 * const va_pic = &dpb->va_pics[i];
-if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) {
-VAPictureH264 temp_va_pic;
-fill_vaapi_pic(&temp_va_pic, pic, 0);
-
-if ((temp_va_pic.flags ^ va_pic->flags) &
(VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD)) {
-va_pic->flags |= temp_va_pic.flags &
(VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD);
-/* Merge second field */
-if (temp_va_pic.flags & VA_PICTURE_H264_TOP_FIELD) {
-va_pic->TopFieldOrderCnt= temp_va_pic.TopFieldOrderCnt;
-} else {
-va_pic->BottomFieldOrderCnt =
temp_va_pic.BottomFieldOrderCnt;
+if (pic->field_picture) {
+for (i = 0; i < dpb->size; i++) {
+VAPictureH264 * const va_pic = &dpb->va_pics[i];
+if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) {
+VAPictureH264 temp_va_pic;
+fill_vaapi_pic(&temp_va_pic, pic, 0);
+
+if ((temp_va_pic.flags ^ va_pic->flags) &
(VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD)) {
+va_pic->flags |= temp_va_pic.flags &
(VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD);
+/* Merge second field */
+if (temp_va_pic.flags & VA_PICTURE_H264_TOP_FIELD) {
+va_pic->TopFieldOrderCnt=
temp_va_pic.TopFieldOrderCnt;
+} else {
+va_pic->BottomFieldOrderCnt =
temp_va_pic.BottomFieldOrderCnt;
+}
}
+return 0;
}
-return 0;
}
}
--
2.45.0
___
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/vaapi_h264: Fix merging fields in DPB with missing references
If there are missing references, h264 decode does error concealment
by copying previous refs which means there will be duplicated surfaces
and this code would try to merge them instead of correctly appending
to DPB. Make sure the fields were actually merged before early return.
---
libavcodec/vaapi_h264.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index b47531ce1c..c62a320e97 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -112,8 +112,9 @@ static int dpb_add(DPB *dpb, const H264Picture *pic)
} else {
va_pic->BottomFieldOrderCnt =
temp_va_pic.BottomFieldOrderCnt;
}
+return 0;
}
-return 0;
+break;
}
}
--
2.45.0
___
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/vaapi_h264: Don't try to merge fields in DPB for non-field pics
On Mon, May 6, 2024 at 9:55 PM Mark Thompson wrote:
>
> On 05/05/2024 17:36, David Rosca wrote:
> > This path can be hit when there are missing references while decoding
> > progressive stream and would completely break the DPB contents.
> > ---
> > libavcodec/vaapi_h264.c | 30 --
> > 1 file changed, 16 insertions(+), 14 deletions(-)
>
> Can you share a stream which does this in a progressive case?
https://github.com/nowrep/chiaki4deck/raw/samples/samples/missingframes.h264
>
> My understanding of this (though I suspect I am missing something) is that we
> are filling from the short/long DPB lists which should not contain duplicates
> (not RefPicListX, which can), so I'm not seeing how this case could be
> triggered.
>
> If you do have two DPB entries which are different frames but refer to the
> same surface then that seems like a bug elsewhere.
It comes from the error concealment in h264dec which copies previous
ref for missing refs. It can actually also happen for interlaced
streams. I've sent a new patch that should fix it for both progressive
and interlaced.
https://github.com/FFmpeg/FFmpeg/blob/b1037d4ebe7b7f9548ce1ed24a2929aedbe9a27a/libavcodec/h264_slice.c#L1520-L1559
Thanks,
David
>
> Thanks,
>
> - Mark
>
>
> > diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
> > index b47531ce1c..ca0076f57a 100644
> > --- a/libavcodec/vaapi_h264.c
> > +++ b/libavcodec/vaapi_h264.c
> > @@ -98,22 +98,24 @@ static int dpb_add(DPB *dpb, const H264Picture *pic)
> > if (dpb->size >= dpb->max_size)
> > return -1;
> >
> > -for (i = 0; i < dpb->size; i++) {
> > -VAPictureH264 * const va_pic = &dpb->va_pics[i];
> > -if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) {
> > -VAPictureH264 temp_va_pic;
> > -fill_vaapi_pic(&temp_va_pic, pic, 0);
> > -
> > -if ((temp_va_pic.flags ^ va_pic->flags) &
> > (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD)) {
> > -va_pic->flags |= temp_va_pic.flags &
> > (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD);
> > -/* Merge second field */
> > -if (temp_va_pic.flags & VA_PICTURE_H264_TOP_FIELD) {
> > -va_pic->TopFieldOrderCnt=
> > temp_va_pic.TopFieldOrderCnt;
> > -} else {
> > -va_pic->BottomFieldOrderCnt =
> > temp_va_pic.BottomFieldOrderCnt;
> > +if (pic->field_picture) {
> > +for (i = 0; i < dpb->size; i++) {
> > +VAPictureH264 * const va_pic = &dpb->va_pics[i];
> > +if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) {
> > +VAPictureH264 temp_va_pic;
> > +fill_vaapi_pic(&temp_va_pic, pic, 0);
> > +
> > +if ((temp_va_pic.flags ^ va_pic->flags) &
> > (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD)) {
> > +va_pic->flags |= temp_va_pic.flags &
> > (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD);
> > +/* Merge second field */
> > +if (temp_va_pic.flags & VA_PICTURE_H264_TOP_FIELD) {
> > +va_pic->TopFieldOrderCnt=
> > temp_va_pic.TopFieldOrderCnt;
> > +} else {
> > +va_pic->BottomFieldOrderCnt =
> > temp_va_pic.BottomFieldOrderCnt;
> > +}
> > }
> > +return 0;
> > }
> > -return 0;
> > }
> > }
> >
> ___
> 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] [PATCH v2 1/2] lavc/vaapi_decode: Make it possible to send multiple slice params buffers
---
v2: No changes
libavcodec/vaapi_av1.c| 2 +-
libavcodec/vaapi_decode.c | 3 ++-
libavcodec/vaapi_decode.h | 1 +
libavcodec/vaapi_h264.c | 2 +-
libavcodec/vaapi_hevc.c | 4 ++--
libavcodec/vaapi_mjpeg.c | 2 +-
libavcodec/vaapi_mpeg2.c | 2 +-
libavcodec/vaapi_mpeg4.c | 2 +-
libavcodec/vaapi_vc1.c| 2 +-
libavcodec/vaapi_vp8.c| 2 +-
libavcodec/vaapi_vp9.c| 2 +-
11 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 1f563483b9..4a90db1e09 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -409,7 +409,7 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
.tg_end= s->tg_end,
};
-err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param,
+err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param, 1,
sizeof(VASliceParameterBufferAV1),
buffer,
size);
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 21b273cd0f..8e9f647c20 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -63,6 +63,7 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
VAAPIDecodePicture *pic,
const void *params_data,
+ int nb_params,
size_t params_size,
const void *slice_data,
size_t slice_size)
@@ -88,7 +89,7 @@ int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
VASliceParameterBufferType,
- params_size, 1, (void*)params_data,
+ params_size, nb_params, (void*)params_data,
&pic->slice_buffers[index]);
if (vas != VA_STATUS_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to create slice "
diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h
index 6beda14e52..702171e108 100644
--- a/libavcodec/vaapi_decode.h
+++ b/libavcodec/vaapi_decode.h
@@ -73,6 +73,7 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
VAAPIDecodePicture *pic,
const void *params_data,
+ int nb_params,
size_t params_size,
const void *slice_data,
size_t slice_size);
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index 55cf5a05ee..b47531ce1c 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -375,7 +375,7 @@ static int vaapi_h264_decode_slice(AVCodecContext *avctx,
slice_param.chroma_offset_l1);
err = ff_vaapi_decode_make_slice_buffer(avctx, pic,
-&slice_param, sizeof(slice_param),
+&slice_param, 1,
sizeof(slice_param),
buffer, size);
if (err) {
ff_vaapi_decode_cancel(avctx, pic);
diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index 3bdd2dd1b8..3937b7574a 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/vaapi_hevc.c
@@ -353,7 +353,7 @@ static int vaapi_hevc_end_frame(AVCodecContext *avctx)
if (pic->last_size) {
last_slice_param->LongSliceFlags.fields.LastSliceOfPic = 1;
ret = ff_vaapi_decode_make_slice_buffer(avctx, &pic->pic,
-&pic->last_slice_param,
slice_param_size,
+&pic->last_slice_param, 1,
slice_param_size,
pic->last_buffer,
pic->last_size);
if (ret < 0)
goto fail;
@@ -471,7 +471,7 @@ static int vaapi_hevc_decode_slice(AVCodecContext *avctx,
if (!sh->first_slice_in_pic_flag) {
err = ff_vaapi_decode_make_slice_buffer(avctx, &pic->pic,
-&pic->last_slice_param,
slice_param_size,
+&pic->last_slice_param, 1,
slice_param_size,
pic->last_buffer,
pic->last_size);
pic->last_buffer = NULL;
pic->last_size = 0;
diff --git a/libavcodec/vaapi_mjpeg.c b/libavcodec/vaapi_mjpeg.c
index 5b8d47bb2a..9557cf5f9b 100644
--- a/libavcodec/vaapi_mjpeg.c
+++ b/libavcodec/vaapi_mjpeg.c
@@ -131,7 +131,7 @@ stati
[FFmpeg-devel] [PATCH v2 2/2] lavc/vaapi_av1: Avoid sending the same slice buffer multiple times
When there are multiple tiles in one slice buffer, use multiple slice
params to avoid sending the same slice buffer multiple times and thus
increasing the bitstream size the driver will need to upload to hw.
---
v2: Avoid allocations every slice.
libavcodec/vaapi_av1.c | 47 +-
1 file changed, 33 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 4a90db1e09..4ee33a3ae3 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -19,6 +19,7 @@
*/
#include "libavutil/frame.h"
+#include "libavutil/mem.h"
#include "hwaccel_internal.h"
#include "vaapi_decode.h"
#include "internal.h"
@@ -42,6 +43,9 @@ typedef struct VAAPIAV1DecContext {
*/
VAAPIAV1FrameRef ref_tab[AV1_NUM_REF_FRAMES];
AVFrame *tmp_frame;
+
+int nb_slice_params;
+VASliceParameterBufferAV1 *slice_params;
} VAAPIAV1DecContext;
static VASurfaceID vaapi_av1_surface_id(AV1Frame *vf)
@@ -97,6 +101,8 @@ static int vaapi_av1_decode_uninit(AVCodecContext *avctx)
for (int i = 0; i < FF_ARRAY_ELEMS(ctx->ref_tab); i++)
av_frame_free(&ctx->ref_tab[i].frame);
+av_freep(&ctx->slice_params);
+
return ff_vaapi_decode_uninit(avctx);
}
@@ -393,13 +399,24 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
{
const AV1DecContext *s = avctx->priv_data;
VAAPIDecodePicture *pic = s->cur_frame.hwaccel_picture_private;
-VASliceParameterBufferAV1 slice_param;
-int err = 0;
+VAAPIAV1DecContext *ctx = avctx->internal->hwaccel_priv_data;
+int err, nb_params;
+
+nb_params = s->tg_end - s->tg_start + 1;
+if (ctx->nb_slice_params < nb_params) {
+ctx->slice_params = av_realloc_array(ctx->slice_params,
+ nb_params,
+ sizeof(*ctx->slice_params));
+if (!ctx->slice_params) {
+ctx->nb_slice_params = 0;
+err = AVERROR(ENOMEM);
+goto fail;
+}
+ctx->nb_slice_params = nb_params;
+}
for (int i = s->tg_start; i <= s->tg_end; i++) {
-memset(&slice_param, 0, sizeof(VASliceParameterBufferAV1));
-
-slice_param = (VASliceParameterBufferAV1) {
+ctx->slice_params[i - s->tg_start] = (VASliceParameterBufferAV1) {
.slice_data_size = s->tile_group_info[i].tile_size,
.slice_data_offset = s->tile_group_info[i].tile_offset,
.slice_data_flag = VA_SLICE_DATA_FLAG_ALL,
@@ -408,18 +425,20 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
.tg_start = s->tg_start,
.tg_end= s->tg_end,
};
-
-err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param, 1,
-
sizeof(VASliceParameterBufferAV1),
-buffer,
-size);
-if (err) {
-ff_vaapi_decode_cancel(avctx, pic);
-return err;
-}
}
+err = ff_vaapi_decode_make_slice_buffer(avctx, pic, ctx->slice_params,
nb_params,
+sizeof(VASliceParameterBufferAV1),
+buffer,
+size);
+if (err)
+goto fail;
+
return 0;
+
+fail:
+ff_vaapi_decode_cancel(avctx, pic);
+return err;
}
const FFHWAccel ff_av1_vaapi_hwaccel = {
--
2.45.0
___
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 2/2] lavc/vaapi_av1: Avoid sending the same slice buffer multiple times
On Tue, May 7, 2024 at 10:01 PM Mark Thompson wrote:
>
> On 28/04/2024 08:26, David Rosca wrote:
> > When there are multiple tiles in one slice buffer, use multiple slice
> > params to avoid sending the same slice buffer multiple times and thus
> > increasing the bitstream size the driver will need to upload to hw.
> > ---
> > libavcodec/vaapi_av1.c | 37 +++--
> > 1 file changed, 23 insertions(+), 14 deletions(-)
>
> Can you confirm that this works on at least iHD (Intel) and Mesa (AMD)? (I
> don't expect any issue, but it's good to check in case of something strange
> going on matching up to what this was previously doing.)
I've tested with Mesa and it works correctly. Gstreamer also does the same.
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/da35ed69164ba8c8599d337b00ba54074215f7e7/subprojects/gst-plugins-bad/sys/va/gstvaav1dec.c#L891-L912
>
> > diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> > index 4a90db1e09..567f505fbd 100644
> > --- a/libavcodec/vaapi_av1.c
> > +++ b/libavcodec/vaapi_av1.c
> > @@ -19,6 +19,7 @@
> > */
> >
> > #include "libavutil/frame.h"
> > +#include "libavutil/mem.h"
> > #include "hwaccel_internal.h"
> > #include "vaapi_decode.h"
> > #include "internal.h"
> > @@ -393,13 +394,17 @@ static int vaapi_av1_decode_slice(AVCodecContext
> > *avctx,
> > {
> > const AV1DecContext *s = avctx->priv_data;
> > VAAPIDecodePicture *pic = s->cur_frame.hwaccel_picture_private;
> > -VASliceParameterBufferAV1 slice_param;
> > -int err = 0;
> > +VASliceParameterBufferAV1 *slice_params;
> > +int err = 0, nb_params = 0;
>
> Remove the spurious initialisation on err?
Done in v2.
>
> >
> > -for (int i = s->tg_start; i <= s->tg_end; i++) {
> > -memset(&slice_param, 0, sizeof(VASliceParameterBufferAV1));
> > +slice_params = av_calloc(s->tg_end - s->tg_start + 1,
> > sizeof(*slice_params));
>
> I suggest allocating this into VAAPIAV1DecContext to avoid the alloc/free on
> every call. (Only reallocate if it needs to be bigger than the previous
> maximum.)
Done in v2.
Thanks,
David
>
> > +if (!slice_params) {
> > +err = AVERROR(ENOMEM);
> > +goto fail;
> > +}
> >
> > -slice_param = (VASliceParameterBufferAV1) {
> > +for (int i = s->tg_start; i <= s->tg_end; i++) {
> > +slice_params[nb_params++] = (VASliceParameterBufferAV1) {
> > .slice_data_size = s->tile_group_info[i].tile_size,
> > .slice_data_offset = s->tile_group_info[i].tile_offset,
> > .slice_data_flag = VA_SLICE_DATA_FLAG_ALL,
> > @@ -408,18 +413,22 @@ static int vaapi_av1_decode_slice(AVCodecContext
> > *avctx,
> > .tg_start = s->tg_start,
> > .tg_end= s->tg_end,
> > };
> > -
> > -err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param,
> > 1,
> > -
> > sizeof(VASliceParameterBufferAV1),
> > -buffer,
> > -size);
> > -if (err) {
> > -ff_vaapi_decode_cancel(avctx, pic);
> > -return err;
> > -}
> > }
> >
> > +err = ff_vaapi_decode_make_slice_buffer(avctx, pic, slice_params,
> > nb_params,
> > +
> > sizeof(VASliceParameterBufferAV1),
> > +buffer,
> > +size);
> > +av_free(slice_params);
> > +
> > +if (err)
> > +goto fail;
> > +
> > return 0;
> > +
> > +fail:
> > +ff_vaapi_decode_cancel(avctx, pic);
> > +return err;
> > }
> >
> > const FFHWAccel ff_av1_vaapi_hwaccel = {
>
> It's amusing that this quadratic behaviour was around for so long! (I guess
> people don't use many tiles.)
>
> Thanks,
>
> - Mark
> ___
> 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] [PATCH v2] lavc/vaapi_h264: Fix merging fields in DPB with missing references
If there are missing references, h264 decode does error concealment
by copying previous refs which means there will be duplicated surfaces.
Check long_ref and frame_idx in addition to surface when looking for
the other field to avoid trying to merge with wrong picture.
Also allow to merge with multiple pictures in case there are duplicates
of the other field.
---
v2: Check long_ref/frame_idx + multiple merge
libavcodec/vaapi_h264.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index b47531ce1c..398e92568c 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -93,14 +93,19 @@ typedef struct DPB {
*/
static int dpb_add(DPB *dpb, const H264Picture *pic)
{
-int i;
+int i, pic_frame_idx, merged = 0;
if (dpb->size >= dpb->max_size)
return -1;
+pic_frame_idx = pic->long_ref ? pic->pic_id : pic->frame_num;
+
for (i = 0; i < dpb->size; i++) {
VAPictureH264 * const va_pic = &dpb->va_pics[i];
-if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) {
+int va_pic_long_ref = !!(va_pic->flags &
VA_PICTURE_H264_LONG_TERM_REFERENCE);
+if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f) &&
+va_pic_long_ref == pic->long_ref &&
+va_pic->frame_idx == pic_frame_idx) {
VAPictureH264 temp_va_pic;
fill_vaapi_pic(&temp_va_pic, pic, 0);
@@ -112,11 +117,14 @@ static int dpb_add(DPB *dpb, const H264Picture *pic)
} else {
va_pic->BottomFieldOrderCnt =
temp_va_pic.BottomFieldOrderCnt;
}
+merged = 1;
}
-return 0;
}
}
+if (merged)
+return 0;
+
fill_vaapi_pic(&dpb->va_pics[dpb->size++], pic, 0);
return 0;
}
--
2.45.0
___
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/vaapi_h264: Fix merging fields in DPB with missing references
On Tue, May 7, 2024 at 10:22 PM Mark Thompson wrote:
>
> On 07/05/2024 07:00, David Rosca wrote:
> > If there are missing references, h264 decode does error concealment
> > by copying previous refs which means there will be duplicated surfaces
> > and this code would try to merge them instead of correctly appending
> > to DPB. Make sure the fields were actually merged before early return.
> > ---
> > libavcodec/vaapi_h264.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
> > index b47531ce1c..c62a320e97 100644
> > --- a/libavcodec/vaapi_h264.c
> > +++ b/libavcodec/vaapi_h264.c
> > @@ -112,8 +112,9 @@ static int dpb_add(DPB *dpb, const H264Picture *pic)
> > } else {
> > va_pic->BottomFieldOrderCnt =
> > temp_va_pic.BottomFieldOrderCnt;
> > }
> > +return 0;
> > }
> > -return 0;
> > +break;
> > }
> > }
> >
>
> I agree that the old code did nasty things, but can you explain a bit more
> about the reasoning for what you've got now?
>
> I'm thinking that given duplication a top field could appear twice, so you'd
> want to merge twice if you have the matching bottom field.
Right, that may be possible.
Also I've looked at vdpau code and there it checks frame_num (in
addition to surface) when searching for the other field, which seems
better to avoid trying to merge when it should not. Posted v2 with
this change + multiple merge.
Thanks,
David
>
> Thanks,
>
> - Mark
> ___
> 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] [PATCH] lavc/vaapi_decode: Reject decoding of frames with no slices
Matches other hwaccels.
---
libavcodec/vaapi_decode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 8e9f647c20..3c4030c073 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -157,6 +157,11 @@ int ff_vaapi_decode_issue(AVCodecContext *avctx,
VAStatus vas;
int err;
+if (pic->nb_slices <= 0) {
+err = -1;
+goto fail;
+}
+
av_log(avctx, AV_LOG_DEBUG, "Decode to surface %#x.\n",
pic->output_surface);
--
2.45.0
___
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 v2] lavc/vaapi_decode: Reject decoding of frames with no slices
Matches other hwaccels.
---
v2: AVERROR
libavcodec/vaapi_decode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 8e9f647c20..7c91d50f7b 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -157,6 +157,11 @@ int ff_vaapi_decode_issue(AVCodecContext *avctx,
VAStatus vas;
int err;
+if (pic->nb_slices <= 0) {
+err = AVERROR(EINVAL);
+goto fail;
+}
+
av_log(avctx, AV_LOG_DEBUG, "Decode to surface %#x.\n",
pic->output_surface);
--
2.45.0
___
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] avcodec/proresenc_anatoliy: change quantization scaling to floating point to utilize vectorization
Quantization scaling seems to be a slight bottleneck,
this change allows the compiler to more easily vectorize
the loop. This improves total encoding performance in my
tests by about 10-20%.
Signed-off-by: David Murmann
---
libavcodec/proresenc_anatoliy.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/proresenc_anatoliy.c
b/libavcodec/proresenc_anatoliy.c
index 0516066163..8b296f6f1b 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec/proresenc_anatoliy.c
@@ -232,14 +232,18 @@ static const uint8_t lev_to_cb[10] = { 0x04, 0x0A,
0x05, 0x06, 0x04, 0x28,
static void encode_ac_coeffs(AVCodecContext *avctx, PutBitContext *pb,
int16_t *in, int blocks_per_slice, int *qmat)
{
+int16_t block[64];
int prev_run = 4;
int prev_level = 2;
int run = 0, level, code, i, j;
-for (i = 1; i < 64; i++) {
-int indp = progressive_scan[i];
-for (j = 0; j < blocks_per_slice; j++) {
-int val = QSCALE(qmat, indp, in[(j << 6) + indp]);
+for (j = 0; j < blocks_per_slice; j++) {
+for (i = 0; i < 64; i++) {
+block[i] = (float)in[(j << 6) + i] / (float)qmat[i];
+}
+
+for (i = 1; i < 64; i++) {
+int val = block[progressive_scan[i]];
if (val) {
encode_codeword(pb, run, run_to_cb[FFMIN(prev_run, 15)]);
-- 2.16.2
--
btf GmbH | Leyendeckerstr. 27, 50825 Köln | +49 (0) 221 82 00 87 10
Geschäftsführer: Philipp Käßbohrer & Matthias Murmann | HR Köln | HRB 74707
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/proresenc_anatoliy: change quantization scaling to floating point to utilize vectorization
On 2/27/2018 9:58 PM, Hendrik Leppkes wrote:
> On Tue, Feb 27, 2018 at 9:35 PM, David Murmann
wrote:
>> Quantization scaling seems to be a slight bottleneck,
>> this change allows the compiler to more easily vectorize
>> the loop. This improves total encoding performance in my
>> tests by about 10-20%.
>>
>> Signed-off-by: David Murmann
>> ---
>> libavcodec/proresenc_anatoliy.c | 12
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
[...]
>> +for (j = 0; j < blocks_per_slice; j++) {
>> +for (i = 0; i < 64; i++) {
>> +block[i] = (float)in[(j << 6) + i] / (float)qmat[i];
>> +}
>> +
>> +for (i = 1; i < 64; i++) {
>> +int val = block[progressive_scan[i]];
>> if (val) {
>> encode_codeword(pb, run, run_to_cb[FFMIN(prev_run,
15)]);
>
> Usually, using float is best avoided. Did you test re-factoring the
> loop structure without changing it to float?
Yes, the vector instructions don't have integer division, AFAIK, and the
compiler just generates a loop with idivs. This is quite a bit slower
than converting to float, dividing and converting back, if the compiler
uses vector instructions. In the general case this wouldn't be exact,
but since the input values are int16 they should losslessly fit into
float32. On platforms where this auto-vectorization fails this might
actually be quite a bit slower, but I have not seen that in my tests
(though I have only tested on x86_64).
--
David Murmann
da...@btf.de
Telefon +49 (0) 221 82008710
Fax +49 (0) 221 82008799
http://btf.de/
--
btf GmbH | Leyendeckerstr. 27, 50825 Köln | +49 (0) 221 82 00 87 10
Geschäftsführer: Philipp Käßbohrer & Matthias Murmann | HR Köln | HRB 74707
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/vaapi_encode: Add filler_data option
---
libavcodec/vaapi_encode.c | 1 +
libavcodec/vaapi_encode.h | 9 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index bfca315a7a..f161c76304 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1860,6 +1860,7 @@ rc_mode_found:
#if VA_CHECK_VERSION(1, 3, 0)
.quality_factor = rc_quality,
#endif
+.rc_flags.bits.disable_bit_stuffing = !ctx->filler_data,
};
vaapi_encode_add_global_param(avctx,
VAEncMiscParameterTypeRateControl,
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index a1e639f56b..a2170cb8b0 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -198,6 +198,9 @@ typedef struct VAAPIEncodeContext {
// Max Frame Size
int max_frame_size;
+// Filler Data
+int filler_data;
+
// Explicitly set RC mode (otherwise attempt to pick from
// available modes).
int explicit_rc_mode;
@@ -490,7 +493,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
{ "max_frame_size", \
"Maximum frame size (in bytes)",\
OFFSET(common.max_frame_size), AV_OPT_TYPE_INT, \
- { .i64 = 0 }, 0, INT_MAX, FLAGS }
+ { .i64 = 0 }, 0, INT_MAX, FLAGS }, \
+{ "filler_data", \
+ "Enable filler data", \
+ OFFSET(common.filler_data), AV_OPT_TYPE_BOOL, \
+ { .i64 = 1 }, 0, 1, FLAGS }
#define VAAPI_ENCODE_RC_MODE(name, desc) \
{ #name, desc, 0, AV_OPT_TYPE_CONST, { .i64 = RC_MODE_ ## name }, \
--
2.41.0
___
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 v2] lavc/vaapi_encode: Add filler_data option
v2: Add description in encoders.texi
---
doc/encoders.texi | 3 +++
libavcodec/vaapi_encode.c | 1 +
libavcodec/vaapi_encode.h | 9 -
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 25d6b7f09e..f146942aa5 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3963,6 +3963,9 @@ Set the allowed max size in bytes for each frame. If the
frame size exceeds
the limitation, encoder will adjust the QP value to control the frame size.
Invalid in CQP rate control mode.
+@item filler_data
+Insert filler data in CBR rate control mode to ensure target bitrate.
+
@item rc_mode
Set the rate control mode to use. A given driver may only support a subset of
modes.
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index bfca315a7a..f161c76304 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1860,6 +1860,7 @@ rc_mode_found:
#if VA_CHECK_VERSION(1, 3, 0)
.quality_factor = rc_quality,
#endif
+.rc_flags.bits.disable_bit_stuffing = !ctx->filler_data,
};
vaapi_encode_add_global_param(avctx,
VAEncMiscParameterTypeRateControl,
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index a1e639f56b..a2170cb8b0 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -198,6 +198,9 @@ typedef struct VAAPIEncodeContext {
// Max Frame Size
int max_frame_size;
+// Filler Data
+int filler_data;
+
// Explicitly set RC mode (otherwise attempt to pick from
// available modes).
int explicit_rc_mode;
@@ -490,7 +493,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
{ "max_frame_size", \
"Maximum frame size (in bytes)",\
OFFSET(common.max_frame_size), AV_OPT_TYPE_INT, \
- { .i64 = 0 }, 0, INT_MAX, FLAGS }
+ { .i64 = 0 }, 0, INT_MAX, FLAGS }, \
+{ "filler_data", \
+ "Enable filler data", \
+ OFFSET(common.filler_data), AV_OPT_TYPE_BOOL, \
+ { .i64 = 1 }, 0, 1, FLAGS }
#define VAAPI_ENCODE_RC_MODE(name, desc) \
{ #name, desc, 0, AV_OPT_TYPE_CONST, { .i64 = RC_MODE_ ## name }, \
--
2.41.0
___
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] lavu/hwcontext_vaapi: Add vaapi_drm_format_map support for x2rgb10
Support for allocating frames with x2rgb10 format was added
in c00264f5013, this adds support for importing DMA-BUFs.
---
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 6c3a227ddd..63544ce476 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1048,6 +1048,9 @@ static const struct {
#if defined(VA_FOURCC_Y412) && defined(DRM_FORMAT_XVYU12_16161616)
DRM_MAP(Y412, 1, DRM_FORMAT_XVYU12_16161616),
#endif
+#ifdef defined(VA_FOURCC_X2R10G10B10) && defined(DRM_FORMAT_XRGB2101010)
+DRM_MAP(X2R10G10B10, 1, DRM_FORMAT_XRGB2101010),
+#endif
};
#undef DRM_MAP
--
2.41.0
___
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 v2] lavu/hwcontext_vaapi: Add vaapi_drm_format_map support for x2rgb10
Support for allocating frames with x2rgb10 format was added
in c00264f5013, this adds support for importing DMA-BUFs.
v2: Fix #ifdef -> #if
---
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 6c3a227ddd..558fed94c6 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1048,6 +1048,9 @@ static const struct {
#if defined(VA_FOURCC_Y412) && defined(DRM_FORMAT_XVYU12_16161616)
DRM_MAP(Y412, 1, DRM_FORMAT_XVYU12_16161616),
#endif
+#if defined(VA_FOURCC_X2R10G10B10) && defined(DRM_FORMAT_XRGB2101010)
+DRM_MAP(X2R10G10B10, 1, DRM_FORMAT_XRGB2101010),
+#endif
};
#undef DRM_MAP
--
2.41.0
___
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".
