Re: [FFmpeg-devel] [PATCH v4 2/2] fftools/ffmpeg: Add stream metadata from first frame's metadata
On Tue, May 7, 2019 at 11:40 PM Gyan wrote:
>
>
> On 08-05-2019 11:54 AM, Jun Li wrote:
> > Fix #6945
> > Exif extension has 'Orientaion' field for image flip and rotation.
> > This change is to add the first frame's exif into stream so that
> > autorotation would use the info to adjust the frames.
>
> Suggest commit msg should be
>
> "
>
> 'Orientation' field from EXIF tags in first decoded frame is extracted
> as stream side data so that ffmpeg can apply auto-rotation.
>
> "
>
Sure, will address that in next iteration.
>
> > ---
> > fftools/ffmpeg.c | 57 +++-
> > 1 file changed, 56 insertions(+), 1 deletion(-)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 01f04103cf..98ccaf0732 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -2341,6 +2341,58 @@ static int decode_audio(InputStream *ist,
> AVPacket *pkt, int *got_output,
> > return err < 0 ? err : ret;
> > }
> >
> > +static int set_metadata_from_1stframe(InputStream* ist, AVFrame* frame)
> > +{
> > +// read exif Orientation data
> > +AVDictionaryEntry *entry = av_dict_get(frame->metadata,
> "Orientation", NULL, 0);
> > +int orientation = 0;
> > +int32_t* sd = NULL;
> > +if (entry) {
> > +orientation = atoi(entry->value);
> > +sd = (int32_t*)av_stream_new_side_data(ist->st,
> AV_PKT_DATA_DISPLAYMATRIX, 4 * 9);
> > +if (!sd)
> > +return AVERROR(ENOMEM);
> > +memset(sd, 0, 4 * 9);
> > +switch (orientation)
> > +{
> > +case 1: // horizontal (normal)
> > +av_display_rotation_set(sd, 0.0);
> > +break;
> > +case 2: // mirror horizontal
> > +av_display_rotation_set(sd, 0.0);
> > +av_display_matrix_flip(sd, 1, 0);
> > +break;
> > +case 3: // rotate 180
> > +av_display_rotation_set(sd, 180.0);
> > +break;
> > +case 4: // mirror vertical
> > +av_display_rotation_set(sd, 0.0);
> > +av_display_matrix_flip(sd, 0, 1);
> > +break;
> > +case 5: // mirror horizontal and rotate 270 CW
> > +av_display_rotation_set(sd, 270.0);
> > +av_display_matrix_flip(sd, 0, 1);
> > +break;
> > +case 6: // rotate 90 CW
> > +av_display_rotation_set(sd, 90.0);
> > +break;
> > +case 7: // mirror horizontal and rotate 90 CW
> > +av_display_rotation_set(sd, 90.0);
> > +av_display_matrix_flip(sd, 0, 1);
> > +break;
> > +case 8: // rotate 270 CW
> > +av_display_rotation_set(sd, 270.0);
> > +break;
> > +default:
> > +av_display_rotation_set(sd, 0.0);
> > +av_log(ist->dec_ctx, AV_LOG_WARNING,
> > +"Exif orientation data out of range: %i. Set to
> default value: horizontal(normal).\n", orientation);
> > +break;
> > +}
> > +}
> > +return 0;
> > +}
> > +
> > static int decode_video(InputStream *ist, AVPacket *pkt, int
> *got_output, int64_t *duration_pts, int eof,
> > int *decode_failed)
> > {
> > @@ -2423,7 +2475,10 @@ static int decode_video(InputStream *ist,
> AVPacket *pkt, int *got_output, int64_
> > decoded_frame->top_field_first = ist->top_field_first;
> >
> > ist->frames_decoded++;
> > -
> > +if (ist->frames_decoded == 1 &&
> > +((err = set_metadata_from_1stframe(ist, decoded_frame)) < 0))
> > +goto fail;
> > +
> > if (ist->hwaccel_retrieve_data && decoded_frame->format ==
> ist->hwaccel_pix_fmt) {
> > err = ist->hwaccel_retrieve_data(ist->dec_ctx, decoded_frame);
> > if (err < 0)
>
> Also, is there a chance that there may be multiple sources for
> orientation data available for a given stream? If yes, what's the
> interaction? It looks like you append a new SD element.
>
Thanks Gyan for review !
Nicolas George asked the same question before. :)
Yes, this patch can't handle the case every frame has its own orientation.
From a technical perspective, it is absolutely possible, for example a
motion jpeg stream with different orientation value
on every frame. I think an ideal solution for this case is a filter doing
transformation per orientation every frame.
But based on my limited experience, I think this kind of content is rare.
What do you think ?
Maybe someone in the community met this kind of content before ?
Gyan
> ___
> 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 1/2] fftools/ffmpeg_filter, ffplay: Add flip support to rotation
On Tue, May 7, 2019 at 11:24 PM Jun Li wrote:
> Current implemantion for autoratation does not support flip.
> That is, if the matrix contains flip info, the API get_rotation
> only reflects partial information. This change is for adding
> support for hflip (vflip can be achieved by rotation+hflip).
> ---
> fftools/cmdutils.c| 4 ++--
> fftools/cmdutils.h| 2 +-
> fftools/ffmpeg_filter.c | 31 ++-
> fftools/ffplay.c | 22 ++
> libavutil/display.c | 14 ++
> libavutil/display.h | 14 ++
> libavutil/tests/display.c | 8
> tests/ref/fate/display| 4
> 8 files changed, 87 insertions(+), 12 deletions(-)
>
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 9cfbc45c2b..1235a3dd7b 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -2172,13 +2172,13 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size)
> return array;
> }
>
> -double get_rotation(AVStream *st)
> +double get_rotation_hflip(AVStream *st, int* hflip)
> {
> uint8_t* displaymatrix = av_stream_get_side_data(st,
>
> AV_PKT_DATA_DISPLAYMATRIX, NULL);
> double theta = 0;
> if (displaymatrix)
> -theta = -av_display_rotation_get((int32_t*) displaymatrix);
> +theta = -av_display_rotation_hflip_get((int32_t*) displaymatrix,
> hflip);
>
> theta -= 360*floor(theta/360 + 0.9/360);
>
> diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> index 6e2e0a2acb..0349d1bea7 100644
> --- a/fftools/cmdutils.h
> +++ b/fftools/cmdutils.h
> @@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size);
> char name[128];\
> av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
>
> -double get_rotation(AVStream *st);
> +double get_rotation_hflip(AVStream *st, int* hflip);
>
> #endif /* FFTOOLS_CMDUTILS_H */
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 72838de1e2..b000958015 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -807,22 +807,43 @@ static int configure_input_video_filter(FilterGraph
> *fg, InputFilter *ifilter,
> last_filter = ifilter->filter;
>
> if (ist->autorotate) {
> -double theta = get_rotation(ist->st);
> +int hflip = 0;
> +double theta = get_rotation_hflip(ist->st, &hflip);
>
> -if (fabs(theta - 90) < 1.0) {
> +if (fabs(theta) < 1.0) {
> +if (hflip)
> +ret = insert_filter(&last_filter, &pad_idx, "hflip",
> NULL);
> +} else if (fabs(theta - 90) < 1.0) {
> ret = insert_filter(&last_filter, &pad_idx, "transpose",
> "clock");
> -} else if (fabs(theta - 180) < 1.0) {
> -ret = insert_filter(&last_filter, &pad_idx, "hflip", NULL);
> if (ret < 0)
> return ret;
> -ret = insert_filter(&last_filter, &pad_idx, "vflip", NULL);
> +if (hflip)
> +ret = insert_filter(&last_filter, &pad_idx, "hflip",
> NULL);
> +} else if (fabs(theta - 180) < 1.0) {
> +if (hflip) { // rotate 180 and hflip equals vflip
> +ret = insert_filter(&last_filter, &pad_idx, "vflip",
> NULL);
> +} else {
> +ret = insert_filter(&last_filter, &pad_idx, "hflip",
> NULL);
> +if (ret < 0)
> +return ret;
> +ret = insert_filter(&last_filter, &pad_idx, "vflip",
> NULL);
> +}
> } else if (fabs(theta - 270) < 1.0) {
> ret = insert_filter(&last_filter, &pad_idx, "transpose",
> "cclock");
> +if (ret < 0)
> +return ret;
> +if (hflip)
> +ret = insert_filter(&last_filter, &pad_idx, "hflip",
> NULL);
> } else if (fabs(theta) > 1.0) {
> char rotate_buf[64];
> snprintf(rotate_buf, sizeof(rotate_buf), "%f*PI/180", theta);
> ret = insert_filter(&last_filter, &pad_idx, "rotate",
> rotate_buf);
> +if (ret < 0)
> +return ret;
> +if (hflip)
> +ret = insert_filter(&last_filter, &pad_idx, "hflip",
> NULL);
> }
> +
> if (ret < 0)
> return ret;
> }
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index 8f050e16e6..2c77612193 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -1914,19 +1914,33 @@ static int configure_video_filters(AVFilterGraph
> *graph, VideoState *is, const c
> } while (0)
>
> if (autorotate) {
> -double theta = get_rotation(is->video_st);
> +int hflip;
> +double theta = get_rotation_hflip(is->video_st, &hflip);
>
> -if (fabs(theta - 90) < 1.0) {
> +if (fabs(theta) < 1.0) {
> +if (hflip)
> +INSERT_FILT("hflip", NULL);
> +} else if (fabs(theta - 90) < 1.0) {
>
Re: [FFmpeg-devel] [PATCH v4 2/2] fftools/ffmpeg: Add stream metadata from first frame's metadata
On 08-05-2019 11:54 AM, Jun Li wrote:
Fix #6945
Exif extension has 'Orientaion' field for image flip and rotation.
This change is to add the first frame's exif into stream so that
autorotation would use the info to adjust the frames.
Suggest commit msg should be
"
'Orientation' field from EXIF tags in first decoded frame is extracted
as stream side data so that ffmpeg can apply auto-rotation.
"
---
fftools/ffmpeg.c | 57 +++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..98ccaf0732 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2341,6 +2341,58 @@ static int decode_audio(InputStream *ist, AVPacket *pkt,
int *got_output,
return err < 0 ? err : ret;
}
+static int set_metadata_from_1stframe(InputStream* ist, AVFrame* frame)
+{
+// read exif Orientation data
+AVDictionaryEntry *entry = av_dict_get(frame->metadata, "Orientation",
NULL, 0);
+int orientation = 0;
+int32_t* sd = NULL;
+if (entry) {
+orientation = atoi(entry->value);
+sd = (int32_t*)av_stream_new_side_data(ist->st,
AV_PKT_DATA_DISPLAYMATRIX, 4 * 9);
+if (!sd)
+return AVERROR(ENOMEM);
+memset(sd, 0, 4 * 9);
+switch (orientation)
+{
+case 1: // horizontal (normal)
+av_display_rotation_set(sd, 0.0);
+break;
+case 2: // mirror horizontal
+av_display_rotation_set(sd, 0.0);
+av_display_matrix_flip(sd, 1, 0);
+break;
+case 3: // rotate 180
+av_display_rotation_set(sd, 180.0);
+break;
+case 4: // mirror vertical
+av_display_rotation_set(sd, 0.0);
+av_display_matrix_flip(sd, 0, 1);
+break;
+case 5: // mirror horizontal and rotate 270 CW
+av_display_rotation_set(sd, 270.0);
+av_display_matrix_flip(sd, 0, 1);
+break;
+case 6: // rotate 90 CW
+av_display_rotation_set(sd, 90.0);
+break;
+case 7: // mirror horizontal and rotate 90 CW
+av_display_rotation_set(sd, 90.0);
+av_display_matrix_flip(sd, 0, 1);
+break;
+case 8: // rotate 270 CW
+av_display_rotation_set(sd, 270.0);
+break;
+default:
+av_display_rotation_set(sd, 0.0);
+av_log(ist->dec_ctx, AV_LOG_WARNING,
+"Exif orientation data out of range: %i. Set to default value:
horizontal(normal).\n", orientation);
+break;
+}
+}
+return 0;
+}
+
static int decode_video(InputStream *ist, AVPacket *pkt, int *got_output,
int64_t *duration_pts, int eof,
int *decode_failed)
{
@@ -2423,7 +2475,10 @@ static int decode_video(InputStream *ist, AVPacket *pkt,
int *got_output, int64_
decoded_frame->top_field_first = ist->top_field_first;
ist->frames_decoded++;
-
+if (ist->frames_decoded == 1 &&
+((err = set_metadata_from_1stframe(ist, decoded_frame)) < 0))
+goto fail;
+
if (ist->hwaccel_retrieve_data && decoded_frame->format ==
ist->hwaccel_pix_fmt) {
err = ist->hwaccel_retrieve_data(ist->dec_ctx, decoded_frame);
if (err < 0)
Also, is there a chance that there may be multiple sources for
orientation data available for a given stream? If yes, what's the
interaction? It looks like you append a new SD element.
Gyan
___
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 1/2] fftools/ffmpeg_filter, ffplay: Add flip support to rotation
On Tue, May 7, 2019 at 2:04 AM Moritz Barsnick wrote:
> On Mon, May 06, 2019 at 22:36:41 -0700, Jun Li wrote:
> > +double av_display_rotation_hflip_get(const int32_t matrix[9], int
> *hflip)
> > +{
> > +int32_t m[9];
> > +*hflip = 0;
> > +memcpy(m, matrix, sizeof(int32_t) * 9);
>
> You were asked to avoid this (at another code location though).
> BTW, sizeof(m) would be a better use of sizeof() here. (Or a constant
> for the triple but related use of "9".)
>
> > +return av_display_rotation_get(m);
> > +}
> > \ No newline at end of file
>
> Cosmetic, but please add a line feed in the last line of the file.
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Thanks Moritz for review.
To address the two issues of line feed and "sizeof(m)", I updated the
iteration here: https://patchwork.ffmpeg.org/patch/13029/
___
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 1/2] fftools/ffmpeg_filter, ffplay: Add flip support to rotation
Current implemantion for autoratation does not support flip.
That is, if the matrix contains flip info, the API get_rotation
only reflects partial information. This change is for adding
support for hflip (vflip can be achieved by rotation+hflip).
---
fftools/cmdutils.c| 4 ++--
fftools/cmdutils.h| 2 +-
fftools/ffmpeg_filter.c | 31 ++-
fftools/ffplay.c | 22 ++
libavutil/display.c | 14 ++
libavutil/display.h | 14 ++
libavutil/tests/display.c | 8
tests/ref/fate/display| 4
8 files changed, 87 insertions(+), 12 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 9cfbc45c2b..1235a3dd7b 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -2172,13 +2172,13 @@ void *grow_array(void *array, int elem_size, int *size,
int new_size)
return array;
}
-double get_rotation(AVStream *st)
+double get_rotation_hflip(AVStream *st, int* hflip)
{
uint8_t* displaymatrix = av_stream_get_side_data(st,
AV_PKT_DATA_DISPLAYMATRIX, NULL);
double theta = 0;
if (displaymatrix)
-theta = -av_display_rotation_get((int32_t*) displaymatrix);
+theta = -av_display_rotation_hflip_get((int32_t*) displaymatrix,
hflip);
theta -= 360*floor(theta/360 + 0.9/360);
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index 6e2e0a2acb..0349d1bea7 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int *size, int
new_size);
char name[128];\
av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
-double get_rotation(AVStream *st);
+double get_rotation_hflip(AVStream *st, int* hflip);
#endif /* FFTOOLS_CMDUTILS_H */
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 72838de1e2..b000958015 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -807,22 +807,43 @@ static int configure_input_video_filter(FilterGraph *fg,
InputFilter *ifilter,
last_filter = ifilter->filter;
if (ist->autorotate) {
-double theta = get_rotation(ist->st);
+int hflip = 0;
+double theta = get_rotation_hflip(ist->st, &hflip);
-if (fabs(theta - 90) < 1.0) {
+if (fabs(theta) < 1.0) {
+if (hflip)
+ret = insert_filter(&last_filter, &pad_idx, "hflip", NULL);
+} else if (fabs(theta - 90) < 1.0) {
ret = insert_filter(&last_filter, &pad_idx, "transpose", "clock");
-} else if (fabs(theta - 180) < 1.0) {
-ret = insert_filter(&last_filter, &pad_idx, "hflip", NULL);
if (ret < 0)
return ret;
-ret = insert_filter(&last_filter, &pad_idx, "vflip", NULL);
+if (hflip)
+ret = insert_filter(&last_filter, &pad_idx, "hflip", NULL);
+} else if (fabs(theta - 180) < 1.0) {
+if (hflip) { // rotate 180 and hflip equals vflip
+ret = insert_filter(&last_filter, &pad_idx, "vflip", NULL);
+} else {
+ret = insert_filter(&last_filter, &pad_idx, "hflip", NULL);
+if (ret < 0)
+return ret;
+ret = insert_filter(&last_filter, &pad_idx, "vflip", NULL);
+}
} else if (fabs(theta - 270) < 1.0) {
ret = insert_filter(&last_filter, &pad_idx, "transpose", "cclock");
+if (ret < 0)
+return ret;
+if (hflip)
+ret = insert_filter(&last_filter, &pad_idx, "hflip", NULL);
} else if (fabs(theta) > 1.0) {
char rotate_buf[64];
snprintf(rotate_buf, sizeof(rotate_buf), "%f*PI/180", theta);
ret = insert_filter(&last_filter, &pad_idx, "rotate", rotate_buf);
+if (ret < 0)
+return ret;
+if (hflip)
+ret = insert_filter(&last_filter, &pad_idx, "hflip", NULL);
}
+
if (ret < 0)
return ret;
}
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 8f050e16e6..2c77612193 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1914,19 +1914,33 @@ static int configure_video_filters(AVFilterGraph
*graph, VideoState *is, const c
} while (0)
if (autorotate) {
-double theta = get_rotation(is->video_st);
+int hflip;
+double theta = get_rotation_hflip(is->video_st, &hflip);
-if (fabs(theta - 90) < 1.0) {
+if (fabs(theta) < 1.0) {
+if (hflip)
+INSERT_FILT("hflip", NULL);
+} else if (fabs(theta - 90) < 1.0) {
INSERT_FILT("transpose", "clock");
+if (hflip)
+INSERT_FILT("hflip", NULL);
} else if (fabs(theta - 180) < 1.0) {
-INSERT_FILT("hflip", NULL);
-INSERT_FILT("vflip", NULL);
[FFmpeg-devel] [PATCH v4 2/2] fftools/ffmpeg: Add stream metadata from first frame's metadata
Fix #6945
Exif extension has 'Orientaion' field for image flip and rotation.
This change is to add the first frame's exif into stream so that
autorotation would use the info to adjust the frames.
---
fftools/ffmpeg.c | 57 +++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..98ccaf0732 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2341,6 +2341,58 @@ static int decode_audio(InputStream *ist, AVPacket *pkt,
int *got_output,
return err < 0 ? err : ret;
}
+static int set_metadata_from_1stframe(InputStream* ist, AVFrame* frame)
+{
+// read exif Orientation data
+AVDictionaryEntry *entry = av_dict_get(frame->metadata, "Orientation",
NULL, 0);
+int orientation = 0;
+int32_t* sd = NULL;
+if (entry) {
+orientation = atoi(entry->value);
+sd = (int32_t*)av_stream_new_side_data(ist->st,
AV_PKT_DATA_DISPLAYMATRIX, 4 * 9);
+if (!sd)
+return AVERROR(ENOMEM);
+memset(sd, 0, 4 * 9);
+switch (orientation)
+{
+case 1: // horizontal (normal)
+av_display_rotation_set(sd, 0.0);
+break;
+case 2: // mirror horizontal
+av_display_rotation_set(sd, 0.0);
+av_display_matrix_flip(sd, 1, 0);
+break;
+case 3: // rotate 180
+av_display_rotation_set(sd, 180.0);
+break;
+case 4: // mirror vertical
+av_display_rotation_set(sd, 0.0);
+av_display_matrix_flip(sd, 0, 1);
+break;
+case 5: // mirror horizontal and rotate 270 CW
+av_display_rotation_set(sd, 270.0);
+av_display_matrix_flip(sd, 0, 1);
+break;
+case 6: // rotate 90 CW
+av_display_rotation_set(sd, 90.0);
+break;
+case 7: // mirror horizontal and rotate 90 CW
+av_display_rotation_set(sd, 90.0);
+av_display_matrix_flip(sd, 0, 1);
+break;
+case 8: // rotate 270 CW
+av_display_rotation_set(sd, 270.0);
+break;
+default:
+av_display_rotation_set(sd, 0.0);
+av_log(ist->dec_ctx, AV_LOG_WARNING,
+"Exif orientation data out of range: %i. Set to default
value: horizontal(normal).\n", orientation);
+break;
+}
+}
+return 0;
+}
+
static int decode_video(InputStream *ist, AVPacket *pkt, int *got_output,
int64_t *duration_pts, int eof,
int *decode_failed)
{
@@ -2423,7 +2475,10 @@ static int decode_video(InputStream *ist, AVPacket *pkt,
int *got_output, int64_
decoded_frame->top_field_first = ist->top_field_first;
ist->frames_decoded++;
-
+if (ist->frames_decoded == 1 &&
+((err = set_metadata_from_1stframe(ist, decoded_frame)) < 0))
+goto fail;
+
if (ist->hwaccel_retrieve_data && decoded_frame->format ==
ist->hwaccel_pix_fmt) {
err = ist->hwaccel_retrieve_data(ist->dec_ctx, decoded_frame);
if (err < 0)
--
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 v2] avformat/ifv: added support for ifv cctv files
On 08.05.2019, at 08:01, Carl Eugen Hoyos wrote: > Am Mi., 8. Mai 2019 um 00:52 Uhr schrieb Reimar Döffinger > : >> >> On 07.05.2019, at 12:00, Swaraj Hota wrote: >> >>> On Sun, May 05, 2019 at 09:59:01PM +0200, Reimar Döffinger wrote: > +/*read video index*/ > +avio_seek(s->pb, 0xf8, SEEK_SET); [...] > +avio_skip(s->pb, ifv->vid_index->frame_offset - avio_tell(s->pb)); Why use avio_seek in one place and avio_skip in the other? >>> >>> No particular reason. Essentially all are just skips. There is no >>> backward seek. I left two seeks becuase they seemed more readable. >>> Someone could know at a glance at what offset the first video and audio >>> index are assumed/found to be. Should I change them to skips as well? >> >> Not quite sure how things work nowadays, but I'd suggest to use whichever >> gives the most readable code. >> Which would mean using avio_seek in this case. > > I originally suggested using avio_skip() instead of avio_seek() to clarify > that no back-seeking is involved. > I realize it may not have been the best approach... Well, it is good advice in principle, but in this case it seems to lead to ugly code (and it was only done in some cases). That kind of thing tends to be hard to know before making the change. ___ 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] avutil: Add NV24 and NV42 pixel formats
Am Mi., 8. Mai 2019 um 00:20 Uhr schrieb Philip Langdale : > > On 2019-05-07 14:43, Carl Eugen Hoyos wrote: > > Am Di., 7. Mai 2019 um 06:33 Uhr schrieb Philip Langdale > > : > >> > >> These are the 4:4:4 variants of the semi-planar NV12/NV21 formats. > >> > >> I'm surprised we've not had a reason to add them until now, but > >> they are the format that VDPAU uses when doing interop for 4:4:4 > >> surfaces. > > > > Is there already a (libswscale) patch that actually uses the new > > formats? > > No. I haven't written any swscale code for this yet, although I could, > but there's no specific requirement for it. > > ffmpeg doesn't implement any of the (opengl) interop, but I've got an > mpv patch that does it and it needs the pixfmt to be able to work. How is ffmpeg (or any other application using libav*) handling the vdpau output if there is no conversion available? Sorry if I misunderstand, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files
Am Mi., 8. Mai 2019 um 00:52 Uhr schrieb Reimar Döffinger : > > On 07.05.2019, at 12:00, Swaraj Hota wrote: > > > On Sun, May 05, 2019 at 09:59:01PM +0200, Reimar Döffinger wrote: > >> > >> > >>> +/*read video index*/ > >>> +avio_seek(s->pb, 0xf8, SEEK_SET); > >> [...] > >>> +avio_skip(s->pb, ifv->vid_index->frame_offset - avio_tell(s->pb)); > >> > >> Why use avio_seek in one place and avio_skip in the other? > >> > > > > No particular reason. Essentially all are just skips. There is no > > backward seek. I left two seeks becuase they seemed more readable. > > Someone could know at a glance at what offset the first video and audio > > index are assumed/found to be. Should I change them to skips as well? > > Not quite sure how things work nowadays, but I'd suggest to use whichever > gives the most readable code. > Which would mean using avio_seek in this case. I originally suggested using avio_skip() instead of avio_seek() to clarify that no back-seeking is involved. I realize it may not have been the best approach... Thank you for your comments, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/af_atempo: Make ffplay display correct timestamps when seeking
NOTE: this is a refinement of the patch from Paul B Mahol
offset all output timestamps by same amount of first input timestamp
---
libavfilter/af_atempo.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index bfdad7d76b..688dac5464 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -103,6 +103,9 @@ typedef struct ATempoContext {
// 1: output sample position
int64_t position[2];
+// first input timestamp, all other timestamps are offset by this one
+int64_t start_pts;
+
// sample format:
enum AVSampleFormat format;
@@ -186,6 +189,7 @@ static void yae_clear(ATempoContext *atempo)
atempo->nfrag = 0;
atempo->state = YAE_LOAD_FRAGMENT;
+atempo->start_pts = AV_NOPTS_VALUE;
atempo->position[0] = 0;
atempo->position[1] = 0;
@@ -1068,7 +1072,7 @@ static int push_samples(ATempoContext *atempo,
atempo->dst_buffer->nb_samples = n_out;
// adjust the PTS:
-atempo->dst_buffer->pts =
+atempo->dst_buffer->pts = atempo->start_pts +
av_rescale_q(atempo->nsamples_out,
(AVRational){ 1, outlink->sample_rate },
outlink->time_base);
@@ -1097,6 +1101,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*src_buffer)
const uint8_t *src = src_buffer->data[0];
const uint8_t *src_end = src + n_in * atempo->stride;
+if (atempo->start_pts == AV_NOPTS_VALUE)
+atempo->start_pts = av_rescale_q(src_buffer->pts,
+ inlink->time_base,
+ outlink->time_base);
+
while (src < src_end) {
if (!atempo->dst_buffer) {
atempo->dst_buffer = ff_get_audio_buffer(outlink, n_out);
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/af_atempo: offset all output timestamps by same amount of first input timestamp
btw, I don't know if there is already a way to do this with an existing utility
function... there probably is and I just don't know about it.
I wrote this debugging helper to help me verify input/output PTS in atempo, I
can send a patch if it's useful. Alternatively, I'd like to know what the right
way to get the same result would be with existing utility functions
static const char * hh_mm_ss_msec(char buf[15], AVRational b, int64_t t)
{
char * str = buf;
t = av_rescale_q(t, b, (AVRational){ 1, 1000 });
if (t < 0)
{
*str++ = '-';
t = -t;
}
// msec:
{
char * p = str + 8;
p[4] = 0;
p[3] = '0' + (t % 10);
t /= 10;
p[2] = '0' + (t % 10);
t /= 10;
p[1] = '0' + (t % 10);
t /= 10;
p[0] = '.';
}
// seconds:
{
int64_t v = t % 60;
char * p = str + 5;
p[2] = '0' + (v % 10);
v /= 10;
p[1] = '0' + v;
t /= 60;
p[0] = ':';
}
// minutes:
{
int64_t v = t % 60;
char * p = str + 2;
p[2] = '0' + (v % 10);
v /= 10;
p[1] = '0' + v;
t /= 60;
p[0] = ':';
}
// hours:
{
int64_t v = t % 100;
str[1] = '0' + (v % 10);
v /= 10;
str[0] = '0' + v;
}
return buf;
}
// elsewhere
char buf_src[15];
char buf_dst[15];
...
av_log(outlink->src, AV_LOG_WARNING,
"FIXME: pkoshevoy: atempo pts: %s -> %s\n",
hh_mm_ss_msec(buf_src,
(AVRational){ 1, outlink->sample_rate },
yae_curr_frag(atempo)->position[0] -
yae_curr_frag(atempo)->nsamples),
hh_mm_ss_msec(buf_dst,
outlink->time_base,
atempo->dst_buffer->pts));
// and the output looks like this:
[Parsed_atempo_2 @ 0x6a5ec0] FIXME: pkoshevoy: atempo pts: 00:00:29.991 ->
00:00:29.989
[Parsed_atempo_2 @ 0x6a5ec0] FIXME: pkoshevoy: atempo pts: 00:00:29.991 ->
00:00:30.002
[Parsed_atempo_2 @ 0x6a5ec0] FIXME: pkoshevoy: atempo pts: 00:00:30.043 ->
00:00:30.015
[Parsed_atempo_2 @ 0x6a5ec0] FIXME: pkoshevoy: atempo pts: 00:00:30.043 ->
00:00:30.028
[Parsed_atempo_2 @ 0x6a5ec0] FIXME: pkoshevoy: atempo pts: 00:00:30.093 ->
00:00:30.041
[Parsed_atempo_2 @ 0x6a5ec0] FIXME: pkoshevoy: atempo pts: 00:00:30.093 ->
00:00:30.054
___
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] avfilter/af_atempo: offset all output timestamps by same amount of first input timestamp
On 5/7/19 9:02 PM, Pavel Koshevoy wrote:
On 5/7/19 8:41 PM, Pavel Koshevoy wrote:
On 5/6/19 6:41 AM, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
Makes ffplay display correct timestamps when seeking.
---
libavfilter/af_atempo.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index bfdad7d76b..6a23d59641 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -103,6 +103,9 @@ typedef struct ATempoContext {
// 1: output sample position
int64_t position[2];
+ // first input timestamp, all other timestamps are offset by this one
+ int64_t start_pts;
+
// sample format:
enum AVSampleFormat format;
@@ -1055,6 +1058,7 @@ static int config_props(AVFilterLink *inlink)
enum AVSampleFormat format = inlink->format;
int sample_rate = (int)inlink->sample_rate;
+ atempo->start_pts = AV_NOPTS_VALUE;
return yae_reset(atempo, format, sample_rate, inlink->channels);
}
@@ -1068,7 +1072,7 @@ static int push_samples(ATempoContext *atempo,
atempo->dst_buffer->nb_samples = n_out;
// adjust the PTS:
- atempo->dst_buffer->pts =
+ atempo->dst_buffer->pts = atempo->start_pts +
av_rescale_q(atempo->nsamples_out,
(AVRational){ 1, outlink->sample_rate },
outlink->time_base);
@@ -1097,6 +1101,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*src_buffer)
const uint8_t *src = src_buffer->data[0];
const uint8_t *src_end = src + n_in * atempo->stride;
+ if (atempo->start_pts == AV_NOPTS_VALUE)
+ atempo->start_pts = src_buffer->pts;
while (src < src_end) {
if (!atempo->dst_buffer) {
atempo->dst_buffer = ff_get_audio_buffer(outlink, n_out);
I was able to confirm from the debugger that af_atempo.c:config_props gets
called and atempo->start_pts is reset when seeking in ffplay, so the patch
looks okay to me.
Thank you,
Pavel.
However, it might be cleaner to move `atempo->start_pts = AV_NOPTS_VALUE;`
from config_props to yae_clear
also, I am not certain that start_pts and output pts are expressed in the same
time base... maybe start_pts should be rescaled to output timebase in filter_frame
___
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] avfilter/af_atempo: offset all output timestamps by same amount of first input timestamp
On 5/6/19 6:41 AM, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
Makes ffplay display correct timestamps when seeking.
---
libavfilter/af_atempo.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index bfdad7d76b..6a23d59641 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -103,6 +103,9 @@ typedef struct ATempoContext {
// 1: output sample position
int64_t position[2];
+// first input timestamp, all other timestamps are offset by this one
+int64_t start_pts;
+
// sample format:
enum AVSampleFormat format;
@@ -1055,6 +1058,7 @@ static int config_props(AVFilterLink *inlink)
enum AVSampleFormat format = inlink->format;
int sample_rate = (int)inlink->sample_rate;
+atempo->start_pts = AV_NOPTS_VALUE;
return yae_reset(atempo, format, sample_rate, inlink->channels);
}
@@ -1068,7 +1072,7 @@ static int push_samples(ATempoContext *atempo,
atempo->dst_buffer->nb_samples = n_out;
// adjust the PTS:
-atempo->dst_buffer->pts =
+atempo->dst_buffer->pts = atempo->start_pts +
av_rescale_q(atempo->nsamples_out,
(AVRational){ 1, outlink->sample_rate },
outlink->time_base);
@@ -1097,6 +1101,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*src_buffer)
const uint8_t *src = src_buffer->data[0];
const uint8_t *src_end = src + n_in * atempo->stride;
+if (atempo->start_pts == AV_NOPTS_VALUE)
+atempo->start_pts = src_buffer->pts;
while (src < src_end) {
if (!atempo->dst_buffer) {
atempo->dst_buffer = ff_get_audio_buffer(outlink, n_out);
I was able to confirm from the debugger that af_atempo.c:config_props gets
called and atempo->start_pts is reset when seeking in ffplay, so the patch looks
okay to me.
Thank you,
Pavel.
___
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] avfilter/af_atempo: offset all output timestamps by same amount of first input timestamp
On 5/7/19 8:41 PM, Pavel Koshevoy wrote:
On 5/6/19 6:41 AM, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
Makes ffplay display correct timestamps when seeking.
---
libavfilter/af_atempo.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index bfdad7d76b..6a23d59641 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -103,6 +103,9 @@ typedef struct ATempoContext {
// 1: output sample position
int64_t position[2];
+ // first input timestamp, all other timestamps are offset by this one
+ int64_t start_pts;
+
// sample format:
enum AVSampleFormat format;
@@ -1055,6 +1058,7 @@ static int config_props(AVFilterLink *inlink)
enum AVSampleFormat format = inlink->format;
int sample_rate = (int)inlink->sample_rate;
+ atempo->start_pts = AV_NOPTS_VALUE;
return yae_reset(atempo, format, sample_rate, inlink->channels);
}
@@ -1068,7 +1072,7 @@ static int push_samples(ATempoContext *atempo,
atempo->dst_buffer->nb_samples = n_out;
// adjust the PTS:
- atempo->dst_buffer->pts =
+ atempo->dst_buffer->pts = atempo->start_pts +
av_rescale_q(atempo->nsamples_out,
(AVRational){ 1, outlink->sample_rate },
outlink->time_base);
@@ -1097,6 +1101,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*src_buffer)
const uint8_t *src = src_buffer->data[0];
const uint8_t *src_end = src + n_in * atempo->stride;
+ if (atempo->start_pts == AV_NOPTS_VALUE)
+ atempo->start_pts = src_buffer->pts;
while (src < src_end) {
if (!atempo->dst_buffer) {
atempo->dst_buffer = ff_get_audio_buffer(outlink, n_out);
I was able to confirm from the debugger that af_atempo.c:config_props gets
called and atempo->start_pts is reset when seeking in ffplay, so the patch
looks okay to me.
Thank you,
Pavel.
However, it might be cleaner to move `atempo->start_pts = AV_NOPTS_VALUE;` from
config_props to yae_clear
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files
On 07.05.2019, at 12:00, Swaraj Hota wrote:
> On Sun, May 05, 2019 at 09:59:01PM +0200, Reimar Döffinger wrote:
>>
>>
>>> +/*read video index*/
>>> +avio_seek(s->pb, 0xf8, SEEK_SET);
>> [...]
>>> +avio_skip(s->pb, ifv->vid_index->frame_offset - avio_tell(s->pb));
>>
>> Why use avio_seek in one place and avio_skip in the other?
>>
>
> No particular reason. Essentially all are just skips. There is no
> backward seek. I left two seeks becuase they seemed more readable.
> Someone could know at a glance at what offset the first video and audio
> index are assumed/found to be. Should I change them to skips as well?
Not quite sure how things work nowadays, but I'd suggest to use whichever
gives the most readable code.
Which would mean using avio_seek in this case.
>>> +pos = avio_tell(s->pb);
>>> +
>>> +for (i = 0; i < ifv->total_vframes; i++) {
>>> +e = &ifv->vid_index[i];
>>> +if (e->frame_offset >= pos)
>>> +break;
>>> +}
>>
>> This looks rather inefficient.
>> Wouldn't it make more sense to either
>> use a binary search or at least to
>> remember the position from the last read?
>> This also does not seem very robust either,
>> if a single frame_offset gets corrupted
>> to a very large value, this code will
>> never be able to find the "correct" position.
>> It seems to assume the frame_offset
>> is ordered increasingly (as would be needed for
>> binary search), but that property isn't
>> really checked/enforced.
>>
>
> Yeah it is indeed inefficient. But it also seems like the "correct" one.
> Because in case of seeking we might not be at the boundary of a frame
> and hence might need to skip to the boundary of next frame we can find.
> I guess this rules out binary search, and maybe also saving the last
> read.
>
> Regarding the frame_offset corruption, well that rules out binary search
> as well because then the order of the index will be disturbed.
>
> Or maybe I misunderstood? Please do mention if this can be done more
> efficiently by some method. I really need some ideas on this if it can
> be done.
First, seeking should be handled specially, by resetting the state.
You should not make the get_packet less efficient because of that.
That should enable the "remember last position and start from there".
As to the corruption case, well the question is what to do about that, and I
don't have the answer.
But if the solution were to e.g. ensure the frame offset is monotonous then
binary search could be used.
However there is also the possibility that the format does in fact allow a
completely arbitrary order of frames in the file, maybe even re-using an
earlier frame_offset if the same frame appears multiple times.
In that case this whole offset-based positioning code would simply be wrong,
and you'd have to store the current index position in your demuxer instead of
relying on avio_tell.
Maybe you chose this solution because you did not know that seeking should be
implemented via special functions?
___
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] Revert "avcodec/qtrle: Do not output duplicated frames on insufficient input"
On Tue, May 07, 2019 at 02:03:22AM +0200, Marton Balint wrote: > > > On Tue, 7 May 2019, Michael Niedermayer wrote: > > >On Sun, May 05, 2019 at 08:51:08PM +0200, Marton Balint wrote: > >>This reverts commit a9dacdeea6168787a142209bd19fdd74aefc9dd6. > >> > >>I don't think it is a good idea to drop frames from CFR input just because > >>they > >>are duplicated, that can cause issues for API users expecting CFR input. > >>Also > >>it can cause issues at the end of file, if the last frame is a duplicated > >>frame. > >> > >>Fixes ticket #7880. > >> > >>Signed-off-by: Marton Balint > >>--- > >> libavcodec/qtrle.c| 12 ++--- > >> tests/ref/fate/qtrle-8bit | 109 > >> ++ > >> 2 files changed, 115 insertions(+), 6 deletions(-) > > > >This change would make the decoder quite a bit slower. > > I guess that can be easily fixed by only copying the buffer if it really is > a different frame. > > >It also would make encoding the output harder. > >For example motion estimation would be run over unchanged frames even when > >no cfr is wanted. > > The performance penalty is much more acceptable to me than the issue > described in the ticket. Do you see a straightforward way to fix it other > than reverting? decoders can in general have frames at the end which need to be flushed out. For example IPB mpeg1/2/4/... In the same way the decoder could output a last frame representing the end exactly [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavutil: add an FFT & MDCT implementation
On 07.05.2019, at 01:33, Lynne wrote: > May 6, 2019, 11:41 PM by barsn...@gmx.net: > >> On Mon, May 06, 2019 at 02:23:26 +0200, Lynne wrote: >> >>> This allowed for the exptabs to be computed just once on startup and >>> stored in a global array. >>> >> >> I have no real understanding of this, but: >> Would there be a desire for a static implementation as well, for those >> using "-enable-hardcoded-tables" (CONFIG_HARDCODED_TABLES)? Just >> wondering whether that's esoteric, optional, or really nice to have. >> >> Moritz >> > > Not really, its just nicer, saves 64 bytes per context and some time on > subsequent inits, > and might help with SIMD because more can be hardcoded into the assembly. > I don't think the hardcoded tables flag helps much nowadays, binary size > seems more > important to users shipping the libraries. Also it might improve precision > somewhat > for floats if the compiling machine has a different libc than the user's > machine, and the > sin/cos approximations used on the compiling machine's libc are worse. It's a bit of a special case, but it also helps memory usage when many instances of FFmpeg run on the same machine. .rodata sections will be shared, whereas runtime-initialized sections will cause copy-on-write at initialization, and unless deduplication is possible and enabled (which has other costs) will use memory for each instance. It can also be swapped out or executed in-place for systems that support that, reducing memory usage of those tables to 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 v2 1/2] fftools/ffmpeg_filter, ffplay: Add flip support to rotation
On Tue, May 07, 2019 at 03:15:33PM -0700, Jun Li wrote: > On Tue, May 7, 2019 at 3:10 PM Michael Niedermayer > wrote: > > > On Sun, May 05, 2019 at 08:41:27PM -0700, Jun Li wrote: > > > Current implemantion for autoratation does not support flip. > > > That is, if the matrix contains flip info, the API get_rotation > > > only reflects partial information. This change is for adding > > > support for hflip (vflip can be achieved by rotation+hflip). > > > --- > > > fftools/cmdutils.c| 4 ++-- > > > fftools/cmdutils.h| 2 +- > > > fftools/ffmpeg_filter.c | 31 ++- > > > fftools/ffplay.c | 22 ++ > > > libavutil/display.c | 12 > > > libavutil/display.h | 14 ++ > > > libavutil/tests/display.c | 8 > > > tests/ref/fate/display| 4 > > > 8 files changed, 85 insertions(+), 12 deletions(-) > > > > this caused people to hang from the ceiling in: > > ./ffplay ~/issues/1086/47j9R7PXBep.mov > > > > Metadata: > > major_brand : qt > > minor_version : 537199360 > > compatible_brands: qt > > creation_time : 2009-05-05T17:20:23.00Z > > com.apple.quicktime.player.movie.audio.gain: 1.00 > > com.apple.quicktime.player.movie.audio.treble: 0.00 > > com.apple.quicktime.player.movie.audio.bass: 0.00 > > com.apple.quicktime.player.movie.audio.balance: 0.00 > > com.apple.quicktime.player.movie.audio.pitchshift: 0.00 > > com.apple.quicktime.player.movie.audio.mute: > > com.apple.quicktime.player.movie.visual.brightness: 0.00 > > com.apple.quicktime.player.movie.visual.color: 1.00 > > com.apple.quicktime.player.movie.visual.tint: 0.00 > > com.apple.quicktime.player.movie.visual.contrast: 1.00 > > com.apple.quicktime.player.version: 7.6 (7.6) > > com.apple.quicktime.version: 7.6.0 (1290) 0x7608000 (Mac OS X, 10.5.6, > > 9G55) > > compilation : 0 > > encoder : Sorenson Squeeze 4.5 > > Duration: 00:00:30.58, start: 0.00, bitrate: 2006 kb/s > > Stream #0:0: Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, > > fltp, 127 kb/s (default) > > Metadata: > > rotate : 0 > > creation_time : 2009-05-05T17:20:23.00Z > > handler_name: Apple Sound Media Handler > > Stream #0:1: Video: h264 (Constrained Baseline) (avc1 / 0x31637661), > > yuv420p, 320x240, 1544 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 180k tbc > > (default) > > Metadata: > > rotate : 0 > > creation_time : 2009-05-05T17:20:23.00Z > > handler_name: Apple Video Media Handler > > encoder : AVC Coding > > Side data: > > displaymatrix: rotation of -0.00 degrees > > Stream #0:2: Data: none (mp4s / 0x7334706D) (default) > > Metadata: > > rotate : 0 > > creation_time : 2009-05-05T17:20:23.00Z > > handler_name: Apple MPEG-4 Scene Media Handler > > Stream #0:3: Data: none (mp4s / 0x7334706D) (default) > > Metadata: > > rotate : 0 > > creation_time : 2009-05-05T17:20:23.00Z > > handler_name: Apple MPEG-4 ODSM Media Handler > > Stream #0:4(eng): Data: none (rtp / 0x20707472), 14 kb/s > > Metadata: > > rotate : 0 > > creation_time : 2009-05-05T17:20:23.00Z > > handler_name: hint media handler > > Stream #0:5(eng): Data: none (rtp / 0x20707472), 64 kb/s > > Metadata: > > rotate : 0 > > creation_time : 2009-05-05T17:20:23.00Z > > handler_name: hint media handler > > [...] > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > The real ebay dictionary, page 2 > > "100% positive feedback" - "All either got their money back or didnt > > complain" > > "Best seller ever, very honest" - "Seller refunded buyer after failed scam" > > ___ > > 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". > > > Thanks Michael for testing. > Do you mind sharing the content "~/issues/1086/47j9R7PXBep.mov" ? sent privatly Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org 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] avutil: Add NV24 and NV42 pixel formats
On 2019-05-07 14:43, Carl Eugen Hoyos wrote: Am Di., 7. Mai 2019 um 06:33 Uhr schrieb Philip Langdale : These are the 4:4:4 variants of the semi-planar NV12/NV21 formats. I'm surprised we've not had a reason to add them until now, but they are the format that VDPAU uses when doing interop for 4:4:4 surfaces. Is there already a (libswscale) patch that actually uses the new formats? No. I haven't written any swscale code for this yet, although I could, but there's no specific requirement for it. ffmpeg doesn't implement any of the (opengl) interop, but I've got an mpv patch that does it and it needs the pixfmt to be able to work. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] fftools/ffmpeg_filter, ffplay: Add flip support to rotation
On Sun, May 05, 2019 at 08:41:27PM -0700, Jun Li wrote: > Current implemantion for autoratation does not support flip. > That is, if the matrix contains flip info, the API get_rotation > only reflects partial information. This change is for adding > support for hflip (vflip can be achieved by rotation+hflip). > --- > fftools/cmdutils.c| 4 ++-- > fftools/cmdutils.h| 2 +- > fftools/ffmpeg_filter.c | 31 ++- > fftools/ffplay.c | 22 ++ > libavutil/display.c | 12 > libavutil/display.h | 14 ++ > libavutil/tests/display.c | 8 > tests/ref/fate/display| 4 > 8 files changed, 85 insertions(+), 12 deletions(-) this caused people to hang from the ceiling in: ./ffplay ~/issues/1086/47j9R7PXBep.mov Metadata: major_brand : qt minor_version : 537199360 compatible_brands: qt creation_time : 2009-05-05T17:20:23.00Z com.apple.quicktime.player.movie.audio.gain: 1.00 com.apple.quicktime.player.movie.audio.treble: 0.00 com.apple.quicktime.player.movie.audio.bass: 0.00 com.apple.quicktime.player.movie.audio.balance: 0.00 com.apple.quicktime.player.movie.audio.pitchshift: 0.00 com.apple.quicktime.player.movie.audio.mute: com.apple.quicktime.player.movie.visual.brightness: 0.00 com.apple.quicktime.player.movie.visual.color: 1.00 com.apple.quicktime.player.movie.visual.tint: 0.00 com.apple.quicktime.player.movie.visual.contrast: 1.00 com.apple.quicktime.player.version: 7.6 (7.6) com.apple.quicktime.version: 7.6.0 (1290) 0x7608000 (Mac OS X, 10.5.6, 9G55) compilation : 0 encoder : Sorenson Squeeze 4.5 Duration: 00:00:30.58, start: 0.00, bitrate: 2006 kb/s Stream #0:0: Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 127 kb/s (default) Metadata: rotate : 0 creation_time : 2009-05-05T17:20:23.00Z handler_name: Apple Sound Media Handler Stream #0:1: Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 320x240, 1544 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 180k tbc (default) Metadata: rotate : 0 creation_time : 2009-05-05T17:20:23.00Z handler_name: Apple Video Media Handler encoder : AVC Coding Side data: displaymatrix: rotation of -0.00 degrees Stream #0:2: Data: none (mp4s / 0x7334706D) (default) Metadata: rotate : 0 creation_time : 2009-05-05T17:20:23.00Z handler_name: Apple MPEG-4 Scene Media Handler Stream #0:3: Data: none (mp4s / 0x7334706D) (default) Metadata: rotate : 0 creation_time : 2009-05-05T17:20:23.00Z handler_name: Apple MPEG-4 ODSM Media Handler Stream #0:4(eng): Data: none (rtp / 0x20707472), 14 kb/s Metadata: rotate : 0 creation_time : 2009-05-05T17:20:23.00Z handler_name: hint media handler Stream #0:5(eng): Data: none (rtp / 0x20707472), 64 kb/s Metadata: rotate : 0 creation_time : 2009-05-05T17:20:23.00Z handler_name: hint media handler [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] fftools/ffmpeg_filter, ffplay: Add flip support to rotation
On Tue, May 7, 2019 at 3:10 PM Michael Niedermayer wrote: > On Sun, May 05, 2019 at 08:41:27PM -0700, Jun Li wrote: > > Current implemantion for autoratation does not support flip. > > That is, if the matrix contains flip info, the API get_rotation > > only reflects partial information. This change is for adding > > support for hflip (vflip can be achieved by rotation+hflip). > > --- > > fftools/cmdutils.c| 4 ++-- > > fftools/cmdutils.h| 2 +- > > fftools/ffmpeg_filter.c | 31 ++- > > fftools/ffplay.c | 22 ++ > > libavutil/display.c | 12 > > libavutil/display.h | 14 ++ > > libavutil/tests/display.c | 8 > > tests/ref/fate/display| 4 > > 8 files changed, 85 insertions(+), 12 deletions(-) > > this caused people to hang from the ceiling in: > ./ffplay ~/issues/1086/47j9R7PXBep.mov > > Metadata: > major_brand : qt > minor_version : 537199360 > compatible_brands: qt > creation_time : 2009-05-05T17:20:23.00Z > com.apple.quicktime.player.movie.audio.gain: 1.00 > com.apple.quicktime.player.movie.audio.treble: 0.00 > com.apple.quicktime.player.movie.audio.bass: 0.00 > com.apple.quicktime.player.movie.audio.balance: 0.00 > com.apple.quicktime.player.movie.audio.pitchshift: 0.00 > com.apple.quicktime.player.movie.audio.mute: > com.apple.quicktime.player.movie.visual.brightness: 0.00 > com.apple.quicktime.player.movie.visual.color: 1.00 > com.apple.quicktime.player.movie.visual.tint: 0.00 > com.apple.quicktime.player.movie.visual.contrast: 1.00 > com.apple.quicktime.player.version: 7.6 (7.6) > com.apple.quicktime.version: 7.6.0 (1290) 0x7608000 (Mac OS X, 10.5.6, > 9G55) > compilation : 0 > encoder : Sorenson Squeeze 4.5 > Duration: 00:00:30.58, start: 0.00, bitrate: 2006 kb/s > Stream #0:0: Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, > fltp, 127 kb/s (default) > Metadata: > rotate : 0 > creation_time : 2009-05-05T17:20:23.00Z > handler_name: Apple Sound Media Handler > Stream #0:1: Video: h264 (Constrained Baseline) (avc1 / 0x31637661), > yuv420p, 320x240, 1544 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 180k tbc > (default) > Metadata: > rotate : 0 > creation_time : 2009-05-05T17:20:23.00Z > handler_name: Apple Video Media Handler > encoder : AVC Coding > Side data: > displaymatrix: rotation of -0.00 degrees > Stream #0:2: Data: none (mp4s / 0x7334706D) (default) > Metadata: > rotate : 0 > creation_time : 2009-05-05T17:20:23.00Z > handler_name: Apple MPEG-4 Scene Media Handler > Stream #0:3: Data: none (mp4s / 0x7334706D) (default) > Metadata: > rotate : 0 > creation_time : 2009-05-05T17:20:23.00Z > handler_name: Apple MPEG-4 ODSM Media Handler > Stream #0:4(eng): Data: none (rtp / 0x20707472), 14 kb/s > Metadata: > rotate : 0 > creation_time : 2009-05-05T17:20:23.00Z > handler_name: hint media handler > Stream #0:5(eng): Data: none (rtp / 0x20707472), 64 kb/s > Metadata: > rotate : 0 > creation_time : 2009-05-05T17:20:23.00Z > handler_name: hint media handler > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The real ebay dictionary, page 2 > "100% positive feedback" - "All either got their money back or didnt > complain" > "Best seller ever, very honest" - "Seller refunded buyer after failed scam" > ___ > 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". Thanks Michael for testing. Do you mind sharing the content "~/issues/1086/47j9R7PXBep.mov" ? Best Regards, Jun ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: Add stream metadata from first frame's metadata
On Sun, May 05, 2019 at 08:41:28PM -0700, Jun Li wrote: > Fix #6945 > Exif extension has 'Orientaion' field for image flip and rotation. > This change is to add the first frame's exif into stream so that > autorotation would use the info to adjust the frames. > --- > fftools/ffmpeg.c | 52 > 1 file changed, 52 insertions(+) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index 01f04103cf..cea85c601e 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -2341,6 +2341,56 @@ static int decode_audio(InputStream *ist, AVPacket > *pkt, int *got_output, this produces warnings like: fftools/ffmpeg.c: In function ‘set_metadata_from_1stframe’: fftools/ffmpeg.c:2362:17: warning: passing argument 1 of ‘av_display_matrix_flip’ from incompatible pointer type [enabled by default] [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil: Add NV24 and NV42 pixel formats
Am Di., 7. Mai 2019 um 06:33 Uhr schrieb Philip Langdale : > > These are the 4:4:4 variants of the semi-planar NV12/NV21 formats. > > I'm surprised we've not had a reason to add them until now, but > they are the format that VDPAU uses when doing interop for 4:4:4 > surfaces. Is there already a (libswscale) patch that actually uses the new formats? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mlp_parser: split off shared code to its own file
On 5/4/2019 4:36 PM, James Almer wrote:
> On 5/4/2019 4:04 PM, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavcodec/Makefile | 4 +-
>> libavcodec/mlp_parse.c | 213 +++
>> libavcodec/{mlp_parser.h => mlp_parse.h} | 15 +-
>> libavcodec/mlp_parser.c | 193 +---
>> libavcodec/mlpdec.c | 2 +-
>> libavcodec/truehd_core_bsf.c | 2 +-
>> 6 files changed, 221 insertions(+), 208 deletions(-)
>> create mode 100644 libavcodec/mlp_parse.c
>> rename libavcodec/{mlp_parser.h => mlp_parse.h} (92%)
>>
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index f37135fc07..edccd73037 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -1042,7 +1042,7 @@ OBJS-$(CONFIG_H263_PARSER) += h263_parser.o
>> OBJS-$(CONFIG_H264_PARSER) += h264_parser.o h264_sei.o
>> h264data.o
>> OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o hevc_data.o
>> OBJS-$(CONFIG_MJPEG_PARSER)+= mjpeg_parser.o
>> -OBJS-$(CONFIG_MLP_PARSER) += mlp_parser.o mlp.o
>> +OBJS-$(CONFIG_MLP_PARSER) += mlp_parse.o mlp_parser.o mlp.o
>> OBJS-$(CONFIG_MPEG4VIDEO_PARSER) += mpeg4video_parser.o h263.o \
>>mpeg4videodec.o mpeg4video.o \
>>ituh263dec.o h263dec.o h263data.o
>> @@ -1097,7 +1097,7 @@ OBJS-$(CONFIG_PRORES_METADATA_BSF)+=
>> prores_metadata_bsf.o
>> OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF) += remove_extradata_bsf.o
>> OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
>> OBJS-$(CONFIG_TRACE_HEADERS_BSF) += trace_headers_bsf.o
>> -OBJS-$(CONFIG_TRUEHD_CORE_BSF)+= truehd_core_bsf.o mlp_parser.o
>> mlp.o
>> +OBJS-$(CONFIG_TRUEHD_CORE_BSF)+= truehd_core_bsf.o mlp_parse.o
>> mlp.o
>> OBJS-$(CONFIG_VP9_METADATA_BSF) += vp9_metadata_bsf.o
>> OBJS-$(CONFIG_VP9_RAW_REORDER_BSF)+= vp9_raw_reorder_bsf.o
>> OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += vp9_superframe_bsf.o
>> diff --git a/libavcodec/mlp_parse.c b/libavcodec/mlp_parse.c
>> new file mode 100644
>> index 00..db2531f665
>> --- /dev/null
>> +++ b/libavcodec/mlp_parse.c
>> @@ -0,0 +1,213 @@
>> +/*
>> + * This file is part of FFmpeg.
>
> Locally added a "Copyright (c) 2007 Ian Caulfield line", same as in
> mlp_parser.c, since the code moved here was effectively written by him
> in the very first mlp parser commit (6b493b2f2f).
Pushed.
___
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] libavutil: add an FFT & MDCT implementation
May 6, 2019, 10:26 PM by mich...@niedermayer.cc: > > also i agree with paul, the API looks good > implementation not really reviewed > > thanks > Updated the patch with the suggestions. I've changed the API to instead have a function which gives you a function pointer which you then call with the context. I'm not sure which is better - a separate function to give you the function pointer or having it as an argument to the init function to fill in. >From bce2c45dcf82923fa9a59ddcc054fcae93be7b2e Mon Sep 17 00:00:00 2001 From: Lynne Date: Thu, 2 May 2019 15:07:12 +0100 Subject: [PATCH] libavutil: add an FFT & MDCT implementation This commit adds a new API to libavutil to allow for arbitrary transformations on various types of data. This is a partly new implementation, with the power of two transforms taken from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while the 3-point FFT was written from scratch. The (i)mdct folding code is taken from mdct15 as well, as the mdct_template code was somewhat old, messy and not easy to separate. A notable feature of this implementation is that it allows for 3xM and 5xM based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc. AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will allow for decoding of such streams. A non-exaustive list of supported sizes: 4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240, 256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560... The API was designed such that it allows for not only 1D transforms but also 2D transforms of certain block sizes. This was partly on accident as the stride argument is required for Opus MDCTs, but can be used in the context of a 2D transform as well. Also, various data types would be implemented eventually as well, such as "double" and "int32_t". Some performance comparisons with libfftw3f (SIMD disabled for both): 120: 22353 decicycles in fftwf_execute, 1024 runs, 0 skips 21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips 128: 22003 decicycles in fftwf_execute, 1024 runs, 0 skips 23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips 384: 75939 decicycles in fftwf_execute,1024 runs, 0 skips 73973 decicycles in compound_fft_3x128,1024 runs, 0 skips 640: 104354 decicycles in fftwf_execute, 1024 runs, 0 skips 149518 decicycles in compound_fft_5x128,1024 runs, 0 skips 768: 109323 decicycles in fftwf_execute,1024 runs, 0 skips 164096 decicycles in compound_fft_3x256,1024 runs, 0 skips 960: 186210 decicycles in fftwf_execute,1024 runs, 0 skips 215256 decicycles in compound_fft_15x64,1024 runs, 0 skips 1024: 163464 decicycles in fftwf_execute, 1024 runs, 0 skips 199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD is around 2x faster than theirs, even if our ptwo SIMD is slightly slower. The goal is to remove the libavcodec/mdct15 code and deprecate the libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported. It is unlikely that libavcodec/fft will be removed soon as there's much SIMD written for exotic or old platforms there, but nevertheless new code should use this new API throughout the project. The implementation passes fate when used in Opus and AAC, and the output is identical in ATRAC9 as well. --- libavutil/Makefile | 2 + libavutil/fft.c| 796 + libavutil/fft.h| 97 ++ 3 files changed, 895 insertions(+) create mode 100644 libavutil/fft.c create mode 100644 libavutil/fft.h diff --git a/libavutil/Makefile b/libavutil/Makefile index 53208fc587..a995eae626 100644 --- a/libavutil/Makefile +++ b/libavutil/Makefile @@ -27,6 +27,7 @@ HEADERS = adler32.h \ encryption_info.h \ error.h \ eval.h\ + fft.h \ fifo.h\ file.h\ frame.h \ @@ -113,6 +114,7 @@ OBJS = adler32.o\ encryption_info.o\ error.o \ eval.o \ + fft.o\ fifo.o
Re: [FFmpeg-devel] [PATCH] avfilter/xstack: set better error msg for missing layout
On 07-05-2019 05:45 PM, Moritz Barsnick wrote:
On Tue, May 07, 2019 at 16:26:01 +0530, Gyan wrote:
{ "inputs", "set number of inputs", OFFSET(nb_inputs), AV_OPT_TYPE_INT,
{.i64=2}, 2, INT_MAX, .flags = FLAGS },
-{ "layout", "set custom layout", OFFSET(layout), AV_OPT_TYPE_STRING,
{.str="0_0|w0_0"}, 0, 0, .flags = FLAGS },
+{ "layout", "set custom layout", OFFSET(layout), AV_OPT_TYPE_STRING,
{.str=NULL}, 0, 0, .flags = FLAGS },
{ "shortest", "force termination when the shortest input terminates",
OFFSET(shortest), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, .flags = FLAGS },
Because the default is no longer self-documenting ("ffmpeg -h
filter=xstack"), filters.texi should be updated to mention the default.
Done. Pushed as a0328f05dc02e61e8173f981cd578d0a36d7c0fc
Thanks,
Gyan
___
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 V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order
> patch1 (awk) configure: print_in_columns: replace pr with awk version: > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243380.html > patch2 (shell) configure: sort decoder/encoder/filter/... names in alphabet > order (v5 as posted in this thread) > > - Why do you prefer patch1 over patch2? In general, I agree with your reasoning, but not entirely sure about the conclusion and its implications. Few exceptions first: > 1. Statistics > * patch1: 1 file changed, 16 insertions(+), 2 deletions(-) > * patch2: 1 file changed, 24 insertions(+), 2 deletions(-) As you said later, and I agree, it's a weak argument, as both versions are the same code and complexity, but differ mostly in style and language syntax. > 2. patch2 uses lots of variables (which is good in itself), but those > should be local and we cannot express that portably in shell. > In turn we have raised potential for clashes now or in the future. This is incorrect. A subshell provides identical isolation as an external process, it's fully portable, it can be used here, and it's not slower than an external process, e.g. `print_in_columns() ( ... )`. > 4. Depending on the input (stdin) unexpected things can happen in the > "eval" and "set" lines. One example is given in the comment. "Unexpected" is a bit general. Specifically, the "eval" line does not execute arbitrary inputs, and neither does the "set" line. The only potential surprise is globbing, as documented, and the technique of expanding variables unquoted - like here, is used throughout configure. Look no further than 100% of the very places which pipe the input stream into print_in_columns, and multiple times earlier than that. It's not great of course, but it's not worse than elsewhere, and it's at least documented. Some day maybe someone would improve it. I generally agree with rest of your comments/arguments, including: > 1. Statistics ... (patch2 is more verbose). > 3. patch2 uses eval combined with non-trivial quoting, which is hard > to read and hard to grasp quickly. It's not wrong, but it's not as > easy and straight forward as in patch1. > 5. patch2 to uses shell for the parts easily expressed in shell and > uses awk for the parts that are non-trivial in shell. > 6. The awk implementation should be easier to read and understand for > the majority of readers/developers. which basically say that shell is hard, and, pardon the pun, awkward. And also I agree with: > Shell though is not really suited for implementing all kinds of algorithms. > OTOH shell is an excellent choice for starting processes that communicate > via stdin/stdout/stderr and plugging them together. and with > Shell is best when coordinating the execution of other programs. And similar assertions, however, let's keep the following facts in mind: - We both agree that we should keep to shell except where an external tool provides some meaningful value over shell code. - An external tool only helps by being more suitable for the task than shell code (readability, portability, correctness, performance, etc), but it doesn't help with isolation more than a subshell would. - Shell is capable in a portable way, including for some tasks which can be considered "programming". - configure is currently written in shell, including some non trivial functionality, and doesn't use external script engines for "scriptlets". - Being a shell script, it already requires competence and reasonable understanding of shell, including quoting, expansions, etc. - Maintaining code in more than one scripting system does carry a cost. - Yes, shell is a lousy programming language. I really don't care if this specific patch ends up as shell or awk. What I do care about is being consistent, and understanding the implications. IMHO, because I'm not convinced that the awk version provides a meaningful additional value other than not being shell, if we use the awk version then it sets a precedence of using awk (or maybe also other languages) for small scripts even if they're basically the same complexity and code as they would be in shell. It's not necessarily a bad precedence (even if I wouldn't do that myself), because I do agree that not being shell code does have value, but I think it's important to acknowledge that it does set such precedence. If there was already such practice of using awk scriptlets where possible then I wouldn't have said anything. So I mainly care about the precedence. I guess it comes down to a judgment call on whether or not this awk script can be considered meaningfully more suitable for the task than shell. I think not, but clearly it's only my subjective assessment. Regards, Avi ___ 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] avfilter/xstack: set better error msg for missing layout
On Tue, May 07, 2019 at 16:26:01 +0530, Gyan wrote:
> { "inputs", "set number of inputs", OFFSET(nb_inputs), AV_OPT_TYPE_INT,
> {.i64=2}, 2, INT_MAX, .flags = FLAGS },
> -{ "layout", "set custom layout", OFFSET(layout), AV_OPT_TYPE_STRING,
> {.str="0_0|w0_0"}, 0, 0, .flags = FLAGS },
> +{ "layout", "set custom layout", OFFSET(layout), AV_OPT_TYPE_STRING,
> {.str=NULL}, 0, 0, .flags = FLAGS },
> { "shortest", "force termination when the shortest input terminates",
> OFFSET(shortest), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, .flags = FLAGS },
Because the default is no longer self-documenting ("ffmpeg -h
filter=xstack"), filters.texi should be updated to mention the default.
Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/xstack: set better error msg for missing layout
On 07-05-2019 04:42 PM, Gyan wrote: On 07-05-2019 04:38 PM, Paul B Mahol wrote: On 5/7/19, Gyan wrote: Set a better error msg than the current failure to configure output pad. Please apply, but with: avfilter/vf_xstack: set better error msg for missing layout Will do. Thanks, Gyan Pushed as b3b7ba623f95224557bd67a060adf4ca7ee94dde Gyan ___ 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] avfilter/xstack: set better error msg for missing layout
On 07-05-2019 04:38 PM, Paul B Mahol wrote: On 5/7/19, Gyan wrote: Set a better error msg than the current failure to configure output pad. Please apply, but with: avfilter/vf_xstack: set better error msg for missing layout Will do. Thanks, Gyan ___ 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] avfilter/xstack: set better error msg for missing layout
On 5/7/19, Gyan wrote: > Set a better error msg than the current failure to configure output pad. > Please apply, but with: avfilter/vf_xstack: set better error msg for missing layout ___ 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] avfilter/xstack: set better error msg for missing layout
Set a better error msg than the current failure to configure output pad.
From 119516fe777e1e026503a6ba176a662680d711bd Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Tue, 7 May 2019 16:00:40 +0530
Subject: [PATCH] avfilter/xstack: set better error msg for missing layout
---
libavfilter/vf_stack.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
index b836d96bf0..1455f196a7 100644
--- a/libavfilter/vf_stack.c
+++ b/libavfilter/vf_stack.c
@@ -83,6 +83,15 @@ static av_cold int init(AVFilterContext *ctx)
return AVERROR(ENOMEM);
if (!strcmp(ctx->filter->name, "xstack")) {
+if (!s->layout) {
+if (s->nb_inputs == 2)
+s->layout = "0_0|w0_0";
+else {
+av_log(ctx, AV_LOG_ERROR, "No layout specified.\n");
+return AVERROR(EINVAL);
+}
+}
+
s->items = av_calloc(s->nb_inputs, sizeof(*s->items));
if (!s->items)
return AVERROR(ENOMEM);
@@ -385,7 +394,7 @@ AVFilter ff_vf_vstack = {
static const AVOption xstack_options[] = {
{ "inputs", "set number of inputs", OFFSET(nb_inputs), AV_OPT_TYPE_INT,
{.i64=2}, 2, INT_MAX, .flags = FLAGS },
-{ "layout", "set custom layout", OFFSET(layout), AV_OPT_TYPE_STRING,
{.str="0_0|w0_0"}, 0, 0, .flags = FLAGS },
+{ "layout", "set custom layout", OFFSET(layout), AV_OPT_TYPE_STRING,
{.str=NULL}, 0, 0, .flags = FLAGS },
{ "shortest", "force termination when the shortest input terminates",
OFFSET(shortest), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, .flags = FLAGS },
{ NULL },
};
--
2.21.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 v2] avformat/ifv: added support for ifv cctv files
On Sun, May 05, 2019 at 09:59:01PM +0200, Reimar Döffinger wrote:
> Hello!
> Nothing major, but a few comments on things that might make
> sense to polish below.
>
> On Sat, May 04, 2019 at 06:42:40PM +0530, Swaraj Hota wrote:
> > +#define IFV_MAGIC "\x11\xd2\xd3\xab\xba\xa9\xcf\x11\
> > +\x8e\xe6\x00\xc0\x0c\x20\x53\x65\x44"
>
> > +if (!memcmp(p->buf, IFV_MAGIC, 17))
>
> Using an array and sizeof() instead of the hard-coded 17 might be a bit
> nicer.
>
That will be another way to do it. I'll change it then.
> > +int ret;
> > +
> > +if (frame_type == AVMEDIA_TYPE_VIDEO) {
> > +ret = av_reallocp_array(&ifv->vid_index, ifv->total_vframes,
> > sizeof(IFVIndexEntry));
> > +if (ret < 0)
> > +return ret;
> > +
> > +} else if (frame_type == AVMEDIA_TYPE_AUDIO) {
> > +ret = av_reallocp_array(&ifv->aud_index, ifv->total_aframes,
> > sizeof(IFVIndexEntry));
> > +if (ret < 0)
> > +return ret;
> > +}
>
> Could just declare "ret" right where it is assigned.
>
Okay that could be done.
>
> > +/*read video index*/
> > +avio_seek(s->pb, 0xf8, SEEK_SET);
> [...]
> > +avio_skip(s->pb, ifv->vid_index->frame_offset - avio_tell(s->pb));
>
> Why use avio_seek in one place and avio_skip in the other?
>
No particular reason. Essentially all are just skips. There is no
backward seek. I left two seeks becuase they seemed more readable.
Someone could know at a glance at what offset the first video and audio
index are assumed/found to be. Should I change them to skips as well?
> > +pos = avio_tell(s->pb);
> > +
> > +for (i = 0; i < ifv->total_vframes; i++) {
> > +e = &ifv->vid_index[i];
> > +if (e->frame_offset >= pos)
> > +break;
> > +}
>
> This looks rather inefficient.
> Wouldn't it make more sense to either
> use a binary search or at least to
> remember the position from the last read?
> This also does not seem very robust either,
> if a single frame_offset gets corrupted
> to a very large value, this code will
> never be able to find the "correct" position.
> It seems to assume the frame_offset
> is ordered increasingly (as would be needed for
> binary search), but that property isn't
> really checked/enforced.
>
Yeah it is indeed inefficient. But it also seems like the "correct" one.
Because in case of seeking we might not be at the boundary of a frame
and hence might need to skip to the boundary of next frame we can find.
I guess this rules out binary search, and maybe also saving the last
read.
Regarding the frame_offset corruption, well that rules out binary search
as well because then the order of the index will be disturbed.
Or maybe I misunderstood? Please do mention if this can be done more
efficiently by some method. I really need some ideas on this if it can
be done.
> > +av_freep(&ifv->vid_index);
> > +if (ifv->is_audio_present)
> > +av_freep(&ifv->aud_index);
>
> Shouldn't the if () be unnecessary?
>
Yeah I guess it is unnecessary. I'll change it.
Thanks for the review!
___
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] avutil: Add NV24 and NV42 pixel formats
Thanks philip for taking this up.
LGTM.
Thanks,
ManojGupta.
> -Original Message-
> From: ffmpeg-devel On Behalf Of Philip
> Langdale
> Sent: Tuesday, May 7, 2019 10:03 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Philip Langdale
> Subject: [FFmpeg-devel] [PATCH] avutil: Add NV24 and NV42 pixel formats
>
> These are the 4:4:4 variants of the semi-planar NV12/NV21 formats.
>
> I'm surprised we've not had a reason to add them until now, but they are
> the format that VDPAU uses when doing interop for 4:4:4 surfaces.
>
> Signed-off-by: Philip Langdale
> ---
> libavutil/pixdesc.c | 24
> libavutil/pixfmt.h| 3 +++
> libavutil/tests/pixfmt_best.c | 1 +
> libavutil/version.h | 2 +-
> 4 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c index
> fe38344d73..b97b0665b0 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -2320,6 +2320,30 @@ static const AVPixFmtDescriptor
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> },
> .flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_ALPHA,
> },
> +[AV_PIX_FMT_NV24] = {
> +.name = "nv24",
> +.nb_components = 3,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 1, 0, 0, 8, 0, 7, 1 },/* Y */
> +{ 1, 2, 0, 0, 8, 1, 7, 1 },/* U */
> +{ 1, 2, 1, 0, 8, 1, 7, 2 },/* V */
> +},
> +.flags = AV_PIX_FMT_FLAG_PLANAR,
> +},
> +[AV_PIX_FMT_NV42] = {
> +.name = "nv42",
> +.nb_components = 3,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 1, 0, 0, 8, 0, 7, 1 },/* Y */
> +{ 1, 2, 1, 0, 8, 1, 7, 2 },/* U */
> +{ 1, 2, 0, 0, 8, 1, 7, 1 },/* V */
> +},
> +.flags = AV_PIX_FMT_FLAG_PLANAR,
> +},
> };
> #if FF_API_PLUS1_MINUS1
> FF_ENABLE_DEPRECATION_WARNINGS
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h index
> 24d1b7e415..8b54c9415b 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -345,6 +345,9 @@ enum AVPixelFormat {
> AV_PIX_FMT_YUVA444P12BE, ///< planar YUV 4:4:4,36bpp, (1 Cr & Cb
> sample per 1x1 Y samples), 12b alpha, big-endian
> AV_PIX_FMT_YUVA444P12LE, ///< planar YUV 4:4:4,36bpp, (1 Cr & Cb
> sample per 1x1 Y samples), 12b alpha, little-endian
>
> +AV_PIX_FMT_NV24, ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1
> plane for the UV components, which are interleaved (first byte U and the
> following byte V)
> +AV_PIX_FMT_NV42, ///< as above, but U and V bytes are swapped
> +
> AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if
> you want to link with shared libav* because the number of formats might
> differ between versions
> };
>
> diff --git a/libavutil/tests/pixfmt_best.c b/libavutil/tests/pixfmt_best.c
> index
> e98fcc19a5..53f7264207 100644
> --- a/libavutil/tests/pixfmt_best.c
> +++ b/libavutil/tests/pixfmt_best.c
> @@ -76,6 +76,7 @@ int main(void)
> TEST(AV_PIX_FMT_P010, AV_PIX_FMT_YUV420P10);
> TEST(AV_PIX_FMT_P016, AV_PIX_FMT_YUV420P16);
> TEST(AV_PIX_FMT_NV16, AV_PIX_FMT_YUV422P);
> +TEST(AV_PIX_FMT_NV24, AV_PIX_FMT_YUV444P);
> TEST(AV_PIX_FMT_YUYV422, AV_PIX_FMT_YUV422P);
> TEST(AV_PIX_FMT_UYVY422, AV_PIX_FMT_YUV422P);
> TEST(AV_PIX_FMT_BGR565,AV_PIX_FMT_RGB565);
> diff --git a/libavutil/version.h b/libavutil/version.h index
> c0968de621..4922e267cc 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -80,7 +80,7 @@
>
> #define LIBAVUTIL_VERSION_MAJOR 56
> #define LIBAVUTIL_VERSION_MINOR 26
> -#define LIBAVUTIL_VERSION_MICRO 101
> +#define LIBAVUTIL_VERSION_MICRO 102
>
> #define LIBAVUTIL_VERSION_INT
> AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> LIBAVUTIL_VERSION_MINOR, \
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-de
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/mediacodecdec: try to receive a frame after signaling EOF to the codec
On Thu, May 2, 2019 at 1:20 AM Matthieu Bouron
wrote:
> On Wed, Apr 24, 2019 at 09:59:28AM +0200, Matthieu Bouron wrote:
> > Avoids returning EAGAIN after signaling EOF to the codec in
> > ff_mediacodec_dec_send() so we can try to receive a frame before
> > returning in mediacodec_receive_frame().
> >
> > This helps avoiding an extra round-trip between avcodec_send_frame() and
> > avcodec_receive_frame() while draining the remaining frames.
> > ---
> > libavcodec/mediacodecdec.c| 1 +
> > libavcodec/mediacodecdec_common.c | 2 +-
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> > index 3a4240aa95..e353e34bd5 100644
> > --- a/libavcodec/mediacodecdec.c
> > +++ b/libavcodec/mediacodecdec.c
> > @@ -461,6 +461,7 @@ static int mediacodec_receive_frame(AVCodecContext
> *avctx, AVFrame *frame)
> > ret = ff_mediacodec_dec_send(avctx, s->ctx, &null_pkt,
> true);
> > if (ret < 0)
> > return ret;
> > +return ff_mediacodec_dec_receive(avctx, s->ctx, frame,
> true);
> > } else if (ret == AVERROR(EAGAIN) &&
> s->ctx->current_input_buffer < 0) {
> > return ff_mediacodec_dec_receive(avctx, s->ctx, frame,
> true);
> > } else if (ret < 0) {
> > diff --git a/libavcodec/mediacodecdec_common.c
> b/libavcodec/mediacodecdec_common.c
> > index 7c2661f672..f7a06cdc6d 100644
> > --- a/libavcodec/mediacodecdec_common.c
> > +++ b/libavcodec/mediacodecdec_common.c
> > @@ -631,7 +631,7 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx,
> MediaCodecDecContext *s,
> > "Queued input buffer %zd size=%zd ts=%"PRIi64"\n",
> index, size, pts);
> >
> > s->draining = 1;
> > -break;
> > +return 0;
> > } else {
> > size = FFMIN(pkt->size - offset, size);
> > memcpy(data, pkt->data + offset, size);
> > --
> > 2.21.0
> >
>
> Ping.
>
Did not test, but the diffs look reasonable to me.
>
> --
> Matthieu B.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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 1/2] fftools/ffmpeg_filter, ffplay: Add flip support to rotation
On Mon, May 06, 2019 at 22:36:41 -0700, Jun Li wrote:
> +double av_display_rotation_hflip_get(const int32_t matrix[9], int *hflip)
> +{
> +int32_t m[9];
> +*hflip = 0;
> +memcpy(m, matrix, sizeof(int32_t) * 9);
You were asked to avoid this (at another code location though).
BTW, sizeof(m) would be a better use of sizeof() here. (Or a constant
for the triple but related use of "9".)
> +return av_display_rotation_get(m);
> +}
> \ No newline at end of file
Cosmetic, but please add a line feed in the last line of the file.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavutil: add an FFT & MDCT implementation
On Tue, May 07, 2019 at 01:33:08 +0200, Lynne wrote: > May 6, 2019, 11:41 PM by barsn...@gmx.net: > > Would there be a desire for a static implementation as well, for those > > using "-enable-hardcoded-tables" (CONFIG_HARDCODED_TABLES)? Just > > wondering whether that's esoteric, optional, or really nice to have. > > Not really, its just nicer, saves 64 bytes per context and some time on > subsequent inits, > and might help with SIMD because more can be hardcoded into the assembly. [...] Thanks for the explanation. Such development details aren't well documented (or I have a hard time re-discovering threads where such stuff was covered). Cheers, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] scaletempo filter
On 5/6/19, Marton Balint wrote: > > > On Mon, 6 May 2019, Marton Balint wrote: > >> >> >> On Mon, 6 May 2019, Paul B Mahol wrote: >> >>> On 5/6/19, Marton Balint wrote: On Sat, 4 May 2019, John Warburton wrote: > On Sat, May 4, 2019 at 3:34 PM Nicolas George wrote: > >> John Warburton (12019-05-04): >> >> > Is there a patch I can use to test scaletempo to compare it against >> atempo? >> > It'll be no trouble to do that with the normal audio that is >> time-adjusted >> > on that radio station. It may be that its increased quality is most >> >> John, we would appreciate your input about whether these new >> implementation of atempo is superior or equal to the existing one with >> regard to your needs. I tested scaletempo (with default settings) and it is definitely worse than atempo for small scaling factors like 25/24. >>> >>> Have you tried other scaling factors? >>> How you done testing? >> >> Simple hearing tests. I hear audible artifacts (a kind of audio >> stuttering) with scaletempo. Here are some files where it is noticable: >> >> fate-suite/delphine-cin/LOGO-partial.CIN >> fate-suite/real/spygames-2MB.rmvb >> fate-suite/wmapro/Beethovens_9th-1_small.wma >> fate-suite/dts/dts.ts >> >> The last one is noticable even with 2x scaling. > > Another one, audible with any (0.5, ~1, 2) scaling: > > fate-suite/paf/hod1-partial.paf > OK, vote and patch dropped. Even by using basically same algorithm, it is very slow to get same quality because does not use FFT for cross-correlation. ___ 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] swscale/ppc: VSX-optimize hScale8To19_vsx
On Tue, 30 Apr 2019 14:43:52 +0300 Lauri Kasanen wrote: > ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \ > -s 2400x720 -f rawvideo -y -vframes 5 -pix_fmt yuv420p16le -nostats > test.raw > > 2.26 speedup (x86 SSE2 is 2.32): > 23772 UNITS in hscale,4096 runs, 0 skips > 53862 UNITS in hscale,4096 runs, 0 skips > > Signed-off-by: Lauri Kasanen > --- > libswscale/ppc/swscale_vsx.c | 64 > +++- > 1 file changed, 63 insertions(+), 1 deletion(-) Applying the series. - Lauri ___ 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".
