cases like
bad metadata e.g. 16-bit 4-ch (impossible) and 32 kHz 12-bit 4-ch.
12-bit is not yet handled but the patch provides the detection of such
file and a smooth rejection of the file.
Jérôme
From 90211198a936ca7087dbf04e5d636fd9992a8332 Mon Sep 17 00:00:00 2001
From: Jerome Martinez
Dat
Le 17/01/2025 à 21:43, Michael Niedermayer a écrit :
On Fri, Jan 17, 2025 at 12:38:02PM +0100, Jerome Martinez wrote:
[...]
Subject: [PATCH] avformat: add DAT demuxer
breaks fate-cdxl-pal8-small
I guess the probe function is not working as expected
cdxl parser provides a read_probe value of
Sample files are available at https://archive.org/download/datstrue-read/
From 50c78a0ae2049e2dbd65e2c3d28f3d8abea1adfa Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Thu, 12 Sep 2024 20:34:22 +0200
Subject: [PATCH] avformat: add DAT demuxer
---
libavformat/Makefile | 1 +
libavformat
Le 24/11/2024 à 04:41, Lynne via ffmpeg-devel a écrit :
On 11/23/24 23:10, Jerome Martinez wrote:
Le 23/11/2024 à 20:58, Lynne via ffmpeg-devel a écrit :
This allows the encoder to fully saturate all queues the GPU
has, giving a good 10% in certain cases and resolutions.
Using a RTX 4070
Le 23/11/2024 à 20:58, Lynne via ffmpeg-devel a écrit :
This allows the encoder to fully saturate all queues the GPU
has, giving a good 10% in certain cases and resolutions.
Using a RTX 4070:
+50% (!!!) with 2K 10-bit content.
+17% with 4K 16-bit content.
Also the speed with 2K content is now
Le 21/11/2024 à 20:02, Lynne via ffmpeg-devel a écrit :
+if (f->num_h_slices <= 0 && f->num_v_slices <= 0) {
f->num_h_slices = 32;
-if (f->num_v_slices <= 0)
f->num_v_slices = 32;
+} else if (f->num_h_slices) {
+} else if (f->num_h_sli
Le 17/11/2024 à 01:19, Lynne via ffmpeg-devel a écrit :
I'll push the patchset tomorrow if there are no more comments to fix.
As it silently creates bad streams with some pix_fmts, please mandate
-strict -2 for the moment.
___
ffmpeg-devel mailing l
Le 16/10/2024 à 22:53, Michael Niedermayer a écrit :
what are you testing?
the new code is faster than the old code.
There is something not right here, the range coder based implementation
i posted now is 5% faster then the range coder based one i posted earlier today
thats overall speed meassure
Le 16/10/2024 à 21:51, Michael Niedermayer a écrit :
did you try qtable 1 ? strangely it performed better for the file i used
compression wise
Updated with latest code (in practice, no change in previous values):
0,037x 0,471 No patch
0,051x 0,491 bitfield
0,046x 0,489 rangec
Le 16/10/2024 à 15:54, Michael Niedermayer a écrit :
3rd implemantation :)
you might ask why i implement this 4?! times
Heres why: (tests done with 4 rawlsb bits, 16bit per sample input)
I tested on my side also including the speed as the goal is to avoid the
speed cost of the LSB, with 6K con
Le 10/10/2024 à 22:45, Michael Niedermayer a écrit :
This makes a 16bit RGB raw sample 25% faster at a 2% loss of compression with
rawlsb=4
Please test and comment, especially if you are an archivist caring about
compression and speed
Id like to know if this is a direction (that is trading com
Le 10/10/2024 à 22:45, Michael Niedermayer a écrit :
[...]
@@ -1266,7 +1268,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
#define OFFSET(x) offsetof(FFV1Context, x)
#define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
-
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 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
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 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
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 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
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 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
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
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
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
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
16 macroblock 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: [PA
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
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 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 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, 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 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
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
=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
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 ++--
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 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 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/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 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 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
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 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 al
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
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
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 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 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 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 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
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
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
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
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
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
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 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
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
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
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
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 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
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 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: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 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 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
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 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
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 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 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
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 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
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 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 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
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 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
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 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:
-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
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 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,
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 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 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
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 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 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
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 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
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 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 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
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 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
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 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
1 - 100 of 130 matches
Mail list logo
