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:
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
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
indicate
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 pos
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 ent
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 gua
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 +-
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), c
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:
https://github.com/Matroska-Org/matroska-specification/pull/
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 wit
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 ou
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
w
Le 04/10/2016 à 01:36, James Almer a écrit :
This patchsets implements the feature requested on ticket #4347.
I tested the patches and it works as expected: the CRC-32 elements are
in the first position and values are the right ones.
___
ffmpeg-deve
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 I
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).
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
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
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 play these files
What do y
Le 01/03/2017 à 15:51, wm4 a écrit :
On Wed, 1 Mar 2017 15:00:27 +0100
Jerome Martinez 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 files), the default is
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 first,
touching 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
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
requests and there was no ad
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 u
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 cd1bfe68a1a809700f25e593ac21ca3876d2
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?=
Date: Fri, 5 Jan 2018 11:09:01 +0100
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: =?UTF
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
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).
Ag
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 below
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
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
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 RENAME(encode_li
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
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 o
On 09/02/2018 02:19, Carl Eugen Hoyos wrote:
2018-02-08 11:28 GMT+01:00 Jerome Martinez :
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
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
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,
checki
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
_
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 for
On 12/02/2018 22:37, Carl Eugen Hoyos wrote:
2018-02-12 20:47 GMT+01:00 Jerome Martinez :
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
Thank you!
This sample
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 gbrp1
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
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 vi
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 stre
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 m
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 1
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 1
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 m
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 mandelbrot=s=1925x
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 2018 10:49:24 +0100
Su
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 no
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
http://ffmpeg.org/mailman/listinfo/ffmpeg
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?=
Date: Wed, 7 Mar 2018
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 00
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
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,
On 09/03/2018 18:30, Paul B Mahol wrote:
On 3/7/18, Jerome Martinez 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" to the source bitdepth
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 e
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
sion).
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 th
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 one
supporting 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
Da
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
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 configurati
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 ++--
=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
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
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 as it
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 mxf_write_j
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 format
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, only
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 (
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
Le 01/05/2015 13:50, Michael Niedermayer a écrit :
duplicate patch [...]
I forgot to attach the patch. Attached now.
>From 591d517e4aafb981e4f2cb21cfc212134a719d0a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Fri, 1 May 2015 12:02:56 +0200
Subject: [PATCH 3/4] A
Le 01/05/2015 13:50, Michael Niedermayer a écrit :
duplicate patch
I forgot to attach the patch. Attached now.
>From 368ade8ba63419e952da3ec21608ebf17dde2616 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Fri, 1 May 2015 12:05:31 +0200
Subject: [PATCH 4/4] Add RFC
Le 01/05/2015 13:49, Michael Niedermayer a écrit :
On Fri, May 01, 2015 at 12:13:22PM +0200, Jerome Martinez wrote:
-if (keyframe) {
+if ( keyframe ) {
[...]
-if(version<2)
+if( version < 2 )
that doesnt look consistent to me
Fixed (I missed this one and several other &quo
Le 01/05/2015 14:07, Michael Niedermayer a écrit :
-quant_tables[i][j][128] =-quant_tables[i][j][127]
+quant_tables[i][j][128] = -quant_tables[i][j][127]
unrelated
Definitely. I apologize for such mistake (should be in PATCH 1/4, it is
now).
New patch attached.
>From 7fc4e973a2fede34b8cc3ca
In FFV1 specification, I read:
> plane_count prior to version 4: without transparency: 2 else 3.
> version 4 and later: gray: 1, gray+alpha or color:2, color+alpha:3
but in both headers (FrameHeader01 or GlobalHeader), I see chroma_planes
flag, it looks like all versions of FFV1 bitstream are s
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: =?UTF-8?q?J=C3
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 pat
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 d
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
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
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 n
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-&g
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:
- plane_co
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
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, includ
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 direct
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
https
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
From c6f16e561d40972e058f4e163ff753bce8fc8acc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Mon, 18 May 2015 20:59:09 +0200
Subject: [PATCH] Merge of FrameHeader01() and GlobalHeader()
FrameHeader01() and GlobalHeader() have a lot of common fields
and having a com
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
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 initial_state
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
Le 29/07/2015 22:41, Hendrik Leppkes a écrit :
On Wed, Jul 29, 2015 at 8:15 PM, Sasi Inguva wrote:
@Reimar:
True about the stream duration being wrong if stream timestamp does not
start at 0 . I just duplicated the logic to compute the total duration. In
which case, the total duration as it is
Quantization Tables syntax was not defined.
Corresponding HTML export:
https://mediaarea.net/temp/ffv1-patched-Quantization-tables-syntax.html#toc-Subsection-4.4
From 7d58498adbc04aeabc5497df0270c6ebd1cfac12 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Wed, 29 A
Slice Header bitstream syntax is moved from the Slice subsection to its
own subsection for more clarity and is expanded.
Corresponding HTML export:
https://mediaarea.net/temp/ffv1-patched-SliceHeader.html#toc-Subsection-4.2
___
ffmpeg-devel mailing lis
>From d7a6ca009e1bc36402d8c73cb7c35185207f6f65 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Thu, 30 Apr 2015 12:59:06 +0200
Subject: [PATCH 1/4] Slice Header subsection
Slice Header syntax is moved from Slice section to its own section
---
ffv1.lyx | 969 +++
>From e700d99b0be2e758a8ae198affcc8c7c3bdc9473 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Thu, 30 Apr 2015 13:04:39 +0200
Subject: [PATCH 2/4] Slice Header specific semantics moved
>From Header version 3 section to Slice Header section
---
ffv1.lyx | 350 +
1 - 100 of 137 matches
Mail list logo
