Aug 9, 2019, 22:54 by geo...@nsup.org:
> Juan De León (12019-08-09):
>
>> AVEncodeInfoFrame data structure to store as AVFrameSideData of type
>> AV_FRAME_DATA_ENCODE_INFO.
>> The structure stores quantization index for each plane, DC/AC deltas
>> for luma and chroma planes, and an array of
Juan De León (12019-08-09):
> AVEncodeInfoFrame data structure to store as AVFrameSideData of type
> AV_FRAME_DATA_ENCODE_INFO.
> The structure stores quantization index for each plane, DC/AC deltas
> for luma and chroma planes, and an array of AVEncodeInfoBlock type
> denoting position, size, and
On Thu, Aug 08, 2019 at 05:19:54PM +0200, Paul B Mahol wrote:
> On Thu, Aug 8, 2019 at 4:44 PM Andriy Gelman
> wrote:
>
> > From: Andriy Gelman
> >
> > This patch avoids a read past the end of the input buffer in memcpy since
> > the size
> > of the received zmq message is recv_buf_size - 1.
>
On Thu, Aug 08, 2019 at 03:39:00PM +0200, Olivier MAIGNIAL wrote:
> Hello here,
>
> Just a mail to ping this patch
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or
AVEncodeInfoFrame data structure to store as AVFrameSideData of type
AV_FRAME_DATA_ENCODE_INFO.
The structure stores quantization index for each plane, DC/AC deltas
for luma and chroma planes, and an array of AVEncodeInfoBlock type
denoting position, size, and delta quantizer for each block in the
Am Fr., 9. Aug. 2019 um 11:42 Uhr schrieb Paul B Mahol :
> patch attached.
>
> If you still encounter hash failures please share input file.
Not sure if this is related but ticket #6216 contains a file that
cannot be encoded to mlp / thd so it is decoded bit-exact.
Carl Eugen
On 8/9/2019 3:28 PM, Nicolas George wrote:
> James Almer (12019-08-09):
>> Or just a pointer that points to the first byte after itself.
>
> The pointer takes places by itself. And it prevents the structure from
> being copied flatly, which IIRC is forbidden with side data.
Yeah, you're right,
James Almer (12019-08-09):
> Or just a pointer that points to the first byte after itself.
The pointer takes places by itself. And it prevents the structure from
being copied flatly, which IIRC is forbidden with side data.
By the way, the lines of the commit message are too long.
Regards,
--
On 8/9/2019 2:58 PM, Hendrik Leppkes wrote:
> On Fri, Aug 9, 2019 at 7:52 PM James Almer wrote:
>>
>> On 8/9/2019 2:38 PM, Juan De León wrote:
>>> AVEncodeInfoFrame data structure to store as AVFrameSideData of type
>>> AV_FRAME_DATA_ENCODE_INFO.
>>> The structure stores quantization index for
On Fri, Aug 9, 2019 at 7:52 PM James Almer wrote:
>
> On 8/9/2019 2:38 PM, Juan De León wrote:
> > AVEncodeInfoFrame data structure to store as AVFrameSideData of type
> > AV_FRAME_DATA_ENCODE_INFO.
> > The structure stores quantization index for each plane, DC/AC deltas for
> > luma and chroma
On 8/9/2019 2:38 PM, Juan De León wrote:
> AVEncodeInfoFrame data structure to store as AVFrameSideData of type
> AV_FRAME_DATA_ENCODE_INFO.
> The structure stores quantization index for each plane, DC/AC deltas for luma
> and chroma planes, and an array of AVEncodeInfoBlock struct denoting
>
AVEncodeInfoFrame data structure to store as AVFrameSideData of type
AV_FRAME_DATA_ENCODE_INFO.
The structure stores quantization index for each plane, DC/AC deltas for luma
and chroma planes, and an array of AVEncodeInfoBlock struct denoting position,
size, and delta quantizer for each block
AVEncodeInfoFrame data structure to store as AVFrameSideData of type
AV_FRAME_DATA_ENCODE_INFO.
The structure stores quantization index for each plane, DC/AC deltas for luma
and chroma planes, and an array of AVEncodeInfoBlock struct denoting position,
size, and delta quantizer for each block
From: Nick Renieris
Also, ensure no false positives when determining DNG bayer images, by
setting them in tiff.c instead of relying on a heuristic. There's no
way to determine this just from the JPEG data, so we have to pass this
information from outside the MJPEG decoder.
Signed-off-by: Nick
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index a118c37c41..4620508d53 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@
From: Nick Renieris
DNG samples here can now be decoded:
- https://www.photographyblog.com/previews/pentax_k1_photos
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 73 +++
1 file changed, 42 insertions(+), 31 deletions(-)
diff --git
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index d5673abb19..a118c37c41 100644
--- a/libavcodec/tiff.c
+++
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
From: Nick Renieris
Sample file:
https://drive.google.com/open?id=0B4JyRT3Lth5HVndyOTVOdWktM3J4TFEydTk1MnY3RWlpSzVB
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/libavcodec/tiff.c
From: Nick Renieris
Samples:
- Embedded JPEG images in the DNG images here:
https://www.photographyblog.com/previews/pentax_k1_photos
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mjpegdec.c
From: Nick Renieris
Inited to (2^BitsPerSample)-1 as per the DNG Specification
This fixes decoding for "X7 CinemaDNG" samples here:
- https://www.dji.com/gr/zenmuse-x7/info#downloads
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 13 ++---
1 file changed, 10 insertions(+), 3
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 37fda15162..174ca168c6 100644
--- a/libavcodec/tiff.c
+++
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 174ca168c6..9d20763186 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -1038,6 +1038,18 @@ static int
From: Nick Renieris
Some JPEGs [1] have incorrect DHT entries that map 2 codes to
the same value.
The second (last) mapping does not ever actually appear in the
code stream, therefore ignoring any mappings after the first one
fixes this.
Without this, an "mjpeg_decode_dc: bad vlc: 0:0" error
From: Nick Renieris
In an image [1], the height was equal to the tile length (full-height
tile) and after `height % tile_length` was applied to them with the
current code, it resulted in the operating tile_length to be 0. This
commit makes this leftover logic only applies if it's necessary.
From: Nick Renieris
This enables decoding of DNG images generated by the 'DJI Zenmuse X7'
digital camera
Samples: https://www.dji.com/gr/zenmuse-x7/info#downloads
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 61 +++
1 file changed, 51
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
> -Original Message-
> From: Guo, Yejun
> Sent: Tuesday, July 30, 2019 9:26 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun
> Subject: [PATCH 2/2] convert_from_tensorflow.py: support conv2d with dilation
>
> conv2d with dilation > 1 generates tens of nodes in graph, it is not
> easy
On 8/8/2019 10:29 PM, rzu...@tebako.net wrote:
> From: Raphaël Zumer
>
> This matches a name change in avutil/pixdesc.
>
> Signed-off-by: Raphaël Zumer
> ---
> libavfilter/version.h | 2 +-
> libavfilter/vf_colorspace.c | 2 +-
> libavfilter/vf_setparams.c | 2 +-
>
On Fri, Aug 9, 2019 at 12:40 PM Hendrik Leppkes wrote:
> The enum and our values are aligned to the H.273 / ISO/IEC 23001-8
> standards, which documents this entry to correspond to the primaries
> in use by vf_colorspace
That makes sense, although I'm now interested to find out where those
On Wed, Nov 29, 2017 at 4:26 AM James Almer wrote:
> On 11/28/2017 4:55 PM, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol
> > ---
> > libavcodec/mlpenc.c | 22 +++---
> > 1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavcodec/mlpenc.c
On Fri, Aug 9, 2019 at 1:34 PM Moritz Barsnick wrote:
> On Thu, Aug 08, 2019 at 22:09:04 +0100, Cameron Cawley wrote:
> > Signed-off-by: Cameron Cawley
> > ---
> > doc/general.texi| 1 +
> > libavcodec/Makefile | 1 +
> > libavcodec/adpcm.c | 14 ++
> >
On 2019-08-09 7:51 a.m., Vittorio Giovara wrote:
this value was already present, this is just a rename
I think it counts as a new enum value (variant), even though it aliases
another.
I initially wrote "rename", but reworded the commit message based on
James Almer's comment:
The subject
On Fri, Aug 9, 2019 at 3:29 AM wrote:
> From: Raphaël Zumer
>
> This is an alias for JEDEC P22.
>
> The name associated with the value is also changed
> from "jedec-p22" to "ebu3213" to match ITU-T H.273.
>
> Signed-off-by: Raphaël Zumer
> ---
> doc/APIchanges | 3 +++
>
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Friday, August 9, 2019 17:40
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
On Fri, Aug 9, 2019 at 12:32 PM Kevin Wheatley
wrote:
>
> Is there a change to include the EBU primaries?
>
> https://tech.ebu.ch/docs/tech/tech3213.pdf
>
> White 0.313 0.329
> Red 0.64 0.33
> Green 0.29 0.60
> Blue 0.15 0.06
>
> as the ones currently called AVCOL_PRI_JEDEC_P22 are not those ones
Hi Marton,
The issue with the out of sync TC was reproducible on all tapes and decks
that we tested. I don't have the exact number now, but a few dozens, less
than 100. They all had between 7 and 17 frames out of sync. We were not
able to obtain anything more in sync than 7 frames.
The TC sync
On Thu, Aug 08, 2019 at 22:09:04 +0100, Cameron Cawley wrote:
> Signed-off-by: Cameron Cawley
> ---
> doc/general.texi| 1 +
> libavcodec/Makefile | 1 +
> libavcodec/adpcm.c | 14 ++
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
>
On 28-07-2019 01:37 AM, Marton Balint wrote:
On Fri, 26 Jul 2019, Gyan wrote:
Patch supported by and tested at Google.
Seems like a huge hack for a decklink issue... ;)
I wonder if there are better approaches to work around this. Like
dropping all frames until we have a valid signal.
Is there a change to include the EBU primaries?
https://tech.ebu.ch/docs/tech/tech3213.pdf
White 0.313 0.329
Red 0.64 0.33
Green 0.29 0.60
Blue 0.15 0.06
as the ones currently called AVCOL_PRI_JEDEC_P22 are not those ones at
least in vf_colorspace.c
[AVCOL_PRI_JEDEC_P22] = { WP_D65, {
On Tue, Aug 6, 2019 at 10:55 AM Fu, Linjie wrote:
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Hendrik Leppkes
> > Sent: Tuesday, August 6, 2019 16:27
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> >
Hi,
patch attached.
If you still encounter hash failures please share input file.
0001-avcodec-mlpenc-fix-invalid-checks-sample-buffers-are.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
> 在 2019年8月5日，上午10:29，Steven Liu 写道：
>
> just remove the 'i' of the v3 mail subject.
> write mpegts or fmp4 context into buffer, and flush the buffer into
> output file when split fragment. merge two format split workflow into
> one workflow
>
> Signed-off-by: Steven Liu
> ---
>
On 08/08/2019 20:33, OvchinnikovDmitrii wrote:
Added linux support for amf encoder through vulkan.
To use h.264(AMD VCE) encoder on linux amdgru-pro version 19.20+ and
amf-amdgpu-pro package(amdgru-pro contains, but does not install automatically)
are required.
This driver can be installed
Limin Wang (12019-08-09):
> IMO, the medata memory is allocate by
> av_content_light_metadata_create_side_data() api, it's valid already,
> there is no need to check the size.
Unless somebody made a programming mistake somewhere else.
Regards,
--
Nicolas George
signature.asc
Description:
rzu...@tebako.net (12019-08-08):
> From: Raphaël Zumer
>
> This matches a name change in avutil/pixdesc.
>
> Signed-off-by: Raphaël Zumer
> ---
> libavfilter/version.h | 2 +-
> libavfilter/vf_colorspace.c | 2 +-
> libavfilter/vf_setparams.c | 2 +-
> libavfilter/vf_zscale.c | 2
For now I'm just reading and storing EPG data, once this part is done I'd
like to do what you said.
But first we will have to think of an easy way to change/insert descriptors
inside a specific table.
Thanks for your response :)
Le jeu. 8 août 2019 à 17:57, Phil Burr a écrit :
> Hello Anthony,
Well… then, can anyone merge this patch?
Best regards,
Lars
On Mon, 5 Aug 2019 14:31:43 +0200
Paul B Mahol wrote:
> On Mon, Aug 5, 2019 at 1:31 PM Lars Kiesow wrote:
>
> > Hi everyone,
> > this is now open for nearly a month with no more comments or change
> > requests. Anything else I should
On Thu, Aug 8, 2019 at 11:20 PM Cameron Cawley
wrote:
> Signed-off-by: Cameron Cawley
> ---
> doc/general.texi| 1 +
> libavcodec/Makefile | 1 +
> libavcodec/adpcm.c | 14 ++
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
>
Hi Marton,
‐‐‐ Original Message ‐‐‐
On Thursday, 8 de August de 2019 23:27, Marton Balint wrote:
> PCR generation was based on counting packets for both CBR and VBR streams.
> Couting packets might have worked for CBR streams (when muxrate was specified)
> but it only took into account
Hi Marton,
‐‐‐ Original Message ‐‐‐
On Thursday, 8 de August de 2019 23:27, Marton Balint wrote:
> The MPEG-TS muxer had a serious bug related to the use of multiple programs:
> in that case, the PCR pid selection was incomplete for all services except
> one.
> This patch solves this
On Fri, Aug 9, 2019 at 1:26 AM Michael Niedermayer
wrote:
> Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
> Fixes:
> 15764/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5102101203517440
>
> Found-by: continuous fuzzing process
>
Hi Gyan, Nicolas and Alexander,
‐‐‐ Original Message ‐‐‐
On Friday, 9 de August de 2019 3:18, Alexander Strasser
wrote:
>
> [...]
> Gyan
>
> [...]
> Nicolas George
>
> [...]
> Alexander
I appreciate your suggestions with the name. But, we need to select one.
So I propose a
53 matches
Mail list logo
