Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

frame_worker_thread for this feature is not so useful but I am ok with either patch v2 or v3. Thanks much,     Jérôme On 20/02/2024 16:07, Jerome Martinez wrote: Attached is an updated version of the patch proposal. About the idea to keep separate fields in the output AVFrame, I note from the discussion

Re: [FFmpeg-devel] [PATCH v3] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

On 01/03/2024 23:29, Tomas Härdin wrote: sön 2024-02-25 klockan 05:14 +0100 skrev Jerome Martinez: [...] I also needed to add a dedicated AVStream field for saying that the decoder is able to manage this functionality (and is needed there). What is the added value to call the decoder twice

Re: [FFmpeg-devel] [PATCH v3] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

the feature in the decoders (even if we implement the idea of calling the decoder twice, the decoder needs to be expanded for this feature). So IMO no dev to do there too for the moment. Jérôme From f4311b718012a92590ce6168355ec118e02052a8 Mon Sep 17 00:00:00 2001 From: Jerome Martinez Date: Tue, 20 Feb

Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

On 21/02/2024 14:11, Tomas Härdin wrote: mxfdec can detect cases where there will be two separate fields in one KLV, In practice the issue is not to detect I2 case in mxfdec (it saves us only a little during probing of the first frame, but I could add such signaling in a patch after this

Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

. It also changes the jpeg2000_decode_frame return value to the count of bytes parsed, it seems that it was what is expected but in practice it was not doing that, fixing the return value could be a separate patch if preferred. Jérôme On 02/02/2024 16:55, Jerome Martinez wrote: Before this pa

Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

On 19/02/2024 12:08, Tomas Härdin wrote: mån 2024-02-19 klockan 00:14 +0100 skrev Tomas Härdin: tor 2024-02-15 klockan 16:02 +0100 skrev Jerome Martinez: On 05/02/2024 01:19, Tomas Härdin wrote: [...] Which entry in the table would the provided file correspond to? To me it seems none of them

Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

On 05/02/2024 01:19, Tomas Härdin wrote: [...] Which entry in the table would the provided file correspond to? To me it seems none of them fit. There's two fields, meaning two j2k codestreams, in each corresponding essence element KLV packet (I think, unless CP packets get reassembled somewhere

Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

On 03/02/2024 11:00, Tomas Härdin wrote: fre 2024-02-02 klockan 16:55 +0100 skrev Jerome Martinez: Before this patch, the FFmpeg MXF parser correctly detects content with 2 fields in 1 AVPacket as e.g. interlaced 720x486 but the FFmpeg JPEG 2000 decoder reads the JPEG 2000 SIZ header without

[FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

4:3, 29.97 fps, 29.97 tbr, 29.97 tbn From 5242971da7d2cf8d8713144e4a7bcc4aa06437c4 Mon Sep 17 00:00:00 2001 From: Jerome Martinez Date: Thu, 1 Feb 2024 17:58:02 +0100 Subject: [PATCH] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket --- libavcodec/jpeg2000

Re: [FFmpeg-devel] [PATCH 3/3] [RFC] avcodec/ffv1: Better rounding for slice positions

On 07/10/2023 02:14, Michael Niedermayer wrote: This fixes green lines in some odd dimensions with some slice configurations like Ticket 5548 This also changes the encoder and whats encoded, and would require an update to the specification. This change attempts to limit the change to

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: fix check of minimal data size for unpadded content

On 19/10/2022 11:47, Jerome Martinez wrote: stride value is not relevant with unpadded content and the total count of pixels (width x height) must be used instead of the rounding based on width only then multiplied by height unpadded_10bit value computing is moved sooner in the code in order t

Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support

On 31/01/2023 15:53, Tomas Härdin wrote: sön 2023-01-29 klockan 11:36 -0500 skrev Dave Rice: On Jan 20, 2023, at 10:17 AM, Tomas Härdin wrote: ons 2023-01-18 klockan 15:15 +0100 skrev Jerome Martinez: On 18/01/2023 14:40, Tomas Härdin wrote: Creating a new subthread because I just noticed

Re: [FFmpeg-devel] avformat/mxfenc: fix stored/sampled/displayed width/height

roblock thing). The FATE tests for DV are not impacted because they are SD and SD width/height are multiple of 16 so I added a DV100 test. JérômeFrom c93c73164d427b2bcd29744b5a26ab82b1fe223a Mon Sep 17 00:00:00 2001 From: Jerome Martinez Date: Sat, 14 Jan 2023 13:32:36 +0100 Subject: [PATCH] avfor

Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support

On 18/01/2023 11:12, Tomas Härdin wrote: mån 2023-01-16 klockan 15:17 +0100 skrev Jerome Martinez: [...] I think it may be relevant to keep the exact same code for the exact same purpose. Would be no more relevant if version and micro_version can be taken from FFV1Context. Perhaps we can have

Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support

On 18/01/2023 14:40, Tomas Härdin wrote: Creating a new subthread because I just noticed something I am a bit lost there because the line of code below is not part of this FFV1 patch. Additionally, none on my patches (FFV1 of MXF stored/sampled/displayed fix) modifies the discussed behavior

Re: [FFmpeg-devel] avformat/mxfenc: fix stored/sampled/displayed width/height

On 16/01/2023 15:00, Nicolas Gaullier wrote: Before the patch: - stored values were rounded to upper 16 multiple also for formats not using macroblocks (should be st->codecpar->width and st->codecpar->height when not MPEG formats; note that I found no other muxer doing the rounding for AVC,

Re: [FFmpeg-devel] avformat/mxfenc: fix stored/sampled/displayed width/height

On 16/01/2023 14:50, Tomas Härdin wrote: lör 2023-01-14 klockan 16:48 +0100 skrev Jerome Martinez: Before the patch: - stored values were rounded to upper 16 multiple also for formats not using macroblocks (should be st->codecpar->width and st->codecpar->height when not MPEG f

Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support

On 16/01/2023 15:00, Tomas Härdin wrote: JPEG2000 will also need an RGBA descriptor filled out, might be good to prepare for that. this was the idea behind the way it is coded, so there is only a new mxf_write_jpeg2000_desc function to write, like the one for FFV1 i.e. static void

Re: [FFmpeg-devel] avformat/mxfenc: fix stored/sampled/displayed width/height

On 14/01/2023 21:04, Michael Niedermayer wrote: On Sat, Jan 14, 2023 at 04:48:10PM +0100, Jerome Martinez wrote: [...] +stored_height = (stored_height+15)/16*16; If this is supposed to match the actual macroblocks, then this would have to consider field pictures and interlacing

[FFmpeg-devel] avformat/mxfenc: fix stored/sampled/displayed width/height

peg2video.mxf From cda353059886182aab2e258023c4d027c448344b Mon Sep 17 00:00:00 2001 From: Jerome Martinez Date: Sat, 14 Jan 2023 13:32:36 +0100 Subject: [PATCH] avformat/mxfenc: fix stored/sampled/displayed width/height Stored values are rounded to upper 16 multiple only for MPEG related formats Sampled and displayed w

[FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support

=duration=10:size=pal:rate=pal -field_order tt -c:v ffv1 -level 3 test_ffv1_pal.mxf ffmpeg -f lavfi -i testsrc=duration=10:size=1920x1080 -pix_fmt yuv422p10 -c:v ffv1 -level 3 test_ffv1_hd.mxf From 2e38dc0a114a1706f6d108ea9ca3e86083bfc2eb Mon Sep 17 00:00:00 2001 From: Jerome Martinez Date: Wed

[FFmpeg-devel] [PATCH] avcodec/dpx: fix check of minimal data size for unpadded content

of minimal content size Fix 'Overread buffer' error when the content is not lucky enough to have (enough) padding bytes at the end for not being rejected by the formula based on the stride value Signed-off-by: Jerome Martinez ---  libavcodec/dpx.c | 34 ++  1 file

Re: [FFmpeg-devel] [PATCH] lavc/ffv1: Properly check that the 4th and 5th quant tables are zeroes

On 03/01/2020 22:59, Derek Buitenhuis wrote: On 02/01/2020 23:09, Michael Niedermayer wrote: I think if entry 128 is 0 then the whole table must be 0. If that is the case, checking the entry 128 of table 4 and 5 would be enough and caching the entry comparission is maybe not needed. Is this

Re: [FFmpeg-devel] [PATCH] lavc/ffv1: Properly check that the 4th and 5th quant tables are zeroes

On 02/01/2020 16:22, Derek Buitenhuis wrote: Currently, the decoder checks the 128th value of the 4th quant table during while deriving the context on each sample, in order to speed itself up. This is due to relying on the behavior of FFmpeg's FFV1 encoder, in which if that value is zero, the

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/rangecoder: factorize termination version code

On 19/12/2018 02:40, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer --- libavcodec/ffv1enc.c | 10 +++--- libavcodec/rangecoder.c | 4 +++- libavcodec/rangecoder.h | 2 +- libavcodec/snowenc.c | 2 +- libavcodec/sonic.c| 2

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

On 12/10/2018 15:30, Jan Ekström wrote: And while it seems like we're focusing on the arbitrary limit in av_malloc (which is an issue of its own), I do note that for this specific case this "worst case packed frame size" allocation heuristic might have to be modified? Or at least explained if

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

On 12/10/2018 11:15, Carl Eugen Hoyos wrote: 2018-10-11 14:01 GMT+02:00, Jerome Martinez : - why is having a number > INT_MAX an issue? modern machines are 64-bit and have 8+ GB of RAM So where is the issue? The issue is that vanilla FFmpeg shows a warning in the scenario I indic

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

On 11/10/2018 14:08, Paul B Mahol wrote: On 10/11/18, Jerome Martinez wrote: Hi, Testing FFmpeg FFV1 encoder on big frames (more than 4K: 4300x3956), I have a warning for each frame encoded (so a lot of warnings!): [ffv1 @ 024a6bcfe880] Cannot allocate worst case packet size, the encoding

[FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

Hi, Testing FFmpeg FFV1 encoder on big frames (more than 4K: 4300x3956), I have a warning for each frame encoded (so a lot of warnings!): [ffv1 @ 024a6bcfe880] Cannot allocate worst case packet size, the encoding could fail Checking avcodec/ffv1enc.c, it is due to the following lines:    

Re: [FFmpeg-devel] [PATCH]lavc/dpx: Support 10-bit packing method b (msbpad)

On 16/06/2018 17:49, Carl Eugen Hoyos wrote: Hi! Attached patch allows to decode 10-bit dpx files with packing method b, needs the 12-bit patch. Great to see the support of Method B. Please comment, Carl Eugen [...] +    *lbuf = (*lbuf << 10) | (*lbuf >> shift); Padding bits are 0 in

[FFmpeg-devel] avcodec/dpx: Support for RGBA 12-bit packed decoding

On 08/02/2018 11:28, Jerome Martinez wrote: Currently RGB and RGBA 12-bit are supported by DPX decoder only if component values are padded (packing "Filled to 32-bit words, method A"). This patch adds decoding of RGB and RGBA 12-bit with no padding (packing "Packed into 32-bit

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding

On 11/04/2018 00:16, Lou Logan wrote: On Tue, Apr 10, 2018, at 2:05 PM, Michael Niedermayer wrote: what do you mean by "Git and me are not good friends" ? If git hates you and sometimes does things that you didnt intend at all then that would be a problem with direct pushes as theres no way to

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding

On 10/04/2018 12:34, Carl Eugen Hoyos wrote: 2018-04-10 12:28 GMT+02:00, Kieran O Leary : I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci Resolve. Testing is good, apart I thought the patch was "technically" OK, as I answered to all change

Re: [FFmpeg-devel] [PATCH 6/7] avcodec/ffv1: support of more pix_fmt

On 09/03/2018 18:30, Paul B Mahol wrote: On 3/7/18, Jerome Martinez <jer...@mediaarea.net> wrote: With some sources having specific pix_fmt (9/10/12/14 bit), the source is padded to 16-bit when the pix_fmt is not supported natively by the FFV1 encoder. Nothing is lost ("cutting&quo

Re: [FFmpeg-devel] [PATCH 2/7] avcodec/ffv1enc: add information message when version is changed by the encoder

On 09/03/2018 03:15, Michael Niedermayer wrote: On Thu, Mar 08, 2018 at 03:12:26AM +0100, Jerome Martinez wrote: checking range coder part, I see that currently there is actually a slight difference with the other AV_LOG_INFO, I don't indicate the message when level is not indicated, as I

Re: [FFmpeg-devel] [PATCH 2/7] avcodec/ffv1enc: add information message when version is changed by the encoder

On 08/03/2018 01:33, Michael Niedermayer wrote: On Wed, Mar 07, 2018 at 04:49:24PM +0100, Jerome Martinez wrote: There is a message when coder type is forced to a value not chosen by user, but no message when version is forced to a value not chosen by user. This patch adds such message for more

Re: [FFmpeg-devel] [PATCH 1/7] avcodec/ffv1dec: add missing error messages when a frame is invalid

On 08/03/2018 01:17, Michael Niedermayer wrote: In the cases where the error is about a scalar value, that value should be printed in the error message (unless it was alread printed elsewhere) Patch modified, showing the scalar value. From 13db9fc4da1d0e531e516bd87d084233e231f0e7 Mon Sep 17

[FFmpeg-devel] [PATCH 7/7] avcodec/ffv1enc: remove warning about transparency

The message about the need of a recent FFmpeg version when encoding alpha plane is 5+ year old, not really relevant anymore. This patch removes the message. From 8e3bbad708b5a3a24920133c5bef0b7399375393 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=

[FFmpeg-devel] [PATCH 7/7] avcodec/ffv1enc: remove warning about transparency

The message about the need of a recent FFmpeg version when encoding alpha plane is 5+ year old, not really relevant anymore. This patch removes the message. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] [PATCH 6/7] avcodec/ffv1: support of more pix_fmt

With some sources having specific pix_fmt (9/10/12/14 bit), the source is padded to 16-bit when the pix_fmt is not supported natively by the FFV1 encoder. Nothing is lost ("cutting" to the source bitdepth permits to retrieve the exact source), but the source bitdepth is not indicated so it is

[FFmpeg-devel] [PATCH 5/7] avcodec/ffv1enc: support of 1024 slices

FFV1 decoder supports up to 1024 slices but FFV1 encoder permits only 961 (31x31) slices. This patch permits to create 1024 (32x32) slices. From 494115e12981a9c54bf04b63a13ef50364349de2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Wed, 7 Mar

[FFmpeg-devel] [PATCH 4/7] avcodec/ffv1enc: prevent encoder to create non-lossless streams with some chroma subsamplings

When all luma samples for a chroma sample are not in the same slice, resulting bitstream is valid but the compression then decompression is not lossless. ffmpeg -y -f lavfi -i mandelbrot=s=1925x1080 -vf format=yuv411p -vframes 1 -c ffv1 -slices 16 a.mkv ffmpeg -y -f lavfi -i

[FFmpeg-devel] [PATCH 3/7] avcodec/ffv1enc: prevent encoder to create buggy streams with small frame sizes

When there is 1 pixel per slice for the first half of slices, the encoder creates buggy slices. Example: ffmpeg -f lavfi -i mandelbrot=s=8x8 -vf format=yuv444p -t 1 -c ffv1 -coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv ffmpeg -f lavfi -i mandelbrot=s=9x9 -vf format=yuv444p -t

[FFmpeg-devel] [PATCH 2/7] avcodec/ffv1enc: add information message when version is changed by the encoder

There is a message when coder type is forced to a value not chosen by user, but no message when version is forced to a value not chosen by user. This patch adds such message for more coherency in the messages, and the user is informed that the command is not fully respected. ffmpeg f lavfi -i

[FFmpeg-devel] [PATCH 3/7] avcodec/ffv1enc: prevent encoder to create buggy streams with small frame sizes

When there is 1 pixel per slice for the first half of slices, the encoder creates buggy slices. Example: ffmpeg -f lavfi -i mandelbrot=s=8x8 -vf format=yuv444p -t 1 -c ffv1 -coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv ffmpeg -f lavfi -i mandelbrot=s=9x9 -vf format=yuv444p -t

[FFmpeg-devel] [PATCH 2/7] avcodec/ffv1enc: add information message when version is changed by the encoder

There is a message when coder type is forced to a value not chosen by user, but no message when version is forced to a value not chosen by user. This patch adds such message for more coherency in the messages, and the user is informed that the command is not fully respected. ffmpeg f lavfi -i

[FFmpeg-devel] [PATCH 1/7] avcodec/ffv1dec: add missing error messages when a frame is invalid

A buggy file (before the patch preventing such issue is applied): ffmpeg -y -f lavfi -i mandelbrot=s=31x31 -vframes 1 -c ffv1 -slices 961 a.mkv Then with: ffmpeg -y -f lavfi -i mandelbrot=s=31x31 -vframes 1 source.jpg ffmpeg -y -i a.mkv a.jpg There is no error message despite the fact the

[FFmpeg-devel] [PATCH 0/7] Hardening FFV1

A bunch of independent patches related to FFV1 encoder and decoder, fixing some issues found during development of FFV1 regression tests (plan is to use a part of these regression tests in FATE). Some of the patches prevent FFmpeg to create buggy files, without fixing the issue. My point of

[FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding

On 08/02/2018 11:28, Jerome Martinez wrote: Currently RGB and RGBA 12-bit are supported by DPX decoder only if component values are padded (packing "Filled to 32-bit words, method A"). This patch adds decoding of RGB and RGBA 12-bit with no padding (packing "Packed into 32-bit

[FFmpeg-devel] [PATCH] avcodec/ffv1: Support for GBRAP10 and GBRAP12

Add support for 10- and 12-bit/component RGB with Alpha encoding and decoding in FFV1. Benched with START/STOP_TIMER around "for (x = 0; x < w; x++)" part during decoding, before the previous patch and with the previous patch + this patch, no obvious impact (+/-1%), e.g. with 1 second of

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

On 12/02/2018 22:37, Carl Eugen Hoyos wrote: 2018-02-12 20:47 GMT+01:00 Jerome Martinez <jer...@mediaarea.net>: https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx is indicated by the person who provided it as with DPX alpha channel used for actually storing infrared

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

On 09/02/2018 11:39, Carl Eugen Hoyos wrote: I think the question is out of topic for this patch proposal, as this question is global for all flavors of DPX (also the ones already supported by FFmpeg, i.e. FFmpeg already supports RGBA 12-bit filled with Method A, here I just add the support

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

On 09/02/2018 12:20, Kieran O Leary wrote: Hi both, I'm just wondering if the past duration errors in my earlier email mean anything,or should they be ignored? They are independent from the patch, e.g.: https://stackoverflow.com/questions/30782771/what-does-past-duration-x-xxx-too-large-mean

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

On 09/02/2018 11:32, Carl Eugen Hoyos wrote: [...] please mention ticket #5639 in the commit message. I should definitely have indicated this source instead of my copy, my mistake. Commit message extended with it. FYI I am running tests on several DPX flavors (to FFV1 and back to DPX,

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

On 09/02/2018 11:15, Carl Eugen Hoyos wrote: Sorry, I see a line was missing in my first post, the one with the link to the RGBA test file. Test file for RGBA 12-bit packed: https://github.com/MediaArea/RAWcooked-RegressionTestingFiles/tree/master/Formats/DPX/Flavors/RGBA_12_Packed_BE Is this

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

On 09/02/2018 02:19, Carl Eugen Hoyos wrote: 2018-02-08 11:28 GMT+01:00 Jerome Martinez <jer...@mediaarea.net>: Currently RGB and RGBA 12-bit are supported by DPX decoder only if component values are padded (packing "Filled to 32-bit words, method A"). This patch adds decoding

[FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

Currently RGB and RGBA 12-bit are supported by DPX decoder only if component values are padded (packing "Filled to 32-bit words, method A"). This patch adds decoding of RGB and RGBA 12-bit with no padding (packing "Packed into 32-bit words"). As I have no file with line boundaries not aligned

Re: [FFmpeg-devel] [Cellar] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

On 03/02/2018 14:48, Michael Niedermayer wrote: I hope this will not reduce interrest in working on a improved 9-16bit mode in v4. I don't like to put politics in technical stuff, but here this is politics, and I think that blocking an easy improvement of FFV1 v3 encoding/decoding in FFmpeg

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

On 04/02/2018 15:00, Michael Niedermayer wrote: diff --git a/libavcodec/ffv1enc_template.c b/libavcodec/ffv1enc_template.c index b7eea0dd70..2763082540 100644 --- a/libavcodec/ffv1enc_template.c +++ b/libavcodec/ffv1enc_template.c @@ -122,8 +122,8 @@ static av_always_inline int

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

On 03/02/2018 00:10, Michael Niedermayer wrote: On Thu, Feb 01, 2018 at 01:43:00PM +0100, Jerome Martinez wrote: Add support for 16-bit/component RGB with Alpha encoding and decoding in FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding. Resulting bitstream was tested about

Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

On 05/01/2018 11:18, Jerome Martinez wrote: 1 year without RGB48 related patches, tested by a couple of users, tested with a FFV1 conformance checker, I suggest that FFV1 RGB48 support in FFmpeg does not mandate anymore the user to add " -strict experimental" on the command l

[FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

Add support for 16-bit/component RGB with Alpha encoding and decoding in FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding. Resulting bitstream was tested about lossless encoding/decoding by the compression from DPX to FFV1 then decompression from FFV1 to DPX, see commands

Re: [FFmpeg-devel] [Cellar] [PATCH] FFV1: make RGB48 support as non-experimental

On 07/01/2018 20:08, Michael Niedermayer wrote: [...] This is correct but i think misleading a bit the 17bit case this is about uses a seperate codepath. For your (FFmpeg) encoder and decoder. Not mine (same code path is used for 8/10/12/16/... bit RGB and YUV with my encoder and decoder).

Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

On 06/01/2018 23:21, Michael Niedermayer wrote: On Sat, Jan 06, 2018 at 04:54:18PM +0100, Jerome Martinez wrote: On 06/01/2018 02:05, Michael Niedermayer wrote: ffv1enc.c |4 1 file changed, 4 deletions(-) acfc60c913b311b148f2eeef2d2d6ea9e37afcf7 0001-avcodec-ffv1enc-mark-RGB48

Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

On 06/01/2018 02:05, Michael Niedermayer wrote: ffv1enc.c |4 1 file changed, 4 deletions(-) acfc60c913b311b148f2eeef2d2d6ea9e37afcf7 0001-avcodec-ffv1enc-mark-RGB48-support-as-non-experiment.patch From 303f63fb7e6172fdb7de66da1f8a4006b79a535f Mon Sep 17 00:00:00 2001 From:

Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

On 05/01/2018 16:14, Tobias Rapp wrote: On 05.01.2018 11:18, Jerome Martinez wrote: 0001-FFV1-make-RGB48-support-as-non-experimental.patch From cd1bfe68a1a809700f25e593ac21ca3876d265ad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <jer...@mediaarea.net> Date:

[FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

1 year without RGB48 related patches, tested by a couple of users, tested with a FFV1 conformance checker, I suggest that FFV1 RGB48 support in FFmpeg does not mandate anymore the user to add " -strict experimental" on the command line during encoding. From

Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not write 0 duration for subtitles

On 23/11/2017 20:02, John Stebbins wrote: [...] It's not practical to know the duration of the previous subtitle before writing it because you can't know it till you have seen this empty PGS.  Once you've seen the empty PGS, it is often too late to properly interleave the previous PGS in the

Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not write 0 duration for subtitles

On 12/11/2017 03:12, Carl Eugen Hoyos wrote: The matroska spec says blockduration == 0 means the frame is not a keyframe. Since all subtitles are "keyframes", 0 blockduration should not be written. As I understand from discussion on CELLAR mailing-list: - if is not expected to have a frame

Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not write 0 duration for subtitles

On 12/11/2017 03:12, Carl Eugen Hoyos wrote: The matroska spec says blockduration == 0 means the frame is not a keyframe. Since all subtitles are "keyframes", 0 blockduration should not be written. The issue is in the specifications:

Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not write 0 duration for subtitles

On 12/11/2017 03:12, Carl Eugen Hoyos wrote: -put_ebml_uint(pb, MATROSKA_ID_BLOCKDURATION, duration); +if (duration > 0) +put_ebml_uint(pb, MATROSKA_ID_BLOCKDURATION, duration); In that case, the duration of the block is DefaultDuration (if it exists),

Re: [FFmpeg-devel] [PATCH] libavcodec: fix field_order labelling

Le 29/08/2017 à 15:16, Tobias Rapp a écrit : On 27.08.2017 19:13, Marton Balint wrote: I agree that a lot of stuff in the codebase is consistent with the updated descriptions. However, as far as I see libavformat/mxfdec.c seems to follow the existing docs, so I think that needs changing as

Re: [FFmpeg-devel] [PATCH] ffmpeg: fix setting field_order during muxing

Le 10/08/2017 à 04:43, James Almer a écrit : AVFrame.top_field_first doxy states "If the content is interlaced, is top field displayed first." And AVFieldOrder doxy defines: AV_FIELD_TB, //< Top coded first, bottom displayed first AV_FIELD_BT, //< Bottom coded

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

Le 01/03/2017 à 15:51, wm4 a écrit : On Wed, 1 Mar 2017 15:00:27 +0100 Jerome Martinez <jer...@mediaarea.net> wrote: [...] then in 12 (or 24, or 36 months), the time that new FFmpeg versions propagate everywhere (we also open tickets for other demuxers in order to get the support of such

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

Le 01/03/2017 à 09:43, Carl Eugen Hoyos a écrit : 2017-03-01 4:40 GMT+01:00 Michael Niedermayer : On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote: Hi! Attached patch fixes ticket #6206 here. Please comment, Carl Eugen previous ffmpeg versions dont

Re: [FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer

Le 06/10/2016 à 12:29, Michael Niedermayer a écrit : Does this reduce writing speed ? in the same manner as e.g. reducing FFV1 writing speed with default configuration, i.e. with CRC per slice (same kind of job). On my machine (i7 from 2012), CRC computing takes less than 1% of the CPU when

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt

Le 13/06/2016 à 19:31, Jerome Martinez a écrit : [...] - JPEG 2000 RCT 9/10/12/14 bit depths with alpha are mapped to a FFmpeg pix_fmt without alpha (e.g. AV_PIX_FMT_GBRP9 for 9-bit with alpha), which is not expected. Sorry, I forgot a remark about this part of the patch: the decoder can

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt

Le 13/06/2016 à 19:55, Michael Niedermayer a écrit : On Mon, Jun 13, 2016 at 07:31:15PM +0200, Jerome Martinez wrote: FFV1 decoder: When checking pix_fmt mapping, some bitstreams are mapped to an incorrect pix_fmt instead of being rejected (ENOSYS). Actually, such bitstreams are not supported

[FFmpeg-devel] [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt

FFV1 decoder: When checking pix_fmt mapping, some bitstreams are mapped to an incorrect pix_fmt instead of being rejected (ENOSYS). Actually, such bitstreams are not supported (FFmpeg encoder does not produce such bitstream, such bitstream may come only from another encoder for the moment).

Re: [FFmpeg-devel] [libav-devel] Remote participation options for IETF session on MKV/FFV1 at July 22 @ 9 CEST

Le 21/07/2015 20:03, Ronald S. Bultje a écrit : +1. I can't stress how important this is. In addition, the spec should be the master, not any one implementation (because then the bugs in that one implementation will be the spec, regardless of what the bug is). In theory, spec should be the

Re: [FFmpeg-devel] [PATCH] FFV1 specification: Merge of FrameHeader01() and GlobalHeader()

Le 20/05/2015 03:44, Michael Niedermayer a écrit : [...] If you want to allow multiple w/h/colorspace, its probably better to allow multiple global headers as in h264/h265 and put a index in the frame header to choose one of the parameter sets some of the tables are also large IIRC

Re: [FFmpeg-devel] [PATCH] FFV1 specification: Merge of FrameHeader01() and GlobalHeader()

Le 19/05/2015 21:15, Michael Niedermayer a écrit : On Mon, May 18, 2015 at 09:04:01PM +0200, Jerome Martinez wrote: FrameHeader01() and GlobalHeader() have a lot of common fields and having a common function + default value for fields unused in previous versions is less complex and more

[FFmpeg-devel] [PATCH] FFV1 specification: Merge of FrameHeader01() and GlobalHeader()

From c6f16e561d40972e058f4e163ff753bce8fc8acc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= jer...@mediaarea.net Date: Mon, 18 May 2015 20:59:09 +0200 Subject: [PATCH] Merge of FrameHeader01() and GlobalHeader() FrameHeader01() and GlobalHeader() have a lot of common

Re: [FFmpeg-devel] [PATCH] FFV1 specification: Add more details about the configuration record

Le 14/05/2015 18:57, Michael Niedermayer a écrit : [...] +reserved the reserved bit is not defined, This way one could misunderstand it as if it was allowed to add such bits in the encoder I don't see it as something allowed (i.e. as a user data for private use) but you're right, it is not

Re: [FFmpeg-devel] [PATCH] FFV1 specification: Add more details about the configuration record

Le 14/05/2015 00:48, Michael Niedermayer a écrit : nut and ffm surely work too I have doubts there are lot of FFV1 content in such container format ;-) Anyway: - Patch updated with NUT file format information - I tested FFmpeg for the support of FFV1 in FFM (source MOV files are there

Re: [FFmpeg-devel] [PATCH] FFV1 specification: Add more details about the configuration record

Le 13/05/2015 21:58, Michael Niedermayer a écrit : Does the text somewhere say why just avi and mp4 are listed as containers ? (i didnt spot that but i might have missed it) They are the only containers I know supporting FFV1 (Matroska is not listed here because it does not support FFV1

[FFmpeg-devel] [PATCH] FFV1 specification: Add more details about the configuration record

Add more details about the configuration record Version 2+ of the format has a configuration record which is in the underlying container track definition. GlobalHeader definition is split in 2 parts: - a configuration record part, including more details about how to find it in AVI and MP4,

Re: [FFmpeg-devel] [PATCH] FFV1 specification: Reduce redundancy in the description of xxPlane() and xxLine()

Le 03/05/2015 04:57, Michael Niedermayer a écrit : i dont think its a good idea to replace a named variable in a for () statement by a construct so long that it needs a linebreak in the text output [...] I hesitated and this is a very good point, so I replaced by 2 named variables: -

Re: [FFmpeg-devel] [PATCH] FFV1 specification: Reduce redundancy in the description of xxPlane() and xxLine()

Le 03/05/2015 13:55, Michael Niedermayer a écrit : On Sun, May 03, 2015 at 12:31:05PM +0200, Jerome Martinez wrote: - plane_count which is the count of planes thats a bad name for packed formats Good point, but this is not worse than the previous name used ;-). and actually you use

[FFmpeg-devel] [PATCH] ffv1dec: plane_index is 1 in case of version 4 gray+alpha.

Le 02/05/2015 12:51, Michael Niedermayer a écrit : On Sat, May 02, 2015 at 02:41:33AM +0200, Jerome Martinez wrote: shouldn't it be if (fs-transparency) decode_plane(fs, p-data[3] + ps*x + y*p-linesize[3], width, height, p-linesize[3], (f-version = 4 !f-chroma_planes

Re: [FFmpeg-devel] [PATCH] FFV1 specification: Reduce redundancy in the description of xxPlane() and xxLine()

New patch because I misunderstood the definition of plane_count. Now LyX Document is 1 + ( ( chroma_planes || version 4 ) ? 1 : 0 ) + ( alpha_plane ? 1 : 0 ) Le 02/05/2015 01:33, Jerome Martinez a écrit : Some notes: - I discarded the if version = 4 stuff for grayscale because I don't see

Re: [FFmpeg-devel] [PATCH] FFV1 specification: Reduce redundancy in the description of xxPlane() and xxLine()

New patch because I misunderstood the definition of plane_count. Now is 1 + ( ( chroma_planes || version 4 ) ? 1 : 0 ) + ( alpha_plane ? 1 : 0 ) Le 02/05/2015 01:33, Jerome Martinez a écrit : Some notes: - I discarded the if version = 4 stuff for grayscale because I don't see

Re: [FFmpeg-devel] FFV1 specification: plane_count prior to version 4

Le 02/05/2015 01:37, Michael Niedermayer a écrit : plane_count was 2 for gray prior to version 4 [...] Got it. Maybe I missed something else, but looks like decode_plane() is never called with plane_index = 1 if chroma_planes is 0. Was it an implementation bug and actually plane_index = 1 is

Re: [FFmpeg-devel] [PATCH 2/4] FFV1 specification: Add missing { }

Le 02/05/2015 00:21, Michael Niedermayer a écrit : why the extra space ? Because of a guy doing stupid mistakes. (this guy may try to blame Lyx but it is difficult to be believable) New patch attached. From 40a211a344c3f7bcb8bc627bd5edcb4cb8b1c56c Mon Sep 17 00:00:00 2001 From:

Re: [FFmpeg-devel] [PATCH 2/4] FFV1 specification: Add missing { }

Le 02/05/2015 01:05, Michael Niedermayer a écrit : this looks wrong in my lyx, quite wrong, certainly doesnt result in a closing bracket Weird, it is OK on my side and actually a pretty patch. I rebased following your latest commits, attached is a new patch. note, that is when i apply the

[FFmpeg-devel] [PATCH] FFV1 specification: Reduce redundancy in the description of xxPlane() and xxLine()

Some notes: - I discarded the if version = 4 stuff for grayscale because I don't see such limitation in the bitstream and in the source code. I am thinking to add a specific section about decoder limitations (e.g. bits_per_raw_sample accepted range, gray/alpha support...) - I hesitated to

[FFmpeg-devel] [PATCH 1/4] FFV1 specification: Change formatting of pseudo-code

From 9da73eaa1ddf40667dca300ee89430283c1e36ff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= jer...@mediaarea.net Date: Fri, 1 May 2015 10:54:04 +0200 Subject: [PATCH 1/4] Change formatting of pseudo-code. In order to have the same formatting everywhere. Formatting is

[FFmpeg-devel] [PATCH 0/4] FFV1 specification: Add formating and conventions

The purpose of this set of patches is to have a coherent document with explicit meaning of used operators. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/4] FFV1 specification: Add missing { }

___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/4] FFV1 specification: Add conventions

___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

  1   2   >