Re: [FFmpeg-devel] [PATCH] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.
>Why is "block" not aligned? Does the code for other architectures also use
>unaligned instructions for
>these?
Thank you for reminding me. After checking the struct H264SliceContext and
function call process, 'block' is find out as 16-bit aligned.
There are some refines in this patch, I will upload them in a new patch and
only keep the following changes in this patch(V2).
>> diff --git a/libavcodec/mips/simple_idct_mmi.c
>> b/libavcodec/mips/simple_idct_mmi.c
>> index 7f4bb74..f54f9ea 100644
>> --- a/libavcodec/mips/simple_idct_mmi.c
>> +++ b/libavcodec/mips/simple_idct_mmi.c
>> @@ -39,7 +39,7 @@
>> #define COL_SHIFT 20
>> #define DC_SHIFT 3
>>
>> -DECLARE_ALIGNED(8, const int16_t, W_arr)[46] = {
>> +DECLARE_ALIGNED(16, const int16_t, W_arr)[46] = {
>> W4, W2, W4, W6,
>> W1, W3, W5, W7,
>> W4, W6, -W4, -W2,
>> diff --git a/libavutil/mips/mmiutils.h b/libavutil/mips/mmiutils.h
>> index 05f6b31..bfa6d8b 100644
>> --- a/libavutil/mips/mmiutils.h
>> +++ b/libavutil/mips/mmiutils.h
>> @@ -205,7 +205,7 @@
>> * backup register
>> */
>> #define BACKUP_REG \
>> - double temp_backup_reg[8];\
>> + double __attribute__ ((aligned (16))) temp_backup_reg[8]; \
>> if (_MIPS_SIM == _ABI64) \
>> __asm__ volatile ( \
>> "gssqc1 $f25, $f24, 0x00(%[temp]) \n\t" \
>> --
>> 2.1.0
>ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.
Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned.
---
libavcodec/mips/simple_idct_mmi.c | 2 +-
libavutil/mips/mmiutils.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mips/simple_idct_mmi.c
b/libavcodec/mips/simple_idct_mmi.c
index 7f4bb74..73d797f 100644
--- a/libavcodec/mips/simple_idct_mmi.c
+++ b/libavcodec/mips/simple_idct_mmi.c
@@ -39,7 +39,7 @@
#define COL_SHIFT 20
#define DC_SHIFT 3
-DECLARE_ALIGNED(8, const int16_t, W_arr)[46] = {
+DECLARE_ALIGNED(16, const int16_t, W_arr)[46] = {
W4, W2, W4, W6,
W1, W3, W5, W7,
W4, W6, -W4, -W2,
diff --git a/libavutil/mips/mmiutils.h b/libavutil/mips/mmiutils.h
index 05f6b31..bfa6d8b 100644
--- a/libavutil/mips/mmiutils.h
+++ b/libavutil/mips/mmiutils.h
@@ -205,7 +205,7 @@
* backup register
*/
#define BACKUP_REG \
- double temp_backup_reg[8];\
+ double __attribute__ ((aligned (16))) temp_backup_reg[8]; \
if (_MIPS_SIM == _ABI64) \
__asm__ volatile ( \
"gssqc1 $f25, $f24, 0x00(%[temp]) \n\t" \
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
On 24.07.2019, at 02:39, Kieran Kunhya wrote: >> >> What was the cause of the slow decoding? Does this actually fix it, or >> does it just swipe it "under the carpet"? >> If someone ever found a sample with a different solution, how would they >> know that they shouldn't just remove this again? Without any kind of >> comment on the point of this call, people might assume it's pointless >> nonsense. >> > > A significant proportion of these patches sweep the issue under the carpet. Which is not necessarily the wrong choice. But by leaving no documentation a lot of the time spend on writing the patches is wasted since the knowledge gained is just lost, maintainers need to "reverse-engineer" them etc. > Not to mention the swathes of annoyed developers And let's not turn this into a conflict, I just tried to give clear feedback why I am unhappy with some of these patches even though they may be worthwhile still. > Hopefully some of that also captures reasons others feel unhappy (and it would be nice if the concerns could be raised more constructively, though I do acknowledge it can be hard). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale
On 24-07-2019 08:15 AM, Fu, Linjie wrote:
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
Of Gyan
Sent: Wednesday, July 24, 2019 00:49
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
autoscale to disable/enable the default scale
On 22-07-2019 01:40 PM, Fu, Linjie wrote:
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
Behalf
Of Gyan
Sent: Saturday, July 20, 2019 13:29
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
autoscale to disable/enable the default scale
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index cd35eb49c8..99121b6981 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
+@item -autoscale
+Automatically scale the video according to the resolution of first frame.
+Enabled by default, use @option{-noautoscale} to disable it. When
autoscale is
+disabled, all output frames might not be in the same resolution and
may
require
+some additional explicit processing according to your final
rendering/output
+destination. Disabling autoscale may not work in all situations.
Therefore,
it
+is not recommended to disable it unless you really know what you are
doing.
+Disable autoscale at your own risk.
Since the auto scaling happens at the end of the graph, what may the
"additional explicit processing" be?
Vpp processing may not be influenced, a warning in transcode is needed.
The expression seems to be improper, how about:
"When autoscale is disabled, all output frames of filter graph might not be
in the same
resolution and may be inadequate for encoder/muxer."
or other suggestions?
@@ -3640,6 +3642,12 @@ const OptionDef options[] = {
{ "autorotate", HAS_ARG | OPT_BOOL | OPT_SPEC |
OPT_EXPERT | OPT_INPUT,
{ .off =
OFFSET(autorotate) },
"automatically insert correct rotate filters" },
+{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
+ OPT_EXPERT | OPT_INPUT,
{ .off =
OFFSET(autoscale) },
+"automatically insert a scale filter at the end of the filter graph if
a
resolution"
+"change is detected. This ensures all frames are the same
resolution
as the first frame"
+"when they leave the filter chain (this option is enabled by
default)."
+"If disabled, some encoders/muxers may not support this mode."},
Which muxers can detect or check for prop changes within coded
bitstreams? Which encoders are known to be able to handle
changing resolution?
It's not supported currently (even in libvpx-vp9, since vp9 supports
dynamic resolution in spec).
I don't intend to be so absolutely in doc, will it be better for you to modify
like:
"If disabled, encoders/muxers won't support this mode currently."
So other than `-c:v rawvideo -f rawvideo`, there is no combination
that supports changing frame sizes?
I didn't check all encoders.
But since the resolution changing is detectable, some additional reinit
procedures
can be added to change resolution at IDR frame and make the encoder works.
They could, but as of now, which encoder + muxer combinations are
**known** to work?
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Gyan
> Sent: Wednesday, July 24, 2019 00:49
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
>
>
>
> On 22-07-2019 01:40 PM, Fu, Linjie wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Gyan
> >> Sent: Saturday, July 20, 2019 13:29
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> >> autoscale to disable/enable the default scale
> >>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> >>> index cd35eb49c8..99121b6981 100644
> >>> --- a/doc/ffmpeg.texi
> >>> +++ b/doc/ffmpeg.texi
> >>> +@item -autoscale
> >>> +Automatically scale the video according to the resolution of first frame.
> >>> +Enabled by default, use @option{-noautoscale} to disable it. When
> >> autoscale is
> >>> +disabled, all output frames might not be in the same resolution and
> may
> >> require
> >>> +some additional explicit processing according to your final
> >> rendering/output
> >>> +destination. Disabling autoscale may not work in all situations.
> Therefore,
> >> it
> >>> +is not recommended to disable it unless you really know what you are
> >> doing.
> >>> +Disable autoscale at your own risk.
> >> Since the auto scaling happens at the end of the graph, what may the
> >> "additional explicit processing" be?
> > Vpp processing may not be influenced, a warning in transcode is needed.
> > The expression seems to be improper, how about:
> >
> > "When autoscale is disabled, all output frames of filter graph might not be
> in the same
> > resolution and may be inadequate for encoder/muxer."
> >
> > or other suggestions?
> >
> >>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
> >>>{ "autorotate", HAS_ARG | OPT_BOOL | OPT_SPEC |
> >>> OPT_EXPERT | OPT_INPUT,
> >>> { .off =
> >> OFFSET(autorotate) },
> >>>"automatically insert correct rotate filters" },
> >>> +{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
> >>> + OPT_EXPERT | OPT_INPUT,
> >>> { .off =
> >> OFFSET(autoscale) },
> >>> +"automatically insert a scale filter at the end of the filter
> >>> graph if a
> >> resolution"
> >>> +"change is detected. This ensures all frames are the same
> resolution
> >> as the first frame"
> >>> +"when they leave the filter chain (this option is enabled by
> default)."
> >>> +"If disabled, some encoders/muxers may not support this mode."},
> >> Which muxers can detect or check for prop changes within coded
> >> bitstreams? Which encoders are known to be able to handle
> >> changing resolution?
> > It's not supported currently (even in libvpx-vp9, since vp9 supports
> dynamic resolution in spec).
> >
> > I don't intend to be so absolutely in doc, will it be better for you to
> > modify
> like:
> > "If disabled, encoders/muxers won't support this mode currently."
>
> So other than `-c:v rawvideo -f rawvideo`, there is no combination
> that supports changing frame sizes?
I didn't check all encoders.
But since the resolution changing is detectable, some additional reinit
procedures
can be added to change resolution at IDR frame and make the encoder works.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
> > What was the cause of the slow decoding? Does this actually fix it, or > does it just swipe it "under the carpet"? > If someone ever found a sample with a different solution, how would they > know that they shouldn't just remove this again? Without any kind of > comment on the point of this call, people might assume it's pointless > nonsense. > A significant proportion of these patches sweep the issue under the carpet. Not to mention the swathes of annoyed developers Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
On 22.07.2019, at 23:57, Michael Niedermayer wrote: > The dimensions are always 320x200 they are hardcoded in the demuxer. > Hardcode them instead in the decoder. > > Fixes: Timeout (16sec -> 400ms) > Fixes: > 15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/rl2.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavcodec/rl2.c b/libavcodec/rl2.c > index 6662979c52..2d336a61e5 100644 > --- a/libavcodec/rl2.c > +++ b/libavcodec/rl2.c > @@ -134,10 +134,15 @@ static av_cold int rl2_decode_init(AVCodecContext > *avctx) > Rl2Context *s = avctx->priv_data; > int back_size; > int i; > +int ret; > > s->avctx = avctx; > avctx->pix_fmt = AV_PIX_FMT_PAL8; > > +ret = ff_set_dimensions(avctx, 320, 200); > +if (ret < 0) > +return ret; I really dislike these completely comment-less patches. So it seems this is only based on what our demuxer does. However does the format itself have any inherent size limitations? What was the cause of the slow decoding? Does this actually fix it, or does it just swipe it "under the carpet"? If someone ever found a sample with a different solution, how would they know that they shouldn't just remove this again? Without any kind of comment on the point of this call, people might assume it's pointless nonsense. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.
Why is "block" not aligned? Does the code for other architectures also use unaligned instructions for these? On 23.07.2019, at 09:27, Shiyou Yin wrote: > Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned. > --- > libavcodec/mips/h264dsp_mmi.c | 48 +--- > libavcodec/mips/simple_idct_mmi.c | 51 +-- > libavutil/mips/mmiutils.h | 2 +- > 3 files changed, 51 insertions(+), 50 deletions(-) > > diff --git a/libavcodec/mips/h264dsp_mmi.c b/libavcodec/mips/h264dsp_mmi.c > index ac65a20..a85d782 100644 > --- a/libavcodec/mips/h264dsp_mmi.c > +++ b/libavcodec/mips/h264dsp_mmi.c > @@ -38,6 +38,11 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, > int stride) > MMI_LDC1(%[ftmp2], %[src], 0x08) > MMI_LDC1(%[ftmp3], %[src], 0x10) > MMI_LDC1(%[ftmp4], %[src], 0x18) > +/* memset(src, 0, 32); */ > +MMI_USDC1(%[ftmp0], %[src], 0x00) > +MMI_USDC1(%[ftmp0], %[src], 0x08) > +MMI_USDC1(%[ftmp0], %[src], 0x10) > +MMI_USDC1(%[ftmp0], %[src], 0x18) > MMI_ULWC1(%[ftmp5], %[dst0], 0x00) > MMI_ULWC1(%[ftmp6], %[dst1], 0x00) > MMI_ULWC1(%[ftmp7], %[dst2], 0x00) > @@ -58,11 +63,6 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, > int stride) > MMI_SWC1(%[ftmp2], %[dst1], 0x00) > MMI_SWC1(%[ftmp3], %[dst2], 0x00) > MMI_SWC1(%[ftmp4], %[dst3], 0x00) > - > -/* memset(src, 0, 32); */ > -"xor%[ftmp0], %[ftmp0], %[ftmp0]\n\t" > -"gssqc1 %[ftmp0], %[ftmp0], 0x00(%[src])\n\t" > -"gssqc1 %[ftmp0], %[ftmp0], 0x10(%[src])\n\t" > : [ftmp0]"=&f"(ftmp[0]),[ftmp1]"=&f"(ftmp[1]), > [ftmp2]"=&f"(ftmp[2]),[ftmp3]"=&f"(ftmp[3]), > [ftmp4]"=&f"(ftmp[4]),[ftmp5]"=&f"(ftmp[5]), > @@ -85,15 +85,21 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, > int stride) > DECLARE_VAR_ADDRT; > > __asm__ volatile ( > -"dli%[tmp0],0x01\n\t" > MMI_LDC1(%[ftmp0], %[block], 0x00) > -"mtc1 %[tmp0],%[ftmp8]\n\t" > MMI_LDC1(%[ftmp1], %[block], 0x08) > -"dli%[tmp0],0x06\n\t" > MMI_LDC1(%[ftmp2], %[block], 0x10) > +MMI_LDC1(%[ftmp3], %[block], 0x18) > +/* memset(block, 0, 32) */ > +"xor%[ftmp4], %[ftmp4], %[ftmp4]\n\t" > +MMI_USDC1(%[ftmp4], %[block], 0x00) > +MMI_USDC1(%[ftmp4], %[block], 0x08) > +MMI_USDC1(%[ftmp4], %[block], 0x10) > +MMI_USDC1(%[ftmp4], %[block], 0x18) > +"dli%[tmp0],0x01\n\t" > +"mtc1 %[tmp0],%[ftmp8]\n\t" > +"dli%[tmp0],0x06\n\t" > "mtc1 %[tmp0],%[ftmp9]\n\t" > "psrah %[ftmp4], %[ftmp1], %[ftmp8]\n\t" > -MMI_LDC1(%[ftmp3], %[block], 0x18) > "psrah %[ftmp5], %[ftmp3], %[ftmp8]\n\t" > "psubh %[ftmp4], %[ftmp4], %[ftmp3]\n\t" > "paddh %[ftmp5], %[ftmp5], %[ftmp1]\n\t" > @@ -121,15 +127,11 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t > *block, int stride) > "paddh %[ftmp10], %[ftmp3], %[ftmp1]\n\t" > "psubh %[ftmp1], %[ftmp1], %[ftmp3]\n\t" > "paddh %[ftmp11], %[ftmp4], %[ftmp5]\n\t" > -"xor%[ftmp7], %[ftmp7], %[ftmp7]\n\t" > "psubh %[ftmp5], %[ftmp5], %[ftmp4]\n\t" > -MMI_SDC1(%[ftmp7], %[block], 0x00) > -MMI_SDC1(%[ftmp7], %[block], 0x08) > -MMI_SDC1(%[ftmp7], %[block], 0x10) > -MMI_SDC1(%[ftmp7], %[block], 0x18) > MMI_ULWC1(%[ftmp2], %[dst], 0x00) > -"psrah %[ftmp3], %[ftmp10], %[ftmp9]\n\t" > MMI_LWXC1(%[ftmp0], %[dst], %[stride], 0x00) > +"xor%[ftmp7], %[ftmp7], %[ftmp7]\n\t" > +"psrah %[ftmp3], %[ftmp10], %[ftmp9]\n\t" > "psrah %[ftmp4], %[ftmp11], %[ftmp9]\n\t" > "punpcklbh %[ftmp2], %[ftmp2], %[ftmp7]\n\t" > "punpcklbh %[ftmp0], %[ftmp0], %[ftmp7]\n\t" > @@ -153,11 +155,6 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t > *block, int stride) > MMI_SWC1(%[ftmp2], %[dst], 0x00) > "packushb %[ftmp0], %[ftmp0], %[ft
Re: [FFmpeg-devel] Patch for IPC SHM
From: Chad Fraleigh
>
> On 7/22/2019 11:14 AM, aran.clau...@wwu.edu wrote:
>
>> +static void rm_shmid(AVFormatContext *s) {
>> +XCBGrabContext *c = s->priv_data;
>> +if(c->shmid != -1) {
>> + shmctl(c->shmid, IPC_RMID, 0);
>> + c->shmid == -1;
> ^^
> Assignment/compare operator mismatch.
>
>
>> +}
>> +}
>> +
Well, that's embarrassing.
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index b7e689343e..1acf3cdf28 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -75,6 +75,7 @@ typedef struct XCBGrabContext {
const char *framerate;
int has_shm;
+int shmid;
} XCBGrabContext;
#define FOLLOW_CENTER -1
@@ -221,6 +222,14 @@ static int check_shm(xcb_connection_t *conn)
return 0;
}
+static void rm_shmid(AVFormatContext *s) {
+XCBGrabContext *c = s->priv_data;
+if(c->shmid != -1) {
+ shmctl(c->shmid, IPC_RMID, 0);
+ c->shmid = -1;
+}
+}
+
static int allocate_shm(AVFormatContext *s)
{
XCBGrabContext *c = s->priv_data;
@@ -230,7 +239,8 @@ static int allocate_shm(AVFormatContext *s)
if (c->buffer)
return 0;
-id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0777);
+
+id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0666);
if (id == -1) {
char errbuf[1024];
int err = AVERROR(errno);
@@ -239,15 +249,20 @@ static int allocate_shm(AVFormatContext *s)
size, errbuf);
return err;
}
+
xcb_shm_attach(c->conn, c->segment, id, 0);
data = shmat(id, NULL, 0);
-shmctl(id, IPC_RMID, 0);
-if ((intptr_t)data == -1 || !data)
-return AVERROR(errno);
+
+if ((intptr_t)data == -1 || !data) {
+ shmctl(id, IPC_RMID, 0);
+ return AVERROR(errno);
+}
c->buffer = data;
+c->shmid = id;
return 0;
}
+
static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket *pkt)
{
XCBGrabContext *c = s->priv_data;
@@ -268,6 +283,8 @@ static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket
*pkt)
xcb_flush(c->conn);
+rm_shmid(s);
+
if (e) {
av_log(s, AV_LOG_ERROR,
"Cannot get the image data "
pgpuJi_hdCDXT.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Patch for IPC SHM
On 7/22/2019 11:14 AM, aran.clau...@wwu.edu wrote:
+static void rm_shmid(AVFormatContext *s) {
+XCBGrabContext *c = s->priv_data;
+if(c->shmid != -1) {
+ shmctl(c->shmid, IPC_RMID, 0);
+ c->shmid == -1;
^^
Assignment/compare operator mismatch.
+}
+}
+
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale
On 22-07-2019 01:40 PM, Fu, Linjie wrote:
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
Of Gyan
Sent: Saturday, July 20, 2019 13:29
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
autoscale to disable/enable the default scale
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index cd35eb49c8..99121b6981 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
+@item -autoscale
+Automatically scale the video according to the resolution of first frame.
+Enabled by default, use @option{-noautoscale} to disable it. When
autoscale is
+disabled, all output frames might not be in the same resolution and may
require
+some additional explicit processing according to your final
rendering/output
+destination. Disabling autoscale may not work in all situations. Therefore,
it
+is not recommended to disable it unless you really know what you are
doing.
+Disable autoscale at your own risk.
Since the auto scaling happens at the end of the graph, what may the
"additional explicit processing" be?
Vpp processing may not be influenced, a warning in transcode is needed.
The expression seems to be improper, how about:
"When autoscale is disabled, all output frames of filter graph might not be in
the same
resolution and may be inadequate for encoder/muxer."
or other suggestions?
@@ -3640,6 +3642,12 @@ const OptionDef options[] = {
{ "autorotate", HAS_ARG | OPT_BOOL | OPT_SPEC |
OPT_EXPERT | OPT_INPUT,
{ .off =
OFFSET(autorotate) },
"automatically insert correct rotate filters" },
+{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
+ OPT_EXPERT | OPT_INPUT,
{ .off =
OFFSET(autoscale) },
+"automatically insert a scale filter at the end of the filter graph if
a
resolution"
+"change is detected. This ensures all frames are the same resolution
as the first frame"
+"when they leave the filter chain (this option is enabled by default)."
+"If disabled, some encoders/muxers may not support this mode."},
Which muxers can detect or check for prop changes within coded
bitstreams? Which encoders are known to be able to handle
changing resolution?
It's not supported currently (even in libvpx-vp9, since vp9 supports dynamic
resolution in spec).
I don't intend to be so absolutely in doc, will it be better for you to modify
like:
"If disabled, encoders/muxers won't support this mode currently."
So other than `-c:v rawvideo -f rawvideo`, there is no combination
that supports changing frame sizes?
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Monday, July 22, 2019 16:11
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Gyan
> > Sent: Saturday, July 20, 2019 13:29
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> > autoscale to disable/enable the default scale
>
> > > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > > index cd35eb49c8..99121b6981 100644
> > > --- a/doc/ffmpeg.texi
> > > +++ b/doc/ffmpeg.texi
> > > +@item -autoscale
> > > +Automatically scale the video according to the resolution of first frame.
> > > +Enabled by default, use @option{-noautoscale} to disable it. When
> > autoscale is
> > > +disabled, all output frames might not be in the same resolution and may
> > require
> > > +some additional explicit processing according to your final
> > rendering/output
> > > +destination. Disabling autoscale may not work in all situations.
> > > Therefore,
> > it
> > > +is not recommended to disable it unless you really know what you are
> > doing.
> > > +Disable autoscale at your own risk.
> >
> > Since the auto scaling happens at the end of the graph, what may the
> > "additional explicit processing" be?
>
> Vpp processing may not be influenced, a warning in transcode is needed.
> The expression seems to be improper, how about:
>
> "When autoscale is disabled, all output frames of filter graph might not be in
> the same
> resolution and may be inadequate for encoder/muxer."
>
> or other suggestions?
>
> > > @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
> > > { "autorotate", HAS_ARG | OPT_BOOL | OPT_SPEC |
> > > OPT_EXPERT | OPT_INPUT,
> > > { .off =
> > OFFSET(autorotate) },
> > > "automatically insert correct rotate filters" },
> > > +{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
> > > + OPT_EXPERT | OPT_INPUT,
> > > { .off =
> > OFFSET(autoscale) },
> > > +"automatically insert a scale filter at the end of the filter
> > > graph if a
> > resolution"
> > > +"change is detected. This ensures all frames are the same
> > > resolution
> > as the first frame"
> > > +"when they leave the filter chain (this option is enabled by
> default)."
> > > +"If disabled, some encoders/muxers may not support this mode."},
> > Which muxers can detect or check for prop changes within coded
> > bitstreams? Which encoders are known to be able to handle
> > changing resolution?
>
> It's not supported currently (even in libvpx-vp9, since vp9 supports dynamic
> resolution in spec).
>
> I don't intend to be so absolutely in doc, will it be better for you to
> modify
> like:
> "If disabled, encoders/muxers won't support this mode currently."
>
Are these modifications acceptable?
If no against, will update a new version. Thanks.
- linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] avcodec: add a WavPack DSD decoder
On 7/23/19 12:47 AM, Paul B Mahol wrote: > On 7/23/19, David Bryant wrote: >> On 7/21/19 11:23 PM, Paul B Mahol wrote: >>> On 7/22/19, David Bryant wrote: Hi, As I promised late last year, here is a patch to add a WavPack DSD decoder. Thanks! -David Bryant >>> Please correct me if I'm wrong, but why this uses new codec id? >>> Apparently is also copies some logic from other files. >> Yes, I created a new codec ID for WavPack DSD. It would be possible to just >> piggyback on the existing WavPack codec by silently >> decimating the DSD to PCM, but that seemed weird and wrong to me. For one >> thing, the user would have no idea that the file was >> actually DSD and not high sample-rate PCM. >> >> Also, since regular WavPack has threading enabled but WavPack DSD can't >> (because of the dsd2pcm conversion) I would have to turn >> off threading for all WavPack (unless there's some way of making that >> conditional at runtime). It would also mean that regular >> WavPack would be dependent on the dsd2pcm component even if DSD was not >> required (not everyone needs DSD). And of course I was >> looking closely at the only other DSD codec in FFmpeg (DST) which has its >> own codec ID. >> >> Because regular WavPack PCM and DSD share the same block format and metadata >> structure, there is a little code that is shared >> between the two codecs (although they are no longer identical because of the >> threading difference). Is this a problem? I could >> combine the two codecs into one file and sprinkle in a few conditionals, but >> I don't think it would be as clean or clear (but >> might save a little duplicate code). >> >> That's my thinking, but obviously I am not as familiar with the FFmpeg >> philosophy as you guys. > Looking carefully at dsd2pcm code in your patch, it appears it would > work only with 1 or 2 channels. > Is this correct? Individual WavPack blocks can only be 1 or 2 channels. Multichannel files contains sequences of blocks which ends up creating multiple frame contexts. This was originally implemented for PCM WavPack years ago and so it "just works" for DSD WavPack because I didn't touch any of that. I have tested this extensively with multichannel DSD files and it works great, including seeking. > > About multi-threading, as dsd2pcm can not be made multi-threaded then > just do locking when doing dsd2pcm to make it single threaded and > update other code as necessary. It's not really that dsd2pcm cannot be multi-threaded, it's that the audio frames cannot be converted to PCM independently or you'll get a click at the frame boundaries. Maybe we're talking about the same thing, but I don't see how a lock would fix this. In any event, could you please show me an example of doing that? > > I still see no valid reason to add separate codec id. Add another > wavpack profile if you wish to help users know the difference between > the two. Again I apologize for not being too familiar with FFmpeg internals. What would another wavpack "profile" be? As long as the user (or caller) has some way to differentiate between DSD and PCM files without parsing the file themselves I'm happy, but what exactly is the hesitation here? Are codec IDs a limited resource? It seems like an obvious win to me. -David > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
Ready for review. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] how to create sub project / git repo under FFMPEG
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Moritz Barsnick > Sent: Tuesday, July 23, 2019 8:41 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] how to create sub project / git repo under FFMPEG > > On Mon, Jul 22, 2019 at 02:03:33 +, Guo, Yejun wrote: > > I do not mean the official repository https://git.ffmpeg.org/ffmpeg.git, I > mean another > > new repo and ffmpeg community has the right to assign/remove someone to > have the write access. > [...] > > thanks, I think we can create a git repo at > code.videolan.org/ffmpeg/dnn_material. > > Actually, http://git.videolan.org/?p=ffmpeg.git;a=summary is the > official repo (or rather its visualization). Github is the secondary > repo, a mirror. thanks Moritz, do you mean that the official repo is not https://git.ffmpeg.org/ffmpeg.git that I mentioned, but http://git.videolan.org/?p=ffmpeg.git;a=summary? I got the git repo at https://ffmpeg.org/download.html#get-sources. > > See this thread: > http://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180844.html > > Cheers, > Moritz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
Jul 23, 2019, 9:13 AM by geo...@nsup.org: > Lynne (12019-07-23): > >> Please stay out of all my emails and harassing me over apparently not >> having enough commits. >> > > What are you taking about? I have gone over your interactions on the > mailing-list, and found nothing about number of commits, nor anything > that looks to me like harassment, but I may have missed something. Can > you elaborate? > IRC. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 1/2] lavc/mjpegdec: Decode Huffman-coded lossless JPEGs embedded in DNGs
From: Nick Renieris
Main image data in DNGs is usually comprised of tiles, each of which is a
Huffman-encoded lossless JPEG.
Tested for ljpeg regressions with:
`ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi`
`ffmpeg test.avi out.avi`
The modified code in ljpeg_decode_rgb_scan runs without issues.
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 54 ---
libavcodec/mjpegdec.h | 1 +
2 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index a65bc8df15..225833d1bd 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -412,6 +412,14 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
return AVERROR_PATCHWELCOME;
}
+/* Lossless JPEGs encoded in DNGs are commonly bayer-encoded. They contain
2
+ interleaved components and the width stored in their SOF3 markers is the
+ width of each one. We only output a single component, therefore we need
+ to adjust the output image width. */
+if (s->lossless == 1 && nb_components == 2) {
+s->bayer = 1;
+width *= 2;
+}
/* if different size, realloc/alloc picture */
if (width != s->width || height != s->height || bits != s->bits ||
@@ -488,6 +496,9 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
switch (pix_fmt_id) {
+case 0x: /* for bayer-encoded huffman lossless JPEGs embedded
in DNGs */
+s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
+break;
case 0x1100:
if (s->rgb)
s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_BGR24 :
AV_PIX_FMT_BGR48;
@@ -1041,26 +1052,36 @@ static int handle_rstn(MJpegDecodeContext *s, int
nb_components)
return reset;
}
+/* Handles 1 to 4 components */
static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s, int nb_components, int
predictor, int point_transform)
{
int i, mb_x, mb_y;
+unsigned width;
uint16_t (*buffer)[4];
int left[4], top[4], topleft[4];
const int linesize = s->linesize[0];
const int mask = ((1 << s->bits) - 1) << point_transform;
int resync_mb_y = 0;
int resync_mb_x = 0;
+int vpred[6];
-if (s->nb_components != 3 && s->nb_components != 4)
+if (s->nb_components <= 0 || s->nb_components > 4)
return AVERROR_INVALIDDATA;
+
if (s->v_max != 1 || s->h_max != 1 || !s->lossless)
return AVERROR_INVALIDDATA;
-
s->restart_count = s->restart_interval;
-av_fast_malloc(&s->ljpeg_buffer, &s->ljpeg_buffer_size,
- (unsigned)s->mb_width * 4 * sizeof(s->ljpeg_buffer[0][0]));
+if (s->restart_interval == 0)
+s->restart_interval = INT_MAX;
+
+if (s->bayer)
+width = s->mb_width / nb_components; /* Interleaved, width stored is
the total so need to divide */
+else
+width = s->mb_width;
+
+av_fast_malloc(&s->ljpeg_buffer, &s->ljpeg_buffer_size, width * 4 *
sizeof(s->ljpeg_buffer[0][0]));
if (!s->ljpeg_buffer)
return AVERROR(ENOMEM);
@@ -1078,7 +1099,12 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
for (i = 0; i < 4; i++)
top[i] = left[i] = topleft[i] = buffer[0][i];
-for (mb_x = 0; mb_x < s->mb_width; mb_x++) {
+if (mb_y * s->width % s->restart_interval == 0) {
+for (i = 0; i < 6; i++)
+vpred[i] = 1 << (s->bits-1);
+}
+
+for (mb_x = 0; mb_x < width; mb_x++) {
int modified_predictor = predictor;
if (get_bits_left(&s->gb) < 1) {
@@ -1102,12 +1128,19 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
topleft[i] = top[i];
top[i] = buffer[mb_x][i];
-PREDICT(pred, topleft[i], top[i], left[i], modified_predictor);
-
dc = mjpeg_decode_dc(s, s->dc_index[i]);
if(dc == 0xF)
return -1;
+if (mb_x) {
+pred = left[i];
+} else {
+vpred[i] += dc;
+pred = vpred[i] - dc;
+}
+
+PREDICT(pred, topleft[i], top[i], pred, modified_predictor);
+
left[i] = buffer[mb_x][i] =
mask & (pred + (unsigned)(dc * (1 << point_transform)));
}
@@ -1151,6 +1184,11 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
ptr[3*mb_x + 0] = buffer[mb_x][1] + ptr[3*mb_x + 1];
ptr[3*mb_x + 2] = buffer[mb_x][2] + ptr[3*mb_x + 1];
}
+} else if (s->bayer && nb_components == 2) {
+for (mb_x = 0; mb_x < width; mb_x++) {
+((uint16_t*)ptr)[2*mb_x + 0] = buffer[mb_x][0];
+((uint16_t*)ptr)[2*mb_x + 1] = buffer[mb_x][1];
+}
}
[FFmpeg-devel] [PATCH v3 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
From: Nick Renieris
Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
This commit adds support for:
- DNG tiles
- DNG tile huffman lossless JPEG decoding
- DNG 8-bpp ("packed" as dcraw calls it) decoding
- DNG color scaling [1]
- LinearizationTable tag
- BlackLevel tag
[1]: As specified in the DNG Specification - Chapter 5
Signed-off-by: Nick Renieris
---
configure | 1 +
libavcodec/Makefile | 2 +-
libavcodec/tiff.c | 326 +++-
libavcodec/tiff.h | 2 +
4 files changed, 323 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index 5a4f507246..54163822a8 100755
--- a/configure
+++ b/configure
@@ -2813,6 +2813,7 @@ theora_decoder_select="vp3_decoder"
thp_decoder_select="mjpeg_decoder"
tiff_decoder_suggest="zlib lzma"
tiff_encoder_suggest="zlib"
+tiff_decoder_select="mjpeg_decoder"
truehd_decoder_select="mlp_parser"
truehd_encoder_select="lpc audio_frame_queue"
truemotion2_decoder_select="bswapdsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3cd73fbcc6..f814c69996 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -616,7 +616,7 @@ OBJS-$(CONFIG_TARGA_ENCODER) += targaenc.o rle.o
OBJS-$(CONFIG_TARGA_Y216_DECODER) += targa_y216dec.o
OBJS-$(CONFIG_TDSC_DECODER)+= tdsc.o
OBJS-$(CONFIG_TIERTEXSEQVIDEO_DECODER) += tiertexseqv.o
-OBJS-$(CONFIG_TIFF_DECODER)+= tiff.o lzw.o faxcompr.o tiff_data.o
tiff_common.o
+OBJS-$(CONFIG_TIFF_DECODER)+= tiff.o lzw.o faxcompr.o tiff_data.o
tiff_common.o mjpegdec.o
OBJS-$(CONFIG_TIFF_ENCODER)+= tiffenc.o rle.o lzwenc.o tiff_data.o
OBJS-$(CONFIG_TMV_DECODER) += tmv.o cga_data.o
OBJS-$(CONFIG_TRUEHD_DECODER) += mlpdec.o mlpdsp.o
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index c520d7df83..423eaf0647 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -46,6 +46,7 @@
#include "mathops.h"
#include "tiff.h"
#include "tiff_data.h"
+#include "mjpegdec.h"
#include "thread.h"
#include "get_bits.h"
@@ -54,6 +55,10 @@ typedef struct TiffContext {
AVCodecContext *avctx;
GetByteContext gb;
+/* JPEG decoding for DNG */
+AVCodecContext *avctx_mjpeg; // wrapper context for MJPEG
+AVFrame *jpgframe; // decoded JPEG tile
+
int get_subimage;
uint16_t get_page;
int get_thumbnail;
@@ -76,7 +81,9 @@ typedef struct TiffContext {
int is_bayer;
uint8_t pattern[4];
+unsigned black_level;
unsigned white_level;
+const uint16_t *dng_lut; // Pointer to DNG linearization table
uint32_t sub_ifd;
uint16_t cur_page;
@@ -86,6 +93,14 @@ typedef struct TiffContext {
int stripsizesoff, stripsize, stripoff, strippos;
LZWState *lzw;
+/* Tile support */
+int is_tiled;
+int tile_byte_counts_offset, tile_offsets_offset;
+int tile_width, tile_length;
+int tile_count;
+
+int is_jpeg; // 0 - Not JPEG, 1 - JPEG, 2 - New JPEG
+
uint8_t *deinvert_buf;
int deinvert_buf_size;
uint8_t *yuv_line;
@@ -257,11 +272,27 @@ static int add_metadata(int count, int type,
};
}
+static void av_always_inline dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
+ const uint8_t *src, int src_stride, int
width, int height, int is_u16);
+
static void av_always_inline horizontal_fill(TiffContext *s,
unsigned int bpp, uint8_t* dst,
int usePtr, const uint8_t *src,
uint8_t c, int width, int offset)
{
+/* Handle DNG images with uncompressed strips (non-tiled) */
+if (s->tiff_type == TIFF_TYPE_DNG || s->tiff_type == TIFF_TYPE_CINEMADNG) {
+dng_blit(s,
+ dst + offset,
+ width,
+ src,
+ width,
+ width,
+ 1,
+ 0);
+return;
+}
+
switch (bpp) {
case 1:
while (--width >= 0) {
@@ -712,6 +743,203 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
return 0;
}
+/**
+ * Map stored raw sensor values into linear reference values.
+ * See: DNG Specification - Chapter 5
+ */
+static uint16_t av_always_inline dng_raw_to_linear16(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+// Lookup table lookup
+if (lut) value = lut[value];
+
+// Black level subtraction
+value = av_clip_uint16_c((unsigned)value - black_level);
+
+// Color scaling
+value = av_clip_uint16_c((unsigned)(((float)value * scale_factor) *
0x));
+
+return value;
+}
+
+static uint16_t av_always_inline dng_raw_to_linear8(uint
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/hqx: Check the input data against the image size
On Tue, Jul 23, 2019 at 09:52:59AM +0200, Paul B Mahol wrote: > On 7/23/19, Michael Niedermayer wrote: > > On Tue, Jul 23, 2019 at 09:03:32AM +0200, Paul B Mahol wrote: > >> On 7/23/19, Michael Niedermayer wrote: > >> > On Mon, Jul 22, 2019 at 08:20:54AM +0200, Paul B Mahol wrote: > >> >> On 7/21/19, Michael Niedermayer wrote: > >> >> > On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote: > >> >> >> On 7/21/19, Michael Niedermayer wrote: > >> >> >> > Fixes: Timeout (22 -> 7 sec) > >> >> >> > Fixes: > >> >> >> > 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992 > >> >> >> > > >> >> >> > Found-by: continuous fuzzing process > >> >> >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > >> >> >> > Signed-off-by: Michael Niedermayer > >> >> >> > --- > >> >> >> > libavcodec/hqx.c | 4 > >> >> >> > 1 file changed, 4 insertions(+) > >> >> >> > > >> >> >> > diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c > >> >> >> > index bc24ba91d1..8639d77a41 100644 > >> >> >> > --- a/libavcodec/hqx.c > >> >> >> > +++ b/libavcodec/hqx.c > >> >> >> > @@ -471,6 +471,10 @@ static int hqx_decode_frame(AVCodecContext > >> >> >> > *avctx, > >> >> >> > void > >> >> >> > *data, > >> >> >> > avctx->height = ctx->height; > >> >> >> > avctx->bits_per_raw_sample = 10; > >> >> >> > > >> >> >> > +if (avctx->coded_width / 16 * (avctx->coded_height / 16) * > >> >> >> > +(100 - avctx->discard_damaged_percentage) / 100 > 8LL * > >> >> >> > avpkt->size) > >> >> >> > +return AVERROR_INVALIDDATA; > >> >> >> > >> >> >> Why just this change and not something better? > >> >> > > >> >> > What would you prefer exactly ? > >> >> > >> >> Something that works with pure black video. > >> > > >> > Can you share the failing video file ? > >> > I thought theres a minimum size of 1 vlc code (2 bit seem the smallest) > >> > per 16x16 block. But quite possibly i might have missed something > >> > > >> > >> This is very disappointing. There is no freely available encoder for HQX. > >> And the one who commits stuff need to make sure it does not introduce > >> regressions. > > > > The reviewer just has to explain how the problem he speaks of can > > occur. > > No, its other way around. > The patch author just has to explain how the problem he tries to solve > is valid solution by given patch. I have explained that in the very mail you just replied to. anyway, no problem ill find a way to encode a pure black hqx video or will otherwise do a more complete proof of correctness. (or of course if an issue is found by doing so improve the patch) I just thought if you know of a issue and told me what it is exactly that would be much simpler and quicker. Thanks [...] -- 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: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avutil/mips: refine msa macro SLDI_Bn.
From: gxw Changing details as following: 1. Refine arguments of SLDI_Bn to make it easier to understand. 2. Remove SLDI_Bn_0, and use SLDI_Bn instead. Signed-off-by: Shiyou Yin --- libavcodec/mips/h264dsp_msa.c | 9 ++-- libavcodec/mips/h264qpel_msa.c | 64 ++-- libavcodec/mips/hevc_lpf_sao_msa.c | 70 --- libavcodec/mips/hevcpred_msa.c | 30 ++--- libavcodec/mips/hpeldsp_msa.c | 66 ++--- libavcodec/mips/me_cmp_msa.c| 8 ++-- libavcodec/mips/qpeldsp_msa.c | 84 ++--- libavcodec/mips/vp8_mc_msa.c| 4 +- libavcodec/mips/vp9_idct_msa.c | 3 +- libavcodec/mips/vp9_lpf_msa.c | 3 +- libavcodec/mips/vp9_mc_msa.c| 16 +++ libavutil/mips/generic_macros_msa.h | 80 ++- 12 files changed, 222 insertions(+), 215 deletions(-) diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c index 89fe399..189c4cf 100644 --- a/libavcodec/mips/h264dsp_msa.c +++ b/libavcodec/mips/h264dsp_msa.c @@ -620,7 +620,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, \ out0 = (v16u8) __msa_ilvr_b((v16i8) in1, (v16i8) in0); \ out1 = (v16u8) __msa_sldi_b(zero_m, (v16i8) out0, 2);\ -SLDI_B2_0_UB(out1, out2, out2, out3, 2); \ +SLDI_B2_UB(out1, zero_m, out2, zero_m, 2, out2, out3); \ } #define AVC_LPF_H_2BYTE_CHROMA_422(src, stride, tc_val, alpha, beta, res) \ @@ -1025,7 +1025,8 @@ static void avc_h_loop_filter_luma_mbaff_intra_msa(uint8_t *src, int32_t stride, ILVR_W2_SB(tmp2, tmp0, tmp3, tmp1, src6, src3); ILVL_W2_SB(tmp2, tmp0, tmp3, tmp1, src1, src5); -SLDI_B4_0_SB(src6, src1, src3, src5, src0, src2, src4, src7, 8); +SLDI_B4_SB(src6, zeros, src1, zeros, src3, zeros, src5, zeros, + 8, src0, src2, src4, src7); p0_asub_q0 = __msa_asub_u_b((v16u8) src2, (v16u8) src3); p1_asub_p0 = __msa_asub_u_b((v16u8) src1, (v16u8) src2); @@ -1116,10 +1117,10 @@ static void avc_h_loop_filter_luma_mbaff_intra_msa(uint8_t *src, int32_t stride, ILVRL_H2_SH(zeros, dst2_x, tmp2, tmp3); ILVR_W2_UB(tmp2, tmp0, tmp3, tmp1, dst0, dst4); -SLDI_B2_0_UB(dst0, dst4, dst1, dst5, 8); +SLDI_B2_UB(dst0, zeros, dst4, zeros, 8, dst1, dst5); dst2_x = (v16u8) __msa_ilvl_w((v4i32) tmp2, (v4i32) tmp0); dst2_y = (v16u8) __msa_ilvl_w((v4i32) tmp3, (v4i32) tmp1); -SLDI_B2_0_UB(dst2_x, dst2_y, dst3_x, dst3_y, 8); +SLDI_B2_UB(dst2_x, zeros, dst2_y, zeros, 8, dst3_x, dst3_y); out0 = __msa_copy_u_w((v4i32) dst0, 0); out1 = __msa_copy_u_h((v8i16) dst0, 2); diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c index df7e3e2..60e3e22 100644 --- a/libavcodec/mips/h264qpel_msa.c +++ b/libavcodec/mips/h264qpel_msa.c @@ -790,8 +790,8 @@ void ff_put_h264_qpel16_mc10_msa(uint8_t *dst, const uint8_t *src, minus5b, res4, res5, res6, res7); DPADD_SB4_SH(vec2, vec5, vec8, vec11, plus20b, plus20b, plus20b, plus20b, res4, res5, res6, res7); -SLDI_B2_SB(src1, src3, src0, src2, src0, src2, 2); -SLDI_B2_SB(src5, src7, src4, src6, src4, src6, 2); +SLDI_B4_SB(src0, src1, src2, src3, src4, src5, src6, src7, 2, + src0, src2, src4, src6); SRARI_H4_SH(res0, res1, res2, res3, 5); SRARI_H4_SH(res4, res5, res6, res7, 5); SAT_SH4_SH(res0, res1, res2, res3, 7); @@ -858,8 +858,8 @@ void ff_put_h264_qpel16_mc30_msa(uint8_t *dst, const uint8_t *src, minus5b, res4, res5, res6, res7); DPADD_SB4_SH(vec2, vec5, vec8, vec11, plus20b, plus20b, plus20b, plus20b, res4, res5, res6, res7); -SLDI_B2_SB(src1, src3, src0, src2, src0, src2, 3); -SLDI_B2_SB(src5, src7, src4, src6, src4, src6, 3); +SLDI_B4_SB(src0, src1, src2, src3, src4, src5, src6, src7, 3, + src0, src2, src4, src6); SRARI_H4_SH(res0, res1, res2, res3, 5); SRARI_H4_SH(res4, res5, res6, res7, 5); SAT_SH4_SH(res0, res1, res2, res3, 7); @@ -911,10 +911,10 @@ void ff_put_h264_qpel8_mc10_msa(uint8_t *dst, const uint8_t *src, VSHF_B2_SB(src6, src6, src7, src7, mask2, mask2, vec10, vec11); DPADD_SB4_SH(vec8, vec9, vec10, vec11, plus20b, plus20b, plus20b, plus20b, res4, res5, res6, res7); -SLDI_B2_SB(src0, src1, src0, src1, src0, src1, 2); -SLDI_B2_SB(src2, src3, src2, src3, src2, src3, 2); -SLDI_B2_SB(src4, src5, src4, src5, src4, src5, 2); -SLDI_B2_SB(src6, src7, src6, src7, src6, src7, 2); +SLDI_B4_SB(src0, src0, src1, src1, src2, src2, src3, src3, 2, + src0, src1, src2, src3); +SLDI_B4_SB(src4, src4, src5, src5, src6, src6, src7, src7, 2, + src4, src5, s
Re: [FFmpeg-devel] [PATCH v2 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
Some sample working DNGs: https://0x0.st/z8pf.dng (non-jpeg) https://www.kenrockwell.com/leica/m9/sample-photos-3.htm (jpeg. these are decoded as dark because there's no color space conversion implemented) A few others work too but I can't find the links to them anymore, I can upload them if requested. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Ticket #7124: Fixes compiler bug - replace vec_lvsl/vec_perm with vec_xl
A bug exist with the gcc compilers for Power in versions 6.x and 7.x
(verified with 6.3 and 7.4). It was fixed in version 8.x (verified with
8.3). I was using a Power 9 ppc64le machine for building and testing.
It appears the compiler is generating the wrong code for little endian
machines for the vec_lvsl/vec_perm instruction combos in some cases. If
these instructions are replaced with vec_xl, the problem goes away for
all versions of the compilers.
---
libswscale/ppc/yuv2rgb_altivec.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/libswscale/ppc/yuv2rgb_altivec.c
b/libswscale/ppc/yuv2rgb_altivec.c
index c1e2852adb..536545293d 100644
--- a/libswscale/ppc/yuv2rgb_altivec.c
+++ b/libswscale/ppc/yuv2rgb_altivec.c
@@ -305,9 +305,6 @@ static int altivec_ ## name(SwsContext *c, const
unsigned char **in, \
vector signed short R1, G1, B1;
\
vector unsigned char R, G, B;
\
\
-const vector unsigned char *y1ivP, *y2ivP, *uivP, *vivP;
\
-vector unsigned char align_perm;
\
-
\
vector signed short lCY = c->CY;
\
vector signed short lOY = c->OY;
\
vector signed short lCRV = c->CRV;
\
@@ -338,26 +335,13 @@ static int altivec_ ## name(SwsContext *c, const
unsigned char **in, \
vec_dstst(oute, (0x0202 | (((w * 3 + 32) / 32) << 16)), 1);
\
\
for (j = 0; j < w / 16; j++) {
\
-y1ivP = (const vector unsigned char *) y1i;
\
-y2ivP = (const vector unsigned char *) y2i;
\
-uivP = (const vector unsigned char *) ui;
\
-vivP = (const vector unsigned char *) vi;
\
-
\
-align_perm = vec_lvsl(0, y1i);
\
-y0 = (vector unsigned char)
\
- vec_perm(y1ivP[0], y1ivP[1], align_perm);
\
+y0 = vec_xl(0, y1i);
\
\
-align_perm = vec_lvsl(0, y2i);
\
-y1 = (vector unsigned char)
\
- vec_perm(y2ivP[0], y2ivP[1], align_perm);
\
+y1 = vec_xl(0, y2i);
\
\
-align_perm = vec_lvsl(0, ui);
\
-u = (vector signed char)
\
-vec_perm(uivP[0], uivP[1], align_perm);
\
+u = (vector signed char) vec_xl(0, ui);
\
\
-align_perm = vec_lvsl(0, vi);
\
-v = (vector signed char)
\
-vec_perm(vivP[0], vivP[1], align_perm);
\
+v = (vector signed char) vec_xl(0, vi);
\
\
u = (vector signed char)
\
vec_sub(u,
\
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
Even though you requested not to review: On Tue, Jul 23, 2019 at 14:51:12 +0300, velocit...@gmail.com wrote: > +#include "mjpegdec.h" Subtle hint: Try configuring and compiling ffmpeg without support for mjpeg, but with support for tiff. I think you need to add a dependency in libavcodec/Makefile. Possibly also in configure (tiff_decoder_select). Perhaps the feature could be #ifdef'd MJPEG_DECODER, but that may create a bit of a mess. Cheers, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
From: Nick Renieris
Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
This commit adds support for:
- DNG tiles
- DNG tile huffman lossless JPEG decoding
- DNG 8-bpp ("packed" as dcraw calls it) decoding
- DNG color scaling [1]
- LinearizationTable tag
- BlackLevel tag
[1]: As specified in the DNG Specification - Chapter 5
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 326 +-
libavcodec/tiff.h | 2 +
2 files changed, 321 insertions(+), 7 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index c520d7df83..423eaf0647 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -46,6 +46,7 @@
#include "mathops.h"
#include "tiff.h"
#include "tiff_data.h"
+#include "mjpegdec.h"
#include "thread.h"
#include "get_bits.h"
@@ -54,6 +55,10 @@ typedef struct TiffContext {
AVCodecContext *avctx;
GetByteContext gb;
+/* JPEG decoding for DNG */
+AVCodecContext *avctx_mjpeg; // wrapper context for MJPEG
+AVFrame *jpgframe; // decoded JPEG tile
+
int get_subimage;
uint16_t get_page;
int get_thumbnail;
@@ -76,7 +81,9 @@ typedef struct TiffContext {
int is_bayer;
uint8_t pattern[4];
+unsigned black_level;
unsigned white_level;
+const uint16_t *dng_lut; // Pointer to DNG linearization table
uint32_t sub_ifd;
uint16_t cur_page;
@@ -86,6 +93,14 @@ typedef struct TiffContext {
int stripsizesoff, stripsize, stripoff, strippos;
LZWState *lzw;
+/* Tile support */
+int is_tiled;
+int tile_byte_counts_offset, tile_offsets_offset;
+int tile_width, tile_length;
+int tile_count;
+
+int is_jpeg; // 0 - Not JPEG, 1 - JPEG, 2 - New JPEG
+
uint8_t *deinvert_buf;
int deinvert_buf_size;
uint8_t *yuv_line;
@@ -257,11 +272,27 @@ static int add_metadata(int count, int type,
};
}
+static void av_always_inline dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
+ const uint8_t *src, int src_stride, int
width, int height, int is_u16);
+
static void av_always_inline horizontal_fill(TiffContext *s,
unsigned int bpp, uint8_t* dst,
int usePtr, const uint8_t *src,
uint8_t c, int width, int offset)
{
+/* Handle DNG images with uncompressed strips (non-tiled) */
+if (s->tiff_type == TIFF_TYPE_DNG || s->tiff_type == TIFF_TYPE_CINEMADNG) {
+dng_blit(s,
+ dst + offset,
+ width,
+ src,
+ width,
+ width,
+ 1,
+ 0);
+return;
+}
+
switch (bpp) {
case 1:
while (--width >= 0) {
@@ -712,6 +743,203 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
return 0;
}
+/**
+ * Map stored raw sensor values into linear reference values.
+ * See: DNG Specification - Chapter 5
+ */
+static uint16_t av_always_inline dng_raw_to_linear16(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+// Lookup table lookup
+if (lut) value = lut[value];
+
+// Black level subtraction
+value = av_clip_uint16_c((unsigned)value - black_level);
+
+// Color scaling
+value = av_clip_uint16_c((unsigned)(((float)value * scale_factor) *
0x));
+
+return value;
+}
+
+static uint16_t av_always_inline dng_raw_to_linear8(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+return dng_raw_to_linear16(value, lut, black_level, scale_factor) >> 8;
+}
+
+static void dng_blit(TiffContext *s, uint8_t *dst, int dst_stride,
+ const uint8_t *src, int src_stride,
+ int width, int height, int is_u16)
+{
+int line, col;
+float scale_factor;
+
+scale_factor = 1.0 / (s->white_level - s->black_level);
+
+if (is_u16) {
+for (line = 0; line < height; line++) {
+uint16_t *dst_u16 = (uint16_t *)dst;
+uint16_t *src_u16 = (uint16_t *)src;
+
+for (col = 0; col < width; col++)
+*dst_u16++ = dng_raw_to_linear16(*src_u16++, s->dng_lut,
s->black_level, scale_factor);
+
+dst += dst_stride * sizeof(uint16_t);
+src += src_stride * sizeof(uint16_t);
+}
+} else {
+for (line = 0; line < height; line++) {
+for (col = 0; col < width; col++)
+*dst++ = dng_raw_to_linear8(*src++, s->dng_lut,
s->black_level, scale_factor);
+
+
[FFmpeg-devel] [PATCH v2 1/2] lavc/mjpegdec: Decode Huffman-coded lossless JPEGs embedded in DNGs
From: Nick Renieris
Main image data in DNGs is usually comprised of tiles, each of which is a
Huffman-encoded lossless JPEG.
Tested for ljpeg regressions with:
`ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi`
`ffmpeg test.avi out.avi`
The modified code in ljpeg_decode_rgb_scan runs without issues.
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 54 ---
libavcodec/mjpegdec.h | 1 +
2 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index a65bc8df15..225833d1bd 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -412,6 +412,14 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
return AVERROR_PATCHWELCOME;
}
+/* Lossless JPEGs encoded in DNGs are commonly bayer-encoded. They contain
2
+ interleaved components and the width stored in their SOF3 markers is the
+ width of each one. We only output a single component, therefore we need
+ to adjust the output image width. */
+if (s->lossless == 1 && nb_components == 2) {
+s->bayer = 1;
+width *= 2;
+}
/* if different size, realloc/alloc picture */
if (width != s->width || height != s->height || bits != s->bits ||
@@ -488,6 +496,9 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
switch (pix_fmt_id) {
+case 0x: /* for bayer-encoded huffman lossless JPEGs embedded
in DNGs */
+s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
+break;
case 0x1100:
if (s->rgb)
s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_BGR24 :
AV_PIX_FMT_BGR48;
@@ -1041,26 +1052,36 @@ static int handle_rstn(MJpegDecodeContext *s, int
nb_components)
return reset;
}
+/* Handles 1 to 4 components */
static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s, int nb_components, int
predictor, int point_transform)
{
int i, mb_x, mb_y;
+unsigned width;
uint16_t (*buffer)[4];
int left[4], top[4], topleft[4];
const int linesize = s->linesize[0];
const int mask = ((1 << s->bits) - 1) << point_transform;
int resync_mb_y = 0;
int resync_mb_x = 0;
+int vpred[6];
-if (s->nb_components != 3 && s->nb_components != 4)
+if (s->nb_components <= 0 || s->nb_components > 4)
return AVERROR_INVALIDDATA;
+
if (s->v_max != 1 || s->h_max != 1 || !s->lossless)
return AVERROR_INVALIDDATA;
-
s->restart_count = s->restart_interval;
-av_fast_malloc(&s->ljpeg_buffer, &s->ljpeg_buffer_size,
- (unsigned)s->mb_width * 4 * sizeof(s->ljpeg_buffer[0][0]));
+if (s->restart_interval == 0)
+s->restart_interval = INT_MAX;
+
+if (s->bayer)
+width = s->mb_width / nb_components; /* Interleaved, width stored is
the total so need to divide */
+else
+width = s->mb_width;
+
+av_fast_malloc(&s->ljpeg_buffer, &s->ljpeg_buffer_size, width * 4 *
sizeof(s->ljpeg_buffer[0][0]));
if (!s->ljpeg_buffer)
return AVERROR(ENOMEM);
@@ -1078,7 +1099,12 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
for (i = 0; i < 4; i++)
top[i] = left[i] = topleft[i] = buffer[0][i];
-for (mb_x = 0; mb_x < s->mb_width; mb_x++) {
+if (mb_y * s->width % s->restart_interval == 0) {
+for (i = 0; i < 6; i++)
+vpred[i] = 1 << (s->bits-1);
+}
+
+for (mb_x = 0; mb_x < width; mb_x++) {
int modified_predictor = predictor;
if (get_bits_left(&s->gb) < 1) {
@@ -1102,12 +1128,19 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
topleft[i] = top[i];
top[i] = buffer[mb_x][i];
-PREDICT(pred, topleft[i], top[i], left[i], modified_predictor);
-
dc = mjpeg_decode_dc(s, s->dc_index[i]);
if(dc == 0xF)
return -1;
+if (mb_x) {
+pred = left[i];
+} else {
+vpred[i] += dc;
+pred = vpred[i] - dc;
+}
+
+PREDICT(pred, topleft[i], top[i], pred, modified_predictor);
+
left[i] = buffer[mb_x][i] =
mask & (pred + (unsigned)(dc * (1 << point_transform)));
}
@@ -1151,6 +1184,11 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
ptr[3*mb_x + 0] = buffer[mb_x][1] + ptr[3*mb_x + 1];
ptr[3*mb_x + 2] = buffer[mb_x][2] + ptr[3*mb_x + 1];
}
+} else if (s->bayer && nb_components == 2) {
+for (mb_x = 0; mb_x < width; mb_x++) {
+((uint16_t*)ptr)[2*mb_x + 0] = buffer[mb_x][0];
+((uint16_t*)ptr)[2*mb_x + 1] = buffer[mb_x][1];
+}
}
Re: [FFmpeg-devel] how to create sub project / git repo under FFMPEG
On Mon, Jul 22, 2019 at 02:03:33 +, Guo, Yejun wrote: > I do not mean the official repository https://git.ffmpeg.org/ffmpeg.git, I > mean another > new repo and ffmpeg community has the right to assign/remove someone to have > the write access. [...] > thanks, I think we can create a git repo at > code.videolan.org/ffmpeg/dnn_material. Actually, http://git.videolan.org/?p=ffmpeg.git;a=summary is the official repo (or rather its visualization). Github is the secondary repo, a mirror. See this thread: http://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180844.html Cheers, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
Please don't review this yet. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/1] avcodec/h264: Fix poc_lsb in open gop context
When no IDR nor mmco_reset is found, prev_poc_lsb is
undefined and shall not be assumed to be zero
---
libavcodec/h264_parse.c | 2 ++
libavcodec/h264dec.c| 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index ac31f54e07..60fff1a549 100644
--- a/libavcodec/h264_parse.c
+++ b/libavcodec/h264_parse.c
@@ -287,6 +287,8 @@ int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
if (sps->poc_type == 0) {
const int max_poc_lsb = 1 << sps->log2_max_poc_lsb;
+if (pc->prev_poc_lsb < 0)
+pc->prev_poc_lsb = pc->poc_lsb;
if (pc->poc_lsb < pc->prev_poc_lsb &&
pc->prev_poc_lsb - pc->poc_lsb >= max_poc_lsb / 2)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 8d1bd16a8e..f12651fa3d 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -474,7 +474,7 @@ static void idr(H264Context *h)
h->poc.prev_frame_num=
h->poc.prev_frame_num_offset = 0;
h->poc.prev_poc_msb = 1<<16;
-h->poc.prev_poc_lsb = 0;
+h->poc.prev_poc_lsb = -1;
for (i = 0; i < MAX_DELAYED_PIC_COUNT; i++)
h->last_pocs[i] = INT_MIN;
}
--
2.14.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/1] avcodec/h264: Fix poc_lsb in open gop context
This fixes parsing of live captures with 'open GOP' when poc_type=0. At init, prev_poc_lsb is set to zero by defaut whereas it is undefined. If the stream starts with a high poc_lsb (ie. > max_poc_lsb/2), then the poc_msb is wrongly incremented. I have uploaded a sample where log2_max_pic_order_cnt_lsb_minus4=5 ie. 512 frames (@25fps), thus there is about 10 seconds of video that are 'lost'. https://framadrop.org/r/a5RSjBKXAS#yBbeVfBR4LQwK4x3seqg4uGRdPv8FLJ6YNv8dVpjGJ4= NB: FATE pass without modification Thank you for the review, Nicolas Nicolas Gaullier (1): avcodec/h264: Fix poc_lsb in open gop context libavcodec/h264_parse.c | 2 ++ libavcodec/h264dec.c| 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) -- 2.14.1.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavc/mjpegdec: Decode Huffman-coded lossless JPEGs embedded in DNGs
From: Nick Renieris
Main image data in DNGs is usually comprised of tiles, each of which is a
Huffman-encoded lossless JPEG.
Changes in ljpeg_decode_rgb_scan are based on dcraw.
Tested for ljpeg regressions with:
`ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi`
`ffmpeg test.avi out.avi`
The modified code in ljpeg_decode_rgb_scan runs without issues.
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 54 ---
libavcodec/mjpegdec.h | 1 +
2 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index a65bc8df15..225833d1bd 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -412,6 +412,14 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
return AVERROR_PATCHWELCOME;
}
+/* Lossless JPEGs encoded in DNGs are commonly bayer-encoded. They contain
2
+ interleaved components and the width stored in their SOF3 markers is the
+ width of each one. We only output a single component, therefore we need
+ to adjust the output image width. */
+if (s->lossless == 1 && nb_components == 2) {
+s->bayer = 1;
+width *= 2;
+}
/* if different size, realloc/alloc picture */
if (width != s->width || height != s->height || bits != s->bits ||
@@ -488,6 +496,9 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
switch (pix_fmt_id) {
+case 0x: /* for bayer-encoded huffman lossless JPEGs embedded
in DNGs */
+s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
+break;
case 0x1100:
if (s->rgb)
s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_BGR24 :
AV_PIX_FMT_BGR48;
@@ -1041,26 +1052,36 @@ static int handle_rstn(MJpegDecodeContext *s, int
nb_components)
return reset;
}
+/* Handles 1 to 4 components */
static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s, int nb_components, int
predictor, int point_transform)
{
int i, mb_x, mb_y;
+unsigned width;
uint16_t (*buffer)[4];
int left[4], top[4], topleft[4];
const int linesize = s->linesize[0];
const int mask = ((1 << s->bits) - 1) << point_transform;
int resync_mb_y = 0;
int resync_mb_x = 0;
+int vpred[6];
-if (s->nb_components != 3 && s->nb_components != 4)
+if (s->nb_components <= 0 || s->nb_components > 4)
return AVERROR_INVALIDDATA;
+
if (s->v_max != 1 || s->h_max != 1 || !s->lossless)
return AVERROR_INVALIDDATA;
-
s->restart_count = s->restart_interval;
-av_fast_malloc(&s->ljpeg_buffer, &s->ljpeg_buffer_size,
- (unsigned)s->mb_width * 4 * sizeof(s->ljpeg_buffer[0][0]));
+if (s->restart_interval == 0)
+s->restart_interval = INT_MAX;
+
+if (s->bayer)
+width = s->mb_width / nb_components; /* Interleaved, width stored is
the total so need to divide */
+else
+width = s->mb_width;
+
+av_fast_malloc(&s->ljpeg_buffer, &s->ljpeg_buffer_size, width * 4 *
sizeof(s->ljpeg_buffer[0][0]));
if (!s->ljpeg_buffer)
return AVERROR(ENOMEM);
@@ -1078,7 +1099,12 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
for (i = 0; i < 4; i++)
top[i] = left[i] = topleft[i] = buffer[0][i];
-for (mb_x = 0; mb_x < s->mb_width; mb_x++) {
+if (mb_y * s->width % s->restart_interval == 0) {
+for (i = 0; i < 6; i++)
+vpred[i] = 1 << (s->bits-1);
+}
+
+for (mb_x = 0; mb_x < width; mb_x++) {
int modified_predictor = predictor;
if (get_bits_left(&s->gb) < 1) {
@@ -1102,12 +1128,19 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
topleft[i] = top[i];
top[i] = buffer[mb_x][i];
-PREDICT(pred, topleft[i], top[i], left[i], modified_predictor);
-
dc = mjpeg_decode_dc(s, s->dc_index[i]);
if(dc == 0xF)
return -1;
+if (mb_x) {
+pred = left[i];
+} else {
+vpred[i] += dc;
+pred = vpred[i] - dc;
+}
+
+PREDICT(pred, topleft[i], top[i], pred, modified_predictor);
+
left[i] = buffer[mb_x][i] =
mask & (pred + (unsigned)(dc * (1 << point_transform)));
}
@@ -1151,6 +1184,11 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
ptr[3*mb_x + 0] = buffer[mb_x][1] + ptr[3*mb_x + 1];
ptr[3*mb_x + 2] = buffer[mb_x][2] + ptr[3*mb_x + 1];
}
+} else if (s->bayer && nb_components == 2) {
+for (mb_x = 0; mb_x < width; mb_x++) {
+((uint16_t*)ptr)[2*mb_x + 0] = buffer[mb_x][0];
+((uint16_t*)ptr)[2*m
[FFmpeg-devel] [PATCH 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
From: Nick Renieris
Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
This commit adds support for:
- DNG tiles
- DNG tile huffman lossless JPEG decoding
- DNG 8-bpp ("packed" as dcraw calls it) decoding
- DNG color scaling [1]
- LinearizationTable tag
- BlackLevel tag
[1]: As specified in the DNG Specification - Chapter 5
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 328 +-
libavcodec/tiff.h | 2 +
2 files changed, 323 insertions(+), 7 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index c520d7df83..e62adb9fc1 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -46,6 +46,7 @@
#include "mathops.h"
#include "tiff.h"
#include "tiff_data.h"
+#include "mjpegdec.h"
#include "thread.h"
#include "get_bits.h"
@@ -54,6 +55,10 @@ typedef struct TiffContext {
AVCodecContext *avctx;
GetByteContext gb;
+/* JPEG decoding for DNG */
+AVCodecContext *avctx_mjpeg; // wrapper context for MJPEG
+AVFrame *jpgframe; // decoded JPEG tile
+
int get_subimage;
uint16_t get_page;
int get_thumbnail;
@@ -76,7 +81,9 @@ typedef struct TiffContext {
int is_bayer;
uint8_t pattern[4];
+unsigned black_level;
unsigned white_level;
+const uint16_t *dng_lut; // Pointer to DNG linearization table
uint32_t sub_ifd;
uint16_t cur_page;
@@ -86,6 +93,14 @@ typedef struct TiffContext {
int stripsizesoff, stripsize, stripoff, strippos;
LZWState *lzw;
+/* Tile support */
+int is_tiled;
+int tile_byte_counts_offset, tile_offsets_offset;
+int tile_width, tile_length;
+int tile_count;
+
+int is_jpeg; // 0 - Not JPEG, 1 - JPEG, 2 - New JPEG
+
uint8_t *deinvert_buf;
int deinvert_buf_size;
uint8_t *yuv_line;
@@ -257,11 +272,32 @@ static int add_metadata(int count, int type,
};
}
+static void av_always_inline dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
+ const uint8_t *src, int src_stride, int
width, int height, int is_u16);
+
static void av_always_inline horizontal_fill(TiffContext *s,
unsigned int bpp, uint8_t* dst,
int usePtr, const uint8_t *src,
uint8_t c, int width, int offset)
{
+/* Handle DNG images with uncompressed strips (non-tiled) */
+if (s->tiff_type == TIFF_TYPE_DNG || s->tiff_type == TIFF_TYPE_CINEMADNG) {
+int is_u16, pixel_size;
+
+is_u16 = (bpp > 8);
+pixel_size = (is_u16 ? sizeof(uint16_t) : sizeof(uint8_t));
+
+dng_blit(s,
+ dst + offset,
+ width * pixel_size,
+ src,
+ width * pixel_size,
+ width * pixel_size,
+ 1,
+ is_u16);
+return;
+}
+
switch (bpp) {
case 1:
while (--width >= 0) {
@@ -712,6 +748,203 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
return 0;
}
+/**
+ * Map stored raw sensor values into linear reference values.
+ * See: DNG Specification - Chapter 5
+ */
+static uint16_t av_always_inline dng_raw_to_linear16(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+// Lookup table lookup
+if (lut) value = lut[value];
+
+// Black level subtraction
+value = av_clip_uint16_c((unsigned)value - black_level);
+
+// Color scaling
+value = av_clip_uint16_c((unsigned)(((float)value * scale_factor) *
0x));
+
+return value;
+}
+
+static uint16_t av_always_inline dng_raw_to_linear8(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+return dng_raw_to_linear16(value, lut, black_level, scale_factor) >> 8;
+}
+
+static void dng_blit(TiffContext *s, uint8_t *dst, int dst_stride,
+ const uint8_t *src, int src_stride,
+ int width, int height, int is_u16)
+{
+int line, col;
+float scale_factor;
+
+scale_factor = 1.0 / (s->white_level - s->black_level);
+
+if (is_u16) {
+for (line = 0; line < height; line++) {
+uint16_t *dst_u16 = (uint16_t *)dst;
+uint16_t *src_u16 = (uint16_t *)src;
+
+for (col = 0; col < width; col++)
+*dst_u16++ = dng_raw_to_linear16(*src_u16++, s->dng_lut,
s->black_level, scale_factor);
+
+dst += dst_stride * sizeof(uint16_t);
+src += src_stride * sizeof(uint16_t);
+}
+} else {
+for (line = 0;
Re: [FFmpeg-devel] avfilter/vf_ciescope: add DCI-P3
On 7/23/19, Kevin Wheatley wrote: > Just a query, but I note that the gamma says 'GAMMA_REC709', this is > not the normal gamma I'd expect for a DCI P3 image, it would typically > be 2.6, so for correct translation into chromaticities, you would need > to use that to convert to linear RGB. It is also not the only option > for encoding the output image, although it appears it is the only > option listed in the structure. > > What is that gamma parameter in the colour space structure supposed to > represent? Its only used if corrgamma is set. It just change overall colors. > > Thanks > > Kevin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
On 7/23/19, Carl Eugen Hoyos wrote: > Am Di., 23. Juli 2019 um 04:47 Uhr schrieb Lynne : >> >> Jul 22, 2019, 11:24 PM by ceffm...@gmail.com: > >> > Please stop with these comments. >> > >> > No matter what others may tell you, they are not useful but very >> > disturbing. >> >> Please stay out of all my emails > > I wish I could! > Sadly, you keep attacking FFmpeg developers and sending these attacks to a > public mailing list on which I happen to be active. FFmpeg developer attacking other FFmpeg developers? This can't be true. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] avfilter/vf_ciescope: add DCI-P3
Just a query, but I note that the gamma says 'GAMMA_REC709', this is not the normal gamma I'd expect for a DCI P3 image, it would typically be 2.6, so for correct translation into chromaticities, you would need to use that to convert to linear RGB. It is also not the only option for encoding the output image, although it appears it is the only option listed in the structure. What is that gamma parameter in the colour space structure supposed to represent? Thanks Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
Am Di., 23. Juli 2019 um 04:47 Uhr schrieb Lynne : > > Jul 22, 2019, 11:24 PM by ceffm...@gmail.com: > > Please stop with these comments. > > > > No matter what others may tell you, they are not useful but very disturbing. > > Please stay out of all my emails I wish I could! Sadly, you keep attacking FFmpeg developers and sending these attacks to a public mailing list on which I happen to be active. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
Lynne (12019-07-23): > Please stay out of all my emails and harassing me over apparently not > having enough commits. What are you taking about? I have gone over your interactions on the mailing-list, and found nothing about number of commits, nor anything that looks to me like harassment, but I may have missed something. Can you elaborate? Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/hqx: Check the input data against the image size
On 7/23/19, Paul B Mahol wrote: > On 7/23/19, Michael Niedermayer wrote: >> On Tue, Jul 23, 2019 at 09:03:32AM +0200, Paul B Mahol wrote: >>> On 7/23/19, Michael Niedermayer wrote: >>> > On Mon, Jul 22, 2019 at 08:20:54AM +0200, Paul B Mahol wrote: >>> >> On 7/21/19, Michael Niedermayer wrote: >>> >> > On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote: >>> >> >> On 7/21/19, Michael Niedermayer wrote: >>> >> >> > Fixes: Timeout (22 -> 7 sec) >>> >> >> > Fixes: >>> >> >> > 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992 >>> >> >> > >>> >> >> > Found-by: continuous fuzzing process >>> >> >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >>> >> >> > Signed-off-by: Michael Niedermayer >>> >> >> > --- >>> >> >> > libavcodec/hqx.c | 4 >>> >> >> > 1 file changed, 4 insertions(+) >>> >> >> > >>> >> >> > diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c >>> >> >> > index bc24ba91d1..8639d77a41 100644 >>> >> >> > --- a/libavcodec/hqx.c >>> >> >> > +++ b/libavcodec/hqx.c >>> >> >> > @@ -471,6 +471,10 @@ static int hqx_decode_frame(AVCodecContext >>> >> >> > *avctx, >>> >> >> > void >>> >> >> > *data, >>> >> >> > avctx->height = ctx->height; >>> >> >> > avctx->bits_per_raw_sample = 10; >>> >> >> > >>> >> >> > +if (avctx->coded_width / 16 * (avctx->coded_height / 16) * >>> >> >> > +(100 - avctx->discard_damaged_percentage) / 100 > 8LL * >>> >> >> > avpkt->size) >>> >> >> > +return AVERROR_INVALIDDATA; >>> >> >> >>> >> >> Why just this change and not something better? >>> >> > >>> >> > What would you prefer exactly ? >>> >> >>> >> Something that works with pure black video. >>> > >>> > Can you share the failing video file ? >>> > I thought theres a minimum size of 1 vlc code (2 bit seem the >>> > smallest) >>> > per 16x16 block. But quite possibly i might have missed something >>> > >>> >>> This is very disappointing. There is no freely available encoder for >>> HQX. >>> And the one who commits stuff need to make sure it does not introduce >>> regressions. >> >> The reviewer just has to explain how the problem he speaks of can >> occur. > > No, its other way around. > The patch author just has to explain how the problem he tries to solve > is valid solution by given patch. > >> >> If we look at decode_slice_thread() each slice reads data from a distinct >> input area (this is checked to be distinct in the code). So even the >> same black slice cannot reuse the same representation. >> >> decode_slice_thread calls decode_slice which calls decode_func >> decode_func can be one of 4 implementations each reading at least >> a minimum of 2 bit. so we have a minimum of 2 bits per macroblock >> the calls happen at a granularity of 16x16 so theres a minimum of >> 2 bits per 16x16 block. >> Its very possible that i have missed some path or case in this >> analysis. But we wont really move forward based on riddles. >> If you know of a path/case where a frame can be encoded with >> less input data just explain that case and ill adjust the >> patch accordingly. Otherwise the patch is stuck as i dont >> know what case you speak of > > For start, get a copy of HQX encoder, than we can talk more. Here, I was not lazy so I got one sample for you: http://0x0.st/zppS.avi > >> >> PS: also there are no other return pathes in hqx_decode_frame() >> all returns are error pathes so i dont see any shortcuts for >> black frames which would bypass the minimum size >> >> Thanks >> >> [...] >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> Never trust a computer, one day, it may think you are the virus. -- Compn >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/hqx: Check the input data against the image size
On 7/23/19, Michael Niedermayer wrote: > On Tue, Jul 23, 2019 at 09:03:32AM +0200, Paul B Mahol wrote: >> On 7/23/19, Michael Niedermayer wrote: >> > On Mon, Jul 22, 2019 at 08:20:54AM +0200, Paul B Mahol wrote: >> >> On 7/21/19, Michael Niedermayer wrote: >> >> > On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote: >> >> >> On 7/21/19, Michael Niedermayer wrote: >> >> >> > Fixes: Timeout (22 -> 7 sec) >> >> >> > Fixes: >> >> >> > 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992 >> >> >> > >> >> >> > Found-by: continuous fuzzing process >> >> >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> >> >> > Signed-off-by: Michael Niedermayer >> >> >> > --- >> >> >> > libavcodec/hqx.c | 4 >> >> >> > 1 file changed, 4 insertions(+) >> >> >> > >> >> >> > diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c >> >> >> > index bc24ba91d1..8639d77a41 100644 >> >> >> > --- a/libavcodec/hqx.c >> >> >> > +++ b/libavcodec/hqx.c >> >> >> > @@ -471,6 +471,10 @@ static int hqx_decode_frame(AVCodecContext >> >> >> > *avctx, >> >> >> > void >> >> >> > *data, >> >> >> > avctx->height = ctx->height; >> >> >> > avctx->bits_per_raw_sample = 10; >> >> >> > >> >> >> > +if (avctx->coded_width / 16 * (avctx->coded_height / 16) * >> >> >> > +(100 - avctx->discard_damaged_percentage) / 100 > 8LL * >> >> >> > avpkt->size) >> >> >> > +return AVERROR_INVALIDDATA; >> >> >> >> >> >> Why just this change and not something better? >> >> > >> >> > What would you prefer exactly ? >> >> >> >> Something that works with pure black video. >> > >> > Can you share the failing video file ? >> > I thought theres a minimum size of 1 vlc code (2 bit seem the smallest) >> > per 16x16 block. But quite possibly i might have missed something >> > >> >> This is very disappointing. There is no freely available encoder for HQX. >> And the one who commits stuff need to make sure it does not introduce >> regressions. > > The reviewer just has to explain how the problem he speaks of can > occur. No, its other way around. The patch author just has to explain how the problem he tries to solve is valid solution by given patch. > > If we look at decode_slice_thread() each slice reads data from a distinct > input area (this is checked to be distinct in the code). So even the > same black slice cannot reuse the same representation. > > decode_slice_thread calls decode_slice which calls decode_func > decode_func can be one of 4 implementations each reading at least > a minimum of 2 bit. so we have a minimum of 2 bits per macroblock > the calls happen at a granularity of 16x16 so theres a minimum of > 2 bits per 16x16 block. > Its very possible that i have missed some path or case in this > analysis. But we wont really move forward based on riddles. > If you know of a path/case where a frame can be encoded with > less input data just explain that case and ill adjust the > patch accordingly. Otherwise the patch is stuck as i dont > know what case you speak of For start, get a copy of HQX encoder, than we can talk more. > > PS: also there are no other return pathes in hqx_decode_frame() > all returns are error pathes so i dont see any shortcuts for > black frames which would bypass the minimum size > > Thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Never trust a computer, one day, it may think you are the virus. -- Compn > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/3] lavf/f_select: support scenecut with more pixel formats
On Tue, 23 Jul 2019, Gyan wrote: On 23-07-2019 02:43 AM, Marton Balint wrote: On Sun, 21 Jul 2019, lance.lmw...@gmail.com wrote: From: Limin Wang This patch haven't make other pixel format usable yet to make sure the test result is same with rgb32 format. Reviewed-by: Marton Balint You should only add this if you got an explicit LGTM for a patch. Signed-off-by: Limin Wang --- libavfilter/f_select.c | 34 ++ 1 file changed, 30 insertions(+), 4 deletions(-) Ok, I applied the series with some minor fixes and rewordings of your commit messages, as they were a bit difficult to understand sometimes. "avformat/f_select: support scenecut with more pixel formats" This should have been avfilter/f_select. Yes, sorry about that. There is one more thing that we might consider. Now the scene change detection score uses all planes to detect scene changes. In this regard this is similar how the frozen frames detection works. However, in classic encoding scene change detection typically only uses the Y plane as far as I know, not the chroma planes. We might get more resonable scores for scene change if we also use only the Y plane for calculating the score if the pixel format is YUV. Although this will require additional work once packed YUV formats are added, because for the moment the generic scene sad score calculation has no way to ignore some components in a packed format. Also it does not make a whole lot of difference, because chroma is usually subsampled anyway, so it is weighting less in the scene score. So I guess there are pros and cons for this. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] avcodec: add a WavPack DSD decoder
On 7/23/19, David Bryant wrote: > On 7/21/19 11:23 PM, Paul B Mahol wrote: >> On 7/22/19, David Bryant wrote: >>> Hi, >>> >>> As I promised late last year, here is a patch to add a WavPack DSD >>> decoder. >>> >>> Thanks! >>> >>> -David Bryant >>> >>> >> Please correct me if I'm wrong, but why this uses new codec id? >> Apparently is also copies some logic from other files. > > Yes, I created a new codec ID for WavPack DSD. It would be possible to just > piggyback on the existing WavPack codec by silently > decimating the DSD to PCM, but that seemed weird and wrong to me. For one > thing, the user would have no idea that the file was > actually DSD and not high sample-rate PCM. > > Also, since regular WavPack has threading enabled but WavPack DSD can't > (because of the dsd2pcm conversion) I would have to turn > off threading for all WavPack (unless there's some way of making that > conditional at runtime). It would also mean that regular > WavPack would be dependent on the dsd2pcm component even if DSD was not > required (not everyone needs DSD). And of course I was > looking closely at the only other DSD codec in FFmpeg (DST) which has its > own codec ID. > > Because regular WavPack PCM and DSD share the same block format and metadata > structure, there is a little code that is shared > between the two codecs (although they are no longer identical because of the > threading difference). Is this a problem? I could > combine the two codecs into one file and sprinkle in a few conditionals, but > I don't think it would be as clean or clear (but > might save a little duplicate code). > > That's my thinking, but obviously I am not as familiar with the FFmpeg > philosophy as you guys. Looking carefully at dsd2pcm code in your patch, it appears it would work only with 1 or 2 channels. Is this correct? About multi-threading, as dsd2pcm can not be made multi-threaded then just do locking when doing dsd2pcm to make it single threaded and update other code as necessary. I still see no valid reason to add separate codec id. Add another wavpack profile if you wish to help users know the difference between the two. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/hqx: Check the input data against the image size
On Tue, Jul 23, 2019 at 09:03:32AM +0200, Paul B Mahol wrote: > On 7/23/19, Michael Niedermayer wrote: > > On Mon, Jul 22, 2019 at 08:20:54AM +0200, Paul B Mahol wrote: > >> On 7/21/19, Michael Niedermayer wrote: > >> > On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote: > >> >> On 7/21/19, Michael Niedermayer wrote: > >> >> > Fixes: Timeout (22 -> 7 sec) > >> >> > Fixes: > >> >> > 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992 > >> >> > > >> >> > Found-by: continuous fuzzing process > >> >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > >> >> > Signed-off-by: Michael Niedermayer > >> >> > --- > >> >> > libavcodec/hqx.c | 4 > >> >> > 1 file changed, 4 insertions(+) > >> >> > > >> >> > diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c > >> >> > index bc24ba91d1..8639d77a41 100644 > >> >> > --- a/libavcodec/hqx.c > >> >> > +++ b/libavcodec/hqx.c > >> >> > @@ -471,6 +471,10 @@ static int hqx_decode_frame(AVCodecContext > >> >> > *avctx, > >> >> > void > >> >> > *data, > >> >> > avctx->height = ctx->height; > >> >> > avctx->bits_per_raw_sample = 10; > >> >> > > >> >> > +if (avctx->coded_width / 16 * (avctx->coded_height / 16) * > >> >> > +(100 - avctx->discard_damaged_percentage) / 100 > 8LL * > >> >> > avpkt->size) > >> >> > +return AVERROR_INVALIDDATA; > >> >> > >> >> Why just this change and not something better? > >> > > >> > What would you prefer exactly ? > >> > >> Something that works with pure black video. > > > > Can you share the failing video file ? > > I thought theres a minimum size of 1 vlc code (2 bit seem the smallest) > > per 16x16 block. But quite possibly i might have missed something > > > > This is very disappointing. There is no freely available encoder for HQX. > And the one who commits stuff need to make sure it does not introduce > regressions. The reviewer just has to explain how the problem he speaks of can occur. If we look at decode_slice_thread() each slice reads data from a distinct input area (this is checked to be distinct in the code). So even the same black slice cannot reuse the same representation. decode_slice_thread calls decode_slice which calls decode_func decode_func can be one of 4 implementations each reading at least a minimum of 2 bit. so we have a minimum of 2 bits per macroblock the calls happen at a granularity of 16x16 so theres a minimum of 2 bits per 16x16 block. Its very possible that i have missed some path or case in this analysis. But we wont really move forward based on riddles. If you know of a path/case where a frame can be encoded with less input data just explain that case and ill adjust the patch accordingly. Otherwise the patch is stuck as i dont know what case you speak of PS: also there are no other return pathes in hqx_decode_frame() all returns are error pathes so i dont see any shortcuts for black frames which would bypass the minimum size Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.
Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned. --- libavcodec/mips/h264dsp_mmi.c | 48 +--- libavcodec/mips/simple_idct_mmi.c | 51 +-- libavutil/mips/mmiutils.h | 2 +- 3 files changed, 51 insertions(+), 50 deletions(-) diff --git a/libavcodec/mips/h264dsp_mmi.c b/libavcodec/mips/h264dsp_mmi.c index ac65a20..a85d782 100644 --- a/libavcodec/mips/h264dsp_mmi.c +++ b/libavcodec/mips/h264dsp_mmi.c @@ -38,6 +38,11 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, int stride) MMI_LDC1(%[ftmp2], %[src], 0x08) MMI_LDC1(%[ftmp3], %[src], 0x10) MMI_LDC1(%[ftmp4], %[src], 0x18) +/* memset(src, 0, 32); */ +MMI_USDC1(%[ftmp0], %[src], 0x00) +MMI_USDC1(%[ftmp0], %[src], 0x08) +MMI_USDC1(%[ftmp0], %[src], 0x10) +MMI_USDC1(%[ftmp0], %[src], 0x18) MMI_ULWC1(%[ftmp5], %[dst0], 0x00) MMI_ULWC1(%[ftmp6], %[dst1], 0x00) MMI_ULWC1(%[ftmp7], %[dst2], 0x00) @@ -58,11 +63,6 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, int stride) MMI_SWC1(%[ftmp2], %[dst1], 0x00) MMI_SWC1(%[ftmp3], %[dst2], 0x00) MMI_SWC1(%[ftmp4], %[dst3], 0x00) - -/* memset(src, 0, 32); */ -"xor%[ftmp0], %[ftmp0], %[ftmp0]\n\t" -"gssqc1 %[ftmp0], %[ftmp0], 0x00(%[src])\n\t" -"gssqc1 %[ftmp0], %[ftmp0], 0x10(%[src])\n\t" : [ftmp0]"=&f"(ftmp[0]),[ftmp1]"=&f"(ftmp[1]), [ftmp2]"=&f"(ftmp[2]),[ftmp3]"=&f"(ftmp[3]), [ftmp4]"=&f"(ftmp[4]),[ftmp5]"=&f"(ftmp[5]), @@ -85,15 +85,21 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, int stride) DECLARE_VAR_ADDRT; __asm__ volatile ( -"dli%[tmp0],0x01\n\t" MMI_LDC1(%[ftmp0], %[block], 0x00) -"mtc1 %[tmp0],%[ftmp8]\n\t" MMI_LDC1(%[ftmp1], %[block], 0x08) -"dli%[tmp0],0x06\n\t" MMI_LDC1(%[ftmp2], %[block], 0x10) +MMI_LDC1(%[ftmp3], %[block], 0x18) +/* memset(block, 0, 32) */ +"xor%[ftmp4], %[ftmp4], %[ftmp4]\n\t" +MMI_USDC1(%[ftmp4], %[block], 0x00) +MMI_USDC1(%[ftmp4], %[block], 0x08) +MMI_USDC1(%[ftmp4], %[block], 0x10) +MMI_USDC1(%[ftmp4], %[block], 0x18) +"dli%[tmp0],0x01\n\t" +"mtc1 %[tmp0],%[ftmp8]\n\t" +"dli%[tmp0],0x06\n\t" "mtc1 %[tmp0],%[ftmp9]\n\t" "psrah %[ftmp4], %[ftmp1], %[ftmp8]\n\t" -MMI_LDC1(%[ftmp3], %[block], 0x18) "psrah %[ftmp5], %[ftmp3], %[ftmp8]\n\t" "psubh %[ftmp4], %[ftmp4], %[ftmp3]\n\t" "paddh %[ftmp5], %[ftmp5], %[ftmp1]\n\t" @@ -121,15 +127,11 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, int stride) "paddh %[ftmp10], %[ftmp3], %[ftmp1]\n\t" "psubh %[ftmp1], %[ftmp1], %[ftmp3]\n\t" "paddh %[ftmp11], %[ftmp4], %[ftmp5]\n\t" -"xor%[ftmp7], %[ftmp7], %[ftmp7]\n\t" "psubh %[ftmp5], %[ftmp5], %[ftmp4]\n\t" -MMI_SDC1(%[ftmp7], %[block], 0x00) -MMI_SDC1(%[ftmp7], %[block], 0x08) -MMI_SDC1(%[ftmp7], %[block], 0x10) -MMI_SDC1(%[ftmp7], %[block], 0x18) MMI_ULWC1(%[ftmp2], %[dst], 0x00) -"psrah %[ftmp3], %[ftmp10], %[ftmp9]\n\t" MMI_LWXC1(%[ftmp0], %[dst], %[stride], 0x00) +"xor%[ftmp7], %[ftmp7], %[ftmp7]\n\t" +"psrah %[ftmp3], %[ftmp10], %[ftmp9]\n\t" "psrah %[ftmp4], %[ftmp11], %[ftmp9]\n\t" "punpcklbh %[ftmp2], %[ftmp2], %[ftmp7]\n\t" "punpcklbh %[ftmp0], %[ftmp0], %[ftmp7]\n\t" @@ -153,11 +155,6 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, int stride) MMI_SWC1(%[ftmp2], %[dst], 0x00) "packushb %[ftmp0], %[ftmp0], %[ftmp7]\n\t" MMI_SWXC1(%[ftmp0], %[dst], %[stride], 0x00) - -/* memset(block, 0, 32) */ -"xor%[ftmp0], %[ftmp0], %[ftmp0]\n\t" -"gssqc1 %[ftmp0], %[ftmp0], 0x00(%[block]) \n\t" -"gssqc1
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/hqx: Check the input data against the image size
On 7/23/19, Michael Niedermayer wrote: > On Mon, Jul 22, 2019 at 08:20:54AM +0200, Paul B Mahol wrote: >> On 7/21/19, Michael Niedermayer wrote: >> > On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote: >> >> On 7/21/19, Michael Niedermayer wrote: >> >> > Fixes: Timeout (22 -> 7 sec) >> >> > Fixes: >> >> > 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992 >> >> > >> >> > Found-by: continuous fuzzing process >> >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> >> > Signed-off-by: Michael Niedermayer >> >> > --- >> >> > libavcodec/hqx.c | 4 >> >> > 1 file changed, 4 insertions(+) >> >> > >> >> > diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c >> >> > index bc24ba91d1..8639d77a41 100644 >> >> > --- a/libavcodec/hqx.c >> >> > +++ b/libavcodec/hqx.c >> >> > @@ -471,6 +471,10 @@ static int hqx_decode_frame(AVCodecContext >> >> > *avctx, >> >> > void >> >> > *data, >> >> > avctx->height = ctx->height; >> >> > avctx->bits_per_raw_sample = 10; >> >> > >> >> > +if (avctx->coded_width / 16 * (avctx->coded_height / 16) * >> >> > +(100 - avctx->discard_damaged_percentage) / 100 > 8LL * >> >> > avpkt->size) >> >> > +return AVERROR_INVALIDDATA; >> >> >> >> Why just this change and not something better? >> > >> > What would you prefer exactly ? >> >> Something that works with pure black video. > > Can you share the failing video file ? > I thought theres a minimum size of 1 vlc code (2 bit seem the smallest) > per 16x16 block. But quite possibly i might have missed something > This is very disappointing. There is no freely available encoder for HQX. And the one who commits stuff need to make sure it does not introduce regressions. > Thanks > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
