Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental
On Thu, Feb 01, 2018 at 01:51:17PM +0100, Jerome Martinez wrote: > 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 line during encoding. > > Sorry, I missed the GBRP16 part. > I tested the encoding through GBRP16 pix_fmt (instead of RGB48 pix_fmt), and > it works fine too. > Additional patch for removing the need of " -strict experimental" for GBRP16 > too. > ffv1enc.c |4 > 1 file changed, 4 deletions(-) > 1af1e3f7fb3a0e866285623d6f5f1e65bfcebba0 > 0001-avcodec-ffv1enc-mark-RGB48-support-as-non-experiment.patch > From 511e036499f716b14fed7ec07d2d8ccf18936444 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= > Date: Thu, 1 Feb 2018 13:15:54 +0100 > Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental > > Remove the 2nd mark, 1st mark was removed in 58e16a4 > --- > libavcodec/ffv1enc.c | 4 > 1 file changed, 4 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 line during encoding.
Sorry, I missed the GBRP16 part.
I tested the encoding through GBRP16 pix_fmt (instead of RGB48 pix_fmt),
and it works fine too.
Additional patch for removing the need of " -strict experimental" for
GBRP16 too.
From 511e036499f716b14fed7ec07d2d8ccf18936444 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Thu, 1 Feb 2018 13:15:54 +0100
Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental
Remove the 2nd mark, 1st mark was removed in 58e16a4
---
libavcodec/ffv1enc.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index c0c1558ffe..0778f84c9b 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -657,10 +657,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
s->chroma_planes = 1;
if (s->bits_per_raw_sample >= 16) {
s->use32bit = 1;
-if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
-av_log(avctx, AV_LOG_ERROR, "16bit RGB is experimental and
under development, only use it for experiments\n");
-return AVERROR_INVALIDDATA;
-}
}
s->version = FFMAX(s->version, 1);
break;
--
2.13.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental
On Fri, Jan 05, 2018 at 10:26:42PM +0100, Jerome Martinez wrote: > 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 > >>Subject: [PATCH] FFV1: make RGB48 support as non-experimental > > > >make => mark > > I reused a commit text from history, both words words were in it. > Anyway, attached is the updated .patch with the suggested subject line. > > > > >BTW: common subject line format would be something like "avcodec/ffv1enc: > >mark RGB48 support as non-experimental" > > 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-8?q?J=C3=A9r=C3=B4me=20Martinez?= > Date: Fri, 5 Jan 2018 11:09:01 +0100 > Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental > > Resulting bitstream was tested with a conformance checker > using the last draft of FFV1 specifications. > --- > libavcodec/ffv1enc.c | 4 > 1 file changed, 4 deletions(-) will apply this with a somewhat expanded commit message thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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-support-as-non-experiment.patch From 303f63fb7e6172fdb7de66da1f8a4006b79a535f 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 Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental Resulting bitstream was tested with a conformance checker using the last draft of FFV1 specifications. But has the way this is stored been optimized ? Once its marked as non exerimental all future decoders must support the exact way. Although this is considered experimental in the encoder, the implementation adheres to the description in the specification. The bitstream specification does not provide a bitdepth limit so with the current draft of the specification, another FFV1 encoder could already encode 16-bit (and more) content. The work on the specification has been careful to not break compatibility with former drafts and at this point the FFV1 bitstream specification for versions 0, 1, and 3 should be considered already non-experimental for all bit depths. All current decoders should already support the exact way it is currently specified. To make a change in the specification at this point would have cascading consequences as we’d have to retract the part of the specification which states that micro_version 4 of version 3 is the first stable variant. Worse, it is impossible to indicate a bitstream change in FFV1 version 1, which permits RGB 16-bit content too, so it would be difficult for a decoder to detect a bitstream not conforming to the bitstream created by the current version of FFmpeg encoder. Are you not making this look alot more complex than it is ? Or maybe we talk about slightly different things here with the next version we can introduce any method of storing 16bit or 9-15 bit and we certainly do not support in the implementation all possible bit depths From what i remember I had always wanted to improve the way that more than 8bit is handled, not just 16. Although 16 is a bit special Consider this: If we improve get_context() in the next version for >8bit we still have to support 9-15 bit with the old definition if we now declare 16bit non experimental then we also must support that with an old get_context() in the decoder. the 16bit path is seperate from the lower bit depth. So this is an Additional codepath that we have to carry in the future isnt it smarter now that if we want to improve get_context() that we dont now extend what can be generated with the current get_context ? or are such current get_context() style files already widespread ? if so then its probably best to accept it and keep supporting it I am lost. Looks like we talk about 2 different subjects: FFV1 bitstream specifications and FFmpeg implementation. Let separate subjects: FFV1 bitstream specifications: Since at least 2012 [1] get_context (in the bitstream) is defined and flagged as stable for **all** bit depths for versions 0, 1, 3. It is still the case today [2]. There was a consensus on discussing about FFV1 bitstream on CELLAR mailing list There was a consensus for not changing the bitstream for version 0, 1, 3 so we can standardize it ASAP without breaking current implementations (reason we document bugs in the main encoder, but the idea is not to accept more changes) If the FFV1 bitstream for version 0, 1, or 3 must be changed in current stable version, it would be a major break in the consensus and it should be discussed on CELLAR list (in copy as they are concerned), but I doubt the consensus would be for breaking the bitstream compatibility as the discussion from day 0 on CELLAR is to document current bitstream without changing it for versions 0, 1, 3. The fact that there was no (publicly available) RGB48 encoder in the wild is not an excuse for breaking the compatibility with current draft of specifications. Same if someone decides to do an encoder for e.g. RGB3000. It is possible to change the bitstream with version 4 (experimental version), and it is a good place for changing get_context for 16-bit content (whatever is the color space, BTW). FFmpeg implementation: FFV1 YCbCr 16-bit is already flagged as non experimental, so there is already some non experimental 16-bit support in FFmpeg FFV1 encoder. 16-bit is not new and for RGB48 the actual encoding after RGB to YCbCr transformation is just 1 bit more (17-bit). FFmpeg experimental flag is for the status of the encoder, not for the status of the bitstream (the bitstream for versions 0, 1, 3 is already considered stable for RGB48 and others) FFV1 RGB48 support in FFmpeg is conform to FFV1 bitstream specifications. Optimizing FFmpeg for better compression of FFV1 RG
Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental
On Sat, Jan 06, 2018 at 05:01:42PM +0100, Reto Kromer wrote: > Michael Niedermayer wrote: > > >>Resulting bitstream was tested with a conformance checker > >>using the last draft of FFV1 specifications. > > > >But has the way this is stored been optimized ? > > > >Once its marked as non exerimental all future decoders must > >support the exact way. It can no longer then be changed, so we > >need to be really sure the design is optimal first. > >Are we ? > >who has checked alternatives? what where the reasons why the > >alternatives were not choosen? > >for example consider get_context(), what it does with >8bit may > >or may not be optimal > >iam interrested to work on that in fact, ive a quite long and > >growing list of other volunteer jobs to do though ... > > Hmm... I am a little surprised about this, as I paid EUR 2000 in > 2016 for implementing the RGB48 support in FFV1. And I didn't it > just for having less money in my pocket, but explicitly for the > benefit of the community. > > As I already said in other contexts, the experimental flag is > actually avoiding a larger use of FFV1 in the archival > community. As long as this flag is present, many film archives > simply cannot adopt FFV1 for film preservation. That's my point. > Therefore I support making the RGB48 support non-experimental. Yes, the flag is annoying. I kind of want to make teh design perfect before removing the experimental check but maybe thats not reasonable i dont know [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental
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-support-as-non-experiment.patch > >> From 303f63fb7e6172fdb7de66da1f8a4006b79a535f 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 > >>Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental > >> > >>Resulting bitstream was tested with a conformance checker > >>using the last draft of FFV1 specifications. > >But has the way this is stored been optimized ? > > > >Once its marked as non exerimental all future decoders must support the exact > >way. > > Although this is considered experimental in the encoder, the implementation > adheres to the description in the specification. The bitstream specification > does not provide a bitdepth limit so with the current draft of the > specification, another FFV1 encoder could already encode 16-bit (and more) > content. The work on the specification has been careful to not break > compatibility with former drafts and at this point the FFV1 bitstream > specification for versions 0, 1, and 3 should be considered already > non-experimental for all bit depths. All current decoders should already > support the exact way it is currently specified. > > To make a change in the specification at this point would have cascading > consequences as we’d have to retract the part of the specification which > states that micro_version 4 of version 3 is the first stable variant. Worse, > it is impossible to indicate a bitstream change in FFV1 version 1, which > permits RGB 16-bit content too, so it would be difficult for a decoder to > detect a bitstream not conforming to the bitstream created by the current > version of FFmpeg encoder. Are you not making this look alot more complex than it is ? Or maybe we talk about slightly different things here with the next version we can introduce any method of storing 16bit or 9-15 bit and we certainly do not support in the implementation all possible bit depths From what i remember I had always wanted to improve the way that more than 8bit is handled, not just 16. Although 16 is a bit special Consider this: If we improve get_context() in the next version for >8bit we still have to support 9-15 bit with the old definition if we now declare 16bit non experimental then we also must support that with an old get_context() in the decoder. the 16bit path is seperate from the lower bit depth. So this is an Additional codepath that we have to carry in the future isnt it smarter now that if we want to improve get_context() that we dont now extend what can be generated with the current get_context ? or are such current get_context() style files already widespread ? if so then its probably best to accept it and keep supporting it > > > > > It can no longer then be changed, so we need to be really sure the design > >is optimal first. > >Are we ? > >who has checked alternatives? what where the reasons why the alternatives > >were not choosen? > >for example consider get_context(), what it does with >8bit may or may not > >be optimal > >iam interrested to work on that in fact, ive a quite long and growing list > >of other volunteer jobs to do though ... > > bitdepths >8bit have been well-used for years since many of them have long > been marked as non-experimental (for instance 10bit is frequently used with > lossless encoding of broadcast media and video from analog tape sources). In > my opinion get_context() is specified for all bitdpeths and non-experimental > for FFV1 versions 0, 1, and 3 by the specification work and it should not be > changed in these versions. what get_context does was designed for 8bit, it should still be good enough for 10bit and maybe 12 but as the bit depth gets larger i suspect get_context becomes less optimal and there is more potential to improve compression by changing it. > > For the encoder there may still be an opportunity to optimize while > continuing to conform to the FFV1 versions 0, 1, and 3 bitstream > specification, even if the encoder marks RGB48 as non-experimental. > Additionally FFV1 version 4 or later could consider further optimization > requesting a change in the FFV1 bitstream as version 4 has no stable > micro_version and the entire version is in an experimental status. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http:
Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental
Michael Niedermayer wrote: >>Resulting bitstream was tested with a conformance checker >>using the last draft of FFV1 specifications. > >But has the way this is stored been optimized ? > >Once its marked as non exerimental all future decoders must >support the exact way. It can no longer then be changed, so we >need to be really sure the design is optimal first. >Are we ? >who has checked alternatives? what where the reasons why the >alternatives were not choosen? >for example consider get_context(), what it does with >8bit may >or may not be optimal >iam interrested to work on that in fact, ive a quite long and >growing list of other volunteer jobs to do though ... Hmm... I am a little surprised about this, as I paid EUR 2000 in 2016 for implementing the RGB48 support in FFV1. And I didn't it just for having less money in my pocket, but explicitly for the benefit of the community. As I already said in other contexts, the experimental flag is actually avoiding a larger use of FFV1 in the archival community. As long as this flag is present, many film archives simply cannot adopt FFV1 for film preservation. That's my point. Therefore I support making the RGB48 support non-experimental. For the wider context regarding an important category of FFmpeg users, I wrote this – and I apologise for mentioning myself: https://retokromer.ch/publications/JFP_96.html Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Fri, 5 Jan 2018 11:09:01 +0100 Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental Resulting bitstream was tested with a conformance checker using the last draft of FFV1 specifications. But has the way this is stored been optimized ? Once its marked as non exerimental all future decoders must support the exact way. Although this is considered experimental in the encoder, the implementation adheres to the description in the specification. The bitstream specification does not provide a bitdepth limit so with the current draft of the specification, another FFV1 encoder could already encode 16-bit (and more) content. The work on the specification has been careful to not break compatibility with former drafts and at this point the FFV1 bitstream specification for versions 0, 1, and 3 should be considered already non-experimental for all bit depths. All current decoders should already support the exact way it is currently specified. To make a change in the specification at this point would have cascading consequences as we’d have to retract the part of the specification which states that micro_version 4 of version 3 is the first stable variant. Worse, it is impossible to indicate a bitstream change in FFV1 version 1, which permits RGB 16-bit content too, so it would be difficult for a decoder to detect a bitstream not conforming to the bitstream created by the current version of FFmpeg encoder. It can no longer then be changed, so we need to be really sure the design is optimal first. Are we ? who has checked alternatives? what where the reasons why the alternatives were not choosen? for example consider get_context(), what it does with >8bit may or may not be optimal iam interrested to work on that in fact, ive a quite long and growing list of other volunteer jobs to do though ... bitdepths >8bit have been well-used for years since many of them have long been marked as non-experimental (for instance 10bit is frequently used with lossless encoding of broadcast media and video from analog tape sources). In my opinion get_context() is specified for all bitdpeths and non-experimental for FFV1 versions 0, 1, and 3 by the specification work and it should not be changed in these versions. For the encoder there may still be an opportunity to optimize while continuing to conform to the FFV1 versions 0, 1, and 3 bitstream specification, even if the encoder marks RGB48 as non-experimental. Additionally FFV1 version 4 or later could consider further optimization requesting a change in the FFV1 bitstream as version 4 has no stable micro_version and the entire version is in an experimental status. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental
On Fri, Jan 05, 2018 at 10:26:42PM +0100, Jerome Martinez wrote: > 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 > >>Subject: [PATCH] FFV1: make RGB48 support as non-experimental > > > >make => mark > > I reused a commit text from history, both words words were in it. > Anyway, attached is the updated .patch with the suggested subject line. > > > > >BTW: common subject line format would be something like "avcodec/ffv1enc: > >mark RGB48 support as non-experimental" > > 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-8?q?J=C3=A9r=C3=B4me=20Martinez?= > Date: Fri, 5 Jan 2018 11:09:01 +0100 > Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental > > Resulting bitstream was tested with a conformance checker > using the last draft of FFV1 specifications. But has the way this is stored been optimized ? Once its marked as non exerimental all future decoders must support the exact way. It can no longer then be changed, so we need to be really sure the design is optimal first. Are we ? who has checked alternatives? what where the reasons why the alternatives were not choosen? for example consider get_context(), what it does with >8bit may or may not be optimal iam interrested to work on that in fact, ive a quite long and growing list of other volunteer jobs to do though ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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?=
Date: Fri, 5 Jan 2018 11:09:01 +0100
Subject: [PATCH] FFV1: make RGB48 support as non-experimental
make => mark
I reused a commit text from history, both words words were in it.
Anyway, attached is the updated .patch with the suggested subject line.
BTW: common subject line format would be something like
"avcodec/ffv1enc: mark RGB48 support as non-experimental"
From 303f63fb7e6172fdb7de66da1f8a4006b79a535f 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
Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental
Resulting bitstream was tested with a conformance checker
using the last draft of FFV1 specifications.
---
libavcodec/ffv1enc.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 09df4c0c57..c0c1558ffe 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -630,10 +630,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
s->bits_per_raw_sample = 16;
s->use32bit = 1;
s->version = FFMAX(s->version, 1);
-if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
-av_log(avctx, AV_LOG_ERROR, "16bit RGB is experimental and under
development, only use it for experiments\n");
-return AVERROR_INVALIDDATA;
-}
break;
case AV_PIX_FMT_0RGB32:
s->colorspace = 1;
--
2.13.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental
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 Subject: [PATCH] FFV1: make RGB48 support as non-experimental make => mark BTW: common subject line format would be something like "avcodec/ffv1enc: mark RGB48 support as non-experimental" Resulting bitstream was tested with a conformance checker using the last draft of FFV1 specifications. --- libavcodec/ffv1enc.c | 4 1 file changed, 4 deletions(-) Otherwise LGTM. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 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
Subject: [PATCH] FFV1: make RGB48 support as non-experimental
Resulting bitstream was tested with a conformance checker
using the last draft of FFV1 specifications.
---
libavcodec/ffv1enc.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 09df4c0c57..c0c1558ffe 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -630,10 +630,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
s->bits_per_raw_sample = 16;
s->use32bit = 1;
s->version = FFMAX(s->version, 1);
-if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
-av_log(avctx, AV_LOG_ERROR, "16bit RGB is experimental and under
development, only use it for experiments\n");
-return AVERROR_INVALIDDATA;
-}
break;
case AV_PIX_FMT_0RGB32:
s->colorspace = 1;
--
2.13.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
