Re: [FFmpeg-devel] [PATCH] libavformat/cache: don't treat 0 as EOF
Le septidi 17 prairial, an CCXXV, Daniel Kucera a écrit : > Signed-off-by: Daniel Kucera > --- > libavformat/cache.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) I think this is correct, but I do not maintain that file and the code has spaghetti properties. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/subfile: return AVERROR_EOF on EOF
Le septidi 17 prairial, an CCXXV, Daniel Kucera a écrit : > Signed-off-by: Daniel Kucera > --- > libavformat/subfile.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/subfile.c b/libavformat/subfile.c > index fa971e1902..497cf85211 100644 > --- a/libavformat/subfile.c > +++ b/libavformat/subfile.c > @@ -102,7 +102,7 @@ static int subfile_read(URLContext *h, unsigned char > *buf, int size) > int ret; > > if (rest <= 0) > -return 0; > +return AVERROR_EOF; > size = FFMIN(size, rest); > ret = ffurl_read(c->h, buf, size); > if (ret >= 0) LGTM, thanks. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/file: return AVERROR_EOF on EOF
Le septidi 17 prairial, an CCXXV, Daniel Kucera a écrit : > Signed-off-by: Daniel Kucera > --- > libavformat/file.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavformat/file.c b/libavformat/file.c > index 264542a36a..1fb83851c0 100644 > --- a/libavformat/file.c > +++ b/libavformat/file.c > @@ -112,6 +112,8 @@ static int file_read(URLContext *h, unsigned char *buf, > int size) > ret = read(c->fd, buf, size); > if (ret == 0 && c->follow) > return AVERROR(EAGAIN); > +if (ret == 0) > +return AVERROR_EOF; > return (ret == -1) ? AVERROR(errno) : ret; > } > LGTM, but I do not maintain that file. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/wtvdec: return AVERROR_EOF on EOF
Le septidi 17 prairial, an CCXXV, Daniel Kucera a écrit :
> Signed-off-by: Daniel Kucera
> ---
> libavformat/wtvdec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
> index 3ac4501306..ee19fd84da 100644
> --- a/libavformat/wtvdec.c
> +++ b/libavformat/wtvdec.c
> @@ -65,7 +65,7 @@ static int64_t seek_by_sector(AVIOContext *pb, int64_t
> sector, int64_t offset)
> }
>
> /**
> - * @return bytes read, 0 on end of file, or <0 on error
> + * @return bytes read, AVERROR_EOF on end of file, or <0 on error
> */
> static int wtvfile_read_packet(void *opaque, uint8_t *buf, int buf_size)
> {
> @@ -76,7 +76,7 @@ static int wtvfile_read_packet(void *opaque, uint8_t *buf,
> int buf_size)
> if (wf->error || pb->error)
> return -1;
> if (wf->position >= wf->length || avio_feof(pb))
> -return 0;
> +return AVERROR_EOF;
>
> buf_size = FFMIN(buf_size, wf->length - wf->position);
> while(nread < buf_size) {
> --
> 2.11.0
LGTM, but I do not maintain that file.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On Thu, 15 Jun 2017 09:42:48 +0530 Gyan wrote: > On Thu, Jun 15, 2017 at 4:59 AM, wm4 wrote: > > > > > > av_log(NULL, AV_LOG_WARNING, > > > "No pixel format specified, %s for H.264 encoding > > chosen.\n" > > > "Use -pix_fmt yuv420p for compatibility with > > outdated media players.\n", > > > > This warning shouldn't exist in the first place. It's dumb and > > incorrect. > > > > It could (and should) be better worded but it's needed. There's a > semi-regular influx of questions at the SE sites where users complain about > their ffmpeg output having audio but 'no video' or having a video stream > which only plays in certain players. I can only imagine that the presence > of the warning cuts down on the frequency of those queries, but also > there's likely a countervailing effect by the use of the term 'outdated' > which implies that if one has a recent version of a player, this warning > can be ignored. When, in fact, browser-based players don't decode anything > other than yuv420p , whichever version, and same's the case for many > players on WIndows, including atleast WMP on Win7. It's wrong and dumb because the pixfmt is not enough to tell whether the encoder will produce a file with w widely compatible profile. There is also a large number of other cases, where ffmpeg CLI would produce files that are not widely compatible (because it uses e.g. an obscure container/codec combination), and it wouldn't warn. I think what you really want is either - defaulting h264 encoding to Main or High profile only - proper presets, that make sure the output is compatible to a certain class of consumers (and make them usable, unless the current horseshit) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On Thu, Jun 15, 2017 at 3:04 PM, wm4 wrote: > It's wrong and dumb because the pixfmt is not enough to tell whether > the encoder will produce a file with w widely compatible profile. > yuv420p is not sufficient to ensure compatibility but !yuv420p is sufficient to ensure incompatibility (with browsers and most players). > I think what you really want is either > - defaulting h264 encoding to Main or High profile only > libx264 already defaults to High, which doesn't prevent non-yuv420p output e.g. encoding of a PNG sequence. Presets bring their other baggage along with them, which the user may not want. If the user knew how to select or set presets, they would know which pixel format is required. The primary audience for this warning is the lay or occasional user, who isn't manually setting the profile or the pix_fmt, and and is likely to get tripped up if the input is not yuv420p. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On Thu, 15 Jun 2017 16:12:00 +0530 Gyan wrote: > On Thu, Jun 15, 2017 at 3:04 PM, wm4 wrote: > > > > It's wrong and dumb because the pixfmt is not enough to tell whether > > the encoder will produce a file with w widely compatible profile. > > > > yuv420p is not sufficient to ensure compatibility but !yuv420p is > sufficient to ensure incompatibility (with browsers and most players). That doesn't conflict with what I said. > > > I think what you really want is either > > - defaulting h264 encoding to Main or High profile only > > > > libx264 already defaults to High, which doesn't prevent non-yuv420p output > e.g. encoding of a PNG sequence. "non-yuv420p output" doesn't make ANY sense. You don't know and don't have to care what some random third party decoders will output. Many indeed never output yuv420p, but use nv12 and even packed or tiled formats. The same is true for encoder input. As the patch shows, not all encoders are restricted to yuv420p even when encoding only to the simple profiles. Forcing the "High" or maybe "Main" profile is enough to ensure compatibility. That is what profiles were designed for. Applying your bogus "non-yuv420p output" idea on libavcodec's decoder, libavcodec would indeed never output non-yuv420p for High profile input (unless you use hwaccel, then it would most likely output nv12). > Presets bring their other baggage along with them, which the user may not > want. If the user knew how to select or set presets, they would know which > pixel format is required. The primary audience for this warning is the lay > or occasional user, who isn't manually setting the profile or the pix_fmt, > and and is likely to get tripped up if the input is not yuv420p. By default, ffmpeg CLI's design is something like "fuck the user". I'm not sure what you are even arguing about. The situation is bad, and the warning is a shitty insufficient hack trying to prevent damage caused by that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On Thu, Jun 15, 2017 at 01:14:34PM +0200, wm4 wrote: [...] > By default, ffmpeg CLI's design is something like "fuck the user". I'm This is not true, nor are statments like this useful. Whatever problem there is, it is not and never was FFmpegs design to fuck the user. Quite the opposite ... If problems exist they should be fixed. If they cannot be fixed they should be at least documented on our issue tracker. Without this, such rants are off topic as they cannot serve to improve FFmpeg. Noone can improve ffmpegs CLI from a incorrect statement of the problem. There may be issues in the CLI, but the issue is not that its designed to "fuck the user" Also id love to see other members of the mailing list, there are over a thousand IIRC. Help a bit with keeping the content and tone of the ffmpeg mailing lists within the purpose of the lists. Which is ultimatly to improve FFmpeg and help its users and developers. thanks > not sure what you are even arguing about. The situation is bad, and the > warning is a shitty insufficient hack trying to prevent damage caused > by that. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On 6/15/17, Michael Niedermayer wrote: > On Thu, Jun 15, 2017 at 01:14:34PM +0200, wm4 wrote: > [...] >> By default, ffmpeg CLI's design is something like "fuck the user". I'm > > This is not true, nor are statments like this useful. > Whatever problem there is, it is not and never was FFmpegs design to > fuck the user. Quite the opposite ... > > If problems exist they should be fixed. If they cannot be fixed they > should be at least documented on our issue tracker. > > Without this, such rants are off topic as they cannot serve to > improve FFmpeg. Noone can improve ffmpegs CLI from a incorrect > statement of the problem. > There may be issues in the CLI, but the issue is not that its > designed to "fuck the user" > > Also id love to see other members of the mailing list, there are over > a thousand IIRC. Help a bit with keeping the content and tone of the > ffmpeg mailing lists within the purpose of the lists. > Which is ultimatly to improve FFmpeg and help its users and developers. We do not have supreme leader any more. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On Thu, Jun 15, 2017 at 4:44 PM, wm4 wrote: > Forcing the "High" or maybe "Main" profile is enough to ensure > compatibility. > Result of encoding a PNG sequence, forcing High profile, but without -pix_fmt - No pixel format specified, yuv444p for H.264 encoding chosen. Use -pix_fmt yuv420p for compatibility with outdated media players. x264 [error]: high profile doesn't support 4:4:4 [libx264 @ 02b02b40] Error setting profile high. [libx264 @ 02b02b40] Possible profiles: baseline main high high10 high422 high444 Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height Conversion failed! - ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On Thu, 15 Jun 2017 18:17:37 +0530 Gyan wrote: > On Thu, Jun 15, 2017 at 4:44 PM, wm4 wrote: > > > > Forcing the "High" or maybe "Main" profile is enough to ensure > > compatibility. > > > > Result of encoding a PNG sequence, forcing High profile, but without > -pix_fmt > > - > No pixel format specified, yuv444p for H.264 encoding chosen. > Use -pix_fmt yuv420p for compatibility with outdated media players. > x264 [error]: high profile doesn't support 4:4:4 > [libx264 @ 02b02b40] Error setting profile high. > [libx264 @ 02b02b40] Possible profiles: baseline main high high10 > high422 high444 > Error initializing output stream 0:0 -- Error while opening encoder for > output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, > width or height > Conversion failed! > - So that's fine and the message is not needed. Where is the problem? Other than ffmpeg not doing the obvious thing, and converting to yuv420p (no, the discussed message has absolutely nothing to do with this). I'm fairly sure this is the fault of the libavcodec encoding API having no format negotiation API, though. Didn't dig into it further. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/6] fate: add test of -idct simpleauto
--- tests/fate/video.mak | 3 +++ tests/ref/fate/idct-simpleauto | 27 +++ 2 files changed, 30 insertions(+) create mode 100644 tests/ref/fate/idct-simpleauto diff --git a/tests/fate/video.mak b/tests/fate/video.mak index d1d35335f2..455c1d3564 100644 --- a/tests/fate/video.mak +++ b/tests/fate/video.mak @@ -245,6 +245,9 @@ fate-mpeg2-ticket186: CMD = framecrc -flags +bitexact -idct simple -i $(TARGET_S FATE_VIDEO-$(call DEMDEC, MPEGPS, MPEG2VIDEO) += fate-mpeg2-ticket6024 fate-mpeg2-ticket6024: CMD = framecrc -flags +bitexact -idct simple -flags +truncated -i $(TARGET_SAMPLES)/mpeg2/matrixbench_mpeg2.lq1.mpg -an +FATE_VIDEO-$(call DEMDEC, MPEGPS, MPEG2VIDEO) += fate-idct-simpleauto +fate-idct-simpleauto: CMD = framecrc -flags +bitexact -idct simpleauto -flags +truncated -i $(TARGET_SAMPLES)/mpeg2/matrixbench_mpeg2.lq1.mpg -an + FATE_VIDEO-$(call DEMDEC, MV, MVC1) += fate-mv-mvc1 fate-mv-mvc1: CMD = framecrc -i $(TARGET_SAMPLES)/mv/posture.mv -an -frames 25 -pix_fmt rgb555le diff --git a/tests/ref/fate/idct-simpleauto b/tests/ref/fate/idct-simpleauto new file mode 100644 index 00..bd416240f3 --- /dev/null +++ b/tests/ref/fate/idct-simpleauto @@ -0,0 +1,27 @@ +#tb 0: 1/25 +#media_type 0: video +#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 -- 2.13.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/6] [v2] sse2/avx functions for 8-bit simple idct
After a lot of work by all involved this is the latest patch set. This includes the results of Ronald's work: rounding, minor coeff differences, "DC only hack". I need a proper term for this "DC only hack" because it is not DC only. It is for the lowest frequency of each row. I squashed all 3 functions together because it is not correct to use only some of them due to the differences in permutation required by these and the C/MMX functions. I would appreciate it if people could run the new fate test (fate-idct-simpleauto) on ARM neon and armv5te. No other platforms use their own functions for simpleauto. I might follow this with a patch to cleanup idctdsp_init.c James Darnley (6): fate: add test of -idct simpleauto avcodec/x86: cleanup simple_idct10 avcodec/x86: modify simple_idct10 macros to add an action paramter avcodec/x86: allow future 8-bit simple idct to use slightly different coefficients avcodec/x86: allow future 8-bit simple idct to have "DC only hack" avcodec/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions libavcodec/tests/x86/dct.c| 2 + libavcodec/x86/idctdsp_init.c | 23 libavcodec/x86/proresdsp.asm | 22 ++-- libavcodec/x86/simple_idct.h | 9 ++ libavcodec/x86/simple_idct10.asm | 139 +--- libavcodec/x86/simple_idct10_template.asm | 174 +++--- tests/fate/video.mak | 3 + tests/ref/fate/idct-simpleauto| 27 + 8 files changed, 312 insertions(+), 87 deletions(-) create mode 100644 tests/ref/fate/idct-simpleauto -- 2.13.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/6] avcodec/x86: allow future 8-bit simple idct to have "DC only hack"
Created by Ronald S. Bultje
---
libavcodec/x86/simple_idct10_template.asm | 38 +++
1 file changed, 38 insertions(+)
diff --git a/libavcodec/x86/simple_idct10_template.asm
b/libavcodec/x86/simple_idct10_template.asm
index d8ea0bcc6b..51baf84c82 100644
--- a/libavcodec/x86/simple_idct10_template.asm
+++ b/libavcodec/x86/simple_idct10_template.asm
@@ -257,6 +257,44 @@
pmullw m12,[%8+96]
IDCT_1D %1, %2, %8
+%elif %2 == 11
+por m1, m8, m13
+por m1, m12
+por m1, [blockq+ 16] ; { row[1] }[0-7]
+por m1, [blockq+ 48] ; { row[3] }[0-7]
+por m1, [blockq+ 80] ; { row[5] }[0-7]
+por m1, [blockq+112] ; { row[7] }[0-7]
+pxorm2, m2
+pcmpeqw m1, m2
+psllw m2, m10, 3
+pandm2, m1
+pcmpeqb m3, m3
+pxorm1, m3
+mova[rsp], m1
+mova[rsp+16], m2
+
+IDCT_1D %1, %2
+
+mova m5, [rsp]
+mova m6, [rsp+16]
+pand m8, m5
+por m8, m6
+pand m0, m5
+por m0, m6
+pand m1, m5
+por m1, m6
+pand m2, m5
+por m2, m6
+pand m4, m5
+por m4, m6
+pand m11, m5
+por m11, m6
+pand m9, m5
+por m9, m6
+pand m10, m5
+por m10, m6
+pand m3, m5
+por m3, m6
%else
IDCT_1D %1, %2
%endif
--
2.13.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/6] avcodec/x86: allow future 8-bit simple idct to use slightly different coefficients
--- libavcodec/x86/proresdsp.asm | 18 ++ libavcodec/x86/simple_idct10.asm | 29 + libavcodec/x86/simple_idct10_template.asm | 19 +++ 3 files changed, 50 insertions(+), 16 deletions(-) diff --git a/libavcodec/x86/proresdsp.asm b/libavcodec/x86/proresdsp.asm index 3be0ff7757..65c9fad51c 100644 --- a/libavcodec/x86/proresdsp.asm +++ b/libavcodec/x86/proresdsp.asm @@ -33,14 +33,14 @@ cextern pw_1 cextern pw_4 cextern pw_1019 ; Below are defined in simple_idct10.asm built from selecting idctdsp -cextern w4_plus_w2 -cextern w4_min_w2 -cextern w4_plus_w6 -cextern w4_min_w6 -cextern w1_plus_w3 -cextern w3_min_w1 -cextern w7_plus_w3 -cextern w3_min_w7 +cextern w4_plus_w2_hi +cextern w4_min_w2_hi +cextern w4_plus_w6_hi +cextern w4_min_w6_hi +cextern w1_plus_w3_hi +cextern w3_min_w1_hi +cextern w7_plus_w3_hi +cextern w3_min_w7_hi cextern w1_plus_w5 cextern w5_min_w1 cextern w5_plus_w7 @@ -50,6 +50,8 @@ cextern w7_min_w5 SECTION .text +define_constants _hi + %macro idct_fn 0 cglobal prores_idct_put_10, 4, 4, 15, pixels, lsize, block, qmat IDCT_FNpw_1, 15, pw_88, 18, "put", pw_4, pw_1019, r3 diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm index 1a5a2eae9b..b492303a57 100644 --- a/libavcodec/x86/simple_idct10.asm +++ b/libavcodec/x86/simple_idct10.asm @@ -46,28 +46,41 @@ times 4 dw %2, %3 %define W2sh2 21407 ; W2 = 85627 = 21407<<2 - 1 %define W3sh2 19265 ; W3 = 77062 = 19265<<2 + 2 %define W4sh2 16384 ; W4 = 65535 = 16384<<2 - 1 +%define W3sh2_lo 19266 +%define W4sh2_lo 16383 %define W5sh2 12873 ; W5 = 51491 = 12873<<2 - 1 %define W6sh2 8867 ; W6 = 35468 = 8867<<2 %define W7sh2 4520 ; W7 = 18081 = 4520<<2 + 1 -CONST_DEC w4_plus_w2, W4sh2, +W2sh2 -CONST_DEC w4_min_w2,W4sh2, -W2sh2 -CONST_DEC w4_plus_w6, W4sh2, +W6sh2 -CONST_DEC w4_min_w6,W4sh2, -W6sh2 -CONST_DEC w1_plus_w3, W1sh2, +W3sh2 -CONST_DEC w3_min_w1,W3sh2, -W1sh2 -CONST_DEC w7_plus_w3, W7sh2, +W3sh2 -CONST_DEC w3_min_w7,W3sh2, -W7sh2 +CONST_DEC w4_plus_w2_hi, W4sh2, +W2sh2 +CONST_DEC w4_min_w2_hi,W4sh2, -W2sh2 +CONST_DEC w4_plus_w6_hi, W4sh2, +W6sh2 +CONST_DEC w4_min_w6_hi,W4sh2, -W6sh2 +CONST_DEC w1_plus_w3_hi, W1sh2, +W3sh2 +CONST_DEC w3_min_w1_hi,W3sh2, -W1sh2 +CONST_DEC w7_plus_w3_hi, W7sh2, +W3sh2 +CONST_DEC w3_min_w7_hi,W3sh2, -W7sh2 CONST_DEC w1_plus_w5, W1sh2, +W5sh2 CONST_DEC w5_min_w1,W5sh2, -W1sh2 CONST_DEC w5_plus_w7, W5sh2, +W7sh2 CONST_DEC w7_min_w5,W7sh2, -W5sh2 +CONST_DEC w4_plus_w2_lo, W4sh2_lo, +W2sh2 +CONST_DEC w4_min_w2_lo,W4sh2_lo, -W2sh2 +CONST_DEC w4_plus_w6_lo, W4sh2_lo, +W6sh2 +CONST_DEC w4_min_w6_lo,W4sh2_lo, -W6sh2 +CONST_DEC w1_plus_w3_lo, W1sh2,+W3sh2_lo +CONST_DEC w3_min_w1_lo,W3sh2_lo, -W1sh2 +CONST_DEC w7_plus_w3_lo, W7sh2,+W3sh2_lo +CONST_DEC w3_min_w7_lo,W3sh2_lo, -W7sh2 %include "libavcodec/x86/simple_idct10_template.asm" SECTION .text %macro idct_fn 0 + +define_constants _hi + cglobal simple_idct10, 1, 1, 16, block IDCT_FN"", 12, "", 19, "store" RET diff --git a/libavcodec/x86/simple_idct10_template.asm b/libavcodec/x86/simple_idct10_template.asm index 8367011dfd..d8ea0bcc6b 100644 --- a/libavcodec/x86/simple_idct10_template.asm +++ b/libavcodec/x86/simple_idct10_template.asm @@ -26,6 +26,25 @@ %if ARCH_X86_64 +%macro define_constants 1 +%undef w4_plus_w2 +%undef w4_min_w2 +%undef w4_plus_w6 +%undef w4_min_w6 +%undef w1_plus_w3 +%undef w3_min_w1 +%undef w7_plus_w3 +%undef w3_min_w7 +%define w4_plus_w2 w4_plus_w2%1 +%define w4_min_w2 w4_min_w2%1 +%define w4_plus_w6 w4_plus_w6%1 +%define w4_min_w6 w4_min_w6%1 +%define w1_plus_w3 w1_plus_w3%1 +%define w3_min_w1 w3_min_w1%1 +%define w7_plus_w3 w7_plus_w3%1 +%define w3_min_w7 w3_min_w7%1 +%endmacro + ; interleave data while maintaining source ; %1=type, %2=dstlo, %3=dsthi, %4=src, %5=interleave %macro SBUTTERFLY3 5 -- 2.13.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/6] avcodec/x86: modify simple_idct10 macros to add an action paramter
---
libavcodec/x86/proresdsp.asm | 2 +-
libavcodec/x86/simple_idct10.asm | 8 +++
libavcodec/x86/simple_idct10_template.asm | 37 +--
3 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/libavcodec/x86/proresdsp.asm b/libavcodec/x86/proresdsp.asm
index 8318a81c5e..3be0ff7757 100644
--- a/libavcodec/x86/proresdsp.asm
+++ b/libavcodec/x86/proresdsp.asm
@@ -52,7 +52,7 @@ SECTION .text
%macro idct_fn 0
cglobal prores_idct_put_10, 4, 4, 15, pixels, lsize, block, qmat
-IDCT_FNpw_1, 15, pw_88, 18, pw_4, pw_1019, r3
+IDCT_FNpw_1, 15, pw_88, 18, "put", pw_4, pw_1019, r3
RET
%endmacro
diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm
index 7cfd33eaa3..1a5a2eae9b 100644
--- a/libavcodec/x86/simple_idct10.asm
+++ b/libavcodec/x86/simple_idct10.asm
@@ -69,24 +69,24 @@ SECTION .text
%macro idct_fn 0
cglobal simple_idct10, 1, 1, 16, block
-IDCT_FN"", 12, "", 19
+IDCT_FN"", 12, "", 19, "store"
RET
cglobal simple_idct10_put, 3, 3, 16, pixels, lsize, block
-IDCT_FN"", 12, "", 19, 0, pw_1023
+IDCT_FN"", 12, "", 19, "put", 0, pw_1023
RET
cglobal simple_idct12, 1, 1, 16, block
; coeffs are already 15bits, adding the offset would cause
; overflow in the input
-IDCT_FN"", 15, pw_2, 16
+IDCT_FN"", 15, pw_2, 16, "store"
RET
cglobal simple_idct12_put, 3, 3, 16, pixels, lsize, block
; range isn't known, so the C simple_idct range is used
; Also, using a bias on input overflows, so use the bias
; on output of the first butterfly instead
-IDCT_FN"", 15, pw_2, 16, 0, pw_4095
+IDCT_FN"", 15, pw_2, 16, "put", 0, pw_4095
RET
%endmacro
diff --git a/libavcodec/x86/simple_idct10_template.asm
b/libavcodec/x86/simple_idct10_template.asm
index 3f398985a5..8367011dfd 100644
--- a/libavcodec/x86/simple_idct10_template.asm
+++ b/libavcodec/x86/simple_idct10_template.asm
@@ -218,11 +218,12 @@
; %2 = row bias macro
; %3 = column shift
; %4 = column bias macro
-; %5 = min pixel value
-; %6 = max pixel value
-; %7 = qmat (for prores)
+; %5 = final action (nothing, "store", "put", "add")
+; %6 = min pixel value
+; %7 = max pixel value
+; %8 = qmat (for prores)
-%macro IDCT_FN 4-7
+%macro IDCT_FN 4-8
; for (i = 0; i < 8; i++)
; idctRowCondDC(block + i*8);
movam10,[blockq+ 0]; { row[0] }[0-7]
@@ -230,13 +231,13 @@
movam13,[blockq+64]; { row[4] }[0-7]
movam12,[blockq+96]; { row[6] }[0-7]
-%if %0 == 7
-pmullw m10,[%7+ 0]
-pmullw m8, [%7+32]
-pmullw m13,[%7+64]
-pmullw m12,[%7+96]
+%if %0 == 8
+pmullw m10,[%8+ 0]
+pmullw m8, [%8+32]
+pmullw m13,[%8+64]
+pmullw m12,[%8+96]
-IDCT_1D %1, %2, %7
+IDCT_1D %1, %2, %8
%else
IDCT_1D %1, %2
%endif
@@ -257,7 +258,8 @@
IDCT_1D %3, %4
; clip/store
-%if %0 == 4
+%if %0 >= 5
+%ifidn %5,"store"
; No clamping, means pure idct
mova [blockq+ 0], m8
mova [blockq+ 16], m0
@@ -267,13 +269,13 @@
mova [blockq+ 80], m11
mova [blockq+ 96], m9
mova [blockq+112], m10
-%else
-%ifidn %5, 0
+%elifidn %5,"put"
+%ifidn %6, 0
pxorm3, m3
%else
-movam3, [%5]
-%endif
-movam5, [%6]
+movam3, [%6]
+%endif ; ifidn %6, 0
+movam5, [%7]
pmaxsw m8, m3
pmaxsw m0, m3
pmaxsw m1, m3
@@ -301,7 +303,8 @@
mova [r0+r1 ], m11
mova [r0+r1*2], m9
mova [r0+r2 ], m10
-%endif
+%endif ; %5 action
+%endif; if %0 >= 5
%endmacro
%endif
--
2.13.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/6] avcodec/x86: cleanup simple_idct10
Use named arguments for the functions so we can remove a define. The
stride/linesize argument is now ptrdiff_t type so we no longer need to
sign extend the register.
---
libavcodec/x86/proresdsp.asm | 2 +-
libavcodec/x86/simple_idct10.asm | 8 ++--
libavcodec/x86/simple_idct10_template.asm | 80 ++-
3 files changed, 41 insertions(+), 49 deletions(-)
diff --git a/libavcodec/x86/proresdsp.asm b/libavcodec/x86/proresdsp.asm
index 16fc262aeb..8318a81c5e 100644
--- a/libavcodec/x86/proresdsp.asm
+++ b/libavcodec/x86/proresdsp.asm
@@ -51,7 +51,7 @@ cextern w7_min_w5
SECTION .text
%macro idct_fn 0
-cglobal prores_idct_put_10, 4, 4, 15
+cglobal prores_idct_put_10, 4, 4, 15, pixels, lsize, block, qmat
IDCT_FNpw_1, 15, pw_88, 18, pw_4, pw_1019, r3
RET
%endmacro
diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm
index 5dee533de0..7cfd33eaa3 100644
--- a/libavcodec/x86/simple_idct10.asm
+++ b/libavcodec/x86/simple_idct10.asm
@@ -68,21 +68,21 @@ CONST_DEC w7_min_w5,W7sh2, -W5sh2
SECTION .text
%macro idct_fn 0
-cglobal simple_idct10, 1, 1, 16
+cglobal simple_idct10, 1, 1, 16, block
IDCT_FN"", 12, "", 19
RET
-cglobal simple_idct10_put, 3, 3, 16
+cglobal simple_idct10_put, 3, 3, 16, pixels, lsize, block
IDCT_FN"", 12, "", 19, 0, pw_1023
RET
-cglobal simple_idct12, 1, 1, 16
+cglobal simple_idct12, 1, 1, 16, block
; coeffs are already 15bits, adding the offset would cause
; overflow in the input
IDCT_FN"", 15, pw_2, 16
RET
-cglobal simple_idct12_put, 3, 3, 16
+cglobal simple_idct12_put, 3, 3, 16, pixels, lsize, block
; range isn't known, so the C simple_idct range is used
; Also, using a bias on input overflows, so use the bias
; on output of the first butterfly instead
diff --git a/libavcodec/x86/simple_idct10_template.asm
b/libavcodec/x86/simple_idct10_template.asm
index 9d323d99b3..3f398985a5 100644
--- a/libavcodec/x86/simple_idct10_template.asm
+++ b/libavcodec/x86/simple_idct10_template.asm
@@ -115,18 +115,18 @@
psubd m3, m9; a1[4-7] intermediate
; load/store
-mova [COEFFS+ 0], m0
-mova [COEFFS+ 32], m2
-mova [COEFFS+ 64], m4
-mova [COEFFS+ 96], m6
-movam10,[COEFFS+ 16] ; { row[1] }[0-7]
-movam8, [COEFFS+ 48] ; { row[3] }[0-7]
-movam13,[COEFFS+ 80] ; { row[5] }[0-7]
-movam14,[COEFFS+112] ; { row[7] }[0-7]
-mova [COEFFS+ 16], m1
-mova [COEFFS+ 48], m3
-mova [COEFFS+ 80], m5
-mova [COEFFS+112], m7
+mova [blockq+ 0], m0
+mova [blockq+ 32], m2
+mova [blockq+ 64], m4
+mova [blockq+ 96], m6
+movam10,[blockq+ 16] ; { row[1] }[0-7]
+movam8, [blockq+ 48] ; { row[3] }[0-7]
+movam13,[blockq+ 80] ; { row[5] }[0-7]
+movam14,[blockq+112] ; { row[7] }[0-7]
+mova [blockq+ 16], m1
+mova [blockq+ 48], m3
+mova [blockq+ 80], m5
+mova [blockq+112], m7
%if %0 == 3
pmullw m10,[%3+ 16]
pmullw m8, [%3+ 48]
@@ -197,17 +197,17 @@
; row[5] = (a2 - b2) >> 15;
; row[3] = (a3 + b3) >> 15;
; row[4] = (a3 - b3) >> 15;
-movam8, [COEFFS+ 0]; a0[0-3]
-movam9, [COEFFS+16]; a0[4-7]
+movam8, [blockq+ 0]; a0[0-3]
+movam9, [blockq+16]; a0[4-7]
SUMSUB_SHPK m8, m9, m10, m11, m0, m1, %2
-movam0, [COEFFS+32]; a1[0-3]
-movam1, [COEFFS+48]; a1[4-7]
+movam0, [blockq+32]; a1[0-3]
+movam1, [blockq+48]; a1[4-7]
SUMSUB_SHPK m0, m1, m9, m11, m2, m3, %2
-movam1, [COEFFS+64]; a2[0-3]
-movam2, [COEFFS+80]; a2[4-7]
+movam1, [blockq+64]; a2[0-3]
+movam2, [blockq+80]; a2[4-7]
SUMSUB_SHPK m1, m2, m11, m3, m4, m5, %2
-movam2, [COEFFS+96]; a3[0-3]
-movam3, [COEFFS+112] ; a3[4-7]
+movam2, [blockq+96]; a3[0-3]
+movam3, [blockq+112] ; a3[4-7]
SUMSUB_SHPK m2, m3, m4, m5, m6, m7, %2
%endmacro
@@ -223,20 +223,12 @@
; %7 = qmat (for prores)
%macro IDCT_FN 4-7
-%if %0 == 4
-; No clamping, means pure idct
-%xdefine COEFFS r0
-%else
-movsxd r1, r1d
-%xdefine COEFFS r2
-%endif
-
; for (i = 0; i < 8; i++)
; idctRowCondDC(block + i*8);
-movam10,[COEFFS+ 0]; { row[0] }[0-7]
-movam8, [COEFFS+32]; { row[2] }[0-7]
-movam13,[COEFFS+64]; { row[4] }[0-7]
-movam12,[COEFFS+96]; { row[6] }[0-7]
+movam10,[blockq+ 0]; { row[0] }[0-7]
+movam8, [blockq+32]; { row[2] }[0-7]
+movam13,[blockq+64]; {
[FFmpeg-devel] [PATCH 6/6] avcodec/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions
Includes add/put functions
Rounding contributed by Ronald S. Bultje
---
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(+)
diff --git a/libavcodec/tests/x86/dct.c b/libavcodec/tests/x86/dct.c
index 34f5b8767b..317d973f9f 100644
--- a/libavcodec/tests/x86/dct.c
+++ b/libavcodec/tests/x86/dct.c
@@ -88,10 +88,12 @@ static const struct algo idct_tab_arch[] = {
#if HAVE_YASM
#if ARCH_X86_64
#if HAVE_SSE2_EXTERNAL
+{ "SIMPLE8-SSE2", ff_simple_idct8_sse2, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_SSE2},
{ "SIMPLE10-SSE2", ff_simple_idct10_sse2, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_SSE2},
{ "SIMPLE12-SSE2", ff_simple_idct12_sse2, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_SSE2, 1 },
#endif
#if HAVE_AVX_EXTERNAL
+{ "SIMPLE8-AVX",ff_simple_idct8_avx, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_AVX},
{ "SIMPLE10-AVX", ff_simple_idct10_avx, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_AVX},
{ "SIMPLE12-AVX", ff_simple_idct12_avx, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_AVX, 1 },
#endif
diff --git a/libavcodec/x86/idctdsp_init.c b/libavcodec/x86/idctdsp_init.c
index f1c915aa00..9da60d1a1e 100644
--- a/libavcodec/x86/idctdsp_init.c
+++ b/libavcodec/x86/idctdsp_init.c
@@ -94,9 +94,32 @@ av_cold void ff_idctdsp_init_x86(IDCTDSPContext *c,
AVCodecContext *avctx,
c->idct_add = ff_simple_idct_add_sse2;
c->perm_type = FF_IDCT_PERM_SIMPLE;
}
+
+if (ARCH_X86_64 &&
+!high_bit_depth &&
+avctx->lowres == 0 &&
+(avctx->idct_algo == FF_IDCT_AUTO ||
+avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
+avctx->idct_algo == FF_IDCT_SIMPLEMMX)) {
+c->idct = ff_simple_idct8_sse2;
+c->idct_put = ff_simple_idct8_put_sse2;
+c->idct_add = ff_simple_idct8_add_sse2;
+c->perm_type = FF_IDCT_PERM_TRANSPOSE;
+}
}
if (ARCH_X86_64 && avctx->lowres == 0) {
+if (EXTERNAL_AVX(cpu_flags) &&
+!high_bit_depth &&
+(avctx->idct_algo == FF_IDCT_AUTO ||
+avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
+avctx->idct_algo == FF_IDCT_SIMPLEMMX)) {
+c->idct = ff_simple_idct8_avx;
+c->idct_put = ff_simple_idct8_put_avx;
+c->idct_add = ff_simple_idct8_add_avx;
+c->perm_type = FF_IDCT_PERM_TRANSPOSE;
+}
+
if (avctx->bits_per_raw_sample == 10 &&
(avctx->idct_algo == FF_IDCT_AUTO ||
avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
diff --git a/libavcodec/x86/simple_idct.h b/libavcodec/x86/simple_idct.h
index d17ef6a462..9b64cfe9bc 100644
--- a/libavcodec/x86/simple_idct.h
+++ b/libavcodec/x86/simple_idct.h
@@ -29,6 +29,15 @@ void ff_simple_idct_put_mmx(uint8_t *dest, ptrdiff_t
line_size, int16_t *block);
void ff_simple_idct_add_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
void ff_simple_idct_put_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+void ff_simple_idct8_sse2(int16_t *block);
+void ff_simple_idct8_avx(int16_t *block);
+
+void ff_simple_idct8_put_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+void ff_simple_idct8_put_avx(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+
+void ff_simple_idct8_add_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+void ff_simple_idct8_add_avx(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+
void ff_simple_idct10_sse2(int16_t *block);
void ff_simple_idct10_avx(int16_t *block);
diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm
index b492303a57..efc8e7ac3e 100644
--- a/libavcodec/x86/simple_idct10.asm
+++ b/libavcodec/x86/simple_idct10.asm
@@ -31,11 +31,14 @@ SECTION_RODATA
cextern pw_2
cextern pw_16
+cextern pw_32
cextern pw_1023
cextern pw_4095
+pd_round_11: times 4 dd 1<<(11-1)
pd_round_12: times 4 dd 1<<(12-1)
pd_round_15: times 4 dd 1<<(15-1)
pd_round_19: times 4 dd 1<<(19-1)
+pd_round_20: times 4 dd 1<<(20-1)
%macro CONST_DEC 3
const %1
@@ -77,8 +80,99 @@ CONST_DEC w3_min_w7_lo,W3sh2_lo, -W7sh2
SECTION .text
+%macro STORE_HI_LO 12
+movq %1, %9
+movq %3, %10
+movq %5, %11
+movq %7, %12
+movhps %2, %9
+movhps %4, %10
+movhps %6, %11
+movhps %8, %12
+%endmacro
+
+%macro LOAD_ZXBW_8 16
+pmovzxbw %1, %9
+pmovzxbw %2, %10
+pmovzxbw %3, %11
+pmovzxbw %4, %12
+pmovzxbw %5, %13
+pmovzxbw %6, %14
+pmovzxbw %7, %15
+pmovzxbw %8, %16
+%endmacro
+
+%macro LOAD_ZXBW_4 9
+movh %1, %5
+movh %2, %6
+movh %3, %7
+movh %4, %8
+punpcklbw %1, %9
+punpcklbw %2, %9
+punpcklbw %3, %9
+punpcklbw %4, %9
+%endmacro
+
+%define PASS4ROWS(base, stri
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On Thu, Jun 15, 2017 at 02:12:09PM +0200, Paul B Mahol wrote: > On 6/15/17, Michael Niedermayer wrote: > > On Thu, Jun 15, 2017 at 01:14:34PM +0200, wm4 wrote: > > [...] > >> By default, ffmpeg CLI's design is something like "fuck the user". I'm > > > > This is not true, nor are statments like this useful. > > Whatever problem there is, it is not and never was FFmpegs design to > > fuck the user. Quite the opposite ... > > > > If problems exist they should be fixed. If they cannot be fixed they > > should be at least documented on our issue tracker. > > > > Without this, such rants are off topic as they cannot serve to > > improve FFmpeg. Noone can improve ffmpegs CLI from a incorrect > > statement of the problem. > > There may be issues in the CLI, but the issue is not that its > > designed to "fuck the user" > > > > Also id love to see other members of the mailing list, there are over > > a thousand IIRC. Help a bit with keeping the content and tone of the > > ffmpeg mailing lists within the purpose of the lists. > > Which is ultimatly to improve FFmpeg and help its users and developers. > > We do not have supreme leader any more. no, but that doesnt mean we can make false statments about other people or their work. Theres the moral wrong Theres the technical wrong, of not correctly stating the problem and that potentially affecting work on the problem Theres the social wrong. That is people who spend significant time on the CLI becoming offended and alienated by such statments. Theres the legal wrong, there are many people who worked on the CLI at some point. Anyone of them can probably sue us for defamation, but IANAL. I dont think that would help FFmpegs / our public image. A big part of the current CLI has btw been implemented by Libav developers, and merged into FFmpeg, other parts are very old code from times when FFmpeg was much simpler. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On Thu, 15 Jun 2017 16:22:34 +0200 Michael Niedermayer wrote: > no, but that doesnt mean we can make false statments about other > people or their work. > > Theres the moral wrong > > Theres the technical wrong, of not correctly stating the problem and > that potentially affecting work on the problem > > Theres the social wrong. That is people who spend significant time on > the CLI becoming offended and alienated by such statments. > > Theres the legal wrong, there are many people who worked on the CLI > at some point. Anyone of them can probably sue us for defamation, > but IANAL. I dont think that would help FFmpegs / our public image. I think you're blowing this out of proportion, as usual (I guess I should sue myself because I've worked on ffmpeg.c too?). But my particular problem here is that some people just can't admit that certain parts of the code are just bad, and that they actively fight cleaning it up. Fuck that, I don't see any reason to hold back under these circumstances. ffmpeg.c in particular is a vile POS. Whenever there is a problem, I find half a dozen more problems, no clear way to fix it, and general misery. If I want to try to find out how to do something specific with ffmpeg.c, its help output is utterly useless and confusing, and I end up reading the code. I guess it produces more stackoverflow traffic and more need for ffmpeg specialists (especially when there's payment), so I guess it has something good too. > A big part of the current CLI has btw been implemented by Libav > developers, and merged into FFmpeg, other parts are very old code > from times when FFmpeg was much simpler. Who mentioned Libav? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On 6/15/2017 11:43 AM, wm4 wrote: > On Thu, 15 Jun 2017 16:22:34 +0200 > Michael Niedermayer wrote: > >> no, but that doesnt mean we can make false statments about other >> people or their work. >> >> Theres the moral wrong >> >> Theres the technical wrong, of not correctly stating the problem and >> that potentially affecting work on the problem >> >> Theres the social wrong. That is people who spend significant time on >> the CLI becoming offended and alienated by such statments. >> >> Theres the legal wrong, there are many people who worked on the CLI >> at some point. Anyone of them can probably sue us for defamation, >> but IANAL. I dont think that would help FFmpegs / our public image. > > I think you're blowing this out of proportion, as usual (I guess I > should sue myself because I've worked on ffmpeg.c too?). > > But my particular problem here is that some people just can't admit that > certain parts of the code are just bad, and that they actively fight > cleaning it up. Fuck that, I don't see any reason to hold back under > these circumstances. > > ffmpeg.c in particular is a vile POS. Whenever there is a problem, I > find half a dozen more problems, no clear way to fix it, and general > misery. If I want to try to find out how to do something specific with > ffmpeg.c, its help output is utterly useless and confusing, and I end > up reading the code. I guess it produces more stackoverflow traffic and > more need for ffmpeg specialists (especially when there's payment), so > I guess it has something good too. Why did a patch to remove a warning from certain cases ended up in shit flinging I'll never know. But I'd very much like it if it stopped here. > >> A big part of the current CLI has btw been implemented by Libav >> developers, and merged into FFmpeg, other parts are very old code >> from times when FFmpeg was much simpler. > > Who mentioned Libav? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions
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(+)
diff --git a/libavcodec/tests/x86/dct.c b/libavcodec/tests/x86/dct.c
index 34f5b8767b..317d973f9f 100644
--- a/libavcodec/tests/x86/dct.c
+++ b/libavcodec/tests/x86/dct.c
@@ -88,10 +88,12 @@ static const struct algo idct_tab_arch[] = {
#if HAVE_YASM
#if ARCH_X86_64
#if HAVE_SSE2_EXTERNAL
+{ "SIMPLE8-SSE2", ff_simple_idct8_sse2, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_SSE2},
{ "SIMPLE10-SSE2", ff_simple_idct10_sse2, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_SSE2},
{ "SIMPLE12-SSE2", ff_simple_idct12_sse2, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_SSE2, 1 },
#endif
#if HAVE_AVX_EXTERNAL
+{ "SIMPLE8-AVX",ff_simple_idct8_avx, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_AVX},
{ "SIMPLE10-AVX", ff_simple_idct10_avx, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_AVX},
{ "SIMPLE12-AVX", ff_simple_idct12_avx, FF_IDCT_PERM_TRANSPOSE,
AV_CPU_FLAG_AVX, 1 },
#endif
diff --git a/libavcodec/x86/idctdsp_init.c b/libavcodec/x86/idctdsp_init.c
index f1c915aa00..9da60d1a1e 100644
--- a/libavcodec/x86/idctdsp_init.c
+++ b/libavcodec/x86/idctdsp_init.c
@@ -94,9 +94,32 @@ av_cold void ff_idctdsp_init_x86(IDCTDSPContext *c,
AVCodecContext *avctx,
c->idct_add = ff_simple_idct_add_sse2;
c->perm_type = FF_IDCT_PERM_SIMPLE;
}
+
+if (ARCH_X86_64 &&
+!high_bit_depth &&
+avctx->lowres == 0 &&
+(avctx->idct_algo == FF_IDCT_AUTO ||
+avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
+avctx->idct_algo == FF_IDCT_SIMPLEMMX)) {
+c->idct = ff_simple_idct8_sse2;
+c->idct_put = ff_simple_idct8_put_sse2;
+c->idct_add = ff_simple_idct8_add_sse2;
+c->perm_type = FF_IDCT_PERM_TRANSPOSE;
+}
}
if (ARCH_X86_64 && avctx->lowres == 0) {
+if (EXTERNAL_AVX(cpu_flags) &&
+!high_bit_depth &&
+(avctx->idct_algo == FF_IDCT_AUTO ||
+avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
+avctx->idct_algo == FF_IDCT_SIMPLEMMX)) {
+c->idct = ff_simple_idct8_avx;
+c->idct_put = ff_simple_idct8_put_avx;
+c->idct_add = ff_simple_idct8_add_avx;
+c->perm_type = FF_IDCT_PERM_TRANSPOSE;
+}
+
if (avctx->bits_per_raw_sample == 10 &&
(avctx->idct_algo == FF_IDCT_AUTO ||
avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
diff --git a/libavcodec/x86/simple_idct.h b/libavcodec/x86/simple_idct.h
index d17ef6a462..9b64cfe9bc 100644
--- a/libavcodec/x86/simple_idct.h
+++ b/libavcodec/x86/simple_idct.h
@@ -29,6 +29,15 @@ void ff_simple_idct_put_mmx(uint8_t *dest, ptrdiff_t
line_size, int16_t *block);
void ff_simple_idct_add_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
void ff_simple_idct_put_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+void ff_simple_idct8_sse2(int16_t *block);
+void ff_simple_idct8_avx(int16_t *block);
+
+void ff_simple_idct8_put_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+void ff_simple_idct8_put_avx(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+
+void ff_simple_idct8_add_sse2(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+void ff_simple_idct8_add_avx(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+
void ff_simple_idct10_sse2(int16_t *block);
void ff_simple_idct10_avx(int16_t *block);
diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm
index b492303a57..10c5cd4340 100644
--- a/libavcodec/x86/simple_idct10.asm
+++ b/libavcodec/x86/simple_idct10.asm
@@ -31,11 +31,14 @@ SECTION_RODATA
cextern pw_2
cextern pw_16
+cextern pw_32
cextern pw_1023
cextern pw_4095
+pd_round_11: times 4 dd 1<<(11-1)
pd_round_12: times 4 dd 1<<(12-1)
pd_round_15: times 4 dd 1<<(15-1)
pd_round_19: times 4 dd 1<<(19-1)
+pd_round_20: times 4 dd 1<<(20-1)
%macro CONST_DEC 3
const %1
@@ -77,8 +80,99 @@ CONST_DEC w3_min_w7_lo,W3sh2_lo, -W7sh2
SECTION .text
+%macro STORE_HI_LO 12
+movq %1, %9
+movq %3, %10
+movq %5, %11
+movq %7, %12
+movhps %2, %9
+movhps %4, %10
+movhps %6, %11
+movhps %8, %12
+%endmacro
+
+%macro LOAD_ZXBW_8 16
+pmovzxbw %1, %9
+pmovzxbw %2, %10
+pmovzxbw %3, %11
+pmovzxbw %4, %12
+pmovzxbw %5, %13
+pmovzxbw %6, %14
+pmovzxbw %7, %15
+pmovzxbw %8, %16
+%endmacro
+
+%macro LOAD_ZXBW_4 9
+movh %1, %5
+movh %2, %6
+movh %3, %7
+movh %4, %8
+punpcklbw %1, %9
+punpcklbw %2, %9
+punpcklbw %3, %9
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/vorbisenc: Stop tracking number of samples per frame
On 14 June 2017 at 21:59, Tyler Jones wrote:
> Each frame is now padded with 0 values if not enough samples are
> present, and all frames are guaranteed to have exactly
> 1 << (venc->log2_blocksize[1] - 1) samples.
>
> Signed-off-by: Tyler Jones
> ---
> libavcodec/vorbisenc.c | 33 -
> 1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/libavcodec/vorbisenc.c b/libavcodec/vorbisenc.c
> index 14de803..bf21a3b 100644
> --- a/libavcodec/vorbisenc.c
> +++ b/libavcodec/vorbisenc.c
> @@ -997,7 +997,7 @@ static int residue_encode(vorbis_enc_context *venc,
> vorbis_enc_residue *rc,
> return 0;
> }
>
> -static int apply_window_and_mdct(vorbis_enc_context *venc, int samples)
> +static int apply_window_and_mdct(vorbis_enc_context *venc)
> {
> int channel;
> const float * win = venc->win[1];
> @@ -1008,13 +1008,13 @@ static int apply_window_and_mdct(vorbis_enc_context
> *venc, int samples)
> for (channel = 0; channel < venc->channels; channel++) {
> float *offset = venc->samples + channel * window_len * 2;
>
> -fdsp->vector_fmul(offset, offset, win, samples);
> -fdsp->vector_fmul_scalar(offset, offset, 1/n, samples);
> +fdsp->vector_fmul(offset, offset, win, window_len);
> +fdsp->vector_fmul_scalar(offset, offset, 1/n, window_len);
>
> offset += window_len;
>
> -fdsp->vector_fmul_reverse(offset, offset, win, samples);
> -fdsp->vector_fmul_scalar(offset, offset, 1/n, samples);
> +fdsp->vector_fmul_reverse(offset, offset, win, window_len);
> +fdsp->vector_fmul_scalar(offset, offset, 1/n, window_len);
>
> venc->mdct[1].mdct_calc(&venc->mdct[1], venc->coeffs + channel *
> window_len,
> venc->samples + channel * window_len * 2);
> @@ -1047,7 +1047,7 @@ static AVFrame *spawn_empty_frame(AVCodecContext
> *avctx, int channels)
> }
>
> /* Set up audio samples for psy analysis and window/mdct */
> -static void move_audio(vorbis_enc_context *venc, int *samples, int
> sf_size)
> +static void move_audio(vorbis_enc_context *venc, int sf_size)
> {
> AVFrame *cur = NULL;
> int frame_size = 1 << (venc->log2_blocksize[1] - 1);
> @@ -1065,7 +1065,6 @@ static void move_audio(vorbis_enc_context *venc, int
> *samples, int sf_size)
>
> for (sf = 0; sf < subframes; sf++) {
> cur = ff_bufqueue_get(&venc->bufqueue);
> -*samples += cur->nb_samples;
>
> for (ch = 0; ch < venc->channels; ch++) {
> float *offset = venc->samples + 2 * ch * frame_size +
> frame_size;
> @@ -1087,7 +1086,7 @@ static int vorbis_encode_frame(AVCodecContext
> *avctx, AVPacket *avpkt,
> {
> vorbis_enc_context *venc = avctx->priv_data;
> int i, ret, need_more;
> -int samples = 0, frame_size = 1 << (venc->log2_blocksize[1] - 1);
> +int frame_size = 1 << (venc->log2_blocksize[1] - 1);
> vorbis_enc_mode *mode;
> vorbis_enc_mapping *mapping;
> PutBitContext pb;
> @@ -1120,9 +1119,9 @@ static int vorbis_encode_frame(AVCodecContext
> *avctx, AVPacket *avpkt,
> }
> }
>
> -move_audio(venc, &samples, avctx->frame_size);
> +move_audio(venc, avctx->frame_size);
>
> -if (!apply_window_and_mdct(venc, samples))
> +if (!apply_window_and_mdct(venc))
> return 0;
>
> if ((ret = ff_alloc_packet2(avctx, avpkt, 8192, 0)) < 0)
> @@ -1149,21 +1148,21 @@ static int vorbis_encode_frame(AVCodecContext
> *avctx, AVPacket *avpkt,
> for (i = 0; i < venc->channels; i++) {
> vorbis_enc_floor *fc = &venc->floors[mapping->floor[
> mapping->mux[i]]];
> uint16_t posts[MAX_FLOOR_VALUES];
> -floor_fit(venc, fc, &venc->coeffs[i * samples], posts, samples);
> -if (floor_encode(venc, fc, &pb, posts, &venc->floor[i * samples],
> samples)) {
> +floor_fit(venc, fc, &venc->coeffs[i * frame_size], posts,
> frame_size);
> +if (floor_encode(venc, fc, &pb, posts, &venc->floor[i *
> frame_size], frame_size)) {
> av_log(avctx, AV_LOG_ERROR, "output buffer is too small\n");
> return AVERROR(EINVAL);
> }
> }
>
> -for (i = 0; i < venc->channels * samples; i++)
> +for (i = 0; i < venc->channels * frame_size; i++)
> venc->coeffs[i] /= venc->floor[i];
>
> for (i = 0; i < mapping->coupling_steps; i++) {
> -float *mag = venc->coeffs + mapping->magnitude[i] * samples;
> -float *ang = venc->coeffs + mapping->angle[i] * samples;
> +float *mag = venc->coeffs + mapping->magnitude[i] * frame_size;
> +float *ang = venc->coeffs + mapping->angle[i] * frame_size;
> int j;
> -for (j = 0; j < samples; j++) {
> +for (j = 0; j < frame_size; j++) {
> float a = ang[j];
> ang[j] -= mag[j];
> if (mag[j] > 0)
> @@ -1174,7 +1173,7 @@ static int vorbis_encode_frame(AVCodecContext
> *avctx, AVPacket *avpkt,
> }
>
>
Re: [FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input
On Thu, 15 Jun 2017 12:10:27 -0300 James Almer wrote: > On 6/15/2017 11:43 AM, wm4 wrote: > > On Thu, 15 Jun 2017 16:22:34 +0200 > > Michael Niedermayer wrote: > > > >> no, but that doesnt mean we can make false statments about other > >> people or their work. > >> > >> Theres the moral wrong > >> > >> Theres the technical wrong, of not correctly stating the problem and > >> that potentially affecting work on the problem > >> > >> Theres the social wrong. That is people who spend significant time on > >> the CLI becoming offended and alienated by such statments. > >> > >> Theres the legal wrong, there are many people who worked on the CLI > >> at some point. Anyone of them can probably sue us for defamation, > >> but IANAL. I dont think that would help FFmpegs / our public image. > > > > I think you're blowing this out of proportion, as usual (I guess I > > should sue myself because I've worked on ffmpeg.c too?). > > > > But my particular problem here is that some people just can't admit that > > certain parts of the code are just bad, and that they actively fight > > cleaning it up. Fuck that, I don't see any reason to hold back under > > these circumstances. > > > > ffmpeg.c in particular is a vile POS. Whenever there is a problem, I > > find half a dozen more problems, no clear way to fix it, and general > > misery. If I want to try to find out how to do something specific with > > ffmpeg.c, its help output is utterly useless and confusing, and I end > > up reading the code. I guess it produces more stackoverflow traffic and > > more need for ffmpeg specialists (especially when there's payment), so > > I guess it has something good too. > > Why did a patch to remove a warning from certain cases ended up in shit > flinging I'll never know. But I'd very much like it if it stopped here. You're right, I'll propose a patch to remove this message. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: remove misleading and incorrect error messages
It is wrong/incorrect in two aspects:
1. The pixel format is not enough to guarantee that the resulting file
will be any more compatible with media players.
2. Media players not supporting higher profiles are not necessarily
outdated (in fact this is simply an arrogant statement that
libavcodec can handle these particular features).
You could add that there are plenty of other ways to produce widely
incompatible files with ffmpeg, and these don't show any warnings.
What we really want to do here is defaulting to codec profiles that
have wide compatibility, such as baseline/main/high for h264. Also,
if an encoder does not accept certain pixfmts, we should automatically
convert them to a pixfmt the encoder can accept. But the existin
message certainly is not appropriate.
It also works for 2 specific encoders only. We should remove the
message for the reason alone to avoid that this code grows in the
future, and becomes a maintenance burden.
---
ffmpeg.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 6170bd453c..a783e6e04b 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3343,20 +3343,7 @@ static int init_output_stream_encode(OutputStream *ost)
ost->frame_aspect_ratio.num ? // overridden by the -aspect cli
option
av_mul_q(ost->frame_aspect_ratio, (AVRational){ enc_ctx->height,
enc_ctx->width }) :
av_buffersink_get_sample_aspect_ratio(ost->filter->filter);
-if (!strncmp(ost->enc->name, "libx264", 7) &&
-enc_ctx->pix_fmt == AV_PIX_FMT_NONE &&
-av_buffersink_get_format(ost->filter->filter) !=
AV_PIX_FMT_YUV420P)
-av_log(NULL, AV_LOG_WARNING,
- "No pixel format specified, %s for H.264 encoding chosen.\n"
- "Use -pix_fmt yuv420p for compatibility with outdated media
players.\n",
-
av_get_pix_fmt_name(av_buffersink_get_format(ost->filter->filter)));
-if (!strncmp(ost->enc->name, "mpeg2video", 10) &&
-enc_ctx->pix_fmt == AV_PIX_FMT_NONE &&
-av_buffersink_get_format(ost->filter->filter) !=
AV_PIX_FMT_YUV420P)
-av_log(NULL, AV_LOG_WARNING,
- "No pixel format specified, %s for MPEG-2 encoding
chosen.\n"
- "Use -pix_fmt yuv420p for compatibility with outdated media
players.\n",
-
av_get_pix_fmt_name(av_buffersink_get_format(ost->filter->filter)));
+
enc_ctx->pix_fmt = av_buffersink_get_format(ost->filter->filter);
if (dec_ctx)
enc_ctx->bits_per_raw_sample = FFMIN(dec_ctx->bits_per_raw_sample,
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: remove misleading and incorrect error messages
Those are warnings, not error messages. Fixed locally. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration
Le quintidi 25 prairial, an CCXXV, Thomas Mundt a écrit :
> Patch attached. This fixes ticket #2674. I inserted a FIXME message as a
> reminder.
> Please comment.
I am sorry to say I do not like it. The timestamp computation code in
vf_fps is already quite complex, and this patch is making it more
complex, introducing frames_in_proc which should not be needed just to
fix the last timestamp, and obviously the EOF handling duplicates the
filter_frame() logic.
Rule of thumb: if you are about to copy-paste a non-trivial block of
code, stop and refactor.
I think the way forward for this filter is to rewrite the core logic
using the activate() design. It should be much simpler since the
framework already handles a FIFO. If you are interested in it, you
probably will need to rebase push this series:
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209678.html
and use the attached patch.
Regards,
--
Nicolas George
From b7a20596861a8baeb746dbe8922c874ab48e26f5 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Sun, 23 Apr 2017 14:05:01 +0200
Subject: [PATCH 5/6] lavfi: add ff_inlink_query_fifo().
Signed-off-by: Nicolas George
---
libavfilter/avfilter.c | 14 ++
libavfilter/filters.h | 7 +++
2 files changed, 21 insertions(+)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index ecfb872ed8..ee79743928 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -1638,6 +1638,20 @@ void ff_inlink_request_frame(AVFilterLink *link)
ff_filter_set_ready(link->src, 100);
}
+void ff_inlink_query_fifo(AVFilterLink *link,
+ size_t *frames, uint64_t *samples,
+ int *status, int64_t *status_pts)
+{
+if (*frames)
+*frames = ff_framequeue_queued_frames(&link->fifo);
+if (*samples)
+*samples = ff_framequeue_queued_samples(&link->fifo);
+if (*status)
+*status = link->status_in;
+if (*status_pts)
+*status_pts = link->status_in_pts;
+}
+
const AVClass *avfilter_get_class(void)
{
return &avfilter_class;
diff --git a/libavfilter/filters.h b/libavfilter/filters.h
index 2c78d60e62..870fbc4708 100644
--- a/libavfilter/filters.h
+++ b/libavfilter/filters.h
@@ -134,4 +134,11 @@ int ff_inlink_acknowledge_status(AVFilterLink *link, int *rstatus, int64_t *rpts
*/
void ff_inlink_request_frame(AVFilterLink *link);
+/**
+ * Query the properties of the link FIFO and surrounding properties.
+ */
+void ff_inlink_query_fifo(AVFilterLink *link,
+ size_t *frames, uint64_t *samples,
+ int *status, int64_t *status_pts);
+
#endif /* AVFILTER_FILTERS_H */
--
2.11.0
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration
2017-06-15 20:00 GMT+02:00 Nicolas George : > Le quintidi 25 prairial, an CCXXV, Thomas Mundt a écrit : > > Patch attached. This fixes ticket #2674. I inserted a FIXME message as a > > reminder. > > Please comment. > > I am sorry to say I do not like it. The timestamp computation code in > vf_fps is already quite complex, and this patch is making it more > complex, introducing frames_in_proc which should not be needed just to > fix the last timestamp, and obviously the EOF handling duplicates the > filter_frame() logic. > > Hmm, before rewriting and sending this patch I asked if it would have a chance to be pushed just to fix the ticket which is open for a very long time. Your answer gave me the assumtion that you´re okay with it. I thought your only concern was the not allowed use of pkt_duration. > I think the way forward for this filter is to rewrite the core logic > using the activate() design. It should be much simpler since the > framework already handles a FIFO. If you are interested in it, you > probably will need to rebase push this series: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209678.html > > and use the attached patch. > > Well, my problem is that I´m not deep enough in ffmpeg programming to understand the interrelations of timestamp handling and unfortunately I don´t have the time to figure it out. Working with patches that I don´t fully understand doesn´t make any sense. My intention was a fix within the filter to close the ticket. Just to bridge the time until a proper fix is made. Regards, Thomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration
Le septidi 27 prairial, an CCXXV, Thomas Mundt a écrit : > Hmm, before rewriting and sending this patch I asked if it would have a > chance to be pushed just to fix the ticket which is open for a very long > time. Your answer gave me the assumtion that you´re okay with it. > I thought your only concern was the not allowed use of pkt_duration. I am ok in principle with a patch that uses the frame rate instead of the correct final timestamp. But not any such patch. I am not ok with a patch that makes the code more complex. I will at some point start again working on this, and any extra code complexity will make my life harder. In particular, I am never ok with a patch that copy-pastes and duplicates a non-trivial block of code. In fact, even if your patch was perfect in its logic, i.e. used the correct final timestamp, I would reject it based on the code complexity and duplication. As I said : the moment you used the "copy" feature of your editor on a non-trivial block of code, you should have stopped and taken a step back to look at the big picture. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/ffv1enc: Try to choose slice count so that slice packet sizes are within the supported size
Fixes assertion failure
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1enc.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 7f31606775..e59d540737 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -848,10 +848,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
if (s->version > 1) {
+int plane_count = 1 + 2*s->chroma_planes + s->transparency;
s->num_v_slices = (avctx->width > 352 || avctx->height > 288 ||
!avctx->slices) ? 2 : 1;
-for (; s->num_v_slices < 9; s->num_v_slices++) {
+for (; s->num_v_slices < 32; s->num_v_slices++) {
for (s->num_h_slices = s->num_v_slices; s->num_h_slices <
2*s->num_v_slices; s->num_h_slices++) {
-if (avctx->slices == s->num_h_slices * s->num_v_slices &&
avctx->slices <= 64 || !avctx->slices)
+int maxw = (avctx->width + s->num_h_slices - 1) /
s->num_h_slices;
+int maxh = (avctx->height + s->num_v_slices - 1) /
s->num_v_slices;
+if (s->num_h_slices > avctx->width || s->num_v_slices >
avctx->height)
+continue;
+if (maxw * maxh * (int64_t)(s->bits_per_raw_sample+1) *
plane_count > 8<<24)
+continue;
+if (avctx->slices == s->num_h_slices * s->num_v_slices &&
avctx->slices <= MAX_SLICES || !avctx->slices)
goto slices_ok;
}
}
--
2.13.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/ffv1: Increase the maximum number of slices to 1024
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index c2bae1e6da..653138b070 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@ -74,7 +74,7 @@ typedef struct PlaneContext {
uint8_t interlace_bit_state[2];
} PlaneContext;
-#define MAX_SLICES 256
+#define MAX_SLICES 1024
typedef struct FFV1Context {
AVClass *class;
--
2.13.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264
From: Anton Mitrofanov
Signed-off-by: Ronald S. Bultje
---
libavcodec/h264_mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index 638dcba..cb9fe85 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_mb.c
@@ -637,7 +637,7 @@ static av_always_inline void
hl_decode_mb_predict_luma(const H264Context *h,
uint8_t *const ptr = dest_y + block_offset[i];
const int dir = sl->intra4x4_pred_mode_cache[scan8[i]];
if (transform_bypass && h->ps.sps->profile_idc == 244 && dir
<= 1) {
-if (h->sei.unregistered.x264_build != -1) {
+if (h->sei.unregistered.x264_build < 151U) {
h->hpc.pred8x8l_add[dir](ptr, sl->mb + (i * 16 + p *
256 << pixel_shift), linesize);
} else
h->hpc.pred8x8l_filter_add[dir](ptr, sl->mb + (i * 16
+ p * 256 << pixel_shift),
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4
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(-)
diff --git a/libavcodec/h264_cabac.c b/libavcodec/h264_cabac.c
index 11ff3a0..28aacc5 100644
--- a/libavcodec/h264_cabac.c
+++ b/libavcodec/h264_cabac.c
@@ -2347,21 +2347,40 @@ decode_intra_mb:
if (CHROMA444(h) && IS_8x8DCT(mb_type)){
int i;
uint8_t *nnz_cache = sl->non_zero_count_cache;
-for (i = 0; i < 2; i++){
-if (sl->left_type[LEFT(i)] && !IS_8x8DCT(sl->left_type[LEFT(i)])) {
-nnz_cache[3+8* 1 + 2*8*i]=
-nnz_cache[3+8* 2 + 2*8*i]=
-nnz_cache[3+8* 6 + 2*8*i]=
-nnz_cache[3+8* 7 + 2*8*i]=
-nnz_cache[3+8*11 + 2*8*i]=
-nnz_cache[3+8*12 + 2*8*i]= IS_INTRA(mb_type) ? 64 : 0;
+if (h->sei.unregistered.x264_build < 151U) {
+for (i = 0; i < 2; i++){
+if (sl->left_type[LEFT(i)] &&
!IS_8x8DCT(sl->left_type[LEFT(i)])) {
+nnz_cache[3+8* 1 + 2*8*i]=
+nnz_cache[3+8* 2 + 2*8*i]=
+nnz_cache[3+8* 6 + 2*8*i]=
+nnz_cache[3+8* 7 + 2*8*i]=
+nnz_cache[3+8*11 + 2*8*i]=
+nnz_cache[3+8*12 + 2*8*i]= IS_INTRA(mb_type) ? 64 : 0;
+}
+}
+if (sl->top_type && !IS_8x8DCT(sl->top_type)){
+uint32_t top_empty = !IS_INTRA(mb_type) ? 0 : 0x40404040;
+AV_WN32A(&nnz_cache[4+8* 0], top_empty);
+AV_WN32A(&nnz_cache[4+8* 5], top_empty);
+AV_WN32A(&nnz_cache[4+8*10], top_empty);
+}
+} else {
+for (i = 0; i < 2; i++){
+if (sl->left_type[LEFT(i)] &&
!IS_8x8DCT(sl->left_type[LEFT(i)])) {
+nnz_cache[3+8* 1 + 2*8*i]=
+nnz_cache[3+8* 2 + 2*8*i]=
+nnz_cache[3+8* 6 + 2*8*i]=
+nnz_cache[3+8* 7 + 2*8*i]=
+nnz_cache[3+8*11 + 2*8*i]=
+nnz_cache[3+8*12 + 2*8*i]=
!IS_INTRA_PCM(sl->left_type[LEFT(i)]) ? 0 : 64;
+}
+}
+if (sl->top_type && !IS_8x8DCT(sl->top_type)){
+uint32_t top_empty = !IS_INTRA_PCM(sl->top_type) ? 0 :
0x40404040;
+AV_WN32A(&nnz_cache[4+8* 0], top_empty);
+AV_WN32A(&nnz_cache[4+8* 5], top_empty);
+AV_WN32A(&nnz_cache[4+8*10], top_empty);
}
-}
-if (sl->top_type && !IS_8x8DCT(sl->top_type)){
-uint32_t top_empty = !IS_INTRA(mb_type) ? 0 : 0x40404040;
-AV_WN32A(&nnz_cache[4+8* 0], top_empty);
-AV_WN32A(&nnz_cache[4+8* 5], top_empty);
-AV_WN32A(&nnz_cache[4+8*10], top_empty);
}
}
h->cur_pic.mb_type[mb_xy] = mb_type;
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/h264: Fix mix of lossless and lossy MBs decoding
From: Anton Mitrofanov
Signed-off-by: Ronald S. Bultje
---
libavcodec/h264_cabac.c | 16
libavcodec/h264_cavlc.c | 16
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec/h264_cabac.c b/libavcodec/h264_cabac.c
index 28aacc5..0973e30 100644
--- a/libavcodec/h264_cabac.c
+++ b/libavcodec/h264_cabac.c
@@ -2389,14 +2389,6 @@ decode_intra_mb:
const uint8_t *scan, *scan8x8;
const uint32_t *qmul;
-if(IS_INTERLACED(mb_type)){
-scan8x8 = sl->qscale ? h->field_scan8x8 : h->field_scan8x8_q0;
-scan= sl->qscale ? h->field_scan : h->field_scan_q0;
-}else{
-scan8x8 = sl->qscale ? h->zigzag_scan8x8 : h->zigzag_scan8x8_q0;
-scan= sl->qscale ? h->zigzag_scan : h->zigzag_scan_q0;
-}
-
// decode_cabac_mb_dqp
if(get_cabac_noinline( &sl->cabac, &sl->cabac_state[60 +
(sl->last_qscale_diff != 0)])){
int val = 1;
@@ -2427,6 +2419,14 @@ decode_intra_mb:
}else
sl->last_qscale_diff=0;
+if(IS_INTERLACED(mb_type)){
+scan8x8 = sl->qscale ? h->field_scan8x8 : h->field_scan8x8_q0;
+scan= sl->qscale ? h->field_scan : h->field_scan_q0;
+}else{
+scan8x8 = sl->qscale ? h->zigzag_scan8x8 : h->zigzag_scan8x8_q0;
+scan= sl->qscale ? h->zigzag_scan : h->zigzag_scan_q0;
+}
+
decode_cabac_luma_residual(h, sl, scan, scan8x8, pixel_shift, mb_type,
cbp, 0);
if (CHROMA444(h)) {
decode_cabac_luma_residual(h, sl, scan, scan8x8, pixel_shift,
mb_type, cbp, 1);
diff --git a/libavcodec/h264_cavlc.c b/libavcodec/h264_cavlc.c
index e70bb3e..f01e760 100644
--- a/libavcodec/h264_cavlc.c
+++ b/libavcodec/h264_cavlc.c
@@ -1102,14 +1102,6 @@ decode_intra_mb:
const uint8_t *scan, *scan8x8;
const int max_qp = 51 + 6 * (h->ps.sps->bit_depth_luma - 8);
-if(IS_INTERLACED(mb_type)){
-scan8x8 = sl->qscale ? h->field_scan8x8_cavlc :
h->field_scan8x8_cavlc_q0;
-scan= sl->qscale ? h->field_scan : h->field_scan_q0;
-}else{
-scan8x8 = sl->qscale ? h->zigzag_scan8x8_cavlc :
h->zigzag_scan8x8_cavlc_q0;
-scan= sl->qscale ? h->zigzag_scan : h->zigzag_scan_q0;
-}
-
dquant= get_se_golomb(&sl->gb);
sl->qscale += (unsigned)dquant;
@@ -1126,6 +1118,14 @@ decode_intra_mb:
sl->chroma_qp[0] = get_chroma_qp(h->ps.pps, 0, sl->qscale);
sl->chroma_qp[1] = get_chroma_qp(h->ps.pps, 1, sl->qscale);
+if(IS_INTERLACED(mb_type)){
+scan8x8 = sl->qscale ? h->field_scan8x8_cavlc :
h->field_scan8x8_cavlc_q0;
+scan= sl->qscale ? h->field_scan : h->field_scan_q0;
+}else{
+scan8x8 = sl->qscale ? h->zigzag_scan8x8_cavlc :
h->zigzag_scan8x8_cavlc_q0;
+scan= sl->qscale ? h->zigzag_scan : h->zigzag_scan_q0;
+}
+
if ((ret = decode_luma_residual(h, sl, gb, scan, scan8x8, pixel_shift,
mb_type, cbp, 0)) < 0 ) {
return -1;
}
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration
2017-06-15 21:23 GMT+02:00 Nicolas George : > Le septidi 27 prairial, an CCXXV, Thomas Mundt a écrit : > > Hmm, before rewriting and sending this patch I asked if it would have a > > chance to be pushed just to fix the ticket which is open for a very long > > time. Your answer gave me the assumtion that you´re okay with it. > > I thought your only concern was the not allowed use of pkt_duration. > > I am ok in principle with a patch that uses the frame rate instead of > the correct final timestamp. But not any such patch. > > I am not ok with a patch that makes the code more complex. I will at > some point start again working on this, and any extra code complexity > will make my life harder. > > In particular, I am never ok with a patch that copy-pastes and > duplicates a non-trivial block of code. > > In fact, even if your patch was perfect in its logic, i.e. used the > correct final timestamp, I would reject it based on the code complexity > and duplication. > > As I said : the moment you used the "copy" feature of your editor on a > non-trivial block of code, you should have stopped and taken a step back > to look at the big picture. > I´m afraid the big picture might be to big for me. The only thing I see that could be factored out is the delta for loop. And even this would need much more investigation and testing form my side. Unfortunately my time is too limited atm. I think I understand your position, so I hope one day you will find the time for the right fix. Regards, Thomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration
On 6/15/17, Thomas Mundt wrote: > 2017-06-15 21:23 GMT+02:00 Nicolas George : > >> Le septidi 27 prairial, an CCXXV, Thomas Mundt a ecrit : >> > Hmm, before rewriting and sending this patch I asked if it would have a >> > chance to be pushed just to fix the ticket which is open for a very long >> > time. Your answer gave me the assumtion that you're okay with it. >> > I thought your only concern was the not allowed use of pkt_duration. >> >> I am ok in principle with a patch that uses the frame rate instead of >> the correct final timestamp. But not any such patch. >> >> I am not ok with a patch that makes the code more complex. I will at >> some point start again working on this, and any extra code complexity >> will make my life harder. >> >> In particular, I am never ok with a patch that copy-pastes and >> duplicates a non-trivial block of code. >> >> In fact, even if your patch was perfect in its logic, i.e. used the >> correct final timestamp, I would reject it based on the code complexity >> and duplication. >> >> As I said : the moment you used the "copy" feature of your editor on a >> non-trivial block of code, you should have stopped and taken a step back >> to look at the big picture. >> > > I'm afraid the big picture might be to big for me. > The only thing I see that could be factored out is the delta for loop. And > even this would need much more investigation and testing form my side. > Unfortunately my time is too limited atm. > I think I understand your position, so I hope one day you will find the > time for the right fix. Yeah, right! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nvenc: Make AUD optional for h264_nvenc and hevc_nvenc
Yes, please try the latest driver version. Thanks Yogender > On 13-Jun-2017, at 6:47 PM, Ali KIZIL wrote: > > 2017-01-05 13:29 GMT+03:00 Yogender Gupta : > There is BUG in Nvidia NVENC when you use AUD for H264 with B-frames, >> it will return corrupted stream, because NVIDIA is inserting AUD type 0 >> (I-frame) before B-frames instead of AUD type 7 (any-frame). >> >> Thanks for bringing this to notice. We have added a fix in the Nvidia >> driver and the newer driver releases will insert the correct AUD type. >> >> Thanks, >> Yogender >> >> >> --- >> This email message is for the sole use of the intended recipient(s) and >> may contain >> confidential information. Any unauthorized review, use, disclosure or >> distribution >> is prohibited. If you are not the intended recipient, please contact the >> sender by >> reply email and destroy all copies of the original message. >> >> --- >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > Yogender, is new driver released for correct AUD type insertion ? > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: add mpeg2 decoder/hwaccel to mediacodec
On Fri, Jun 2, 2017 at 6:16 AM, Matthieu Bouron
wrote:
> Hi,
>
> On Fri, Jun 02, 2017 at 04:23:41AM -0400, Aman Gupta wrote:
> > From: Aman Gupta
> >
> > Android TV and FireOS hardware supports mpeg2 hardware decoding via
> MediaCodec.
> > ---
> > configure | 2 ++
> > libavcodec/Makefile| 1 +
> > libavcodec/allcodecs.c | 2 ++
> > libavcodec/mediacodecdec.c | 23 ++-
> > 4 files changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index 72060ef0e9..5816de2398 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2656,6 +2656,7 @@ mpeg2_d3d11va_hwaccel_deps="d3d11va"
> > mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
> > mpeg2_dxva2_hwaccel_deps="dxva2"
> > mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
> > +mpeg2_mediacodec_hwaccel_deps="mediacodec"
> > mpeg2_mmal_hwaccel_deps="mmal"
> > mpeg2_qsv_hwaccel_deps="libmfx"
> > mpeg2_qsv_hwaccel_select="qsvdec_mpeg2"
> > @@ -2762,6 +2763,7 @@ mpeg1_vdpau_decoder_select="mpeg1video_decoder"
> > mpeg2_crystalhd_decoder_select="crystalhd"
> > mpeg2_cuvid_decoder_deps="cuda cuvid"
> > mpeg2_mmal_decoder_deps="mmal"
> > +mpeg2_mediacodec_decoder_deps="mediacodec"
> > mpeg2_qsv_decoder_deps="libmfx"
> > mpeg2_qsv_decoder_select="qsvdec mpeg2_qsv_hwaccel"
> > mpeg2_qsv_encoder_deps="libmfx"
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 0818950ad9..a752f87ef5 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -423,6 +423,7 @@ OBJS-$(CONFIG_MPEG2_QSV_DECODER) +=
> qsvdec_other.o
> > OBJS-$(CONFIG_MPEG2_QSV_ENCODER) += qsvenc_mpeg2.o
> > OBJS-$(CONFIG_MPEG2VIDEO_DECODER) += mpeg12dec.o mpeg12.o
> mpeg12data.o
> > OBJS-$(CONFIG_MPEG2VIDEO_ENCODER) += mpeg12enc.o mpeg12.o
> > +OBJS-$(CONFIG_MPEG2_MEDIACODEC_DECODER) += mediacodecdec.o
> > OBJS-$(CONFIG_MPEG2_VAAPI_ENCODER) += vaapi_encode_mpeg2.o
> > OBJS-$(CONFIG_MPEG4_DECODER) += xvididct.o
> > OBJS-$(CONFIG_MPEG4_MEDIACODEC_DECODER) += mediacodecdec.o
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index 89fadcd2fa..4373ebd975 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -96,6 +96,7 @@ static void register_all(void)
> > REGISTER_HWACCEL(MPEG2_VAAPI, mpeg2_vaapi);
> > REGISTER_HWACCEL(MPEG2_VDPAU, mpeg2_vdpau);
> > REGISTER_HWACCEL(MPEG2_VIDEOTOOLBOX, mpeg2_videotoolbox);
> > +REGISTER_HWACCEL(MPEG2_MEDIACODEC, mpeg2_mediacodec);
> > REGISTER_HWACCEL(MPEG4_CUVID, mpeg4_cuvid);
> > REGISTER_HWACCEL(MPEG4_MEDIACODEC, mpeg4_mediacodec);
> > REGISTER_HWACCEL(MPEG4_MMAL,mpeg4_mmal);
> > @@ -257,6 +258,7 @@ static void register_all(void)
> > REGISTER_DECODER(MPEG2_MMAL,mpeg2_mmal);
> > REGISTER_DECODER(MPEG2_CRYSTALHD, mpeg2_crystalhd);
> > REGISTER_DECODER(MPEG2_QSV, mpeg2_qsv);
> > +REGISTER_DECODER(MPEG2_MEDIACODEC, mpeg2_mediacodec);
> > REGISTER_DECODER(MSA1, msa1);
> > REGISTER_DECODER(MSCC, mscc);
> > REGISTER_DECODER(MSMPEG4V1, msmpeg4v1);
> > diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> > index ccfcb4b9ce..f3f6155392 100644
> > --- a/libavcodec/mediacodecdec.c
> > +++ b/libavcodec/mediacodecdec.c
> > @@ -1,5 +1,5 @@
> > /*
> > - * Android MediaCodec H.264 / H.265 / MPEG-4 / VP8 / VP9 decoders
> > + * Android MediaCodec MPEG-2 / H.264 / H.265 / MPEG-4 / VP8 / VP9
> decoders
> > *
> > * Copyright (c) 2015-2016 Matthieu Bouron stupeflix.com>
> > *
> > @@ -333,6 +333,11 @@ static av_cold int
> > mediacodec_decode_init(AVCodecContext
> *avctx)
> > goto done;
> > break;
> > #endif
> > +#if CONFIG_MPEG2_MEDIACODEC_DECODER
> > +case AV_CODEC_ID_MPEG2VIDEO:
> > +codec_mime = "video/mpeg2",
>
> This line should end with a ;
>
> > +break;
> > +#endif
> > #if CONFIG_MPEG4_MEDIACODEC_DECODER
> > case AV_CODEC_ID_MPEG4:
> > codec_mime = "video/mp4v-es",
> > @@ -575,6 +580,22 @@ AVCodec ff_hevc_mediacodec_decoder = {
> > };
> > #endif
> >
> > +#if CONFIG_MPEG2_MEDIACODEC_DECODER
> > +AVCodec ff_mpeg2_mediacodec_decoder = {
> > +.name = "mpeg2_mediacodec",
> > +.long_name = NULL_IF_CONFIG_SMALL("MPEG-2 Android MediaCodec
> decoder"),
> > +.type = AVMEDIA_TYPE_VIDEO,
> > +.id = AV_CODEC_ID_MPEG2VIDEO,
> > +.priv_data_size = sizeof(MediaCodecH264DecContext),
> > +.init = mediacodec_decode_init,
> > +.decode = mediacodec_decode_frame,
> > +.flush = mediacodec_decode_flush,
> > +.close = mediacodec_decode_close,
> > +.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING,
> > +.caps_internal = FF_CODEC_CAP_SETS_PKT_DTS,
> > +};
> > +#endif
> > +
> > #if CONFIG_MPEG4_MEDIACODEC_DECODER
> > AVCodec ff_mpeg4_mediacodec_deco
[FFmpeg-devel] Patch to fix Chromium issues with ARMv8
Hi there, Here's a patch requested by Google in the context of the Chromium project. See: https://bugs.chromium.org/p/chromium/issues/detail?id=686903 The ARMv8 deprecates some IT block usage that this patch tries to address. I've ran some regression tests (the part that works on a native ARM build), and it looks fine, but some tests are failing for a vanilla top of the tree ffmpeg, so it's hard for me to confirm unless you trust me because I have tested the only relevant part of this patch thoroughly with my own unit tests. This patch does not add any new regressions. Please advise if this is not the right way to send a patch Thanks IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. p Description: p ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add A53 Closed Captions to MPEG header if they are available.
Indeed, multiple entries of the same type are really a bad idea and we basically made them impossible with stream sidedata, although maybe not with frame side data yet. We should not add API for them or encourage their use. If there is a real need for multiple of the same type, maybe the type should be expanded to hold more information. The cc_count is only 5 bits, which mean that only 31 3-byte "closed caption constructs" will fit in a "block".Testing this with 1080i60 material, I found that 2 or 3 blocks was often necessary to hold all of the CC data. I tried ignoring that limit of 31 "constructs" per block, and ended up with corrupt captions. By preserving the 2 or 3 separate blocks I observed from the original source, the captions are perfect. According to CEA-708, in the case of 1080i60, the correct number for cc_count is 10. The highest number that cc_count is allowed to be is 30 in the case of repeating a frame three times for film mode. Exceeding the correct cc_count for the frame rate would cause the CC channel data rate to exceed 9,600bps. ~Brian ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Update decode_simple_internal() to get the side data correctly.
From 6418fc43b06cea4cf49e410d474ae92022c4dbd1 Mon Sep 17 00:00:00 2001
From: John Rummell
Date: Wed, 14 Jun 2017 14:43:04 -0700
Subject: [PATCH] Update decode_simple_internal() to get the side data
correctly.
When FF_API_MERGE_SD is set, the compressed side data is expanded into
|tmp|,
leaving the original |pkt| unchanged. So when retrieving side data, get it
from |tmp|. If the side data is not compressed, |tmp| is a copy of |pkt|
so the side data should be accessible from either.
---
libavcodec/decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 584d9d6241..327fb8ccb7 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -462,7 +462,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
frame->sample_rate = avctx->sample_rate;
}
-side= av_packet_get_side_data(pkt, AV_PKT_DATA_SKIP_SAMPLES,
&side_size);
+side= av_packet_get_side_data(&tmp, AV_PKT_DATA_SKIP_SAMPLES,
&side_size);
if(side && side_size>=10) {
avctx->internal->skip_samples = AV_RL32(side) *
avctx->internal->skip_samples_multiplier;
discard_padding = AV_RL32(side + 4);
--
2.13.1.518.g3df882009-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Patch for FPE (floating point exception)
Dear developers, Most unfortunately I found 2 bugs in ffserver.c Both are related to floating point bugs. I wrote a patch and submitted it on git: https://github.com/masikh/FFmpeg/commit/50326ef568.patch I hope it helps! Kind regards, Robert Nagtegaal Alias: Masikh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch to fix Chromium issues with ARMv8
On Sat, Jun 3, 2017 at 12:57 AM, Amaury LeLeyzour wrote: > Hi there, > > > Here's a patch requested by Google in the context of the Chromium project. > See: > > https://bugs.chromium.org/p/chromium/issues/detail?id=686903 > > > The ARMv8 deprecates some IT block usage that this patch tries to address. > I've ran some regression tests (the part that works on a native ARM build), > and it looks fine, but some tests are failing for a vanilla top of the tree > ffmpeg, so it's hard for me to confirm unless you trust me because I have > tested the only relevant part of this patch thoroughly with my own unit > tests. This patch does not add any new regressions. > Your implementation of FASTDIV looks almost like the original macro we have in the generic code, if there is no need for an optimized assembly, then it should be removed entirely, and fallback to the generic macro. On that note, wouldn't older systems still benefit from having the assembly over the C code, and it should just be disabled conditionally if needed? A similar thing goes for av_clipl_int32_arm, we generally don't like "platform optimized" C code, either we can tune the original C code to be fast, or we write CPU specific assembly. Same remark about older systems applies. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update decode_simple_internal() to get the side data correctly.
On 6/14/2017 9:04 PM, John Rummell wrote: > From 6418fc43b06cea4cf49e410d474ae92022c4dbd1 Mon Sep 17 00:00:00 2001 > From: John Rummell > Date: Wed, 14 Jun 2017 14:43:04 -0700 > Subject: [PATCH] Update decode_simple_internal() to get the side data > correctly. > > When FF_API_MERGE_SD is set, the compressed side data is expanded into > |tmp|, > leaving the original |pkt| unchanged. So when retrieving side data, get it > from |tmp|. If the side data is not compressed, |tmp| is a copy of |pkt| > so the side data should be accessible from either. > --- > libavcodec/decode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/decode.c b/libavcodec/decode.c > index 584d9d6241..327fb8ccb7 100644 > --- a/libavcodec/decode.c > +++ b/libavcodec/decode.c > @@ -462,7 +462,7 @@ FF_ENABLE_DEPRECATION_WARNINGS > frame->sample_rate = avctx->sample_rate; > } > > -side= av_packet_get_side_data(pkt, AV_PKT_DATA_SKIP_SAMPLES, > &side_size); > +side= av_packet_get_side_data(&tmp, AV_PKT_DATA_SKIP_SAMPLES, > &side_size); Could you please test if using avci->last_pkt_props instead of &tmp also works for you? I'm the one that changed it from avci->last_pkt_props (which contains packet properties, including side data, as taken from tmp post side data splitting) to pkt two months ago, if i remember correctly because it fixed a regression in some test, but I'm unable to reproduce anything if i revert it right now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?
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 Thank you for your understanding. Best regards. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for FPE (floating point exception)
On Tue, Jun 06, 2017 at 06:41:55PM +0200, Robert Nagtegaal wrote:
> Dear developers,
>
> Most unfortunately I found 2 bugs in ffserver.c Both are related to
> floating point bugs. I wrote a patch and submitted it on git:
>
> https://github.com/masikh/FFmpeg/commit/50326ef568.patch
> commit 46f83db9da7397b1d390a98aecd8d812dee37d98 (HEAD -> master)
> Author: Robert Nagtegaal
> Date: Tue Jun 6 18:34:23 2017 +0200
>
> Update ffserver.c
The first line should summarize the commit
that says too little and is too generic
>
> This patch fixes a floating point exception. You are not allowed to
> defide by zero (FPE)
This is missing an explanation of how/why the variables are 0
Its important in judging if the fix is correct.
also patches should be sent to the mailing list not just linked to
>
> diff --git a/ffserver.c b/ffserver.c
> index f9f987acac..2faa4bc06a 100644
> --- a/ffserver.c
> +++ b/ffserver.c
> @@ -466,7 +466,7 @@ static void update_datarate(DataRateData *drd, int64_t
> count)
> /* In bytes per second */
> static int compute_datarate(DataRateData *drd, int64_t count)
> {
> -if (cur_time == drd->time1)
> +if (cur_time == drd->time1 || cur_time == 0 || drd->time1 == 0)
> return 0;
>
> return ((count - drd->count1) * 1000) / (cur_time - drd->time1);
> @@ -1905,10 +1905,16 @@ static inline void print_stream_params(AVIOContext
> *pb, FFServerStream *stream)
> break;
> case AVMEDIA_TYPE_VIDEO:
> type = "video";
> -snprintf(parameters, sizeof(parameters),
> - "%dx%d, q=%d-%d, fps=%d", st->codecpar->width,
> - st->codecpar->height, st->codec->qmin, st->codec->qmax,
> - st->time_base.den / st->time_base.num);
> +if (st->time_base.num != 0) {
> +snprintf(parameters, sizeof(parameters),
> + "%dx%d, q=%d-%d, fps=%d", st->codecpar->width,
> + st->codecpar->height, st->codec->qmin,
> st->codec->qmax,
> + st->time_base.den / st->time_base.num);
> +} else {
> +snprintf(parameters, sizeof(parameters),
> + "%dx%d, q=%d-%d, fps=0", st->codecpar->width,
> + st->codecpar->height, st->codec->qmin,
> st->codec->qmax);
> +}
> break;
> default:
> abort();
>
>
>
> I hope it helps!
>
> Kind regards,
>
> Robert Nagtegaal
> Alias: Masikh
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
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/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions
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) [...] -- 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
[FFmpeg-devel] [PATCH] avformat/hlsenc: donnot show duplicate segment warning at byterange mode
When the hlsenc at BYTERANGE mode, it should not show the warning message:
"Duplicated segment filename detected:"
Reported-by: Marco
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 7ed121a..40143c8 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -722,6 +722,7 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
{
HLSSegment *en = av_malloc(sizeof(*en));
const char *filename;
+int byterange_mode = (hls->flags & HLS_SINGLE_FILE) || (hls->max_seg_size
> 0);
int ret;
if (!en)
@@ -737,8 +738,8 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
if (hls->use_localtime_mkdir) {
filename = hls->avf->filename;
}
-if (find_segment_by_filename(hls->segments, filename)
-|| find_segment_by_filename(hls->old_segments, filename)) {
+if ((find_segment_by_filename(hls->segments, filename) ||
find_segment_by_filename(hls->old_segments, filename))
+&& !byterange_mode) {
av_log(hls, AV_LOG_WARNING, "Duplicated segment filename detected:
%s\n", filename);
}
av_strlcpy(en->filename, filename, sizeof(en->filename));
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/aacps: move checks for valid length outside the stereo_interpolate dsp function
On 6/14/2017 11:33 PM, James Almer wrote: > On 6/3/2017 2:04 PM, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavcodec/aacps.c | 7 --- >> libavcodec/x86/aacpsdsp.asm | 6 -- >> 2 files changed, 4 insertions(+), 9 deletions(-) > > I'll push this soon if nobody comments. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
