Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
Quoting Nicolas George (2020-01-12 14:33:19) > Anton Khirnov (12020-01-07): > > Why would such filters exist and why would we accept them? I do not see > > how can there be a clean user interface for a broken and undefined use > > case. > > They are already there, they work very well, and people use them. Their > behavior is perfectly well defined, but to give them a good user > interface requires channel names and duplication. It's too bad you > invested a lot of work while forgetting about them. You still did not say which filters those are, why do they need to create streams with duplicate channels, or for that matter how they can even do so when the current API does not support it. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/oggparsevorbis: Error out on double init of vp
Fixes: memleak Fixes: 19949/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5743636058210304 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/oggparsevorbis.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c index 43f05f928a..889c7950d3 100644 --- a/libavformat/oggparsevorbis.c +++ b/libavformat/oggparsevorbis.c @@ -230,7 +230,7 @@ static int fixup_vorbis_headers(AVFormatContext *as, len = priv->len[0] + priv->len[1] + priv->len[2]; buf_len = len + len / 255 + 64; -if (*buf) +if (*buf || priv->vp) return AVERROR_INVALIDDATA; ptr = *buf = av_realloc(NULL, buf_len); -- 2.24.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] avio: do not export avpriv_io_{move, delete}
Quoting Hendrik Leppkes (2020-01-10 23:40:37) > On Fri, Jan 10, 2020 at 7:31 PM James Almer wrote: > > Yes, i agree with this if we were talking about clearly marked > > non-public structs, fields and defines. In those cases, people using > > them should be aware of the consequences. But these are two five years > > old documented functions in a public header (Although admittedly not > > announced in APIChanges) and even featured in an API example tool. > > I don't think the avpriv_ prefix is something we documented outside of > > the developer guidelines, so anyone reading avio.h and the example will > > have no reason to think these were there by mistake. > > > > You could replace the doxy with a "do not use" notice aside from > > wrapping them in a scheduled removal preprocessor check, but at the very > > least the symbols should not be removed until the next major bump. > > > > If others agree with you though, I'll not block this. > > > > If we plan to do a bump relatively soon anyway, then there is no > reason to really rush anything, and just let them in until such a time > that there is a bump. Considering their only not-really-public nature > we can forego the 2 year deprecation and just throw them out when we > open the ABI. Ok, I can wait with this patch until the bump if it's going to happen soon. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavfi/dnn_processing: refine code to use function av_image_copy_plane for data copy
Signed-off-by: Guo, Yejun
---
libavfilter/vf_dnn_processing.c | 85 -
1 file changed, 24 insertions(+), 61 deletions(-)
diff --git a/libavfilter/vf_dnn_processing.c b/libavfilter/vf_dnn_processing.c
index 13273f2..492df93 100644
--- a/libavfilter/vf_dnn_processing.c
+++ b/libavfilter/vf_dnn_processing.c
@@ -27,6 +27,7 @@
#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
#include "libavutil/avassert.h"
+#include "libavutil/imgutils.h"
#include "avfilter.h"
#include "dnn_interface.h"
#include "formats.h"
@@ -231,6 +232,8 @@ static int config_output(AVFilterLink *outlink)
static int copy_from_frame_to_dnn(DNNData *dnn_input, const AVFrame *frame)
{
+int bytewidth = av_image_get_linesize(frame->format, frame->width, 0);
+
switch (frame->format) {
case AV_PIX_FMT_RGB24:
case AV_PIX_FMT_BGR24:
@@ -244,42 +247,17 @@ static int copy_from_frame_to_dnn(DNNData *dnn_input,
const AVFrame *frame)
}
}
} else {
-uint8_t *dnn_input_data = dnn_input->data;
av_assert0(dnn_input->dt == DNN_UINT8);
-for (int i = 0; i < frame->height; i++) {
-for(int j = 0; j < frame->width * 3; j++) {
-int k = i * frame->linesize[0] + j;
-int t = i * frame->width * 3 + j;
-dnn_input_data[t] = frame->data[0][k];
-}
-}
+av_image_copy_plane(dnn_input->data, bytewidth,
+frame->data[0], frame->linesize[0],
+bytewidth, frame->height);
}
return 0;
case AV_PIX_FMT_GRAY8:
-{
-uint8_t *dnn_input_data = dnn_input->data;
-av_assert0(dnn_input->dt == DNN_UINT8);
-for (int i = 0; i < frame->height; i++) {
-for(int j = 0; j < frame->width; j++) {
-int k = i * frame->linesize[0] + j;
-int t = i * frame->width + j;
-dnn_input_data[t] = frame->data[0][k];
-}
-}
-}
-return 0;
case AV_PIX_FMT_GRAYF32:
-{
-float *dnn_input_data = dnn_input->data;
-av_assert0(dnn_input->dt == DNN_FLOAT);
-for (int i = 0; i < frame->height; i++) {
-for(int j = 0; j < frame->width; j++) {
-int k = i * frame->linesize[0] + j * sizeof(float);
-int t = i * frame->width + j;
-dnn_input_data[t] = *(float*)(frame->data[0] + k);
-}
-}
-}
+av_image_copy_plane(dnn_input->data, bytewidth,
+frame->data[0], frame->linesize[0],
+bytewidth, frame->height);
return 0;
default:
return AVERROR(EIO);
@@ -290,6 +268,8 @@ static int copy_from_frame_to_dnn(DNNData *dnn_input, const
AVFrame *frame)
static int copy_from_dnn_to_frame(AVFrame *frame, const DNNData *dnn_output)
{
+int bytewidth = av_image_get_linesize(frame->format, frame->width, 0);
+
switch (frame->format) {
case AV_PIX_FMT_RGB24:
case AV_PIX_FMT_BGR24:
@@ -303,42 +283,25 @@ static int copy_from_dnn_to_frame(AVFrame *frame, const
DNNData *dnn_output)
}
}
} else {
-uint8_t *dnn_output_data = dnn_output->data;
av_assert0(dnn_output->dt == DNN_UINT8);
-for (int i = 0; i < frame->height; i++) {
-for(int j = 0; j < frame->width * 3; j++) {
-int k = i * frame->linesize[0] + j;
-int t = i * frame->width * 3 + j;
-frame->data[0][k] = dnn_output_data[t];
-}
-}
+av_image_copy_plane(frame->data[0], frame->linesize[0],
+dnn_output->data, bytewidth,
+bytewidth, frame->height);
}
return 0;
case AV_PIX_FMT_GRAY8:
-{
-uint8_t *dnn_output_data = dnn_output->data;
-av_assert0(dnn_output->dt == DNN_UINT8);
-for (int i = 0; i < frame->height; i++) {
-for(int j = 0; j < frame->width; j++) {
-int k = i * frame->linesize[0] + j;
-int t = i * frame->width + j;
-frame->data[0][k] = dnn_output_data[t];
-}
-}
-}
+// it is possible that data type of dnn output is float32,
+// need to add support for such case when needed.
+av_assert0(dnn_output->dt == DNN_UINT8);
+av_image_copy_plane(frame->data[0], frame->linesize[0],
+dnn_output->data, bytewidth,
+bytewidth, frame->height);
return 0;
case AV_PIX_FMT_GRAYF32:
-{
-float *dnn_output_data = d
Re: [FFmpeg-devel] [PATCHv2 1/3] avutil/eval: separate AVExpr state to a new AVExprState struct
Quoting Marton Balint (2020-01-10 18:42:03) > > > On Fri, 10 Jan 2020, Anton Khirnov wrote: > > > Quoting Marton Balint (2019-12-30 23:23:40) > >> Also add helper functions to allocate and free such a struct, and make it > >> usable by providing a new av_eval_expr2 function for which you can specify > >> a > >> custom AVExprState. > > > > Why not just parse the expression multiple times? Performance? > > For fixing the vf_geq issue in the second patch, yes parsing the > expression multiple times should work, parsing MAX_THREADS * 4 expressions > is totally OK. > > However API-wise, it is cleaner to separate state from the expression, I > find it totally unintuitive that an expression has a state or that > evaluating an expression is not thread safe. I agree that it is unintuitive and that it would be good to address that. My concern is that you are adding new ways to use the API, but do not remove or deprecate the previous unintuitive ones. > > > Beyond that, it seems to me that the user now has to juggle multiple > > contexts manually, which is complex and can be avoided. > > It is only a possibility, most users can use av_eval_expr as before and > use the internal state of the expression. And get burned by the exact same issue you are fixing here. Our APIs generally have a bad reputation for being obscure and hard to use. I think we should put more effort into making it hard to use them incorrectly. > > > How about introducing a function for duplicating AVExpr instead? Would > > that not solve this as well? > > I don't really like this idea, you want to duplicate the state, > not the expression. The question is: what is (or should be) AVExpr? Is it an immutable parsed expression? Then why should it be visible to the API users at all? the only meaningful operation on it is instantiating the expression evaluation state. We could also just rename AVExpr to AVExprState - or maybe AVExpr(Eval)Context to be consistent with other APIs (keeping the old name as a deprecated alias until next bump) to make it clear that it has internal state. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/oggparsevorbis: Error out on double init of vp
NAK On 1/13/20, Michael Niedermayer wrote: > Fixes: memleak > Fixes: > 19949/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5743636058210304 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/oggparsevorbis.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c > index 43f05f928a..889c7950d3 100644 > --- a/libavformat/oggparsevorbis.c > +++ b/libavformat/oggparsevorbis.c > @@ -230,7 +230,7 @@ static int fixup_vorbis_headers(AVFormatContext *as, > len = priv->len[0] + priv->len[1] + priv->len[2]; > buf_len = len + len / 255 + 64; > > -if (*buf) > +if (*buf || priv->vp) > return AVERROR_INVALIDDATA; > > ptr = *buf = av_realloc(NULL, buf_len); > -- > 2.24.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".
Re: [FFmpeg-devel] [PATCH V1 01/11] lavfi/spp: add "quality" option in runtime change path
On Sat, Jan 11, 2020 at 12:13:48 +0800, Jun Zhao wrote:
> +@item level
> +@item quality
> +Same as quality option. And the command accepts the @code{max} same as the
> @code{6}.
> +@end table
I'm sorry for coming in late, but this sentence doesn't make much sense
to me:
And the command accepts the "max" same as the 6.
Are you trying to say that the allowed range for the command(s) is
(are) the same as for the option?
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".
[FFmpeg-devel] [PATCH v1] avfilter/vf_eq: cosmetics
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_eq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
index f4cf499..de93901 100644
--- a/libavfilter/vf_eq.c
+++ b/libavfilter/vf_eq.c
@@ -390,5 +390,5 @@ AVFilter ff_vf_eq = {
.query_formats = query_formats,
.init= initialize,
.uninit = uninit,
-.flags = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC,
+.flags = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC,
};
--
2.9.5
___
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 v1 3/3] avutil/tests: add more avstring test case for fate
From: Limin Wang
One test case is different, before the patchset, it's:
"path" + "/" = "path/"
After applied the patchset, it's:
"path" + "/" = "path"
Signed-off-by: Limin Wang
---
libavutil/tests/avstring.c | 3 +++
tests/ref/fate/avstring| 3 +++
2 files changed, 6 insertions(+)
diff --git a/libavutil/tests/avstring.c b/libavutil/tests/avstring.c
index 887bd25..a94f7a5 100644
--- a/libavutil/tests/avstring.c
+++ b/libavutil/tests/avstring.c
@@ -76,6 +76,9 @@ int main(void)
TEST_APPEND_PATH_COMPONENT(NULL, NULL, "(null)")
TEST_APPEND_PATH_COMPONENT("path", NULL, "path");
TEST_APPEND_PATH_COMPONENT(NULL, "comp", "comp");
+TEST_APPEND_PATH_COMPONENT("path", "", "path");
+TEST_APPEND_PATH_COMPONENT("", "comp", "comp");
+TEST_APPEND_PATH_COMPONENT("path", "/", "path");
TEST_APPEND_PATH_COMPONENT("path", "comp", "path/comp");
TEST_APPEND_PATH_COMPONENT("path/", "comp", "path/comp");
TEST_APPEND_PATH_COMPONENT("path", "/comp", "path/comp");
diff --git a/tests/ref/fate/avstring b/tests/ref/fate/avstring
index 1ca9be5..92ec918 100644
--- a/tests/ref/fate/avstring
+++ b/tests/ref/fate/avstring
@@ -29,6 +29,9 @@ Testing av_append_path_component()
(null) = (null)
path = path
comp = comp
+path = path
+comp = comp
+path/ = path
path/comp = path/comp
path/comp = path/comp
path/comp = path/comp
--
2.9.5
___
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/9] avformat/s337m: Consider container bit resolution
>> +if (container_word_bits && (container_word_bits+7)/8 !=
>> + (word_bits+7)/8) {
>
>Can it happen that word_bits is anything but 16 or 24 with a valid stream? If
>not then I'd check container_word_bits == word_bits && (word_bits == 16 ||
>word_bits == 24) or so
word_bits may be 20, and in that case container_word_bits must be 24 (this is
the case in my fate test), so I think this is correct.
>> +while ((container_word_bits == 24 || !IS_16LE_MARKER(state))
>> +&& (container_word_bits == 16 || !IS_20LE_MARKER(state) &&
>> + !IS_24LE_MARKER(state))) {
>
>I'd rewrite this as while ((bits == 24 && (20LE || 24LE)) || (bits ==20 &&
>16LE)), more readable
container_word_bits may be 0 for autodetect, this results in this expression...
I agree it is not that great for readability, but doing otherwise would require
some additions and macros duplications, for example:
while ( !(!bits && LE) || !(bits == 24 && (20LE || 24LE)) || !(bits ==16 &&
16LE))
Sounds heavy, not sure this is really better ?
Nicolas
___
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 v1 1/3] avutil/avstring: Fix warning: ISO C90 forbids mixed declarations and code
From: Limin Wang
Signed-off-by: Limin Wang
---
libavutil/avstring.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index 76a13ba..f4b8ed2 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -258,15 +258,17 @@ char *av_strireplace(const char *str, const char *from,
const char *to)
const char *av_basename(const char *path)
{
char *p;
+#if HAVE_DOS_PATHS
+char *q, *d;
+#endif
if (!path || *path == '\0')
return ".";
p = strrchr(path, '/');
#if HAVE_DOS_PATHS
-char *q = strrchr(path, '\\');
-char *d = strchr(path, ':');
-
+q = strrchr(path, '\\');
+d = strchr(path, ':');
p = FFMAX3(p, q, d);
#endif
--
2.9.5
___
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 v1 2/3] avutil/avstring: add support for '\\' seperator for the path append
From: Limin Wang
I don't have a windows develoment system yet, so I had to test with modified
avutil/tests/avstring.c like below,
(change / to \\) and change HAVE_DOS_PATHS to 1 in config.h:
-TEST_APPEND_PATH_COMPONENT("path", "/", "path");
-TEST_APPEND_PATH_COMPONENT("path", "comp", "path/comp");
-TEST_APPEND_PATH_COMPONENT("path/", "comp", "path/comp");
-TEST_APPEND_PATH_COMPONENT("path", "/comp", "path/comp");
-TEST_APPEND_PATH_COMPONENT("path/", "/comp", "path/comp");
-TEST_APPEND_PATH_COMPONENT("path/path2/", "/comp/comp2",
"path/path2/comp/comp2");
+TEST_APPEND_PATH_COMPONENT("path", "\\", "path");
+TEST_APPEND_PATH_COMPONENT("path", "comp", "path\\comp");
+TEST_APPEND_PATH_COMPONENT("path\\", "comp", "path\\comp");
+TEST_APPEND_PATH_COMPONENT("path", "\\comp", "path\\comp");
+TEST_APPEND_PATH_COMPONENT("path\\", "\\comp", "path\\comp");
+TEST_APPEND_PATH_COMPONENT("path\\path2\\", "\\comp\\comp2",
"path\\path2\\comp\\comp2");
Then do test with fate-avstring for valid checking:
make fate-avstring SAMPLES=../fate-suite
master:
-path/comp = path/comp
-path/comp = path/comp
-path/comp = path/comp
-path/comp = path/comp
-path/path2/comp/comp2 = path/path2/comp/comp2
+path/comp = path\comp
+path\/comp = path\comp
+path/\comp = path\comp
+path\/\comp = path\comp
+path\path2\/\comp\comp2 = path\path2\comp\comp2
Applied the patch:
-path/comp = path/comp
-path/comp = path/comp
-path/comp = path/comp
-path/comp = path/comp
-path/path2/comp/comp2 = path/path2/comp/comp2
+path\comp = path\comp
+path\comp = path\comp
+path\comp = path\comp
+path\comp = path\comp
+path\path2\comp\comp2 = path\path2\comp\comp2
Signed-off-by: Limin Wang
---
libavutil/avstring.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index f4b8ed2..24bcc7d 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -299,14 +299,20 @@ const char *av_dirname(char *path)
return path;
}
+#if HAVE_DOS_PATHS
+#define SEPARATOR '\\'
+#else
+#define SEPARATOR '/'
+#endif
+
char *av_append_path_component(const char *path, const char *component)
{
size_t p_len, c_len;
char *fullpath;
-if (!path)
+if (!path || strlen(path) == 0 )
return av_strdup(component);
-if (!component)
+if (!component || strlen(component) == 0)
return av_strdup(path);
p_len = strlen(path);
@@ -315,18 +321,16 @@ char *av_append_path_component(const char *path, const
char *component)
return NULL;
fullpath = av_malloc(p_len + c_len + 2);
if (fullpath) {
-if (p_len) {
-av_strlcpy(fullpath, path, p_len + 1);
-if (c_len) {
-if (fullpath[p_len - 1] != '/' && component[0] != '/')
-fullpath[p_len++] = '/';
-else if (fullpath[p_len - 1] == '/' && component[0] == '/')
-p_len--;
-}
-}
-av_strlcpy(&fullpath[p_len], component, c_len + 1);
-fullpath[p_len + c_len] = 0;
+const char *component1 = component;
+
+av_strlcpy(fullpath, path, p_len + 1);
+if (fullpath[p_len - 1] != SEPARATOR)
+fullpath[p_len++] = SEPARATOR;
+if (*component1 == SEPARATOR)
+component1++;
+av_strlcpy(fullpath + p_len, component1, strlen(component1) + 1);
}
+
return fullpath;
}
--
2.9.5
___
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 6/9] avformat/wavdec: fix s337m/spdif probing beyond data_end
>> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
>> 2796905e1f..ccb9576b84 100644
>> --- a/libavformat/wavdec.c
>> +++ b/libavformat/wavdec.c
>> @@ -78,7 +78,7 @@ static void set_spdif_s337m(AVFormatContext *s,
>> WAVDemuxContext *wav)
>> ret = AVERROR(ENOMEM);
>> } else {
>> int64_t pos = avio_tell(s->pb);
>> -len = ret = avio_read(s->pb, buf, len);
>> +len = ret = avio_read(s->pb, buf, FFMIN(len,
>> + wav->data_end - pos));
>> if (len >= 0) {
>> ret = ff_spdif_probe(buf, len, &codec);
>> if (ret > AVPROBE_SCORE_EXTENSION) {
>
>Looks OK. I suppose this fixes a potential SIGSEGV too?
AVIO would just stop at EOF, I don't think a SIGSEGV could occur in any
scenario.
This fix only affects probing (ie. reading start of file) in a surprising
scenario where the data chunk would not extend to the end of the file.
This is many IF and I find it unlikely, but I think it should be fixed anyway.
Nicolas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 7/9] avformat/wavdec: Fix s337m last packet parsing
>> if (CONFIG_SPDIF_DEMUXER && wav->spdif == 1)
>> return ff_spdif_read_packet(s, pkt);
>> -if (CONFIG_S337M_DEMUXER && wav->s337m == 1)
>> -return ff_s337m_read_packet(s, pkt);
>>
>> if (wav->smv_data_ofs > 0) {
>> int64_t audio_dts, video_dts; @@ -712,6 +710,10 @@ smv_out:
>> wav->data_end = avio_tell(s->pb) + left;
>> }
>>
>> +if (CONFIG_S337M_DEMUXER && wav->s337m == 1) {
>> +size = FFMIN(S337M_MAX_OFFSET, left);
>> +ret = ff_s337m_get_packet(s->pb, pkt, size, NULL, s,
>> st->codecpar->bits_per_coded_sample);
>> +} else {
>
>Couldn't you roll this into the patch that adds the call to
>ff_s337m_read_packet()?
OK. I was not sure about it. I thought it might have been interesting to keep
s337m as close as possible to spdif as long as possible, and then only fork at
the very end with this last patch, but maybe it is does not make so much sense.
Thus, I will move ff_s337m_read_packet() back to a static s337m_read_packet(),
I think this is better as indeed s337m_read_packet should never be used from
outside when s337m is submuxed in another mux because it does not restrict the
available size that could be read from avio.
Nicolas
___
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 21/21] avformat/matroskaenc: Simplify writing Void elements
Reserving space in Matroska works by writing a Void element. And until
now this worked as follows: The current position was recorded and the
EBML ID as well as the length field written; then the new position was
recorded to know how much more to write. Afterwards the actual writing
has been performed via ffio_fill().
But it is unnecessary to explicitly use the positions (obtained via
avio_tell()) to find out how much still needs to be written, because the
length of the ID and the length field are known. So rewrite the function
to no longer use them.
Also, given that ffio_fill() uses an int parameter and given that no
current caller (and no sane future caller) will want to reserve several
GB of space, make the size parameter of put_ebml_void() itself an int.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 258638e459..e74d59d271 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -288,21 +288,22 @@ static void put_ebml_string(AVIOContext *pb, uint32_t
elementid,
*
* @param size The number of bytes to reserve, which must be at least 2.
*/
-static void put_ebml_void(AVIOContext *pb, uint64_t size)
+static void put_ebml_void(AVIOContext *pb, int size)
{
-int64_t currentpos = avio_tell(pb);
-
av_assert0(size >= 2);
put_ebml_id(pb, EBML_ID_VOID);
// we need to subtract the length needed to store the size from the
// size we need to reserve so 2 cases, we use 8 bytes to store the
// size if possible, 1 byte otherwise
-if (size < 10)
-put_ebml_num(pb, size - 2, 0);
-else
-put_ebml_num(pb, size - 9, 8);
-ffio_fill(pb, 0, currentpos + size - avio_tell(pb));
+if (size < 10) {
+size -= 2;
+put_ebml_num(pb, size, 0);
+} else {
+size -= 9;
+put_ebml_num(pb, size, 8);
+}
+ffio_fill(pb, 0, size);
}
static ebml_master start_ebml_master(AVIOContext *pb, uint32_t elementid,
--
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".
Re: [FFmpeg-devel] [PATCH 02/11] avformat: Remove unnecessary av_packet_unref()
On Tue, Jan 7, 2020 at 2:56 PM Andreas Rheinhardt < andreas.rheinha...@gmail.com> wrote: > Since bae8844e the packet will always be unreferenced when a demuxer > returns an error, so that a lot of calls to av_packet_unref() in lots of > demuxers are now redundant and can be removed. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/aacdec.c | 6 -- > libavformat/adp.c| 1 - > libavformat/adxdec.c | 2 -- > libavformat/amr.c| 1 - > libavformat/ape.c| 1 - > libavformat/avs.c| 1 - > libavformat/brstm.c | 3 +-- > libavformat/c93.c| 13 +++-- > libavformat/cdxl.c | 1 - > libavformat/concatdec.c | 4 +--- > libavformat/dfa.c| 3 --- > libavformat/dsicin.c | 1 - > libavformat/dss.c| 6 +- > libavformat/dxa.c| 1 - > libavformat/electronicarts.c | 3 --- > libavformat/fitsdec.c| 2 -- > libavformat/flic.c | 3 +-- > libavformat/g723_1.c | 1 - > libavformat/gdv.c| 1 - > libavformat/gsmdec.c | 1 - > libavformat/hls.c| 1 - > libavformat/icodec.c | 1 - > libavformat/idcin.c | 2 -- > libavformat/idroqdec.c | 3 +-- > libavformat/ilbc.c | 1 - > libavformat/img2dec.c| 1 - > libavformat/iv8.c| 1 - > libavformat/libmodplug.c | 1 - > libavformat/lxfdec.c | 1 - > libavformat/mov.c| 1 - > libavformat/mpc.c| 1 - > libavformat/mpegts.c | 1 - > libavformat/mpjpegdec.c | 2 -- > libavformat/ncdec.c | 1 - > libavformat/nuv.c| 1 - > libavformat/oggdec.c | 7 ++- > libavformat/redspark.c | 1 - > libavformat/rl2.c| 1 - > libavformat/rpl.c| 2 -- > libavformat/s337m.c | 2 -- > libavformat/sapdec.c | 1 - > libavformat/sdr2.c | 1 - > libavformat/sierravmd.c | 1 - > libavformat/siff.c | 1 - > libavformat/spdifdec.c | 5 + > libavformat/swfdec.c | 3 --- > libavformat/thp.c| 2 -- > libavformat/vivo.c | 14 +- > libavformat/vpk.c| 4 +--- > libavformat/vqf.c| 1 - > libavformat/wvdec.c | 4 > libavformat/yuv4mpegdec.c| 1 - > 52 files changed, 17 insertions(+), 108 deletions(-) > > Ping for this and the other open patches (namely #1, #2, #5 and #9) of this patchset. If it is deemed to help reviewing I can split this patch per-file. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] ffplay is not working on ARM processor
On Mon, Jan 13, 2020 at 12:08:28 +0530, Parameshwaran Thangaraj wrote: > I would like to cross compile ffmpeg and ffplay for linux embedded with ARM > processor. > Other parameters: > *Toradex Apalis iMX6* > *RAM 1GB* > > ffmpeg is working fine. But ffplay is not working. Shows following error, This mailing list is for the discussion of the development of ffmpeg and its tools. You are encountering a crash which may be considered a serious bug, so kindly report it on the bug tracker: https://ffmpeg.org/bugreports.html (Note: Once you have gathered the information requested, go to https://trac.ffmpeg.org/) Please note that you have compiled from an old git snapshot. Please grab the latest HEAD from master. Since you are encountering a segmentation fault, please take special notice to the section "If you encounter a crash bug..." and the instructions given there. Those instructions are quite straight forward, except for the "git bisect", which you can skip initially. Thanks, 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 v4 1/1] avdevice/gdigrab add use_captureblt option
On 11/01/2020 09:18, fgodt...@hotmail.com wrote: > From: FgoDt > > Add use_captureblt option for disable or use CAPTUREBLT flag, when useing the > bitblt function with CAPTUREBLT may caused the Windows mouse cursor flicker. > most time we don't need this flag to capture window > I tested on Windows 10 works fine > > Signed-off-by: fgodt > --- > doc/indevs.texi | 7 +++ > libavdevice/gdigrab.c | 10 +- > 2 files changed, 16 insertions(+), 1 deletion(-) Does it make sense to name this something like 'capature_layered_windows'? Using the name of the flag is a bit unintuitive from a user perspective. Same for the description. - Derek ___ 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 9/9] avformat/wavdec: Test s337m
>> Test the new 'dolbyeprobe' AVOption.
>> Test dolby_e decoding for 24 bits with program config '5.1+2'
>> ---
>> tests/Makefile | 1 +
>> tests/fate-run.sh| 4
>> tests/fate/audio.mak | 5 +
>> 3 files changed, 10 insertions(+)
>>
>> diff --git a/tests/Makefile b/tests/Makefile index
>> e5f41008d4..65cccac312 100644
>> --- a/tests/Makefile
>> +++ b/tests/Makefile
>> @@ -75,6 +75,7 @@ ENCDEC2 = $(call ALLYES, $(firstword $(1))_ENCODER
>> $(lastword $(1))_DECODER \
>> $(firstword $(3))_MUXER $(lastword $(3))_DEMUXER)
>>
>> DEMDEC = $(call ALLYES, $(1)_DEMUXER $(2:%=%_DECODER))
>> +DEMDEMDEC = $(call ALLYES, $(1)_DEMUXER $(2)_DEMUXER
>> +$(3:%=%_DECODER))
>> ENCMUX = $(call ALLYES, $(1:%=%_ENCODER) $(2)_MUXER)
>>
>> DEMMUX = $(call ALLYES, $(1)_DEMUXER $(2)_MUXER) diff --git
>> a/tests/fate-run.sh b/tests/fate-run.sh index 83cad8cabe..f06b2fd029
>> 100755
>> --- a/tests/fate-run.sh
>> +++ b/tests/fate-run.sh
>> @@ -162,6 +162,10 @@ pcm(){
>> ffmpeg "$@" -vn -f s16le -
>> }
>>
>> +dolbye2pcm16(){
>> +ffmpeg -dolbyeprobe 1 "$@" -vn -f s16le - }
>> +
>> fmtstdout(){
>> fmt=$1
>> shift 1
>> diff --git a/tests/fate/audio.mak b/tests/fate/audio.mak index
>> c41958ea2d..0e56d401ea 100644
>> --- a/tests/fate/audio.mak
>> +++ b/tests/fate/audio.mak
>> @@ -24,6 +24,11 @@ fate-dolby-e: CMD = pcm -i
>> $(TARGET_SAMPLES)/dolby_e/16-11
>> fate-dolby-e: CMP = oneoff
>> fate-dolby-e: REF = $(SAMPLES)/dolby_e/16-11.pcm
>>
>> +FATE_SAMPLES_AUDIO-$(call DEMDEMDEC, WAV, S337M, DOLBY_E) +=
>> +fate-dolby-e-wav
>> +fate-dolby-e-wav: CMD = dolbye2pcm16 -i
>> +$(TARGET_SAMPLES)/dolby_e/512.wav
>> +fate-dolby-e-wav: CMP = oneoff
>> +fate-dolby-e-wav: REF = $(SAMPLES)/dolby_e/512.wav.pcm
>> +
>> FATE_SAMPLES_AUDIO-$(call DEMDEC, DSS, DSS_SP) += fate-dss-lp
>> fate-dss-sp
>> fate-dss-lp: CMD = framecrc -i $(TARGET_SAMPLES)/dss/lp.dss -frames
>> 30
>> fate-dss-sp: CMD = framecrc -i $(TARGET_SAMPLES)/dss/sp.dss -frames
>> 30
>>
>This is missing some kind of hash check on the demuxed data
The "oneoff" tests consists in checking the maximum difference between the raw
pcm output samples, it must be 0 or 1 max. This test is done in 16-bit
truncated output of the decoded stream.
It raises an error too if the duration does not strictly match. I found it
appropriate (a strict hash on decoded samples may also break with the many
floats of the DolbyE decoder).
My idea was to keep a single test for both "wav demux" and "5.1+2" decode.
Do you think there should be an additional test focused on demuxed data ?
Nicolas
___
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: compare without the last directory separator in get_relative_url
On 10/01/2020 14:51, Steven Liu wrote: > fix ticket: 8461 > > Signed-off-by: Steven Liu > --- > libavformat/hlsenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Can you explain the intent? The referenced bug seems specific to Windows? - Derek ___ 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 v1] avcodec/libx265: Fix Uninitialized scalar variable
On 09/01/2020 10:52, lance.lmw...@gmail.com wrote: > +default: > +pict_type = AV_PICTURE_TYPE_NONE; Is this ever possible to actually hit in the API, though? Maybe more useful to return an error in such a case, since something is really wrong probably? - Derek ___ 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: compare without the last directory separator in get_relative_url
> 在 2020年1月14日，00:13，Derek Buitenhuis 写道： > > On 10/01/2020 14:51, Steven Liu wrote: >> fix ticket: 8461 >> >> Signed-off-by: Steven Liu >> --- >> libavformat/hlsenc.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > Can you explain the intent? The referenced bug seems specific to Windows? Yes, windows, there no problem since commit 75aea52a1051a22bdebd0b7a8098ac6479a529a0 > > - Derek > ___ > 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 Steven ___ 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] tiffdec: support embedded ICC profiles
On 10/01/2020 22:06, Lynne wrote: > Patch attached. > > Very widespread, every NASA TIFF image has an ICC profile embedded, and its > almost never sRGB, so this is really needed for proper color display. [...] > --- > libavcodec/tiff.c | 13 + > libavcodec/tiff.h | 1 + > 2 files changed, 14 insertions(+) > +case TIFF_ICC_PROFILE: > +if (count >= INT_MAX || count <= 0) > +return AVERROR_INVALIDDATA; Should this be > instead of >=? Otherwise, LGTM. - Derek ___ 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: compare without the last directory separator in get_relative_url
> 在 2020年1月14日，00:29，Steven Liu 写道： > > > >> 在 2020年1月14日，00:13，Derek Buitenhuis 写道： >> >> On 10/01/2020 14:51, Steven Liu wrote: >>> fix ticket: 8461 >>> >>> Signed-off-by: Steven Liu >>> --- >>> libavformat/hlsenc.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> Can you explain the intent? The referenced bug seems specific to Windows? > Yes, windows, there no problem since commit > 75aea52a1051a22bdebd0b7a8098ac6479a529a0 s/since/before/g > >> >> - Derek >> ___ >> 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 > Steven > > > > Thanks Steven ___ 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/6] doc/v4l2_m2m: Add documentation
On Mon, 13. Jan 10:56, Gyan wrote:
>
>
> On 13-01-2020 09:41 am, Andriy Gelman wrote:
> > From: Andriy Gelman
> >
> > Signed-off-by: Andriy Gelman
> > ---
> > doc/decoders.texi | 12
> > doc/encoders.texi | 27 +++
> > 2 files changed, 39 insertions(+)
> >
> > diff --git a/doc/decoders.texi b/doc/decoders.texi
> > index f18226b3504..222f681810b 100644
> > --- a/doc/decoders.texi
> > +++ b/doc/decoders.texi
> > @@ -86,6 +86,18 @@ AVS2-P2/IEEE1857.4 video decoder wrapper.
> > This decoder allows libavcodec to decode AVS2 streams with davs2 library.
> > +@section v4l2m2m
> > +
> > +@command{ffmpeg} supports a set of v4l2m2m wrappers for interfacing with
> > +hardware decoders. Depending on the hardware's capabilties the following
> > decoders may be selected:
> > +h264, hevc, mpeg1, mpeg2, mpeg4, h263, vc1, vp8, and vp9.
>
> If these decoders are available through lavc API then replace ffmpeg with
> libavcodec.
Thanks, will update.
> Is there a command for a user to identify which decoder/encoders
> are available?
At the moment this doesn't exist.
But I do have a patch that lists the supported encoders/decoders.
I'll send this in the next version.
>
> Also, s/capabilties/capabilities
>
> > +
> > +To use a specifix decoder append a _v4l2m2m suffix. For example to select
> > h264
> s/specifix/specific
will update both.
>
> > +decoder use:
> > +@example
> > +ffmpeg -codec:v h264_v4l2m2m -i INPUT OUTPUT
> > +@end example
> > +
> > @c man end VIDEO DECODERS
> > @chapter Audio Decoders
> > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > index 61e674cf968..6cb43aedbce 100644
> > --- a/doc/encoders.texi
> > +++ b/doc/encoders.texi
> > @@ -3117,6 +3117,33 @@ required to produce a stream usable with all
> > decoders.
> > @end table
> > +@section v4l2m2m
> > +
> > +@command{ffmpeg} supports a set of v4l2m2m wrappers for interfacing with
> > hardware encoders.
> > +Depending on the hardware's capabilties the following encoders may be
> > selected:
> > +mpeg4, h263, h264, hevc, and vp8.
>
> Same notes as for decoders.
>
> > +
> > +To use a specific encoder append _v4l2m2m suffix. For example to select
> > h264 use:
> > +@example
> > +ffmpeg -i INPUT [-pix_fmt pixfmt] -codec:v h264_v4l2m2m OUTPUT
> > +@end example
> > +In some cases, it may be necessary to insert a pixel format conversion with
> > +@code{-pix_fmt} option. This is required if the pixel format of the input
> > does not
> > +match the format of the encoder. If there is a mismatch, @command{ffmpeg}
> > will
> > +exit and specify the required pixfmt to use.
> > +
> > +The following standard libavcodec options are supported:
> > +@itemize
> > +@item
> > +@option{g} / @option{gop_size}
> > +@item
> > +@option{qpel}
> > +@item
> > +@option{qmin}
> > +@item
> > +@option{qmax}
> > +@end itemize
> > +
>
> I see both the decoder and encoder wrappers have options for nb of capture
> and output buffers. Should document these with description, range and
> default values.
yep, will add this.
Thanks,
--
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: compare without the last directory separator in get_relative_url
On 13/01/2020 16:31, Steven Liu wrote: >>> Can you explain the intent? The referenced bug seems specific to Windows? >> Yes, windows, there no problem since commit >> 75aea52a1051a22bdebd0b7a8098ac6479a529a0 > s/since/before/g OK. If you could add that in the commit message (and what broke), LGTM. - Derek ___ 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/asrc_anoisesrc: add velvet noise
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 2 +-
libavfilter/asrc_anoisesrc.c | 22 +++---
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index e691ec0bb2..ba070d40a8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5985,7 +5985,7 @@ results in noise with an infinite length.
@item color, colour, c
Specify the color of noise. Available noise colors are white, pink, brown,
-blue and violet. Default color is white.
+blue, violet and velvet. Default color is white.
@item seed, s
Specify a value used to seed the PRNG.
diff --git a/libavfilter/asrc_anoisesrc.c b/libavfilter/asrc_anoisesrc.c
index cedadde6c9..ebcc446ae1 100644
--- a/libavfilter/asrc_anoisesrc.c
+++ b/libavfilter/asrc_anoisesrc.c
@@ -36,7 +36,7 @@ typedef struct ANoiseSrcContext {
int64_t pts;
int infinite;
-double (*filter)(double white, double *buf);
+double (*filter)(double white, double *buf, double half_amplitude);
double buf[7];
AVLFG c;
} ANoiseSrcContext;
@@ -47,6 +47,7 @@ enum NoiseMode {
NM_BROWN,
NM_BLUE,
NM_VIOLET,
+NM_VELVET,
NM_NB
};
@@ -68,6 +69,7 @@ static const AVOption anoisesrc_options[] = {
{ "brown",0, 0,
AV_OPT_TYPE_CONST, {.i64 = NM_BROWN}, 0, 0, FLAGS, "color" },
{ "blue", 0, 0,
AV_OPT_TYPE_CONST, {.i64 = NM_BLUE},0, 0, FLAGS, "color" },
{ "violet", 0, 0,
AV_OPT_TYPE_CONST, {.i64 = NM_VIOLET}, 0, 0, FLAGS, "color" },
+{ "velvet", 0, 0,
AV_OPT_TYPE_CONST, {.i64 = NM_VELVET}, 0, 0, FLAGS, "color" },
{ "seed", "set random seed", OFFSET(seed),
AV_OPT_TYPE_INT64, {.i64 = -1},-1, UINT_MAX, FLAGS },
{ "s","set random seed", OFFSET(seed),
AV_OPT_TYPE_INT64, {.i64 = -1},-1, UINT_MAX, FLAGS },
{ "nb_samples", "set the number of samples per requested frame",
OFFSET(nb_samples), AV_OPT_TYPE_INT, {.i64 = 1024}, 1, INT_MAX, FLAGS },
@@ -111,12 +113,12 @@ static av_cold int query_formats(AVFilterContext *ctx)
return ff_set_common_samplerates(ctx, formats);
}
-static double white_filter(double white, double *buf)
+static double white_filter(double white, double *buf, double ha)
{
return white;
}
-static double pink_filter(double white, double *buf)
+static double pink_filter(double white, double *buf, double ha)
{
double pink;
@@ -132,7 +134,7 @@ static double pink_filter(double white, double *buf)
return pink * 0.11;
}
-static double blue_filter(double white, double *buf)
+static double blue_filter(double white, double *buf, double ha)
{
double blue;
@@ -148,7 +150,7 @@ static double blue_filter(double white, double *buf)
return blue * 0.11;
}
-static double brown_filter(double white, double *buf)
+static double brown_filter(double white, double *buf, double ha)
{
double brown;
@@ -157,7 +159,7 @@ static double brown_filter(double white, double *buf)
return brown * 3.5;
}
-static double violet_filter(double white, double *buf)
+static double violet_filter(double white, double *buf, double ha)
{
double violet;
@@ -166,6 +168,11 @@ static double violet_filter(double white, double *buf)
return violet * 3.5;
}
+static double velvet_filter(double white, double *buf, double ha)
+{
+return 2. * ha * ((white > ha) - (white < -ha));
+}
+
static av_cold int config_props(AVFilterLink *outlink)
{
AVFilterContext *ctx = outlink->src;
@@ -185,6 +192,7 @@ static av_cold int config_props(AVFilterLink *outlink)
case NM_BROWN: s->filter = brown_filter; break;
case NM_BLUE: s->filter = blue_filter; break;
case NM_VIOLET: s->filter = violet_filter; break;
+case NM_VELVET: s->filter = velvet_filter; break;
}
return 0;
@@ -213,7 +221,7 @@ static int request_frame(AVFilterLink *outlink)
for (i = 0; i < nb_samples; i++) {
double white;
white = s->amplitude * ((2 * ((double) av_lfg_get(&s->c) /
0x)) - 1);
-dst[i] = s->filter(white, s->buf);
+dst[i] = s->filter(white, s->buf, s->amplitude * 0.5);
}
if (!s->infinite)
--
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] tiffdec: support embedded ICC profiles
Jan 13, 2020, 16:06 by derek.buitenh...@gmail.com:
> On 10/01/2020 22:06, Lynne wrote:
>
>> Patch attached.
>>
>> Very widespread, every NASA TIFF image has an ICC profile embedded, and its
>> almost never sRGB, so this is really needed for proper color display.
>>
>
> [...]
>
>> ---
>> libavcodec/tiff.c | 13 +
>> libavcodec/tiff.h | 1 +
>> 2 files changed, 14 insertions(+)
>>
>> +case TIFF_ICC_PROFILE:
>> +if (count >= INT_MAX || count <= 0)
>> +return AVERROR_INVALIDDATA;
>>
>
> Should this be > instead of >=?
>
Actually the entire condition needs to be gone. count is uint32_t. The length
is already checked below.
Copied this from ff_tadd_shorts_metadata which has an int count.
And the offset value isn't taken into account. TIFF allows the ICC profile to
be placed pretty much anywhere within the file (the 32 bit offset points from
the start of the file, not the field). So this would only work with files where
the ICC profile immediately follows the tag.
Attached a new patch.
>From b1c9e7a6a72b35707ba234df046b7c55f02bb12f Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 10 Jan 2020 21:55:19 +
Subject: [PATCH] tiffdec: support embedded ICC profiles
---
libavcodec/tiff.c | 18 ++
libavcodec/tiff.h | 1 +
2 files changed, 19 insertions(+)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 636614aa28..e8357114de 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -1218,6 +1218,8 @@ static void set_sar(TiffContext *s, unsigned tag, unsigned num, unsigned den)
static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
{
+AVFrameSideData *sd;
+GetByteContext gb_temp;
unsigned tag, type, count, off, value = 0, value2 = 1; // value2 is a denominator so init. to 1
int i, start;
int pos;
@@ -1643,6 +1645,22 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
}
}
break;
+case TIFF_ICC_PROFILE:
+if (type != TIFF_UNDEFINED)
+return AVERROR_INVALIDDATA;
+
+gb_temp = s->gb;
+bytestream2_seek(&gb_temp, SEEK_SET, off);
+
+if (bytestream2_get_bytes_left(&gb_temp) < count)
+return AVERROR_INVALIDDATA;
+
+sd = av_frame_new_side_data(frame, AV_FRAME_DATA_ICC_PROFILE, count);
+if (!sd)
+return AVERROR(ENOMEM);
+
+bytestream2_get_bufferu(&gb_temp, sd->data, count);
+break;
case TIFF_ARTIST:
ADD_METADATA(count, "artist", NULL);
break;
diff --git a/libavcodec/tiff.h b/libavcodec/tiff.h
index 2184c2c829..c07a5d4fa9 100644
--- a/libavcodec/tiff.h
+++ b/libavcodec/tiff.h
@@ -92,6 +92,7 @@ enum TiffTags {
TIFF_MODEL_TIEPOINT = 0x8482,
TIFF_MODEL_PIXEL_SCALE = 0x830E,
TIFF_MODEL_TRANSFORMATION= 0x8480,
+TIFF_ICC_PROFILE= 0x8773,
TIFF_GEO_KEY_DIRECTORY = 0x87AF,
TIFF_GEO_DOUBLE_PARAMS = 0x87B0,
TIFF_GEO_ASCII_PARAMS = 0x87B1,
--
2.25.0.rc2
___
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] libavformat/mpegtsenc: splice count [WIP]
This patch is Work-In-Progess, and I need your help...
The objective of this patch is to insert the Splicing Point Count data inside
the MPEG-TS header. The current code does it for every video packet. But this
is buggy as we need to insert this data at GOP boundaries. Then the code is
prepared to use the vars 'is_start_gop' and 'is_end_gop'. But we need to
complete it with two functions that get these data from the pkt of from the
bitstream.
Please, can you help me to complete it?
Thank you!
--
A.H.From 54cfa26b83110bbd71d41fb9729828291dbfc873 Mon Sep 17 00:00:00 2001
From: Andreas Hakon
Date: Mon, 13 Jun 2020 19:11:00 +0100
Subject: [PATCH] libavformat/mpegtsenc: splice count [WIP]
This patch is Work-In-Progess, and I need your help...
The objective of this patch is to insert the Splicing Point Count data inside
the MPEG-TS header. The current code does it for every video packet. But this
is buggy as we need to insert this data at GOP boundaries. Then the code is
prepared to use the vars 'is_start_gop' and 'is_end_gop'. But we need to
complete it with two functions that get these data from the pkt of from the
bitstream.
Please, can you help me to complete it?
Thank you!
Signed-off-by: Andreas Hakon
---
libavformat/mpegtsenc.c | 23 +++
1 file changed, 23 insertions(+), 0 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index ccb631d746..00647a6750 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1162,6 +1162,7 @@ static void mpegts_write_pes(AVFormatContext *s, AVStream
*st,
uint8_t buf[TS_PACKET_SIZE];
uint8_t *q;
int val, is_start, len, header_len, write_pcr, is_dvb_subtitle,
is_dvb_teletext, flags;
+int splice, is_start_gop, is_end_gop;
int afc_len, stuffing_len;
int64_t delay = av_rescale(s->max_delay, 9, AV_TIME_BASE);
int force_pat = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO && key &&
!ts_st->prev_payload_key;
@@ -1266,6 +1267,28 @@ static void mpegts_write_pes(AVFormatContext *s,
AVStream *st,
extend_af(buf, write_pcr_bits(q, pcr));
q = get_ts_payload_start(buf);
}
+/* Set the Splicing Point Count */
+/* http://www.mpeg.org/MPEG/splicing-FAQ.html */
+if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
+is_start_gop = 1; // TODO: Get if this is the first PES packet of
a GOP
+is_end_gop = 1; // TODO: Get if this is the last PES packet of
the GOP
+
+if (is_start && is_start_gop)
+splice = -1;
+else if (is_end_gop && payload_size < TS_PACKET_SIZE * 127)
+splice = payload_size / TS_PACKET_SIZE;
+else
+splice = 127;
+
+if (splice <= 5) {
+av_log(s, AV_LOG_TRACE, "Splicing Point Count to %i\n",
splice);
+set_af_flag(buf, 0x04);
+q = get_ts_payload_start(buf);
+extend_af(buf, 1);
+*q++ = splice;
+q = get_ts_payload_start(buf);
+}
+}
if (is_start) {
int pes_extension = 0;
int pes_header_stuffing_bytes = 0;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v6 0/5] Fix mpeg1/2 stream copy
This patch was initially composed of 7 patchs, the two first have been applied. There was no feedback on these remaining 5 patchs for long, but I just have catched in the patchwork that Michael asked me to repost the whole set to facilitate the review... So here it is! Thank you in advance for the review. For the record, the target use case is to fix things like this: ffmpeg -i xdcamhd.mxf -c:v copy output.mpg (And note that as a side effect, ffmpeg now reports the cpb and signaled bitrate of mpeg2 video inputs) Nicolas Nicolas Gaullier (5): avformat: Add av_stream_add_coded_side_data() avformat/utils: Make find_stream_info get side data from codec context fftools/ffmpeg: Use the new av_stream_add_coded_side_data() avcodec/utils: Fix ff_add_cpb_side_data() add twice avcodec/mpeg12dec: Add CPB coded side data doc/APIchanges | 3 +++ fftools/ffmpeg.c | 16 +++- libavcodec/mpeg12dec.c | 7 +++ libavcodec/utils.c | 5 + libavformat/avformat.h | 11 +++ libavformat/utils.c | 18 ++ libavformat/version.h| 4 ++-- tests/ref/fate/mxf-probe-d10 | 3 +++ tests/ref/fate/ts-demux | 2 +- 9 files changed, 53 insertions(+), 16 deletions(-) -- 2.14.1.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v6 2/5] avformat/utils: Make find_stream_info get side data from codec context
This will allow probing input coded side data, and also forwarding them to the
output.
---
libavformat/utils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 3270d971c6..ddc36cce1c 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4135,6 +4135,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
ret = avcodec_parameters_from_context(st->codecpar,
st->internal->avctx);
if (ret < 0)
goto find_stream_info_err;
+ret = av_stream_add_coded_side_data(st, st->internal->avctx);
+if (ret < 0)
+goto find_stream_info_err;
#if FF_API_LOWRES
// The decoder might reduce the video size by the lowres factor.
if (st->internal->avctx->lowres && orig_w) {
--
2.14.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v6 1/5] avformat: Add av_stream_add_coded_side_data()
This will allow avformat_find_stream_info() get side data from the codec
context.
---
doc/APIchanges | 3 +++
libavformat/avformat.h | 11 +++
libavformat/utils.c| 15 +++
libavformat/version.h | 4 ++--
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 3c24dc6fbc..b3656f2671 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2020-01-13 - xx - lavf 58.36.100 - avformat.h
+ Add av_stream_add_coded_side_data().
+
2019-12-27 - xx - lavu 56.38.100 - eval.h
Add av_expr_count_func().
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index d4d9a3b06e..4dee1a272a 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2191,6 +2191,17 @@ int av_stream_add_side_data(AVStream *st, enum
AVPacketSideDataType type,
*/
uint8_t *av_stream_new_side_data(AVStream *stream,
enum AVPacketSideDataType type, int size);
+
+/**
+ * Add stream side_data from the coded_side_data of the supplied context.
+ *
+ * @param stream stream
+ * @param avctx the codec context that may contain coded_side_data
+ * @return >= 0 in case of success, a negative AVERROR code in case of
+ * failure
+ */
+int av_stream_add_coded_side_data(AVStream *stream, AVCodecContext *avctx);
+
/**
* Get side information from stream.
*
diff --git a/libavformat/utils.c b/libavformat/utils.c
index f3d71642c3..3270d971c6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5554,6 +5554,21 @@ uint8_t *av_stream_new_side_data(AVStream *st, enum
AVPacketSideDataType type,
return data;
}
+int av_stream_add_coded_side_data(AVStream *st, AVCodecContext *avctx)
+{
+int i;
+
+for (i = 0; i < avctx->nb_coded_side_data; i++) {
+const AVPacketSideData *sd_src = &avctx->coded_side_data[i];
+uint8_t *dst_data;
+dst_data = av_stream_new_side_data(st, sd_src->type, sd_src->size);
+if (!dst_data)
+return AVERROR(ENOMEM);
+memcpy(dst_data, sd_src->data, sd_src->size);
+}
+return 0;
+}
+
int ff_stream_add_bitstream_filter(AVStream *st, const char *name, const char
*args)
{
int ret;
diff --git a/libavformat/version.h b/libavformat/version.h
index 43f3811df1..f72fb9478a 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,8 +32,8 @@
// Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
// Also please add any ticket numbers that you believe might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 58
-#define LIBAVFORMAT_VERSION_MINOR 35
-#define LIBAVFORMAT_VERSION_MICRO 102
+#define LIBAVFORMAT_VERSION_MINOR 36
+#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
--
2.14.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v6 3/5] fftools/ffmpeg: Use the new av_stream_add_coded_side_data()
This code is now shared with avformat_find_stream_info().
---
fftools/ffmpeg.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6bcd7b94d2..a513e9f3cc 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3534,19 +3534,9 @@ static int init_output_stream(OutputStream *ost, char
*error, int error_len)
if (ret < 0)
return ret;
-if (ost->enc_ctx->nb_coded_side_data) {
-int i;
-
-for (i = 0; i < ost->enc_ctx->nb_coded_side_data; i++) {
-const AVPacketSideData *sd_src =
&ost->enc_ctx->coded_side_data[i];
-uint8_t *dst_data;
-
-dst_data = av_stream_new_side_data(ost->st, sd_src->type,
sd_src->size);
-if (!dst_data)
-return AVERROR(ENOMEM);
-memcpy(dst_data, sd_src->data, sd_src->size);
-}
-}
+ret = av_stream_add_coded_side_data(ost->st, ost->enc_ctx);
+if (ret < 0)
+return ret;
/*
* Add global input side data. For now this is naive, and copies it
--
2.14.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v6 4/5] avcodec/utils: Fix ff_add_cpb_side_data() add twice
Makes it behave similarly to av_stream_add_side_data(). --- libavcodec/utils.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavcodec/utils.c b/libavcodec/utils.c index ab48754a64..d9af6053bb 100644 --- a/libavcodec/utils.c +++ b/libavcodec/utils.c @@ -1978,6 +1978,11 @@ AVCPBProperties *ff_add_cpb_side_data(AVCodecContext *avctx) AVPacketSideData *tmp; AVCPBProperties *props; size_t size; +int i; + +for (i = 0; i < avctx->nb_coded_side_data; i++) +if (avctx->coded_side_data[i].type == AV_PKT_DATA_CPB_PROPERTIES) +return (AVCPBProperties *)avctx->coded_side_data[i].data; props = av_cpb_properties_alloc(&size); if (!props) -- 2.14.1.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v6 5/5] avcodec/mpeg12dec: Add CPB coded side data
This fixes mpeg2video stream copies to mpeg muxer like this:
ffmpeg -i xdcamhd.mxf -c:v copy output.mpg
---
libavcodec/mpeg12dec.c | 7 +++
tests/ref/fate/mxf-probe-d10 | 3 +++
tests/ref/fate/ts-demux | 2 +-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 17f9495a1d..48ac14fafa 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1398,6 +1398,7 @@ static void mpeg_decode_sequence_extension(Mpeg1Context
*s1)
MpegEncContext *s = &s1->mpeg_enc_ctx;
int horiz_size_ext, vert_size_ext;
int bit_rate_ext;
+AVCPBProperties *cpb_props;
skip_bits(&s->gb, 1); /* profile and level esc*/
s->avctx->profile = get_bits(&s->gb, 3);
@@ -1429,6 +1430,12 @@ static void mpeg_decode_sequence_extension(Mpeg1Context
*s1)
ff_dlog(s->avctx, "sequence extension\n");
s->codec_id = s->avctx->codec_id = AV_CODEC_ID_MPEG2VIDEO;
+if (cpb_props = ff_add_cpb_side_data(s->avctx)) {
+cpb_props->buffer_size = FFMAX(cpb_props->buffer_size,
s->avctx->rc_buffer_size);
+if (s->bit_rate != 0x3*400)
+cpb_props->max_bitrate = FFMAX(cpb_props->max_bitrate,
s->bit_rate);
+}
+
if (s->avctx->debug & FF_DEBUG_PICT_INFO)
av_log(s->avctx, AV_LOG_DEBUG,
"profile: %d, level: %d ps: %d cf:%d vbv buffer: %d,
bitrate:%"PRId64"\n",
diff --git a/tests/ref/fate/mxf-probe-d10 b/tests/ref/fate/mxf-probe-d10
index ab564467b5..317d4ae4c5 100644
--- a/tests/ref/fate/mxf-probe-d10
+++ b/tests/ref/fate/mxf-probe-d10
@@ -50,6 +50,9 @@ DISPOSITION:clean_effects=0
DISPOSITION:attached_pic=0
DISPOSITION:timed_thumbnails=0
TAG:file_package_umid=0x060A2B340101010501010D131300AE86B20091310580080046A54011
+[SIDE_DATA]
+side_data_type=CPB properties
+[/SIDE_DATA]
[/STREAM]
[STREAM]
index=1
diff --git a/tests/ref/fate/ts-demux b/tests/ref/fate/ts-demux
index eb13ecc684..cdf34d6af0 100644
--- a/tests/ref/fate/ts-demux
+++ b/tests/ref/fate/ts-demux
@@ -15,7 +15,7 @@
1, 5760, 5760, 2880, 1536, 0xbab5129c
1, 8640, 8640, 2880, 1536, 0x602f034b, S=1,1,
0x00bd00bd
1, 11520, 11520, 2880, 906, 0x69cdcbcd
-0, 32037, 36541, 1501, 114336, 0x37a215a8, S=1,1,
0x00e000e0
+0, 32037, 36541, 1501, 114336, 0x37a215a8, S=2,1,
0x00e000e0, 24, 0x663d0b52
0, 33538, 33538, 1501,12560, 0xb559a3d4, F=0x0, S=1,
1, 0x00e000e0
0, 35040, 35040, 1501,12704, 0x2614adf4, F=0x0, S=1,
1, 0x00e000e0
0, 36541, 41046, 1501,51976, 0x9ff1dbfe, F=0x0, S=1,
1, 0x00e000e0
--
2.14.1.windows.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 v6 1/5] avformat: Add av_stream_add_coded_side_data()
Quoting Nicolas Gaullier (2020-01-13 19:54:55) > This will allow avformat_find_stream_info() get side data from the codec > context. If the intention is to use this code from avformat_find_stream_info(), then why should it be public? The documentation is very unclear as to when/how an API user is supposed to call it. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] tiffdec: support embedded ICC profiles
On 13/01/2020 17:50, Lynne wrote: > Actually the entire condition needs to be gone. count is uint32_t. The length > is already checked below. > Copied this from ff_tadd_shorts_metadata which has an int count. Ah. > And the offset value isn't taken into account. TIFF allows the ICC profile to > be placed pretty much anywhere within the file (the 32 bit offset points from > the start of the file, not the field). So this would only work with files > where the ICC profile immediately follows the tag. Oh, that's a bit wild. I did a quick Google search for the ICC profile tag spec, and it wasn't obvious to me where it is defined, so I assumed it was directly after the tag. > Attached a new patch. > +gb_temp = s->gb; > +bytestream2_seek(&gb_temp, SEEK_SET, off); > + > +if (bytestream2_get_bytes_left(&gb_temp) < count) > +return AVERROR_INVALIDDATA; Is it worth checking the bytestream2_seek return value too, or will that be handled by bytestream2_get_bytes_left anyway? If it is handled, patch seems OK. - Derek ___ 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/9] avformat/s337m: Consider container bit resolution
mån 2020-01-13 klockan 14:02 + skrev Gaullier Nicolas:
> > > +if (container_word_bits && (container_word_bits+7)/8 !=
> > > + (word_bits+7)/8) {
> >
> > Can it happen that word_bits is anything but 16 or 24 with a valid
> > stream? If not then I'd check container_word_bits == word_bits &&
> > (word_bits == 16 || word_bits == 24) or so
> word_bits may be 20, and in that case container_word_bits must be 24
> (this is the case in my fate test), so I think this is correct.
I think explicit checks for these three cases would be better instead
of rounding up. I wouldn't be surprised if there are files out there
that claim to be 18-bit or whatever..
> > > +while ((container_word_bits == 24 || !IS_16LE_MARKER(state))
> > > +&& (container_word_bits == 16 || !IS_20LE_MARKER(state)
> > > &&
> > > + !IS_24LE_MARKER(state))) {
> >
> > I'd rewrite this as while ((bits == 24 && (20LE || 24LE)) || (bits
> > ==20 && 16LE)), more readable
> container_word_bits may be 0 for autodetect, this results in this
> expression...
> I agree it is not that great for readability, but doing otherwise
> would require some additions and macros duplications, for example:
> while ( !(!bits && LE) || !(bits == 24 && (20LE || 24LE)) || !(bits
> ==16 && 16LE))
> Sounds heavy, not sure this is really better ?
Hrm, not sure tbh
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 9/9] avformat/wavdec: Test s337m
mån 2020-01-13 klockan 16:10 + skrev Gaullier Nicolas: > > > > > > +FATE_SAMPLES_AUDIO-$(call DEMDEMDEC, WAV, S337M, DOLBY_E) += > > > +fate-dolby-e-wav > > > +fate-dolby-e-wav: CMD = dolbye2pcm16 -i > > > +$(TARGET_SAMPLES)/dolby_e/512.wav > > > +fate-dolby-e-wav: CMP = oneoff > > > +fate-dolby-e-wav: REF = $(SAMPLES)/dolby_e/512.wav.pcm > > > + > > > FATE_SAMPLES_AUDIO-$(call DEMDEC, DSS, DSS_SP) += fate-dss-lp > > > fate-dss-sp > > > fate-dss-lp: CMD = framecrc -i $(TARGET_SAMPLES)/dss/lp.dss -frames > > > 30 > > > fate-dss-sp: CMD = framecrc -i $(TARGET_SAMPLES)/dss/sp.dss -frames > > > 30 > > > > > This is missing some kind of hash check on the demuxed data > > The "oneoff" tests consists in checking the maximum difference between the > raw pcm output samples, it must be 0 or 1 max. This test is done in 16-bit > truncated output of the decoded stream. > It raises an error too if the duration does not strictly match. I found it > appropriate (a strict hash on decoded samples may also break with the many > floats of the DolbyE decoder). > My idea was to keep a single test for both "wav demux" and "5.1+2" decode. > Do you think there should be an additional test focused on demuxed data ? I don't mean has the decoded data, but rather hash the demuxed packets before they're decoded. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/5] Fix mpeg1/2 stream copy
Am Mo., 13. Jan. 2020 um 19:55 Uhr schrieb Nicolas Gaullier : > > This patch was initially composed of 7 patchs, the two first have been > applied. > There was no feedback on these remaining 5 patchs for long, but I just have > catched in > the patchwork that Michael asked me to repost the whole set to facilitate the > review... Apart from what Anton wrote, it appears to me that not all patches in the series are necessary to fix the stream-copying. 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 4/9] avformat/s337m: New ff_s337m_probe()
Am Fr., 3. Jan. 2020 um 16:57 Uhr schrieb Nicolas Gaullier
:
>
> Similar to ff_spdif_probe() with two additionnal parameters:
> - an AVClass for logging
> - the bit resolution of the container as it may be 16 or 24 for s337m
> ---
> libavformat/s337m.c | 35 +++
> libavformat/s337m.h | 19 +++
> 2 files changed, 54 insertions(+)
>
> diff --git a/libavformat/s337m.c b/libavformat/s337m.c
> index 5c8ab2649c..dc62d6ab98 100644
> --- a/libavformat/s337m.c
> +++ b/libavformat/s337m.c
> @@ -133,6 +133,41 @@ static int s337m_probe(const AVProbeData *p)
> return 0;
> }
>
> +int ff_s337m_probe(const uint8_t *buf, int size, enum AVCodecID *codec, void
> *avc, int container_word_bits)
> +{
> +int pos = 0;
> +int consecutive_codes = 0;
> +
> +if ( size < S337M_MIN_OFFSET)
> +return 0;
> +size = FFMIN(2 * S337M_MAX_OFFSET, size);
> +
> +do {
> +uint64_t state;
> +int data_type, data_size, offset;
> +while (pos < size - 12 && !buf[pos]) {
> +pos++;
> +}
> +if (pos >= size - 12 || pos < S337M_PROBE_GUARDBAND_MIN_BYTES)
> +return 0;
> +state = container_word_bits == 16 ? AV_RB32(buf + pos) : AV_RB48(buf
> + pos);
> +if (!IS_LE_MARKER(state))
> +return 0;
> +data_type = container_word_bits == 16 ? AV_RL16(buf + pos + 4) :
> AV_RL24(buf + pos + 6);
> +data_size = container_word_bits == 16 ? AV_RL16(buf + pos + 6) :
> AV_RL24(buf + pos + 9);
> +if (s337m_get_offset_and_codec(avc, state, data_type, data_size,
> container_word_bits, &offset, codec))
> +return 0;
> +if (avc) {
> +double s337m_phase = pos * 4. / container_word_bits / 48000;
> +av_log(avc, AV_LOG_INFO, "s337m sample %d detected with phase =
> %.6fs\n", consecutive_codes, s337m_phase);
> +if (*codec == AV_CODEC_ID_DOLBY_E && (s337m_phase <
> DOLBY_E_PHASE_MIN || s337m_phase > DOLBY_E_PHASE_MAX))
> +av_log(avc, AV_LOG_WARNING, "Dolby E phase is out of
> valid range (%.6fs-%.6fs)\n", DOLBY_E_PHASE_MIN, DOLBY_E_PHASE_MAX);
> +}
> +} while (++consecutive_codes < 2);
> +
> +return AVPROBE_SCORE_MAX;
> +}
Probe functions must never av_log() anything.
Since you add an option in a later patch: Can you explain the
reasoning for the whole patchset better?
If DolbyE can be auto-detected (I assume so), this should be
done and no further option should be needed.
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 0/9] avformat: Use s337m subdemux inside wav
Am Fr., 3. Jan. 2020 um 16:56 Uhr schrieb Nicolas Gaullier : > > This is a new version of my previous patchset reviewed by Tomas. > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247677.html > > It takes into account the last feedback from Carl Eugen, > I mean that the integration of s337m in wav is now similar to the existing > one for spdif, > main differences remains that : > - s337m is not enabled by default (activated by the 'dolbyeprobe' AVOption) This option should be avoided if possible at all. 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 6/9] avformat/wavdec: fix s337m/spdif probing beyond data_end
Am Mo., 13. Jan. 2020 um 15:53 Uhr schrieb Gaullier Nicolas
:
>
> >> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
> >> 2796905e1f..ccb9576b84 100644
> >> --- a/libavformat/wavdec.c
> >> +++ b/libavformat/wavdec.c
> >> @@ -78,7 +78,7 @@ static void set_spdif_s337m(AVFormatContext *s,
> >> WAVDemuxContext *wav)
> >> ret = AVERROR(ENOMEM);
> >> } else {
> >> int64_t pos = avio_tell(s->pb);
> >> -len = ret = avio_read(s->pb, buf, len);
> >> +len = ret = avio_read(s->pb, buf, FFMIN(len,
> >> + wav->data_end - pos));
> >> if (len >= 0) {
> >> ret = ff_spdif_probe(buf, len, &codec);
> >> if (ret > AVPROBE_SCORE_EXTENSION) {
> >
> >Looks OK. I suppose this fixes a potential SIGSEGV too?
> AVIO would just stop at EOF, I don't think a SIGSEGV could occur in any
> scenario.
> This fix only affects probing (ie. reading start of file) in a surprising
> scenario where the data chunk would not extend to the end of the file.
> This is many IF and I find it unlikely, but I think it should be fixed anyway.
Could you elaborate?
I believe the code is fine as-is but maybe I miss something...
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] tiffdec: support embedded ICC profiles
Jan 13, 2020, 20:20 by derek.buitenh...@gmail.com: > On 13/01/2020 17:50, Lynne wrote: > >> Actually the entire condition needs to be gone. count is uint32_t. The >> length is already checked below. >> Copied this from ff_tadd_shorts_metadata which has an int count. >> > > Ah. > >> And the offset value isn't taken into account. TIFF allows the ICC profile >> to be placed pretty much anywhere within the file (the 32 bit offset points >> from the start of the file, not the field). So this would only work with >> files where the ICC profile immediately follows the tag. >> > > Oh, that's a bit wild. I did a quick Google search for the ICC profile tag > spec, and it wasn't obvious to me where it is defined, so I assumed it was > directly after the tag. > Yeah, I thought it was after the tag too with the offset being used to align to the nearest 16bits or maybe for some padding. But for the sample I have the position of the offset and the current byte in the bytestream reader match, and the ICC spec (which defines TIFF encapsulation) says the start of the file, so I can't argue with that. >> Attached a new patch. >> +gb_temp = s->gb; >> +bytestream2_seek(&gb_temp, SEEK_SET, off); >> + >> +if (bytestream2_get_bytes_left(&gb_temp) < count) >> +return AVERROR_INVALIDDATA; >> > > Is it worth checking the bytestream2_seek return value too, or will that > be handled by bytestream2_get_bytes_left anyway? If it is handled, patch > seems OK. > bytestream2_seek returns the amount of bytes since the start of the buffer after seeking. It clips to the size of the buffer so you can't seek past the end. ___ 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] tiffdec: support embedded ICC profiles
On 13/01/2020 22:05, Lynne wrote: > bytestream2_seek returns the amount of bytes since the start of the buffer > after seeking. It clips to the size of the buffer so you can't seek past the > end. LGTM then. - Derek ___ 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 v6 1/5] avformat: Add av_stream_add_coded_side_data()
>If the intention is to use this code from avformat_find_stream_info(), >then why should it be public? The documentation is very unclear as to >when/how an API user is supposed to call it. > >Anton Khirnov Sorry about that, I should have explained this in the cover letter, or maybe even in the commit msg. The reason is that this code already exists in ffmpeg.c (executed in case of non-codec copy if I remember correctly) and now I need it to be shared and used in avformat_find_stream_info also (for probing in general, and for codec copy in particular) to avoid code duplication. The fact is that initially, I had regrouped all this refactoring in a single commit, thus resulting in a clear full picture but it was not correct to mix libav and fftools changes, so I split the commit but an explanation was lacking, I missed that, sorry. I propose to describe this in the commit msg, this should be enough as the code/usage itself already exists in ffmpeg.c so maybe it is not necessary to add public documentation. Nicolas ___ 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 v6 0/5] Fix mpeg1/2 stream copy
>Apart from what Anton wrote, it appears to me that not all patches in the >series are necessary to fix the stream-copying. > >Carl Eugen Precisely: - 1/2/3 are working together : actual code from ffmpeg.c that is used for stream encoding is now used for probing in libav, so it is "moved to public" and shared. But strictly speaking, 3 is not required to fix the stream-copying, it is only a "code simplification" = use the newly created public method. - 4 is a bug fix that is necessary to apply before 5 to avoid generating duplicate side data (this does not prevent stream copy from working, but of course this is very bad), but maybe I should have indicated this in the commit msg - 5 just add the coded side data that find_stream_info will forward to stream side data that ffmpeg will forward to output mux in case of stream copy. Sorry, I have little experience in contributing to open projects and I think I tend to not document enough in the commit msgs Nicolas ___ 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 4/9] avformat/s337m: New ff_s337m_probe()
>Since you add an option in a later patch: Can you explain the >reasoning for the whole patchset better? >If DolbyE can be auto-detected (I assume so), this should be >done and no further option should be needed. > >Carl Eugen A common use case is stream copying : you want to be able to forward the input dolbyE to the output. But the mxf mux, for example, does not support dolby_e (up to now). In the future, if we come to support muxing dolby_e in s337m, then yes, that would be nice, we would be able to remux a dolby_e and fix its position/guard band, that would be a very interesting repairing workflow, but that would require much hard work (DolbyE recommanded position is dependant on video raster etc.). Second thing is that, even if we were able to support stream copying, the fact is that users have tons of script like this : ffmpeg -i input.mxf -vcodec copy output.mxf I mean broadcasters are often missing the "audio codec copy" parameter because they think "my audio is uncompressed 16 bits, stream copying is bitexact the same as transcoding". I am afraid I have myself many scripts like this... So, it is necessary to default to not-probe/decode dolby_e to not break scripts. And most of the time, the fact is that users just want to pass trough the data as they indeed need to be agnostic. This was the reason to choose to 1) add an AVOption, and 2) makes it default to disabled Nicolas ___ 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/1] avdevice/gdigrab add use_captureblt option
Am Mo., 13. Jan. 2020 um 17:10 Uhr schrieb Derek Buitenhuis : > > On 11/01/2020 09:18, fgodt...@hotmail.com wrote: > > From: FgoDt > > > > Add use_captureblt option for disable or use CAPTUREBLT flag, when useing > > the bitblt function with CAPTUREBLT may caused the Windows mouse cursor > > flicker. most time we don't need this flag to capture window > > I tested on Windows 10 works fine > > > > Signed-off-by: fgodt > > --- > > doc/indevs.texi | 7 +++ > > libavdevice/gdigrab.c | 10 +- > > 2 files changed, 16 insertions(+), 1 deletion(-) > > Does it make sense to name this something like 'capature_layered_windows'? > > Using the name of the flag is a bit unintuitive from a user perspective. Not sure if "capture_layered_windows" is more intuitive than using the name of an os flag but ... > Same for the description. Shouldn't the description explain that this option helps against mouse cursor flicker? 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] ffplay is not working on ARM processor
Am Mo., 13. Jan. 2020 um 17:07 Uhr schrieb Moritz Barsnick : > > On Mon, Jan 13, 2020 at 12:08:28 +0530, Parameshwaran Thangaraj wrote: > > I would like to cross compile ffmpeg and ffplay for linux embedded with ARM > > processor. > > Other parameters: > > *Toradex Apalis iMX6* > > *RAM 1GB* > > > > ffmpeg is working fine. But ffplay is not working. Shows following error, > > This mailing list is for the discussion of the development of ffmpeg > and its tools. You are encountering a crash which may be considered a > serious bug, so kindly report it on the bug tracker: Or even better on the user mailing list: https://ffmpeg.org/contact.html#MailingLists 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] tiffdec: support embedded ICC profiles
Jan 13, 2020, 22:07 by derek.buitenh...@gmail.com: > On 13/01/2020 22:05, Lynne wrote: > >> bytestream2_seek returns the amount of bytes since the start of the buffer >> after seeking. It clips to the size of the buffer so you can't seek past the >> end. >> > > LGTM then. > Pushed, 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] Vulkan hwcontext and filters
On Fri, 10 Jan 2020 22:05:21 +0100 (CET) Lynne wrote: > Patches attached > Also pushed to https://github.com/cyanreg/FFmpeg/ master branch > because they're 9 and they add about 7000 lines. Filtering won't work > without a recent glslang version since they moved a header and broke > API because they felt like it. I'm obviously biased because I made some contributions to this effort, but I think it is valuable functionality and gets us into a good position to support GPU accelerated filters in a cross-vendor, cross-platform fashion, as well as getting us into the right place to handle the Vulkan video decode/encode API stuff that's coming down the pipe. --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 v4 1/2] avcodec/libvpxenc: add VP9 temporal scalability encoding option
Hi,
On Fri, Jan 10, 2020 at 9:59 AM Wonkap Jang
wrote:
>
> This commit reuses the configuration options for VP8 that enables
> temporal scalability for VP9. It also adds a way to enable three
> preset temporal structures (refer to the documentation for more
> detail) that can be used in offline encoding.
> ---
> doc/encoders.texi | 18 ++-
> libavcodec/libvpxenc.c | 251 +
> 2 files changed, 243 insertions(+), 26 deletions(-)
>
> [...]
> #endif
> @@ -223,8 +231,16 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
> " %*s%u\n", width, "ts_number_layers:", cfg->ts_number_layers);
> av_log(avctx, level,
> "\n %*s", width, "ts_target_bitrate:");
This should move to the vp8 branch and a new heading added for vp9's
layer_target_bitrate.
> [...]
> -static int vp8_ts_param_parse(struct vpx_codec_enc_cfg *enccfg, char *key,
> char *value)
> +static void set_temporal_layer_pattern(int layering_mode,
> + vpx_codec_enc_cfg_t *cfg,
> + int *layer_flags,
> + int *flag_periodicity)
> +{
> +switch (layering_mode) {
> +case 2: {
> +/**
> + * 2-layers, 2-frame period.
> + */
> +int ids[2] = { 0, 1 };
these can be static const.
> +cfg->ts_periodicity = 2;
> +*flag_periodicity = 2;
> +cfg->ts_number_layers = 2;
> +cfg->ts_rate_decimator[0] = 2;
> +cfg->ts_rate_decimator[1] = 1;
> +memcpy(cfg->ts_layer_id, ids, sizeof(ids));
> +
> +layer_flags[0] =
> + VP8_EFLAG_NO_REF_GF | VP8_EFLAG_NO_REF_ARF |
> + VP8_EFLAG_NO_UPD_GF | VP8_EFLAG_NO_UPD_ARF;
> +
this line can be removed.
> +layer_flags[1] =
> +VP8_EFLAG_NO_UPD_ARF | VP8_EFLAG_NO_UPD_GF |
> +VP8_EFLAG_NO_UPD_LAST |
> +VP8_EFLAG_NO_REF_ARF | VP8_EFLAG_NO_REF_GF;
> +break;
> +}
> +case 3: {
> +/**
> + * 3-layers structure with one reference frame.
> + * This works same as temporal_layering_mode 3.
> + *
> + * 3-layers, 4-frame period.
> + */
> +int ids[4] = { 0, 2, 1, 2 };
> +cfg->ts_periodicity = 4;
> +*flag_periodicity = 4;
> +cfg->ts_number_layers = 3;
> +cfg->ts_rate_decimator[0] = 4;
> +cfg->ts_rate_decimator[1] = 2;
> +cfg->ts_rate_decimator[2] = 1;
> +memcpy(cfg->ts_layer_id, ids, sizeof(ids));
> +
> +/**
> + * 0=L, 1=GF, 2=ARF,
what about [3]?
> + * Intra-layer prediction disabled.
> + */
> +layer_flags[0] =
> +VP8_EFLAG_NO_REF_GF | VP8_EFLAG_NO_REF_ARF |
> +VP8_EFLAG_NO_UPD_GF | VP8_EFLAG_NO_UPD_ARF;
> +layer_flags[2] =
can you reorder this to be in the natural 0...3 order?
> [...]
> +/**
> + * 0=L, 1=GF, 2=ARF, Intra-layer prediction disabled.
> + */
> +layer_flags[0] =
> +VP8_EFLAG_NO_REF_GF | VP8_EFLAG_NO_REF_ARF |
> +VP8_EFLAG_NO_UPD_GF | VP8_EFLAG_NO_UPD_ARF;
> +layer_flags[2] =
same comment here about order.
> [...]
> +
> +#if (VPX_ENCODER_ABI_VERSION >= 12) && CONFIG_LIBVPX_VP9_ENCODER
> +enccfg->temporal_layering_mode = 1; // only bypass mode is being
> supported for now.
...mode is supported...
> +enccfg->ss_number_layers = 1; // making sure the spatial scalability is
> off. Will support this in future.
this can be TODO: add spatial scalability support.
> +#endif
> +if (ts_layering_mode) {
> + // make sure the ts_layering_mode comes at the end of the ts_parameter
> string to ensure that
> + // correct configuration is done.
> + ctx->ts_layer_flags = av_malloc(sizeof(int) * VPX_TS_MAX_PERIODICITY);
prefer sizeof(var).
> [...]
>
> -if(!avctx->bit_rate)
> -if(avctx->rc_max_rate || avctx->rc_buffer_size ||
> avctx->rc_initial_buffer_occupancy) {
> +if (!avctx->bit_rate)
> +if (avctx->rc_max_rate || avctx->rc_buffer_size ||
> avctx->rc_initial_buffer_occupancy) {
this is unrelated to the change, please remove it.
> [...]
> +#if VPX_ENCODER_ABI_VERSION >= 12
> +codecctl_int(avctx, VP9E_SET_SVC, 1);
> +codecctl_intp(avctx, VP9E_SET_SVC_PARAMETERS, (int *) &svc_params);
drop the space after the cast.
> [...]
> +#if CONFIG_LIBVPX_VP9_ENCODER && VPX_ENCODER_ABI_VERSION >= 12
> +else if (avctx->codec_id == AV_CODEC_ID_VP9) {
> +codecctl_intp(avctx, VP9E_SET_SVC_LAYER_ID, (int *) &layer_id);
drop the space after the cast.
___
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] avcodec/libvpxenc: add VP9 temporal scalability encoding option
HI,
On Mon, Jan 13, 2020 at 4:44 PM James Zern
wrote:
> Hi,
>
> On Fri, Jan 10, 2020 at 9:59 AM Wonkap Jang
> wrote:
> >
> > This commit reuses the configuration options for VP8 that enables
> > temporal scalability for VP9. It also adds a way to enable three
> > preset temporal structures (refer to the documentation for more
> > detail) that can be used in offline encoding.
> > ---
> > doc/encoders.texi | 18 ++-
> > libavcodec/libvpxenc.c | 251 +
> > 2 files changed, 243 insertions(+), 26 deletions(-)
> >
> > [...]
> > #endif
> > @@ -223,8 +231,16 @@ static av_cold void dump_enc_cfg(AVCodecContext
> *avctx,
> > " %*s%u\n", width, "ts_number_layers:",
> cfg->ts_number_layers);
> > av_log(avctx, level,
> > "\n %*s", width, "ts_target_bitrate:");
>
> This should move to the vp8 branch and a new heading added for vp9's
> layer_target_bitrate.
>
> > [...]
> > -static int vp8_ts_param_parse(struct vpx_codec_enc_cfg *enccfg, char
> *key, char *value)
> > +static void set_temporal_layer_pattern(int layering_mode,
> > + vpx_codec_enc_cfg_t *cfg,
> > + int *layer_flags,
> > + int *flag_periodicity)
> > +{
> > +switch (layering_mode) {
> > +case 2: {
> > +/**
> > + * 2-layers, 2-frame period.
> > + */
> > +int ids[2] = { 0, 1 };
>
> these can be static const.
>
[WJ] OK.
>
> > +cfg->ts_periodicity = 2;
> > +*flag_periodicity = 2;
> > +cfg->ts_number_layers = 2;
> > +cfg->ts_rate_decimator[0] = 2;
> > +cfg->ts_rate_decimator[1] = 1;
> > +memcpy(cfg->ts_layer_id, ids, sizeof(ids));
> > +
> > +layer_flags[0] =
> > + VP8_EFLAG_NO_REF_GF | VP8_EFLAG_NO_REF_ARF |
> > + VP8_EFLAG_NO_UPD_GF | VP8_EFLAG_NO_UPD_ARF;
> > +
>
> this line can be removed.
>
[WJ] OK.
>
> > +layer_flags[1] =
> > +VP8_EFLAG_NO_UPD_ARF | VP8_EFLAG_NO_UPD_GF |
> > +VP8_EFLAG_NO_UPD_LAST |
> > +VP8_EFLAG_NO_REF_ARF | VP8_EFLAG_NO_REF_GF;
> > +break;
> > +}
> > +case 3: {
> > +/**
> > + * 3-layers structure with one reference frame.
> > + * This works same as temporal_layering_mode 3.
> > + *
> > + * 3-layers, 4-frame period.
> > + */
> > +int ids[4] = { 0, 2, 1, 2 };
> > +cfg->ts_periodicity = 4;
> > +*flag_periodicity = 4;
> > +cfg->ts_number_layers = 3;
> > +cfg->ts_rate_decimator[0] = 4;
> > +cfg->ts_rate_decimator[1] = 2;
> > +cfg->ts_rate_decimator[2] = 1;
> > +memcpy(cfg->ts_layer_id, ids, sizeof(ids));
> > +
> > +/**
> > + * 0=L, 1=GF, 2=ARF,
>
> what about [3]?
>
[WJ] decimator is for indicating the framerate decimation per temporal
layer. There are three temporal layers in this case, no need for [3].
>
> > + * Intra-layer prediction disabled.
> > + */
> > +layer_flags[0] =
> > +VP8_EFLAG_NO_REF_GF | VP8_EFLAG_NO_REF_ARF |
> > +VP8_EFLAG_NO_UPD_GF | VP8_EFLAG_NO_UPD_ARF;
> > +layer_flags[2] =
>
> can you reorder this to be in the natural 0...3 order?
>
[WJ] this is in the order of temporal layer id, just like it is written in
vpx_temporal_svc_encoder in libvpx/examples, but I'll make the change as
suggested.
>
> > [...]
> > +/**
> > + * 0=L, 1=GF, 2=ARF, Intra-layer prediction disabled.
> > + */
> > +layer_flags[0] =
> > +VP8_EFLAG_NO_REF_GF | VP8_EFLAG_NO_REF_ARF |
> > +VP8_EFLAG_NO_UPD_GF | VP8_EFLAG_NO_UPD_ARF;
> > +layer_flags[2] =
>
> same comment here about order.
>
> > [...]
> > +
> > +#if (VPX_ENCODER_ABI_VERSION >= 12) && CONFIG_LIBVPX_VP9_ENCODER
> > +enccfg->temporal_layering_mode = 1; // only bypass mode is being
> supported for now.
>
> ...mode is supported...
>
[WJ] gotit.
>
> > +enccfg->ss_number_layers = 1; // making sure the spatial
> scalability is off. Will support this in future.
>
> this can be TODO: add spatial scalability support.
[WJ] gotit.
>
> > +#endif
> > +if (ts_layering_mode) {
> > + // make sure the ts_layering_mode comes at the end of the
> ts_parameter string to ensure that
> > + // correct configuration is done.
> > + ctx->ts_layer_flags = av_malloc(sizeof(int) *
> VPX_TS_MAX_PERIODICITY);
>
> prefer sizeof(var).
>
[WJ] OK.
>
> > [...]
> >
> > -if(!avctx->bit_rate)
> > -if(avctx->rc_max_rate || avctx->rc_buffer_size ||
> avctx->rc_initial_buffer_occupancy) {
> > +if (!avctx->bit_rate)
> > +if (avctx->rc_max_rate || avctx->rc_buffer_size ||
> avctx->rc_initial_buffer_occupancy) {
>
> this is unrelated to the change, please remove it.
>
[WJ] ok.
>
> > [...]
> > +#if VPX_ENCODER_ABI_VERSION >= 12
> > +codecctl_int(avctx, VP9E_SE
Re: [FFmpeg-devel] [PATCH v1] avcodec/libx265: Fix Uninitialized scalar variable
On Mon, Jan 13, 2020 at 04:19:10PM +, Derek Buitenhuis wrote: > On 09/01/2020 10:52, lance.lmw...@gmail.com wrote: > > +default: > > +pict_type = AV_PICTURE_TYPE_NONE; > > Is this ever possible to actually hit in the API, though? > > Maybe more useful to return an error in such a case, since something > is really wrong probably? It's OK to return an error from my side, I'm use the same way like libx264, if prefer to such way, it's better to change libx264 to return error also. > > - Derek > ___ > 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, Limin Wang ___ 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 V1 01/11] lavfi/spp: add "quality" option in runtime change path
On Mon, Jan 13, 2020 at 9:27 PM Moritz Barsnick wrote:
>
> On Sat, Jan 11, 2020 at 12:13:48 +0800, Jun Zhao wrote:
> > +@item level
> > +@item quality
> > +Same as quality option. And the command accepts the @code{max} same as the
> > @code{6}.
> > +@end table
>
> I'm sorry for coming in late, but this sentence doesn't make much sense
> to me:
>And the command accepts the "max" same as the 6.
> Are you trying to say that the allowed range for the command(s) is
> (are) the same as for the option?
>
No, from the code,
if (!strcmp(args, "max"))
s->log2_count = MAX_LEVEL;
this means, we can setting value "max" or "6" (MAX_LEVEL)
___
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/8] lavu/pix_fmt: add new pixel format y210
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Monday, January 13, 2020 00:41
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/8] lavu/pix_fmt: add new pixel format
> y210
>
> Am So., 12. Jan. 2020 um 08:57 Uhr schrieb Fu, Linjie :
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Mark Thompson
> > > Sent: Thursday, January 9, 2020 05:47
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH 1/8] lavu/pix_fmt: add new pixel
> format
> > > y210
> > >
> > > On 29/12/2019 16:28, Linjie Fu wrote:
> > > > Add some packed 4:2:2 10-bit pixel formats for hardware decode
> support
> > > > in VAAPI and QSV.
> > > >
> > > > Signed-off-by: Linjie Fu
> > > > ---
> > > > libavutil/pixdesc.c | 23 +++
> > > > libavutil/pixfmt.h | 5 +
> > > > libavutil/version.h | 2 +-
> > > > tests/ref/fate/sws-pixdesc-query | 7 +++
> > > > 4 files changed, 36 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> > > > index 05dd4a1..1e118ef 100644
> > > > --- a/libavutil/pixdesc.c
> > > > +++ b/libavutil/pixdesc.c
> > > > @@ -205,6 +205,29 @@ static const AVPixFmtDescriptor
> > > av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> > > > { 0, 4, 1, 0, 8, 3, 7, 2 },/* V */
> > > > },
> > > > },
> > > > +[AV_PIX_FMT_Y210LE] = {
> > > > +.name = "y210le",
> > > > +.nb_components = 3,
> > > > +.log2_chroma_w = 1,
> > > > +.log2_chroma_h = 0,
> > > > +.comp = {
> > > > +{ 0, 4, 0, 6, 10, 3, 9, 1 },/* Y */
> > > > +{ 0, 8, 2, 6, 10, 7, 9, 3 },/* U */
> > > > +{ 0, 8, 6, 6, 10, 7, 9, 7 },/* V */
> > > > +},
> > > > +},
> > > > +[AV_PIX_FMT_Y210BE] = {
> > > > +.name = "y210be",
> > > > +.nb_components = 3,
> > > > +.log2_chroma_w = 1,
> > > > +.log2_chroma_h = 0,
> > > > +.comp = {
> > > > +{ 0, 4, 0, 6, 10, 3, 9, 1 },/* Y */
> > > > +{ 0, 8, 2, 6, 10, 7, 9, 3 },/* U */
> > > > +{ 0, 8, 6, 6, 10, 7, 9, 7 },/* V */
> > > > +},
> > > > +.flags = AV_PIX_FMT_FLAG_BE,
> > > > +},
> > > > [AV_PIX_FMT_RGB24] = {
> > > > .name = "rgb24",
> > > > .nb_components = 3,
> > > > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > > > index 37ecebd..7ffa5a0 100644
> > > > --- a/libavutil/pixfmt.h
> > > > +++ b/libavutil/pixfmt.h
> > > > @@ -348,6 +348,9 @@ enum AVPixelFormat {
> > > > 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_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
> big-
> > > endian
> > > > +AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
> little-
> > > endian
> > >
> > > These comments should be clear that the data are in the high bits (like
> P010),
> > > rather than in the low bits (like most formats used by software codecs).
> > >
> > > Being consistent with other comments would write 20bpp rather than
> 32bpp,
> > > though I'm not sure how much information that number is really adding.
> > >
> > Would update the comments like:
> > packed YUV 4:2:2 like YUYV422, 20bpp, data in the high bits, zeros in the
> low bits, big-endian
>
> Please do not write "zeros in the low bits", this is just confusing.
>
P010LE/P010BE are using similar comments, and there is identical description in
the doc:
"The 10-bit formats also use 16 bits for each channel, with the lowest 6 bits
set to zero"
https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats
Hi Carl, would you please help to elaborate more on how to refine the comments?
___
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/7] avformat/segafilmenc: Fix undefined left shift of 1 by 31 places
by changing the type to unsigned. Signed-off-by: Andreas Rheinhardt --- libavformat/segafilmenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c index 812d0ad64e..d721ec38fa 100644 --- a/libavformat/segafilmenc.c +++ b/libavformat/segafilmenc.c @@ -70,7 +70,7 @@ static int film_write_packet_to_header(AVFormatContext *format_context, FILMPack info2 = pkt->duration; /* The top bit being set indicates a key frame */ if (!pkt->keyframe) -info1 |= (1 << 31); +info1 |= 1U << 31; } /* Write the 16-byte sample info packet to the STAB chunk in the header */ -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/7] avformat/segafilmenc: Remove AVClass
This muxer does not have any private options and so does not need a
private class.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 8
1 file changed, 8 deletions(-)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index bd7c03faf5..5ac60ea5c3 100644
--- a/libavformat/segafilmenc.c
+++ b/libavformat/segafilmenc.c
@@ -45,7 +45,6 @@ typedef struct FILMPacket {
} FILMPacket;
typedef struct FILMOutputContext {
-const AVClass *class;
int audio_index;
int video_index;
int64_t stab_pos;
@@ -377,12 +376,6 @@ static int film_write_header(AVFormatContext
*format_context)
return 0;
}
-static const AVClass film_muxer_class = {
-.class_name = "Sega FILM muxer",
-.item_name = av_default_item_name,
-.version= LIBAVUTIL_VERSION_INT,
-};
-
AVOutputFormat ff_segafilm_muxer = {
.name = "film_cpk",
.long_name = NULL_IF_CONFIG_SMALL("Sega FILM / CPK"),
@@ -393,5 +386,4 @@ AVOutputFormat ff_segafilm_muxer = {
.init = film_init,
.write_trailer = film_write_header,
.write_packet = film_write_packet,
-.priv_class = &film_muxer_class,
};
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/7] avformat/segafilmenc: Check early whether video is allowed
The current code only checks when writing the trailer whether the video
format and Codec ID are actually compatible with the container. At this
point, a lot of data will already have been written (in vain, of
course), so check during the init function instead.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index 56fc59a811..bd7c03faf5 100644
--- a/libavformat/segafilmenc.c
+++ b/libavformat/segafilmenc.c
@@ -181,6 +181,17 @@ static int film_init(AVFormatContext *format_context)
av_log(format_context, AV_LOG_ERROR, "Sega FILM allows a
maximum of one video stream.\n");
return AVERROR(EINVAL);
}
+if (st->codecpar->codec_id != AV_CODEC_ID_CINEPAK &&
+st->codecpar->codec_id != AV_CODEC_ID_RAWVIDEO) {
+av_log(format_context, AV_LOG_ERROR,
+ "Incompatible video stream format.\n");
+return AVERROR(EINVAL);
+}
+if (st->codecpar->format != AV_PIX_FMT_RGB24) {
+av_log(format_context, AV_LOG_ERROR,
+ "Pixel format must be rgb24.\n");
+return AVERROR(EINVAL);
+}
film->video_index = i;
}
}
@@ -293,11 +304,6 @@ static int film_write_header(AVFormatContext
*format_context)
}
}
-if (video->codecpar->format != AV_PIX_FMT_RGB24) {
-av_log(format_context, AV_LOG_ERROR, "Pixel format must be rgb24.\n");
-return AVERROR(EINVAL);
-}
-
/* First, write the FILM header; this is very simple */
ffio_wfourcc(pb, "FILM");
@@ -320,9 +326,6 @@ static int film_write_header(AVFormatContext
*format_context)
case AV_CODEC_ID_RAWVIDEO:
ffio_wfourcc(pb, "raw ");
break;
-default:
-av_log(format_context, AV_LOG_ERROR, "Incompatible video stream
format.\n");
-return AVERROR(EINVAL);
}
avio_wb32(pb, video->codecpar->height);
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/7] avformat/segafilmenc: Postpone check for existence of video stream
Up until now, the Sega FILM muxer complained if the first stream wasn't a
video stream that there is no video stream at all which is of course
nonsense. So postpone this check.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index d721ec38fa..56fc59a811 100644
--- a/libavformat/segafilmenc.c
+++ b/libavformat/segafilmenc.c
@@ -183,11 +183,11 @@ static int film_init(AVFormatContext *format_context)
}
film->video_index = i;
}
+}
-if (film->video_index == -1) {
-av_log(format_context, AV_LOG_ERROR, "No video stream present.\n");
-return AVERROR(EINVAL);
-}
+if (film->video_index == -1) {
+av_log(format_context, AV_LOG_ERROR, "No video stream present.\n");
+return AVERROR(EINVAL);
}
if (audio != NULL && get_audio_codec_id(audio->codecpar->codec_id) < 0) {
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/7] avformat/segafilmenc: Remove redundant checks
If an audio stream is present, the Sega FILM muxer checks for its
compability with the container during init, so that the very same check
needn't be repeated during writing the trailer.
Essentially the same is true for the presence of a video stream: It has
already been checked during init. Furthermore, after the check for the
presence of a video stream succeeded, a pointer is set to point to the
video stream. Yet said pointer (which was NULL before) will be
derefenced anyway regardless of the result of the check. Coverity thus
complained about this in CID 1434155 and removing this pointless check
will also fix this issue.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index 5ac60ea5c3..4f881f4f2f 100644
--- a/libavformat/segafilmenc.c
+++ b/libavformat/segafilmenc.c
@@ -292,15 +292,9 @@ static int film_write_header(AVFormatContext
*format_context)
if (film->audio_index > -1)
audio = format_context->streams[film->audio_index];
-if (film->video_index > -1)
-video = format_context->streams[film->video_index];
if (audio != NULL) {
audio_codec = get_audio_codec_id(audio->codecpar->codec_id);
-if (audio_codec < 0) {
-av_log(format_context, AV_LOG_ERROR, "Incompatible audio stream
format.\n");
-return AVERROR(EINVAL);
-}
}
/* First, write the FILM header; this is very simple */
@@ -317,6 +311,8 @@ static int film_write_header(AVFormatContext
*format_context)
ffio_wfourcc(pb, "FDSC");
avio_wb32(pb, 0x20); /* Size of FDSC chunk */
+video = format_context->streams[film->video_index];
+
/* The only two supported codecs; raw video is rare */
switch (video->codecpar->codec_id) {
case AV_CODEC_ID_CINEPAK:
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 7/7] avformat/segafilmenc: Add deinit function
Prevents memleaks when the trailer is never written or when shifting the
data fails when writing the trailer.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index 137f153331..6b66c68328 100644
--- a/libavformat/segafilmenc.c
+++ b/libavformat/segafilmenc.c
@@ -360,10 +360,23 @@ static int film_write_header(AVFormatContext
*format_context)
packet = packet->next;
av_freep(&prev);
}
+film->start = film->last = NULL;
return 0;
}
+static void film_deinit(AVFormatContext *format_context)
+{
+FILMOutputContext *film = format_context->priv_data;
+FILMPacket *packet = film->start;
+while (packet != NULL) {
+FILMPacket *next = packet->next;
+av_free(packet);
+packet = next;
+}
+film->start = film->last = NULL;
+}
+
AVOutputFormat ff_segafilm_muxer = {
.name = "film_cpk",
.long_name = NULL_IF_CONFIG_SMALL("Sega FILM / CPK"),
@@ -374,4 +387,5 @@ AVOutputFormat ff_segafilm_muxer = {
.init = film_init,
.write_trailer = film_write_header,
.write_packet = film_write_packet,
+.deinit = film_deinit,
};
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/7] avformat/segafilmenc: Combine several checks
by moving them around.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index 4f881f4f2f..137f153331 100644
--- a/libavformat/segafilmenc.c
+++ b/libavformat/segafilmenc.c
@@ -155,7 +155,6 @@ static int get_audio_codec_id(enum AVCodecID codec_id)
static int film_init(AVFormatContext *format_context)
{
-AVStream *audio = NULL;
FILMOutputContext *film = format_context->priv_data;
film->audio_index = -1;
film->video_index = -1;
@@ -171,8 +170,12 @@ static int film_init(AVFormatContext *format_context)
av_log(format_context, AV_LOG_ERROR, "Sega FILM allows a
maximum of one audio stream.\n");
return AVERROR(EINVAL);
}
+if (get_audio_codec_id(st->codecpar->codec_id) < 0) {
+av_log(format_context, AV_LOG_ERROR,
+ "Incompatible audio stream format.\n");
+return AVERROR(EINVAL);
+}
film->audio_index = i;
-audio = st;
}
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
@@ -200,11 +203,6 @@ static int film_init(AVFormatContext *format_context)
return AVERROR(EINVAL);
}
-if (audio != NULL && get_audio_codec_id(audio->codecpar->codec_id) < 0) {
-av_log(format_context, AV_LOG_ERROR, "Incompatible audio stream
format.\n");
-return AVERROR(EINVAL);
-}
-
return 0;
}
@@ -269,11 +267,9 @@ static int film_write_header(AVFormatContext
*format_context)
{
int ret = 0;
int64_t sample_table_size, stabsize, headersize;
-int8_t audio_codec;
AVIOContext *pb = format_context->pb;
FILMOutputContext *film = format_context->priv_data;
FILMPacket *prev, *packet;
-AVStream *audio = NULL;
AVStream *video = NULL;
/* Calculate how much we need to reserve for the header;
@@ -290,13 +286,6 @@ static int film_write_header(AVFormatContext
*format_context)
/* Seek back to the beginning to start writing the header now */
avio_seek(pb, 0, SEEK_SET);
-if (film->audio_index > -1)
-audio = format_context->streams[film->audio_index];
-
-if (audio != NULL) {
-audio_codec = get_audio_codec_id(audio->codecpar->codec_id);
-}
-
/* First, write the FILM header; this is very simple */
ffio_wfourcc(pb, "FILM");
@@ -327,7 +316,10 @@ static int film_write_header(AVFormatContext
*format_context)
avio_wb32(pb, video->codecpar->width);
avio_w8(pb, 24); /* Bits per pixel - observed to always be 24 */
-if (audio != NULL) {
+if (film->audio_index > -1) {
+AVStream *audio = format_context->streams[film->audio_index];
+int audio_codec = get_audio_codec_id(audio->codecpar->codec_id);
+
avio_w8(pb, audio->codecpar->channels); /* Audio channels */
avio_w8(pb, audio->codecpar->bits_per_coded_sample); /* Audio bit
depth */
avio_w8(pb, audio_codec); /* Compression - 0 is PCM, 2 is ADX */
--
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".
Re: [FFmpeg-devel] [PATCH 2/8] swscale: Add swscale input support for Y210
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Monday, January 13, 2020 00:40
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/8] swscale: Add swscale input support
> for Y210
>
> Am So., 29. Dez. 2019 um 17:40 Uhr schrieb Linjie Fu :
> >
> > Add swscale input support for Y210, output support and fate
> > test could be added later if there is requirement for software
> > CSC to this packed format.
> >
> > Signed-off-by: Linjie Fu
> > ---
> format_entries[AV_PIX_FMT_NB] = {
> > [AV_PIX_FMT_YUVA444P12LE] = { 1, 1 },
> > [AV_PIX_FMT_NV24]= { 1, 1 },
> > [AV_PIX_FMT_NV42]= { 1, 1 },
> > +[AV_PIX_FMT_Y210BE] = { 1, 0 },
> > +[AV_PIX_FMT_Y210LE] = { 1, 0 },
>
> Am I correct that this functions only work on LE because the vaapi drivers
> only exist for LE?
The only output from VAAPI driver is Y210LE. Y210BE is not available for
the hardware.(swscale input support for BE is identical to LE, and should also
work)
The Y210BE definition and software scale support could be hold currently and
maybe
add later if there is a requirement.
Will update a new version.
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 2/8] swscale: Add swscale input support for Y210
> Am 14.01.2020 um 04:20 schrieb Fu, Linjie :
>
> Zitierten Inhalt anzeigen
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Carl Eugen Hoyos
>> Sent: Monday, January 13, 2020 00:40
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH 2/8] swscale: Add swscale input support
>> for Y210
>>
>>> Am So., 29. Dez. 2019 um 17:40 Uhr schrieb Linjie Fu :
>>>
>>> Add swscale input support for Y210, output support and fate
>>> test could be added later if there is requirement for software
>>> CSC to this packed format.
>>>
>>> Signed-off-by: Linjie Fu
>>> ---
>> format_entries[AV_PIX_FMT_NB] = {
>>> [AV_PIX_FMT_YUVA444P12LE] = { 1, 1 },
>>> [AV_PIX_FMT_NV24]= { 1, 1 },
>>> [AV_PIX_FMT_NV42]= { 1, 1 },
>>> +[AV_PIX_FMT_Y210BE] = { 1, 0 },
>>> +[AV_PIX_FMT_Y210LE] = { 1, 0 },
>>
>> Am I correct that this functions only work on LE because the vaapi drivers
>> only exist for LE?
>
>
> The only output from VAAPI driver is Y210LE.
But does the driver also exist on big-endian hardware? And was your conversion
routine tested on big-endian hardware?
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 1/8] lavu/pix_fmt: add new pixel format y210
Am 14.01.2020 um 03:38 schrieb Fu, Linjie :
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Carl Eugen Hoyos
>> Sent: Monday, January 13, 2020 00:41
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH 1/8] lavu/pix_fmt: add new pixel format
>> y210
>>
>>> Am So., 12. Jan. 2020 um 08:57 Uhr schrieb Fu, Linjie :
>>>
-Original Message-
From: ffmpeg-devel On Behalf Of
Mark Thompson
Sent: Thursday, January 9, 2020 05:47
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/8] lavu/pix_fmt: add new pixel
>> format
y210
> On 29/12/2019 16:28, Linjie Fu wrote:
> Add some packed 4:2:2 10-bit pixel formats for hardware decode
>> support
> in VAAPI and QSV.
>
> Signed-off-by: Linjie Fu
> ---
> libavutil/pixdesc.c | 23 +++
> libavutil/pixfmt.h | 5 +
> libavutil/version.h | 2 +-
> tests/ref/fate/sws-pixdesc-query | 7 +++
> 4 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index 05dd4a1..1e118ef 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -205,6 +205,29 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> { 0, 4, 1, 0, 8, 3, 7, 2 },/* V */
> },
> },
> +[AV_PIX_FMT_Y210LE] = {
> +.name = "y210le",
> +.nb_components = 3,
> +.log2_chroma_w = 1,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 0, 6, 10, 3, 9, 1 },/* Y */
> +{ 0, 8, 2, 6, 10, 7, 9, 3 },/* U */
> +{ 0, 8, 6, 6, 10, 7, 9, 7 },/* V */
> +},
> +},
> +[AV_PIX_FMT_Y210BE] = {
> +.name = "y210be",
> +.nb_components = 3,
> +.log2_chroma_w = 1,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 0, 6, 10, 3, 9, 1 },/* Y */
> +{ 0, 8, 2, 6, 10, 7, 9, 3 },/* U */
> +{ 0, 8, 6, 6, 10, 7, 9, 7 },/* V */
> +},
> +.flags = AV_PIX_FMT_FLAG_BE,
> +},
> [AV_PIX_FMT_RGB24] = {
> .name = "rgb24",
> .nb_components = 3,
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 37ecebd..7ffa5a0 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -348,6 +348,9 @@ enum AVPixelFormat {
> 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_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
>> big-
endian
> +AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
>> little-
endian
These comments should be clear that the data are in the high bits (like
>> P010),
rather than in the low bits (like most formats used by software codecs).
Being consistent with other comments would write 20bpp rather than
>> 32bpp,
though I'm not sure how much information that number is really adding.
>>> Would update the comments like:
>>> packed YUV 4:2:2 like YUYV422, 20bpp, data in the high bits, zeros in the
>> low bits, big-endian
>>
>> Please do not write "zeros in the low bits", this is just confusing.
>>
>
> P010LE/P010BE are using similar comments, and there is identical description
> in the doc:
> "The 10-bit formats also use 16 bits for each channel, with the lowest 6 bits
> set to zero"
> https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats
>
> Hi Carl, would you please help to elaborate more on how to refine the
> comments?
Just remove „zeros in the low bits“.
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 V7 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code
> -Original Message- > From: ffmpeg-devel On Behalf Of Fu, > Ting > Sent: Friday, January 10, 2020 01:58 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: Change > inline assembly into nasm code > > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Ting > > Fu > > Sent: Friday, January 10, 2020 01:38 AM > > To: ffmpeg-devel@ffmpeg.org > > Subject: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: Change > > inline assembly into nasm code > > > > Signed-off-by: Ting Fu > > --- > > V7: > > Fix compile issue when user configure with --disable-mmx. > > Fix issue when running ./ffmpeg with --cpuflags mmx/ssse3. > > Adjust the SIMD verify logic in libswscale/x86/yuv2rgb.c > > To be more detail. I was use 'if clause' to judge the color format in > libswscale/x86/yuv2rgb.c and then the '#if macro' to judge SIMD in > libswscale/x86/yuv2rgb_template.c. Which cannot correctly respond to the > command when use ./ffmpeg with --cpuflags, cause it does not get value of > av_get_cpu_flags() any more. So, I abandoned the macro and judge both color > format and SIMD in libswscale/x86/yuv2rgb.c. > > Thank you, > Ting Fu > > > > libswscale/x86/Makefile | 1 + > > libswscale/x86/swscale.c | 16 +- > > libswscale/x86/yuv2rgb.c | 66 ++--- > > libswscale/x86/yuv2rgb_template.c | 467 ++ > > libswscale/x86/yuv_2_rgb.asm | 270 + > > 5 files changed, 405 insertions(+), 415 deletions(-) create mode > > 100644 libswscale/x86/yuv_2_rgb.asm > > A kindle ping. [...] > > -- > > 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 V7 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code
> -Original Message- > From: ffmpeg-devel On Behalf Of Fu, > Ting > Sent: Tuesday, January 14, 2020 02:15 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: Change > inline assembly into nasm code > > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Fu, > > Ting > > Sent: Friday, January 10, 2020 01:58 AM > > To: FFmpeg development discussions and patches > > > > Subject: Re: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: > > Change inline assembly into nasm code > > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Ting Fu > > > Sent: Friday, January 10, 2020 01:38 AM > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: > > > Change inline assembly into nasm code > > > > > > Signed-off-by: Ting Fu > > > --- > > > V7: > > > Fix compile issue when user configure with --disable-mmx. > > > Fix issue when running ./ffmpeg with --cpuflags mmx/ssse3. > > > Adjust the SIMD verify logic in libswscale/x86/yuv2rgb.c > > > > To be more detail. I was use 'if clause' to judge the color format in > > libswscale/x86/yuv2rgb.c and then the '#if macro' to judge SIMD in > > libswscale/x86/yuv2rgb_template.c. Which cannot correctly respond to > > the command when use ./ffmpeg with --cpuflags, cause it does not get > > value of > > av_get_cpu_flags() any more. So, I abandoned the macro and judge both > > color format and SIMD in libswscale/x86/yuv2rgb.c. > > > > Thank you, > > Ting Fu > > > > > > libswscale/x86/Makefile | 1 + > > > libswscale/x86/swscale.c | 16 +- > > > libswscale/x86/yuv2rgb.c | 66 ++--- > > > libswscale/x86/yuv2rgb_template.c | 467 ++ > > > libswscale/x86/yuv_2_rgb.asm | 270 + > > > 5 files changed, 405 insertions(+), 415 deletions(-) create mode > > > 100644 libswscale/x86/yuv_2_rgb.asm > > > > A kindle ping. Sorry , I mean 'a kindly ping'. Ting Fu > [...] > > > -- > > > 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". ___ 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 3/5] avfilter/scale: separate exprs parse and eval
On 09-01-2020 11:31 am, Gyan wrote: Barring further reviews, I'll retest and push the patchset on Monday. Manual and FATE testing passed. Will push patchset in a day. On 06-01-2020 11:44 am, Gyan wrote: Ping for the remainder of patchset. Expression parsing and backup has been factorized so code duplication is minimized. On 01-01-2020 01:12 am, Gyan Doshi wrote: Retains parsed expressions which allows for better error-checking and adding animation support. --- 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 2/8] swscale: Add swscale input support for Y210
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Tuesday, January 14, 2020 12:42
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/8] swscale: Add swscale input support
> for Y210
>
>
>
> > Am 14.01.2020 um 04:20 schrieb Fu, Linjie :
> >
> > Zitierten Inhalt anzeigen
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Carl Eugen Hoyos
> >> Sent: Monday, January 13, 2020 00:40
> >> To: FFmpeg development discussions and patches >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH 2/8] swscale: Add swscale input
> support
> >> for Y210
> >>
> >>> Am So., 29. Dez. 2019 um 17:40 Uhr schrieb Linjie Fu
> :
> >>>
> >>> Add swscale input support for Y210, output support and fate
> >>> test could be added later if there is requirement for software
> >>> CSC to this packed format.
> >>>
> >>> Signed-off-by: Linjie Fu
> >>> ---
> >> format_entries[AV_PIX_FMT_NB] = {
> >>> [AV_PIX_FMT_YUVA444P12LE] = { 1, 1 },
> >>> [AV_PIX_FMT_NV24]= { 1, 1 },
> >>> [AV_PIX_FMT_NV42]= { 1, 1 },
> >>> +[AV_PIX_FMT_Y210BE] = { 1, 0 },
> >>> +[AV_PIX_FMT_Y210LE] = { 1, 0 },
> >>
> >> Am I correct that this functions only work on LE because the vaapi drivers
> >> only exist for LE?
> >
> >
> > The only output from VAAPI driver is Y210LE.
>
> But does the driver also exist on big-endian hardware? And was your
> conversion routine tested on big-endian hardware?
As far as I know from media-driver, there is no support on big-endian hardware,
hence no testing for big endian conversion locally. To avoid any uncertainty, we
can hold the big-endian support unless it's demanded someday.
___
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".
