Re: [FFmpeg-devel] [PATCH] avcodec/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions
On 2017-06-16 03:58, Michael Niedermayer wrote: > On Thu, Jun 15, 2017 at 05:08:33PM +0200, James Darnley wrote: >> Includes add/put functions >> >> Rounding contributed by Ronald S. Bultje >> --- >> I must be stupid. I dropped the stack space change somewhere. >> >> libavcodec/tests/x86/dct.c | 2 + >> libavcodec/x86/idctdsp_init.c| 23 ++ >> libavcodec/x86/simple_idct.h | 9 >> libavcodec/x86/simple_idct10.asm | 94 >> >> 4 files changed, 128 insertions(+) > > theres something wrong with this > it totally breaks this: > make -j12 ffmpeg && ./ffmpeg -ss 1 -i cache:matrixbench_mpeg2.mpg -t 2 -y > test.avi > ./ffplay test.avi > > (totally as in bitstream errors not some idct artifacts) How did you manage to break it that much? I don't touch avformat. I don't touch the rest of the decoder. I don't have that file to test with and the cut down version which I think is in fate is only 0.96 seconds long. However trying your command on that file successfully decodes 1 frame from it. I made decoding it with the new functions the fate test I added. All the other fate samples in mpeg2/ decode seemingly fine with no extra messages. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions
On 6/16/17, James Darnley wrote: > On 2017-06-16 03:58, Michael Niedermayer wrote: >> On Thu, Jun 15, 2017 at 05:08:33PM +0200, James Darnley wrote: >>> Includes add/put functions >>> >>> Rounding contributed by Ronald S. Bultje >>> --- >>> I must be stupid. I dropped the stack space change somewhere. >>> >>> libavcodec/tests/x86/dct.c | 2 + >>> libavcodec/x86/idctdsp_init.c| 23 ++ >>> libavcodec/x86/simple_idct.h | 9 >>> libavcodec/x86/simple_idct10.asm | 94 >>> >>> 4 files changed, 128 insertions(+) >> >> theres something wrong with this >> it totally breaks this: >> make -j12 ffmpeg && ./ffmpeg -ss 1 -i cache:matrixbench_mpeg2.mpg -t 2 -y >> test.avi >> ./ffplay test.avi >> >> (totally as in bitstream errors not some idct artifacts) > > How did you manage to break it that much? I don't touch avformat. I > don't touch the rest of the decoder. > > I don't have that file to test with and the cut down version which I > think is in fate is only 0.96 seconds long. However trying your command > on that file successfully decodes 1 frame from it. I made decoding it > with the new functions the fate test I added. All the other fate > samples in mpeg2/ decode seemingly fine with no extra messages. File is in samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg Michael failed to write that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?
On Fri, 16 Jun 2017 02:32:10 +0200 21na...@gmail.com wrote: > Hello, > > > I would like to know why the tag “DURATION” in Matroska files (.mkv) is > a necessity? Even mkvmerge lets the choice to use it or not with > “--enable-durations”, in addition it is written “Write durations for all > blocks. This will increase file size and does not offer any additional > value for players at the moment.” (source > https://mkvtoolnix.download/doc/mkvmerge.html#d4e535). > > Possibly linked to > http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=31852540d4fba0c4e8a16d0b3ddff08fc98e48fd As far as I'm aware, the linked commit does not do the same thing as the mkvmerge option you pointed out. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions
On 2017-06-16 12:48, Paul B Mahol wrote: > On 6/16/17, James Darnley wrote: >> On 2017-06-16 03:58, Michael Niedermayer wrote: >>> theres something wrong with this >>> it totally breaks this: >>> make -j12 ffmpeg && ./ffmpeg -ss 1 -i cache:matrixbench_mpeg2.mpg -t 2 -y >>> test.avi >>> ./ffplay test.avi >>> >>> (totally as in bitstream errors not some idct artifacts) >> >> How did you manage to break it that much? I don't touch avformat. I >> don't touch the rest of the decoder. >> >> I don't have that file to test with and the cut down version which I >> think is in fate is only 0.96 seconds long. However trying your command >> on that file successfully decodes 1 frame from it. I made decoding it >> with the new functions the fate test I added. All the other fate >> samples in mpeg2/ decode seemingly fine with no extra messages. > > File is in samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg > > Michael failed to write that. TYVM. Even with that file I get just 3 messages when I seek 1 second. > [mpeg @ 0x399e3c0] start time for stream 0 is not set in > estimate_timings_from_pts > [mp2 @ 0x39a07a0] Header missing > Error while decoding stream #0:2: Invalid data found when processing input Furthermore I get those messages on master and they remain the same with my commits. (Stream 0:2 is the mp2 audio in this file.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/htmlsubtitles.c: make tags case-insensitive
Signed-off-by: DongHoon Kang
---
libavcodec/htmlsubtitles.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
tags in srt and sami subtitles don't need to be in lowercase.
diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
index 16295daa0c..94430f7345 100644
--- a/libavcodec/htmlsubtitles.c
+++ b/libavcodec/htmlsubtitles.c
@@ -99,12 +99,12 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst,
const char *in)
if ((param = strchr(tagname, ' ')))
*param++ = 0;
if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack)) ||
-( tag_close && sptr > 0 && !strcmp(stack[sptr-1].tag,
tagname))) {
+( tag_close && sptr > 0 &&
!av_strcasecmp(stack[sptr-1].tag, tagname))) {
int i, j, unknown = 0;
in += len + tag_close;
if (!tag_close)
memset(stack+sptr, 0, sizeof(*stack));
-if (!strcmp(tagname, "font")) {
+if (!av_strcasecmp(tagname, "font")) {
if (tag_close) {
for (i=PARAM_NUMBER-1; i>=0; i--)
if (stack[sptr-1].param[i][0])
@@ -115,7 +115,7 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst,
const char *in)
}
} else {
while (param) {
-if (!strncmp(param, "size=", 5)) {
+if (!av_strncasecmp(param, "size=", 5)) {
unsigned font_size;
param += 5 + (param[5] == '"');
if (sscanf(param, "%u", &font_size) == 1) {
@@ -123,13 +123,13 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst,
const char *in)
sizeof(stack[0].param[PARAM_SIZE]),
"{\\fs%u}", font_size);
}
-} else if (!strncmp(param, "color=", 6)) {
+} else if (!av_strncasecmp(param, "color=",
6)) {
param += 6 + (param[6] == '"');
snprintf(stack[sptr].param[PARAM_COLOR],
sizeof(stack[0].param[PARAM_COLOR]),
"{\\c&H%X&}",
html_color_parse(log_ctx, param));
-} else if (!strncmp(param, "face=", 5)) {
+} else if (!av_strncasecmp(param, "face=", 5))
{
param += 5 + (param[5] == '"');
len = strcspn(param,
param[-1] == '"' ? "\"" :"
");
@@ -147,8 +147,8 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst,
const char *in)
if (stack[sptr].param[i][0])
av_bprintf(dst, "%s",
stack[sptr].param[i]);
}
-} else if (tagname[0] && !tagname[1] && strspn(tagname,
"bisu") == 1) {
-av_bprintf(dst, "{\\%c%d}", tagname[0], !tag_close);
+} else if (tagname[0] && !tagname[1] && av_stristr("bisu",
tagname)) {
+av_bprintf(dst, "{\\%c%d}",
(char)av_tolower(tagname[0]), !tag_close);
} else {
unknown = 1;
snprintf(tmp, sizeof(tmp), "", tagname);
--
2.13.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?
Le 16/06/2017 à 12:55, wm4 a écrit : On Fri, 16 Jun 2017 02:32:10 +0200 21na...@gmail.com wrote: Hello, I would like to know why the tag “DURATION” in Matroska files (.mkv) is a necessity? Even mkvmerge lets the choice to use it or not with “--enable-durations”, in addition it is written “Write durations for all blocks. This will increase file size and does not offer any additional value for players at the moment.” (source https://mkvtoolnix.download/doc/mkvmerge.html#d4e535). Possibly linked to http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=31852540d4fba0c4e8a16d0b3ddff08fc98e48fd As far as I'm aware, the linked commit does not do the same thing as the mkvmerge option you pointed out. Yes that is why I wrote “possibly”, also because this commit is the one which adds the tag “DURATION” as a necessity, but a necessity that no software seems to use and it is not even a standard in the Matroska’s documentation if I am not mistaken. So the fact that it is a necessity and not a choice is the main problem. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?
On Fri, 16 Jun 2017 13:51:20 +0200 21na...@gmail.com wrote: > Le 16/06/2017 à 12:55, wm4 a écrit : > > On Fri, 16 Jun 2017 02:32:10 +0200 > > 21na...@gmail.com wrote: > > > >> Hello, > >> > >> > >> I would like to know why the tag “DURATION” in Matroska files (.mkv) is > >> a necessity? Even mkvmerge lets the choice to use it or not with > >> “--enable-durations”, in addition it is written “Write durations for all > >> blocks. This will increase file size and does not offer any additional > >> value for players at the moment.” (source > >> https://mkvtoolnix.download/doc/mkvmerge.html#d4e535). > >> > >> Possibly linked to > >> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=31852540d4fba0c4e8a16d0b3ddff08fc98e48fd > >> > > As far as I'm aware, the linked commit does not do the same thing as > > the mkvmerge option you pointed out. > > Yes that is why I wrote “possibly”, also because this commit is the one > which adds the tag “DURATION” as a necessity, but a necessity that no > software seems to use and it is not even a standard in the Matroska’s > documentation if I am not mistaken. So the fact that it is a necessity > and not a choice is the main problem. Who says it's a necessity or standard? It's just what mkvmerge does. Since the patch is by google, I assume google has some use for it (there might also be a discussion about it on the ML). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions
On Fri, Jun 16, 2017 at 12:09:27PM +0200, James Darnley wrote: > On 2017-06-16 03:58, Michael Niedermayer wrote: > > On Thu, Jun 15, 2017 at 05:08:33PM +0200, James Darnley wrote: > >> Includes add/put functions > >> > >> Rounding contributed by Ronald S. Bultje > >> --- > >> I must be stupid. I dropped the stack space change somewhere. > >> > >> libavcodec/tests/x86/dct.c | 2 + > >> libavcodec/x86/idctdsp_init.c| 23 ++ > >> libavcodec/x86/simple_idct.h | 9 > >> libavcodec/x86/simple_idct10.asm | 94 > >> > >> 4 files changed, 128 insertions(+) > > > > theres something wrong with this > > it totally breaks this: > > make -j12 ffmpeg && ./ffmpeg -ss 1 -i cache:matrixbench_mpeg2.mpg -t 2 -y > > test.avi > > ./ffplay test.avi > > > > (totally as in bitstream errors not some idct artifacts) > > How did you manage to break it that much? I don't touch avformat. I > don't touch the rest of the decoder. > > I don't have that file to test with and the cut down version which I > think is in fate is only 0.96 seconds long. However trying your command > on that file successfully decodes 1 frame from it. I made decoding it > with the new functions the fate test I added. All the other fate > samples in mpeg2/ decode seemingly fine with no extra messages. i retested and it does fail with this patch. looking at the code changing the perm_type alone is enough to trigger it. see dct_quantize() in libavcodec/x86/mpegvideoenc_template.c it seems this lacks support for TRANSPOSE [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?
Le 16/06/2017 à 14:25, wm4 a écrit : On Fri, 16 Jun 2017 13:51:20 +0200 21na...@gmail.com wrote: Le 16/06/2017 à 12:55, wm4 a écrit : On Fri, 16 Jun 2017 02:32:10 +0200 21na...@gmail.com wrote: Hello, I would like to know why the tag “DURATION” in Matroska files (.mkv) is a necessity? Even mkvmerge lets the choice to use it or not with “--enable-durations”, in addition it is written “Write durations for all blocks. This will increase file size and does not offer any additional value for players at the moment.” (source https://mkvtoolnix.download/doc/mkvmerge.html#d4e535). Possibly linked to http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=31852540d4fba0c4e8a16d0b3ddff08fc98e48fd As far as I'm aware, the linked commit does not do the same thing as the mkvmerge option you pointed out. Yes that is why I wrote “possibly”, also because this commit is the one which adds the tag “DURATION” as a necessity, but a necessity that no software seems to use and it is not even a standard in the Matroska’s documentation if I am not mistaken. So the fact that it is a necessity and not a choice is the main problem. Who says it's a necessity or standard? It's just what mkvmerge does. Since the patch is by google, I assume google has some use for it (there might also be a discussion about it on the ML). Sorry for the bad word “necessity”, it is better with “imposed”. Could you let the choice to the user like mkvmerge with “--disable-track-statistics-tags”? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/x86/mpegenc: support transpose permuation type
---
libavcodec/x86/mpegvideoenc_template.c | 47 +-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/mpegvideoenc_template.c
b/libavcodec/x86/mpegvideoenc_template.c
index 3ce72e1367..1201be514b 100644
--- a/libavcodec/x86/mpegvideoenc_template.c
+++ b/libavcodec/x86/mpegvideoenc_template.c
@@ -366,12 +366,57 @@ static int RENAME(dct_quantize)(MpegEncContext *s,
block[0x3D] = temp_block[0x3D]; block[0x36] = temp_block[0x36];
block[0x2F] = temp_block[0x2F]; block[0x37] = temp_block[0x37];
block[0x3E] = temp_block[0x3E]; block[0x3F] = temp_block[0x3F];
+} else if (s->idsp.perm_type == FF_IDCT_PERM_TRANSPOSE) {
+if(last_non_zero_p1 <= 1) goto end;
+block[0x08] = temp_block[0x01];
+block[0x01] = temp_block[0x08]; block[0x02] = temp_block[0x10];
+if(last_non_zero_p1 <= 4) goto end;
+block[0x09] = temp_block[0x09]; block[0x10] = temp_block[0x02];
+block[0x18] = temp_block[0x03];
+if(last_non_zero_p1 <= 7) goto end;
+block[0x11] = temp_block[0x0A]; block[0x0A] = temp_block[0x11];
+block[0x03] = temp_block[0x18]; block[0x04] = temp_block[0x20];
+if(last_non_zero_p1 <= 11) goto end;
+block[0x0B] = temp_block[0x19];
+block[0x12] = temp_block[0x12]; block[0x19] = temp_block[0x0B];
+block[0x20] = temp_block[0x04]; block[0x28] = temp_block[0x05];
+if(last_non_zero_p1 <= 16) goto end;
+block[0x21] = temp_block[0x0C]; block[0x1A] = temp_block[0x13];
+block[0x13] = temp_block[0x1A]; block[0x0C] = temp_block[0x21];
+block[0x05] = temp_block[0x28]; block[0x06] = temp_block[0x30];
+block[0x0D] = temp_block[0x29]; block[0x14] = temp_block[0x22];
+if(last_non_zero_p1 <= 24) goto end;
+block[0x1B] = temp_block[0x1B]; block[0x22] = temp_block[0x14];
+block[0x29] = temp_block[0x0D]; block[0x30] = temp_block[0x06];
+block[0x38] = temp_block[0x07]; block[0x31] = temp_block[0x0E];
+block[0x2A] = temp_block[0x15]; block[0x23] = temp_block[0x1C];
+if(last_non_zero_p1 <= 32) goto end;
+block[0x1C] = temp_block[0x23]; block[0x15] = temp_block[0x2A];
+block[0x0E] = temp_block[0x31]; block[0x07] = temp_block[0x38];
+block[0x0F] = temp_block[0x39]; block[0x16] = temp_block[0x32];
+block[0x1D] = temp_block[0x2B]; block[0x24] = temp_block[0x24];
+if(last_non_zero_p1 <= 40) goto end;
+block[0x2B] = temp_block[0x1D]; block[0x32] = temp_block[0x16];
+block[0x39] = temp_block[0x0F]; block[0x3A] = temp_block[0x17];
+block[0x33] = temp_block[0x1E]; block[0x2C] = temp_block[0x25];
+block[0x25] = temp_block[0x2C]; block[0x1E] = temp_block[0x33];
+if(last_non_zero_p1 <= 48) goto end;
+block[0x17] = temp_block[0x3A]; block[0x1F] = temp_block[0x3B];
+block[0x26] = temp_block[0x34]; block[0x2D] = temp_block[0x2D];
+block[0x34] = temp_block[0x26]; block[0x3B] = temp_block[0x1F];
+block[0x3C] = temp_block[0x27]; block[0x35] = temp_block[0x2E];
+if(last_non_zero_p1 <= 56) goto end;
+block[0x2E] = temp_block[0x35]; block[0x27] = temp_block[0x3C];
+block[0x2F] = temp_block[0x3D]; block[0x36] = temp_block[0x36];
+block[0x3D] = temp_block[0x2F]; block[0x3E] = temp_block[0x37];
+block[0x37] = temp_block[0x3E]; block[0x3F] = temp_block[0x3F];
} else {
av_log(s, AV_LOG_DEBUG, "s->idsp.perm_type: %d\n",
(int)s->idsp.perm_type);
av_assert0(s->idsp.perm_type == FF_IDCT_PERM_NONE ||
s->idsp.perm_type == FF_IDCT_PERM_LIBMPEG2 ||
-s->idsp.perm_type == FF_IDCT_PERM_SIMPLE);
+s->idsp.perm_type == FF_IDCT_PERM_SIMPLE ||
+s->idsp.perm_type == FF_IDCT_PERM_TRANSPOSE);
}
end:
return last_non_zero_p1 - 1;
--
2.13.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/x86/mpegenc: check IDCT permutation type is a valid value
---
libavcodec/x86/mpegvideoenc_template.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/mpegvideoenc_template.c
b/libavcodec/x86/mpegvideoenc_template.c
index b2512744ca..3ce72e1367 100644
--- a/libavcodec/x86/mpegvideoenc_template.c
+++ b/libavcodec/x86/mpegvideoenc_template.c
@@ -322,7 +322,7 @@ static int RENAME(dct_quantize)(MpegEncContext *s,
block[0x3E] = temp_block[0x3D]; block[0x33] = temp_block[0x36];
block[0x2F] = temp_block[0x2F]; block[0x37] = temp_block[0x37];
block[0x3B] = temp_block[0x3E]; block[0x3F] = temp_block[0x3F];
-}else{
+} else if (s->idsp.perm_type == FF_IDCT_PERM_NONE) {
if(last_non_zero_p1 <= 1) goto end;
block[0x01] = temp_block[0x01];
block[0x08] = temp_block[0x08]; block[0x10] = temp_block[0x10];
@@ -366,6 +366,12 @@ static int RENAME(dct_quantize)(MpegEncContext *s,
block[0x3D] = temp_block[0x3D]; block[0x36] = temp_block[0x36];
block[0x2F] = temp_block[0x2F]; block[0x37] = temp_block[0x37];
block[0x3E] = temp_block[0x3E]; block[0x3F] = temp_block[0x3F];
+} else {
+av_log(s, AV_LOG_DEBUG, "s->idsp.perm_type: %d\n",
+(int)s->idsp.perm_type);
+av_assert0(s->idsp.perm_type == FF_IDCT_PERM_NONE ||
+s->idsp.perm_type == FF_IDCT_PERM_LIBMPEG2 ||
+s->idsp.perm_type == FF_IDCT_PERM_SIMPLE);
}
end:
return last_non_zero_p1 - 1;
--
2.13.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?
On Fri, 16 Jun 2017 15:43:51 +0200 21na...@gmail.com wrote: > Le 16/06/2017 à 14:25, wm4 a écrit : > > On Fri, 16 Jun 2017 13:51:20 +0200 > > 21na...@gmail.com wrote: > > > >> Le 16/06/2017 à 12:55, wm4 a écrit : > >>> On Fri, 16 Jun 2017 02:32:10 +0200 > >>> 21na...@gmail.com wrote: > >>> > Hello, > > > I would like to know why the tag “DURATION” in Matroska files (.mkv) is > a necessity? Even mkvmerge lets the choice to use it or not with > “--enable-durations”, in addition it is written “Write durations for all > blocks. This will increase file size and does not offer any additional > value for players at the moment.” (source > https://mkvtoolnix.download/doc/mkvmerge.html#d4e535). > > Possibly linked to > http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=31852540d4fba0c4e8a16d0b3ddff08fc98e48fd > > >>> As far as I'm aware, the linked commit does not do the same thing as > >>> the mkvmerge option you pointed out. > >> Yes that is why I wrote “possibly”, also because this commit is the one > >> which adds the tag “DURATION” as a necessity, but a necessity that no > >> software seems to use and it is not even a standard in the Matroska’s > >> documentation if I am not mistaken. So the fact that it is a necessity > >> and not a choice is the main problem. > > Who says it's a necessity or standard? It's just what mkvmerge does. > > Since the patch is by google, I assume google has some use for it > > (there might also be a discussion about it on the ML). > > Sorry for the bad word “necessity”, it is better with “imposed”. Could > you let the choice to the user like mkvmerge with > “--disable-track-statistics-tags”? We could add a private option to the ffmpeg matroska muxer to disable writing this tag, and we could even switch that option off by default (so the tag isn't written unless the user explicitly requests it). Feel free to propose a patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?
Le 16/06/2017 à 16:04, wm4 a écrit : On Fri, 16 Jun 2017 15:43:51 +0200 21na...@gmail.com wrote: Le 16/06/2017 à 14:25, wm4 a écrit : On Fri, 16 Jun 2017 13:51:20 +0200 21na...@gmail.com wrote: Le 16/06/2017 à 12:55, wm4 a écrit : On Fri, 16 Jun 2017 02:32:10 +0200 21na...@gmail.com wrote: Hello, I would like to know why the tag “DURATION” in Matroska files (.mkv) is a necessity? Even mkvmerge lets the choice to use it or not with “--enable-durations”, in addition it is written “Write durations for all blocks. This will increase file size and does not offer any additional value for players at the moment.” (source https://mkvtoolnix.download/doc/mkvmerge.html#d4e535). Possibly linked to http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=31852540d4fba0c4e8a16d0b3ddff08fc98e48fd As far as I'm aware, the linked commit does not do the same thing as the mkvmerge option you pointed out. Yes that is why I wrote “possibly”, also because this commit is the one which adds the tag “DURATION” as a necessity, but a necessity that no software seems to use and it is not even a standard in the Matroska’s documentation if I am not mistaken. So the fact that it is a necessity and not a choice is the main problem. Who says it's a necessity or standard? It's just what mkvmerge does. Since the patch is by google, I assume google has some use for it (there might also be a discussion about it on the ML). Sorry for the bad word “necessity”, it is better with “imposed”. Could you let the choice to the user like mkvmerge with “--disable-track-statistics-tags”? We could add a private option to the ffmpeg matroska muxer to disable writing this tag, and we could even switch that option off by default (so the tag isn't written unless the user explicitly requests it). Feel free to propose a patch. I do not have the capacity for the moment to write patches for such a software but what you have written is exactly what I would like. I can create a bug report if needed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: use -x instead of -wN ..@ to strip assembly files
On 16 May 2017 at 19:50, James Darnley wrote: > On 2017-05-16 13:08, Rostislav Pehlivanov wrote: > > Reduces the amount of debugging information of external asm from > > uselessly verbose to informative enough. > > --- > > configure | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/configure b/configure > > index e4862f6a35..df849df14f 100755 > > --- a/configure > > +++ b/configure > > @@ -6185,8 +6185,7 @@ enabled rpath && add_ldlibflags -Wl,-rpath,$libdir > > test_ldflags -Wl,-Bsymbolic && append SHFLAGS -Wl,-Bsymbolic > > > > # add some strip flags > > -# -wN '..@*' is more selective than -x, but not available everywhere. > > -check_stripflags -wN \'..@*\' || check_stripflags -x > > +check_stripflags -x > > > > enabled neon_clobber_test && > > check_ldflags -Wl,--wrap,avcodec_open2 \ > > > > Look good. I'm in favour of this change. It does exactly what I was > (partly) advocating for in my email on Friday. > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Thanks, pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/1] ffmpeg: Switch cuvid to generic hwaccel
This is mechanically simple, but does the fact that additional command line arguments have to be used to get the same results count as a compatibility break? Do we need to fix that before we can actually make this change? Philip Langdale (1): ffmpeg: Switch cuvid to generic hwaccel Makefile | 1 - ffmpeg.h | 1 - ffmpeg_cuvid.c | 73 -- ffmpeg_opt.c | 4 ++-- 4 files changed, 2 insertions(+), 77 deletions(-) delete mode 100644 ffmpeg_cuvid.c -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/1] ffmpeg: Switch cuvid to generic hwaccel
With generic hwaccel, it is additionally necessary to specify the
output format. If this is not done, we'll end up downloading the
frames back and then re-uploading them.
For example:
ffmpeg -y -hwaccel cuvid -hwaccel_output_format cuda \
-c:v h264_cuvid -i sample.mp4 \
-c:v h264_nvenc -f rawvideo /dev/null
Signed-off-by: Philip Langdale
---
Makefile | 1 -
ffmpeg.h | 1 -
ffmpeg_cuvid.c | 73 --
ffmpeg_opt.c | 4 ++--
4 files changed, 2 insertions(+), 77 deletions(-)
delete mode 100644 ffmpeg_cuvid.c
diff --git a/Makefile b/Makefile
index ea90ec8b44..7ba3868fa1 100644
--- a/Makefile
+++ b/Makefile
@@ -37,7 +37,6 @@ OBJS-ffmpeg-$(CONFIG_LIBMFX) += ffmpeg_qsv.o
ifndef CONFIG_VIDEOTOOLBOX
OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
endif
-OBJS-ffmpeg-$(CONFIG_CUVID) += ffmpeg_cuvid.o
OBJS-ffmpeg-$(HAVE_DXVA2_LIB) += ffmpeg_dxva2.o
OBJS-ffserver += ffserver_config.o
diff --git a/ffmpeg.h b/ffmpeg.h
index c3854bcb4a..fa81427471 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -665,7 +665,6 @@ int dxva2_init(AVCodecContext *s);
int vda_init(AVCodecContext *s);
int videotoolbox_init(AVCodecContext *s);
int qsv_init(AVCodecContext *s);
-int cuvid_init(AVCodecContext *s);
HWDevice *hw_device_get_by_name(const char *name);
int hw_device_init_from_string(const char *arg, HWDevice **dev);
diff --git a/ffmpeg_cuvid.c b/ffmpeg_cuvid.c
deleted file mode 100644
index 3ff3b40f17..00
--- a/ffmpeg_cuvid.c
+++ /dev/null
@@ -1,73 +0,0 @@
-/*
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#include "libavutil/hwcontext.h"
-#include "libavutil/pixdesc.h"
-
-#include "ffmpeg.h"
-
-static void cuvid_uninit(AVCodecContext *avctx)
-{
-InputStream *ist = avctx->opaque;
-av_buffer_unref(&ist->hw_frames_ctx);
-}
-
-int cuvid_init(AVCodecContext *avctx)
-{
-InputStream *ist = avctx->opaque;
-AVHWFramesContext *frames_ctx;
-int ret;
-
-av_log(avctx, AV_LOG_VERBOSE, "Initializing cuvid hwaccel\n");
-
-if (!hw_device_ctx) {
-ret = av_hwdevice_ctx_create(&hw_device_ctx, AV_HWDEVICE_TYPE_CUDA,
- ist->hwaccel_device, NULL, 0);
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR, "Error creating a CUDA device\n");
-return ret;
-}
-}
-
-av_buffer_unref(&ist->hw_frames_ctx);
-ist->hw_frames_ctx = av_hwframe_ctx_alloc(hw_device_ctx);
-if (!ist->hw_frames_ctx) {
-av_log(avctx, AV_LOG_ERROR, "Error creating a CUDA frames context\n");
-return AVERROR(ENOMEM);
-}
-
-frames_ctx = (AVHWFramesContext*)ist->hw_frames_ctx->data;
-
-frames_ctx->format = AV_PIX_FMT_CUDA;
-frames_ctx->sw_format = avctx->sw_pix_fmt;
-frames_ctx->width = avctx->width;
-frames_ctx->height = avctx->height;
-
-av_log(avctx, AV_LOG_DEBUG, "Initializing CUDA frames context: sw_format =
%s, width = %d, height = %d\n",
- av_get_pix_fmt_name(frames_ctx->sw_format), frames_ctx->width,
frames_ctx->height);
-
-ret = av_hwframe_ctx_init(ist->hw_frames_ctx);
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR, "Error initializing a CUDA frame pool\n");
-return ret;
-}
-
-ist->hwaccel_uninit = cuvid_uninit;
-
-return 0;
-}
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index bb6001f534..6dc4ad43d2 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -91,8 +91,8 @@ const HWAccel hwaccels[] = {
AV_HWDEVICE_TYPE_VAAPI },
#endif
#if CONFIG_CUVID
-{ "cuvid", cuvid_init, HWACCEL_CUVID, AV_PIX_FMT_CUDA,
- AV_HWDEVICE_TYPE_NONE },
+{ "cuvid", hwaccel_decode_init, HWACCEL_CUVID, AV_PIX_FMT_CUDA,
+ AV_HWDEVICE_TYPE_CUDA },
#endif
{ 0 },
};
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/file: increase max packet size to 256k for written files
On 05.06.2017 19:16, Marton Balint wrote: Another huge performance improvement when using SMB/CIFS as output. Signed-off-by: Marton Balint --- libavformat/file.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavformat/file.c b/libavformat/file.c index 264542a36a..ae7231a484 100644 --- a/libavformat/file.c +++ b/libavformat/file.c @@ -227,6 +227,11 @@ static int file_open(URLContext *h, const char *filename, int flags) h->is_streamed = !fstat(fd, &st) && S_ISFIFO(st.st_mode); +/* Buffer writes more than the default 32k to improve throughput especially + * with networked file systems */ +if (!h->is_streamed && flags & AVIO_FLAG_WRITE) +h->max_packet_size = 262144; + return 0; } My tests show ~50% improved throughput rates. LGTM, but I'm not the maintainer of this file. Thanks, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/x86/mpegenc: support transpose permuation type
On Fri, Jun 16, 2017 at 03:53:28PM +0200, James Darnley wrote: > --- > libavcodec/x86/mpegvideoenc_template.c | 47 > +- > 1 file changed, 46 insertions(+), 1 deletion(-) Are these 2 with the other patchset intended to give exactly the same output ? for example: (with the 2 patches and the previously problematic one) ./ffmpeg -i ~/tickets/5311/TOON.AVI -flags +bitexact file.avi ./ffmpeg-try -i ~/tickets/5311/TOON.AVI -flags +bitexact file-new.avi -rw-r- 1 michael michael 9124822 Jun 16 17:45 file.avi -rw-r- 1 michael michael 9124874 Jun 16 17:46 file-new.avi source file should be at: https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU (link from ticket) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/x86/mpegenc: check IDCT permutation type is a valid value
On Fri, Jun 16, 2017 at 03:53:27PM +0200, James Darnley wrote:
> ---
> libavcodec/x86/mpegvideoenc_template.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/x86/mpegvideoenc_template.c
> b/libavcodec/x86/mpegvideoenc_template.c
> index b2512744ca..3ce72e1367 100644
> --- a/libavcodec/x86/mpegvideoenc_template.c
> +++ b/libavcodec/x86/mpegvideoenc_template.c
> @@ -322,7 +322,7 @@ static int RENAME(dct_quantize)(MpegEncContext *s,
> block[0x3E] = temp_block[0x3D]; block[0x33] = temp_block[0x36];
> block[0x2F] = temp_block[0x2F]; block[0x37] = temp_block[0x37];
> block[0x3B] = temp_block[0x3E]; block[0x3F] = temp_block[0x3F];
> -}else{
> +} else if (s->idsp.perm_type == FF_IDCT_PERM_NONE) {
> if(last_non_zero_p1 <= 1) goto end;
> block[0x01] = temp_block[0x01];
> block[0x08] = temp_block[0x08]; block[0x10] = temp_block[0x10];
> @@ -366,6 +366,12 @@ static int RENAME(dct_quantize)(MpegEncContext *s,
> block[0x3D] = temp_block[0x3D]; block[0x36] = temp_block[0x36];
> block[0x2F] = temp_block[0x2F]; block[0x37] = temp_block[0x37];
> block[0x3E] = temp_block[0x3E]; block[0x3F] = temp_block[0x3F];
> +} else {
> +av_log(s, AV_LOG_DEBUG, "s->idsp.perm_type: %d\n",
> +(int)s->idsp.perm_type);
> +av_assert0(s->idsp.perm_type == FF_IDCT_PERM_NONE ||
> +s->idsp.perm_type == FF_IDCT_PERM_LIBMPEG2 ||
> +s->idsp.perm_type == FF_IDCT_PERM_SIMPLE);
> }
you could add the assert into the existing else case
that would be slightly simpler and might avoid a conditional branch
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4
On Thu, Jun 15, 2017 at 03:50:31PM -0400, Ronald S. Bultje wrote: > From: Anton Mitrofanov > > Use the correct ctxIdxInc calculation for coded_block_flag. > Keep old behavior for old versions of x264 for backward compatibility. > > Signed-off-by: Ronald S. Bultje > --- > libavcodec/h264_cabac.c | 47 +-- > 1 file changed, 33 insertions(+), 14 deletions(-) patchset should be ok if tested against some reference also do we have some file/reference i should upload for a fate test? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/shorten: Sanity check maxnlpc
On Fri, Jun 09, 2017 at 03:14:12AM +0200, Michael Niedermayer wrote: > Fixes OOM > Fixes: 2131/clusterfuzz-testcase-minimized-4718045157130240 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/shorten.c | 4 > 1 file changed, 4 insertions(+) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/wavpack: Change wp_log2() to unsigned
On Fri, Jun 09, 2017 at 06:47:52PM +0200, Michael Niedermayer wrote: > Fixes: runtime error: signed integer overflow: 2143315325 + 4186162 cannot be > represented in type 'int' > Fixes: 2134/clusterfuzz-testcase-minimized-4619258405322752 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/wavpack.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/x86/mpegenc: support transpose permuation type
On 2017-06-16 17:48, Michael Niedermayer wrote: > On Fri, Jun 16, 2017 at 03:53:28PM +0200, James Darnley wrote: >> --- >> libavcodec/x86/mpegvideoenc_template.c | 47 >> +- >> 1 file changed, 46 insertions(+), 1 deletion(-) > > Are these 2 with the other patchset intended to give exactly the same > output ? > > for example: (with the 2 patches and the previously problematic one) > ./ffmpeg -i ~/tickets/5311/TOON.AVI -flags +bitexact file.avi > ./ffmpeg-try -i ~/tickets/5311/TOON.AVI -flags +bitexact file-new.avi > > -rw-r- 1 michael michael 9124822 Jun 16 17:45 file.avi > -rw-r- 1 michael michael 9124874 Jun 16 17:46 file-new.avi Thank you. The intention was that all 8 patches should give identical output to either the C or the MMX or both. Ronald says he has modeled his "hacks" based on the C because it is much clearer than the MMX. Barring any remaining bugs in my/our new code we would expect it to be identical to the C. With this sample I do infarct get identical results. For you I think these should give identical results > ./ffmpeg-try -i ~/tickets/5311/TOON.AVI -flags +bitexact -idct simple file.avi > ./ffmpeg-try -i ~/tickets/5311/TOON.AVI -flags +bitexact -idct simpleauto > file.avi The first should use the C and the second should use the new SSE2 (or AVX depending on your CPU). This could be an issue with the MMX function raising its head. MMX was the old default choice. Ronald and I are investigating. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/htmlsubtitles: skip newline characters at the beginning of the subtitle
We can have a certain number of newline characters at the very beginning
of the subtitles. We must skip them to get the correct result.
---
libavcodec/htmlsubtitles.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
index 16295da..b144aaa 100644
--- a/libavcodec/htmlsubtitles.c
+++ b/libavcodec/htmlsubtitles.c
@@ -62,6 +62,9 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, const
char *in)
strcpy(stack[0].param[PARAM_COLOR], "{\\c}");
strcpy(stack[0].param[PARAM_FACE], "{\\fn}");
+while (*in && (*in == '\r' || *in == '\n'))
+in++;
+
for (; !end && *in; in++) {
switch (*in) {
case '\r':
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/htmlsubtitles: skip newline characters at the beginning of the subtitle
Info about this patch:
Working with one video, I noticed that ffmpeg incorrectly extracts out
subtitles. Some subtitles have disappeared.
I have a video file as Matroska (.mkv) container, subtitles are there in
the SubRip (.srt) format.
Output of `ffmpeg`: https://pastebin.com/raw/vyiMNFbe
Output of my Matroska parser: https://pastebin.com/raw/8XsXkm0C
Output of `mkvextract`: https://pastebin.com/raw/7K7nkwsd
When I open the .mkv file in VLC Player, these magical subtitles are
displayed correctly.
But of all the extracted subtitle files, only the second file works
correctly (from my parser) in VLC, in other 2 files these subtitle lines
have dissapeared.
Therefore, I suggest deleting the newline characters at the beginning of
the line, and working on. FATE tests works without error.
2017-06-16 21:23 GMT+03:00 Evgeny Shulgin :
> We can have a certain number of newline characters at the very beginning
> of the subtitles. We must skip them to get the correct result.
> ---
> libavcodec/htmlsubtitles.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> index 16295da..b144aaa 100644
> --- a/libavcodec/htmlsubtitles.c
> +++ b/libavcodec/htmlsubtitles.c
> @@ -62,6 +62,9 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst,
> const char *in)
> strcpy(stack[0].param[PARAM_COLOR], "{\\c}");
> strcpy(stack[0].param[PARAM_FACE], "{\\fn}");
>
> +while (*in && (*in == '\r' || *in == '\n'))
> +in++;
> +
> for (; !end && *in; in++) {
> switch (*in) {
> case '\r':
> --
> 2.7.4
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/1] ffmpeg: Switch cuvid to generic hwaccel
Am 16.06.2017 um 16:41 schrieb Philip Langdale: This is mechanically simple, but does the fact that additional command line arguments have to be used to get the same results count as a compatibility break? Do we need to fix that before we can actually make this change? I'd consider that as a breaking change, even though things don't "break", it results in unexpected behavior that is not obvious. Philip Langdale (1): ffmpeg: Switch cuvid to generic hwaccel Makefile | 1 - ffmpeg.h | 1 - ffmpeg_cuvid.c | 73 -- ffmpeg_opt.c | 4 ++-- 4 files changed, 2 insertions(+), 77 deletions(-) delete mode 100644 ffmpeg_cuvid.c ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] fate: add test of -idct simpleauto
On Thu, Jun 15, 2017 at 03:34:21PM +0200, James Darnley wrote: > --- > tests/fate/video.mak | 3 +++ > tests/ref/fate/idct-simpleauto | 27 +++ > 2 files changed, 30 insertions(+) > create mode 100644 tests/ref/fate/idct-simpleauto fails on ARM TESTidct-simpleauto --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/idct-simpleauto 2017-06-16 20:13:43.949944505 +0200 +++ tests/data/fate/idct-simpleauto 2017-06-16 20:22:50.613951024 +0200 @@ -3,25 +3,25 @@ #codec_id 0: rawvideo #dimensions 0: 716x236 #sar 0: 1/1 -0, 2, 2,1, 253464, 0xc51a46f9 -0, 4, 4,1, 253464, 0xd0661651 -0, 5, 5,1, 253464, 0x38a213b3 -0, 6, 6,1, 253464, 0x038a5118 -0, 7, 7,1, 253464, 0xebd8de64 -0, 8, 8,1, 253464, 0x0b319ee0 -0, 9, 9,1, 253464, 0x37b03a45 -0, 10, 10,1, 253464, 0x5f9c89ae -0, 11, 11,1, 253464, 0x88ad9c08 -0, 12, 12,1, 253464, 0x387198bc -0, 13, 13,1, 253464, 0xf3933eb6 -0, 14, 14,1, 253464, 0x9bd27b98 -0, 15, 15,1, 253464, 0x9442c538 -0, 16, 16,1, 253464, 0x330be2a4 -0, 17, 17,1, 253464, 0xb4b8c1df -0, 18, 18,1, 253464, 0xc97ded34 -0, 19, 19,1, 253464, 0xcad936e0 -0, 20, 20,1, 253464, 0x11a2850d -0, 21, 21,1, 253464, 0x2545ad23 -0, 22, 22,1, 253464, 0xa5e17c47 -0, 23, 23,1, 253464, 0x39452689 -0, 24, 24,1, 253464, 0x1daefd72 +0, 2, 2,1, 253464, 0xdb0246f3 +0, 4, 4,1, 253464, 0x342f1641 +0, 5, 5,1, 253464, 0x2d5413a4 +0, 6, 6,1, 253464, 0x48da510b +0, 7, 7,1, 253464, 0xdb10de4b +0, 8, 8,1, 253464, 0x5ffb9ecf +0, 9, 9,1, 253464, 0xa6dc3a37 +0, 10, 10,1, 253464, 0x6deb899d +0, 11, 11,1, 253464, 0x117a9bff +0, 12, 12,1, 253464, 0x1eeb98b2 +0, 13, 13,1, 253464, 0xbd8f3eb1 +0, 14, 14,1, 253464, 0x094d7b95 +0, 15, 15,1, 253464, 0x7a99c534 +0, 16, 16,1, 253464, 0x25c6e29e +0, 17, 17,1, 253464, 0x262dc1da +0, 18, 18,1, 253464, 0x3af2ed2f +0, 19, 19,1, 253464, 0xb13036dc +0, 20, 20,1, 253464, 0xfab78509 +0, 21, 21,1, 253464, 0x96ecad20 +0, 22, 22,1, 253464, 0x028f7c44 +0, 23, 23,1, 253464, 0x95e52686 +0, 24, 24,1, 253464, 0x7a4efd6f Test idct-simpleauto failed. Look at tests/data/fate/idct-simpleauto.err for details. make: *** [fate-idct-simpleauto] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/1] ffmpeg: Switch cuvid to generic hwaccel
On Fri, 16 Jun 2017 20:31:14 +0200 Timo Rothenpieler wrote: > Am 16.06.2017 um 16:41 schrieb Philip Langdale: > > This is mechanically simple, but does the fact that additional command line > > arguments have to be used to get the same results count as a compatibility > > break? Do we need to fix that before we can actually make this change? > > I'd consider that as a breaking change, even though things don't > "break", it results in unexpected behavior that is not obvious. Probably, but it's also slightly saner in general if you consider that a user could add video filters. Currently, hwaccel filters and normal filters are completely different beasts, so the user needs to be aware of the difference, and select the appropriate mode. So depending on whether you output hw surfaces by default, you'll break hw filters or sw filters by default. Making sure sw filters work by default seems like the better choice. But yes, maybe we could rename the hwaccel just so that users of the old hwaccel become aware of the change. You could even keep the old hwaccel name, and make it somehow override the -hwaccel_output_format option and print a warning, in case you care enough for compatibility in this case. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web - src/contact - added link to SuperUser forum
On Wed, 07 Jun 2017 23:37:40 -0800 Lou Logan wrote: > LGTM, but I can't push anything until after June 15. Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/htmlsubtitles: skip newline characters at the beginning of the subtitle
On Fri, 16 Jun 2017 21:30:44 +0300 Evgeny Shulgin wrote: > Info about this patch: > > Working with one video, I noticed that ffmpeg incorrectly extracts out > subtitles. Some subtitles have disappeared. > I have a video file as Matroska (.mkv) container, subtitles are there in > the SubRip (.srt) format. > > Output of `ffmpeg`: https://pastebin.com/raw/vyiMNFbe > Output of my Matroska parser: https://pastebin.com/raw/8XsXkm0C > Output of `mkvextract`: https://pastebin.com/raw/7K7nkwsd > > When I open the .mkv file in VLC Player, these magical subtitles are > displayed correctly. > But of all the extracted subtitle files, only the second file works > correctly (from my parser) in VLC, in other 2 files these subtitle lines > have dissapeared. > > Therefore, I suggest deleting the newline characters at the beginning of > the line, and working on. FATE tests works without error. Most of this should probably go into the commit message (without pastebin links, and instead with excerpts of interesting subtitle lines). Anyway, I don't understand why this makes subtitle lines actually disappear? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] fate: add test of -idct simpleauto
On 2017-06-16 20:31, Michael Niedermayer wrote: > On Thu, Jun 15, 2017 at 03:34:21PM +0200, James Darnley wrote: >> --- >> tests/fate/video.mak | 3 +++ >> tests/ref/fate/idct-simpleauto | 27 +++ >> 2 files changed, 30 insertions(+) >> create mode 100644 tests/ref/fate/idct-simpleauto > > fails on ARM > Thank you for testing. I what do do about that after I'm done with my current debugging. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/htmlsubtitles: skip newline characters at the beginning of the subtitle
> Anyway, I don't understand why this makes subtitle lines actually
> disappear?
Because SubRip format does not allow to have empty lines, that is:
1. Subtitle text itself on one or more lines
2. A blank line containing no text, indicating the end of this subtitle
So, when we have '\n' at the start or two '\n'-s in a row, the code
interrupts the recording of sub. But in this video we could get subtitles
as "\r\n\r\n\r\nСкандинавия", and this video is played perfectly in VLC
player like it's "Скандинавия". So we had to deal with it. Anyway, this
.mkv was recorded successfully a couple of years ago:
Metadata:
encoder : libebml v1.3.0 + libmatroska v1.4.1
creation_time : 2015-05-30T16:56:01.00Z
_STATISTICS_WRITING_APP: mkvmerge v7.0.0 ('Where We Going') 32bit built on
Jun 9 2014 15:08:34
> Most of this should probably go into the commit message
How can I edit the patch? Send the updated patch as attachment in the emal?
I don't see how can I do it on the patchwork site. Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/libssh: check the user provided a password before trying to use it
On 6/11/2017 2:47 PM, James Almer wrote:
> Fixes ticket #6413
>
> Signed-off-by: James Almer
> ---
> The public key authentication also tries to use the password variable. I
> don't know if NULL is valid in that case or not.
> Perhaps for that one it would be better to replace the current usage of
> legacy API instead.
Ping.
>
> libavformat/libssh.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/libssh.c b/libavformat/libssh.c
> index 49e92e7516..9e3d4da45e 100644
> --- a/libavformat/libssh.c
> +++ b/libavformat/libssh.c
> @@ -103,7 +103,7 @@ static av_cold int libssh_authentication(LIBSSHContext
> *libssh, const char *user
> }
> }
>
> -if (!authorized && (auth_methods & SSH_AUTH_METHOD_PASSWORD)) {
> +if (!authorized && password && (auth_methods &
> SSH_AUTH_METHOD_PASSWORD)) {
> if (ssh_userauth_password(libssh->session, NULL, password) ==
> SSH_AUTH_SUCCESS) {
> av_log(libssh, AV_LOG_DEBUG, "Authentication successful with
> password.\n");
> authorized = 1;
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/1] ffmpeg: Switch cuvid to generic hwaccel
On Fri, 16 Jun 2017 21:53:22 +0200 wm4 wrote: > On Fri, 16 Jun 2017 20:31:14 +0200 > Timo Rothenpieler wrote: > > > Am 16.06.2017 um 16:41 schrieb Philip Langdale: > > > This is mechanically simple, but does the fact that additional > > > command line arguments have to be used to get the same results > > > count as a compatibility break? Do we need to fix that before we > > > can actually make this change? > > > > I'd consider that as a breaking change, even though things don't > > "break", it results in unexpected behavior that is not obvious. > > Probably, but it's also slightly saner in general if you consider that > a user could add video filters. Currently, hwaccel filters and normal > filters are completely different beasts, so the user needs to be aware > of the difference, and select the appropriate mode. So depending on > whether you output hw surfaces by default, you'll break hw filters or > sw filters by default. Making sure sw filters work by default seems > like the better choice. > > But yes, maybe we could rename the hwaccel just so that users of the > old hwaccel become aware of the change. You could even keep the old > hwaccel name, and make it somehow override the -hwaccel_output_format > option and print a warning, in case you care enough for compatibility > in this case. We could use it as an opportunity to rename it to 'cuda' which is more accurate. Keeping the old specialised code for 'cuvid' would also ensure compatibility :-) --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/oggenc: add ogg_init() and ogg_free()
On 6/3/2017 2:39 PM, James Almer wrote: > On 5/28/2017 5:09 PM, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavformat/oggenc.c | 32 >> 1 file changed, 28 insertions(+), 4 deletions(-) >> > > Ping for this and the aiff one. > > I have a set of about 50 patches to do the same with almost every other > muxer, but i want to know if the approach is correct or not before > sending it. > The idea is making avformat_init_output() more useful and eventually > adapting ffmpeg.c to use it to initialize the muxers and do its thing > before the need to actually write the header comes up. No comments? I don't really feel like risking pushing 50+ patches without at least someone commenting on it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avformat/options: disable flush_packets as default
On Sun, 4 Jun 2017, Marton Balint wrote:
It is a huge performance improvement for encoding files with small packets
(e.g. wav) over SMB/CIFS.
Ping? Maybe enabling this unconditionally is also problematic for
protocols other than file? If that so, then how about making flush_packet
a tri state with -1 (auto) as default, and then similar to how
max_packet_size is handled define something in URLContext to be able to
set the flush preference on a protocol basis?
Thanks,
Marton
Signed-off-by: Marton Balint
---
libavformat/mux.c | 4 ++--
libavformat/options_table.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index e1e49a81be..540ac56c3f 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -479,7 +479,7 @@ static int write_header_internal(AVFormatContext *s)
s->internal->write_header_ret = ret;
if (ret < 0)
return ret;
-if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
+if ((s->flush_packets || s->flags & AVFMT_FLAG_FLUSH_PACKETS) && s->pb &&
s->pb->error >= 0)
avio_flush(s->pb);
}
s->internal->header_written = 1;
@@ -772,7 +772,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
if (s->pb && ret >= 0) {
-if (s->flush_packets && s->flags & AVFMT_FLAG_FLUSH_PACKETS)
+if (s->flush_packets || s->flags & AVFMT_FLAG_FLUSH_PACKETS)
avio_flush(s->pb);
if (s->pb->error < 0)
ret = s->pb->error;
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index 0c1915d6d4..b72f72b845 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -39,7 +39,7 @@ static const AVOption avformat_options[] = {
{"probesize", "set probing size", OFFSET(probesize), AV_OPT_TYPE_INT64, {.i64 =
500 }, 32, INT64_MAX, D},
{"formatprobesize", "number of bytes to probe file format",
OFFSET(format_probesize), AV_OPT_TYPE_INT, {.i64 = PROBE_BUF_MAX}, 0, INT_MAX-1, D},
{"packetsize", "set packet size", OFFSET(packet_size), AV_OPT_TYPE_INT, {.i64 =
DEFAULT }, 0, INT_MAX, E},
-{"fflags", NULL, OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = AVFMT_FLAG_FLUSH_PACKETS |
AVFMT_FLAG_AUTO_BSF }, INT_MIN, INT_MAX, D|E, "fflags"},
+{"fflags", NULL, OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = AVFMT_FLAG_AUTO_BSF },
INT_MIN, INT_MAX, D|E, "fflags"},
{"flush_packets", "reduce the latency by flushing out packets immediately", 0,
AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_FLUSH_PACKETS }, INT_MIN, INT_MAX, E, "fflags"},
{"ignidx", "ignore index", 0, AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_IGNIDX }, INT_MIN,
INT_MAX, D, "fflags"},
{"genpts", "generate pts", 0, AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_GENPTS }, INT_MIN,
INT_MAX, D, "fflags"},
@@ -85,7 +85,7 @@ static const AVOption avformat_options[] = {
{"use_wallclock_as_timestamps", "use wallclock as timestamps",
OFFSET(use_wallclock_as_timestamps), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, D},
{"skip_initial_bytes", "set number of bytes to skip before reading header and
frames", OFFSET(skip_initial_bytes), AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX-1, D},
{"correct_ts_overflow", "correct single timestamp overflows",
OFFSET(correct_ts_overflow), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, D},
-{"flush_packets", "enable flushing of the I/O context after each packet",
OFFSET(flush_packets), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, E},
+{"flush_packets", "enable flushing of the I/O context after each packet",
OFFSET(flush_packets), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, E},
{"metadata_header_padding", "set number of bytes to be written as padding in a
metadata header", OFFSET(metadata_header_padding), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX,
E},
{"output_ts_offset", "set output timestamp offset", OFFSET(output_ts_offset),
AV_OPT_TYPE_DURATION, {.i64 = 0}, -INT64_MAX, INT64_MAX, E},
{"max_interleave_delta", "maximum buffering duration for interleaving",
OFFSET(max_interleave_delta), AV_OPT_TYPE_INT64, { .i64 = 1000 }, 0, INT64_MAX, E },
--
2.12.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/rmenc: do not access AVIO write buffer directly
Signed-off-by: Marton Balint
---
libavformat/rmenc.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/libavformat/rmenc.c b/libavformat/rmenc.c
index f9821d1875..3bff4daf0a 100644
--- a/libavformat/rmenc.c
+++ b/libavformat/rmenc.c
@@ -72,14 +72,12 @@ static int rv10_write_header(AVFormatContext *ctx,
RMMuxContext *rm = ctx->priv_data;
AVIOContext *s = ctx->pb;
StreamInfo *stream;
-unsigned char *data_offset_ptr, *start_ptr;
const char *desc, *mimetype;
int nb_packets, packet_total_size, packet_max_size, size, packet_avg_size,
i;
-int bit_rate, v, duration, flags, data_pos;
+int bit_rate, v, duration, flags;
+int data_offset;
AVDictionaryEntry *tag;
-start_ptr = s->buf_ptr;
-
ffio_wfourcc(s, ".RMF");
avio_wb32(s,18); /* header size */
avio_wb16(s,0);
@@ -119,7 +117,7 @@ static int rv10_write_header(AVFormatContext *ctx,
avio_wb32(s, BUFFER_DURATION); /* preroll */
avio_wb32(s, index_pos); /* index offset */
/* computation of data the data offset */
-data_offset_ptr = s->buf_ptr;
+data_offset = avio_tell(s);
avio_wb32(s, 0); /* data offset : will be patched after */
avio_wb16(s, ctx->nb_streams);/* num streams */
flags = 1 | 2; /* save allowed & perfect play */
@@ -276,12 +274,11 @@ static int rv10_write_header(AVFormatContext *ctx,
}
/* patch data offset field */
-data_pos = s->buf_ptr - start_ptr;
-rm->data_pos = data_pos;
-data_offset_ptr[0] = data_pos >> 24;
-data_offset_ptr[1] = data_pos >> 16;
-data_offset_ptr[2] = data_pos >> 8;
-data_offset_ptr[3] = data_pos;
+rm->data_pos = avio_tell(s);
+if (avio_seek(s, data_offset, SEEK_SET) >= 0) {
+avio_wb32(s, rm->data_pos);
+avio_seek(s, rm->data_pos, SEEK_SET);
+}
/* data stream */
ffio_wfourcc(s, "DATA");
--
2.12.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] fate: use do_md5sum instead of the md5 protocol for md5 fate tests
The md5 protocol has no seek support, but some tests use seeks. This changes
the fate tests to actually create the output files and calculate the md5 on the
written files, which also makes the tests independent of the size of the output
buffers and output buffering in general.
Signed-off-by: Marton Balint
---
tests/fate-run.sh | 5 -
tests/fate/filter-audio.mak | 4 ++--
tests/fate/matroska.mak | 2 +-
tests/fate/wavpack.mak| 4 ++--
tests/ref/fate/binsub-mksenc | 2 +-
tests/ref/fate/mapchan-6ch-extract-2-downmix-mono | 2 +-
tests/ref/fate/mapchan-silent-mono| 2 +-
tests/ref/fate/mpeg4-bsf-unpack-bframes | 2 +-
tests/ref/fate/time_base | 2 +-
tests/ref/fate/v410enc| 2 +-
10 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 931150b5a6..20dae9ea13 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -143,7 +143,10 @@ crc(){
}
md5(){
-ffmpeg "$@" md5:
+encfile="${outdir}/${test}.out"
+cleanfiles=$encfile
+ffmpeg "$@" $encfile
+do_md5sum $encfile | awk '{print $1}'
}
pcm(){
diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 5d15b31e0b..8030641ed6 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -215,7 +215,7 @@ fate-filter-channelmap-one-int: SRC =
$(TARGET_PATH)/tests/data/asynth-44100-6.w
fate-filter-channelmap-one-int: tests/data/asynth-44100-6.wav
fate-filter-channelmap-one-int: CMD = md5 -i $(SRC) -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/channelmap_one_int -f wav -fflags
+bitexact
fate-filter-channelmap-one-int: CMP = oneline
-fate-filter-channelmap-one-int: REF = 428b8f9fac6d57147069b97335019ef5
+fate-filter-channelmap-one-int: REF = 8cfe553d65ed4696756d8c1b824fcdd3
FATE_FILTER_CHANNELMAP += fate-filter-channelmap-one-str
fate-filter-channelmap-one-str: tests/data/filtergraphs/channelmap_one_str
@@ -223,7 +223,7 @@ fate-filter-channelmap-one-str: SRC =
$(TARGET_PATH)/tests/data/asynth-44100-2.w
fate-filter-channelmap-one-str: tests/data/asynth-44100-2.wav
fate-filter-channelmap-one-str: CMD = md5 -i $(SRC) -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/channelmap_one_str -f wav -fflags
+bitexact
fate-filter-channelmap-one-str: CMP = oneline
-fate-filter-channelmap-one-str: REF = e788890db6a11c2fb29d7c4229072d49
+fate-filter-channelmap-one-str: REF = 0ea3052e482c95d5d3bd9da6dac1b5fa
FATE_AFILTER-$(call FILTERDEMDECENCMUX, CHANNELMAP, WAV, PCM_S16LE, PCM_S16LE,
WAV) += $(FATE_FILTER_CHANNELMAP)
diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak
index 48b710c26c..9e233cf510 100644
--- a/tests/fate/matroska.mak
+++ b/tests/fate/matroska.mak
@@ -4,7 +4,7 @@
FATE_MATROSKA-$(call DEMMUX, MATROSKA, MATROSKA) += fate-matroska-remux
fate-matroska-remux: CMD = md5 -i
$(TARGET_SAMPLES)/vp9-test-vectors/vp90-2-2pass-akiyo.webm -color_trc 4 -c:v
copy -fflags +bitexact -strict -2 -f matroska
fate-matroska-remux: CMP = oneline
-fate-matroska-remux: REF = 1ed49a4f2b6790357fac268938357353
+fate-matroska-remux: REF = 53be067cfaee3626d1c94b4a0fd5ac10
FATE_MATROSKA_FFPROBE-$(call ALLYES, MATROSKA_DEMUXER) +=
fate-matroska-spherical-mono
fate-matroska-spherical-mono: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
-show_entries stream_side_data_list -select_streams v -v 0
$(TARGET_SAMPLES)/mkv/spherical.mkv
diff --git a/tests/fate/wavpack.mak b/tests/fate/wavpack.mak
index 32ae3f6100..1cb414447c 100644
--- a/tests/fate/wavpack.mak
+++ b/tests/fate/wavpack.mak
@@ -91,12 +91,12 @@ fate-wavpack-matroskamode: CMD = md5 -i
$(TARGET_SAMPLES)/wavpack/special/matros
FATE_WAVPACK-$(call DEMMUX, WV, MATROSKA) += fate-wavpack-matroska_mux-mono
fate-wavpack-matroska_mux-mono: CMD = md5 -i
$(TARGET_SAMPLES)/wavpack/num_channels/mono_16bit_int.wv -c copy -fflags
+bitexact -f matroska
fate-wavpack-matroska_mux-mono: CMP = oneline
-fate-wavpack-matroska_mux-mono: REF = 11773e2a518edc788475f3880d849230
+fate-wavpack-matroska_mux-mono: REF = 31c0b4e71b532103bbfd2e284795cac1
FATE_WAVPACK-$(call DEMMUX, WV, MATROSKA) += fate-wavpack-matroska_mux-61
fate-wavpack-matroska_mux-61: CMD = md5 -i
$(TARGET_SAMPLES)/wavpack/num_channels/eva_2.22_6.1_16bit-partial.wv -c copy
-fflags +bitexact -f matroska
fate-wavpack-matroska_mux-61: CMP = oneline
-fate-wavpack-matroska_mux-61: REF = 9641abdf596c10c2e21bd9b026d4bade
+fate-wavpack-matroska_mux-61: REF = a0e5ad857d57a50869c21f1621e55674
FATE_SAMPLES_AVCONV += $(FATE_WAVPACK-yes)
fate-wavpack: $(FATE_WAVPACK-yes)
diff --git a/tests/ref/fate/binsub-mksenc b/tests/ref/fate/binsub-mksenc
index f247d9d22d..a0a58b880d 100644
--- a/tests/ref/fate/binsub-mksenc
+++ b/tests/ref/fate/binsub-mksenc
@@ -1 +1 @@
-f80f42e646fce972e73aa6d99dcfa470
+cdc96049a5aeaccec0126f1960
Re: [FFmpeg-devel] [PATCH 2/2] fate: use do_md5sum instead of the md5 protocol for md5 fate tests
On 6/16/2017 8:24 PM, Marton Balint wrote:
> The md5 protocol has no seek support, but some tests use seeks. This changes
> the fate tests to actually create the output files and calculate the md5 on
> the
> written files, which also makes the tests independent of the size of the
> output
> buffers and output buffering in general.
The fact md5() forced non seekable output came in handy to test certain
codepaths, especially in matroska. Perhaps you could instead add a new
fate-run.sh function for this change and port those tests that use
output formats that don't behave any different in non seekable output?
>
> Signed-off-by: Marton Balint
> ---
> tests/fate-run.sh | 5 -
> tests/fate/filter-audio.mak | 4 ++--
> tests/fate/matroska.mak | 2 +-
> tests/fate/wavpack.mak| 4 ++--
> tests/ref/fate/binsub-mksenc | 2 +-
> tests/ref/fate/mapchan-6ch-extract-2-downmix-mono | 2 +-
> tests/ref/fate/mapchan-silent-mono| 2 +-
> tests/ref/fate/mpeg4-bsf-unpack-bframes | 2 +-
> tests/ref/fate/time_base | 2 +-
> tests/ref/fate/v410enc| 2 +-
> 10 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index 931150b5a6..20dae9ea13 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -143,7 +143,10 @@ crc(){
> }
>
> md5(){
> -ffmpeg "$@" md5:
> +encfile="${outdir}/${test}.out"
> +cleanfiles=$encfile
> +ffmpeg "$@" $encfile
> +do_md5sum $encfile | awk '{print $1}'
> }
>
> pcm(){
> diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
> index 5d15b31e0b..8030641ed6 100644
> --- a/tests/fate/filter-audio.mak
> +++ b/tests/fate/filter-audio.mak
> @@ -215,7 +215,7 @@ fate-filter-channelmap-one-int: SRC =
> $(TARGET_PATH)/tests/data/asynth-44100-6.w
> fate-filter-channelmap-one-int: tests/data/asynth-44100-6.wav
> fate-filter-channelmap-one-int: CMD = md5 -i $(SRC) -filter_complex_script
> $(TARGET_PATH)/tests/data/filtergraphs/channelmap_one_int -f wav -fflags
> +bitexact
> fate-filter-channelmap-one-int: CMP = oneline
> -fate-filter-channelmap-one-int: REF = 428b8f9fac6d57147069b97335019ef5
> +fate-filter-channelmap-one-int: REF = 8cfe553d65ed4696756d8c1b824fcdd3
>
> FATE_FILTER_CHANNELMAP += fate-filter-channelmap-one-str
> fate-filter-channelmap-one-str: tests/data/filtergraphs/channelmap_one_str
> @@ -223,7 +223,7 @@ fate-filter-channelmap-one-str: SRC =
> $(TARGET_PATH)/tests/data/asynth-44100-2.w
> fate-filter-channelmap-one-str: tests/data/asynth-44100-2.wav
> fate-filter-channelmap-one-str: CMD = md5 -i $(SRC) -filter_complex_script
> $(TARGET_PATH)/tests/data/filtergraphs/channelmap_one_str -f wav -fflags
> +bitexact
> fate-filter-channelmap-one-str: CMP = oneline
> -fate-filter-channelmap-one-str: REF = e788890db6a11c2fb29d7c4229072d49
> +fate-filter-channelmap-one-str: REF = 0ea3052e482c95d5d3bd9da6dac1b5fa
>
> FATE_AFILTER-$(call FILTERDEMDECENCMUX, CHANNELMAP, WAV, PCM_S16LE,
> PCM_S16LE, WAV) += $(FATE_FILTER_CHANNELMAP)
>
> diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak
> index 48b710c26c..9e233cf510 100644
> --- a/tests/fate/matroska.mak
> +++ b/tests/fate/matroska.mak
> @@ -4,7 +4,7 @@
> FATE_MATROSKA-$(call DEMMUX, MATROSKA, MATROSKA) += fate-matroska-remux
> fate-matroska-remux: CMD = md5 -i
> $(TARGET_SAMPLES)/vp9-test-vectors/vp90-2-2pass-akiyo.webm -color_trc 4 -c:v
> copy -fflags +bitexact -strict -2 -f matroska
> fate-matroska-remux: CMP = oneline
> -fate-matroska-remux: REF = 1ed49a4f2b6790357fac268938357353
> +fate-matroska-remux: REF = 53be067cfaee3626d1c94b4a0fd5ac10
>
> FATE_MATROSKA_FFPROBE-$(call ALLYES, MATROSKA_DEMUXER) +=
> fate-matroska-spherical-mono
> fate-matroska-spherical-mono: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
> -show_entries stream_side_data_list -select_streams v -v 0
> $(TARGET_SAMPLES)/mkv/spherical.mkv
> diff --git a/tests/fate/wavpack.mak b/tests/fate/wavpack.mak
> index 32ae3f6100..1cb414447c 100644
> --- a/tests/fate/wavpack.mak
> +++ b/tests/fate/wavpack.mak
> @@ -91,12 +91,12 @@ fate-wavpack-matroskamode: CMD = md5 -i
> $(TARGET_SAMPLES)/wavpack/special/matros
> FATE_WAVPACK-$(call DEMMUX, WV, MATROSKA) += fate-wavpack-matroska_mux-mono
> fate-wavpack-matroska_mux-mono: CMD = md5 -i
> $(TARGET_SAMPLES)/wavpack/num_channels/mono_16bit_int.wv -c copy -fflags
> +bitexact -f matroska
> fate-wavpack-matroska_mux-mono: CMP = oneline
> -fate-wavpack-matroska_mux-mono: REF = 11773e2a518edc788475f3880d849230
> +fate-wavpack-matroska_mux-mono: REF = 31c0b4e71b532103bbfd2e284795cac1
>
> FATE_WAVPACK-$(call DEMMUX, WV, MATROSKA) += fate-wavpack-matroska_mux-61
> fate-wavpack-matroska_mux-61: CMD = md5 -i
> $(TARGET_SAMPLES)/wavpack/num_channels/eva_2.22_6.1_16bit-partial.wv -c copy
> -fflags +bitexac
Re: [FFmpeg-devel] [PATCH 2/2] fate: use do_md5sum instead of the md5 protocol for md5 fate tests
On Fri, 16 Jun 2017, James Almer wrote: On 6/16/2017 8:24 PM, Marton Balint wrote: The md5 protocol has no seek support, but some tests use seeks. This changes the fate tests to actually create the output files and calculate the md5 on the written files, which also makes the tests independent of the size of the output buffers and output buffering in general. The fact md5() forced non seekable output came in handy to test certain codepaths, especially in matroska. Perhaps you could instead add a new fate-run.sh function for this change and port those tests that use output formats that don't behave any different in non seekable output? IMHO when most people are using the md5 test, they are typically not aware the lack of seek support. Considering how many md5 tests are used all over fate, I'd rather create a test named md5pipe which uses the md5 protocol (this name better reflects the streaming property of the test as well), and change the matroska tests to use that, if you really want to test the streaming output. BTW in the matroska muxer, should a non-seekable output and using the -live option produce the same result? Because there are some places in the code which only checks if -live is set, and I am not sure if that is intentional. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] fate: use do_md5sum instead of the md5 protocol for md5 fate tests
On 6/16/2017 9:36 PM, Marton Balint wrote: > > On Fri, 16 Jun 2017, James Almer wrote: > >> On 6/16/2017 8:24 PM, Marton Balint wrote: >>> The md5 protocol has no seek support, but some tests use seeks. This >>> changes >>> the fate tests to actually create the output files and calculate the >>> md5 on the >>> written files, which also makes the tests independent of the size of >>> the output >>> buffers and output buffering in general. >> >> The fact md5() forced non seekable output came in handy to test certain >> codepaths, especially in matroska. Perhaps you could instead add a new >> fate-run.sh function for this change and port those tests that use >> output formats that don't behave any different in non seekable output? >> > > IMHO when most people are using the md5 test, they are typically not > aware the lack of seek support. Considering how many md5 tests are used > all over fate, I'd rather create a test named md5pipe which uses the md5 > protocol (this name better reflects the streaming property of the test > as well), and change the matroska tests to use that, if you really want > to test the streaming output. Yes, that also works. The idea is to keep a working fate function that can easily let us test muxers when using non seekable output. > > BTW in the matroska muxer, should a non-seekable output and using the > -live option produce the same result? Because there are some places in > the code which only checks if -live is set, and I am not sure if that is > intentional. Probably not. All the code related to the -live option is nowadays somwhat precarious after further development and merges took place in the muxer. > > Regards, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
