Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
August 13, 2021 9:30 PM, "Soft Works" wrote: >> -Original Message- >> From: ffmpeg-devel On Behalf Of Lynne >> Sent: Saturday, 14 August 2021 03:08 >> To: FFmpeg development discussions and patches >> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with >> GitHub >> >> The situation is far from perfect. In my opinion, mirroring will just >> result in such an incredible amount of noise on the ML, the ML >> will turn useless anyway, and due to needing to maintain both, >> one will fall out of favour with developers and will break, while >> limiting the integration for the other. > > I'm don't think it would create much noise, please see my reply to > Michael from 1.5h ago. > > There's no need to maintain both, because what happens on GitHub is > automated and the ML remains the core instrument. > > Should it turn out over time that activity would converge away > from the ML, then this would be a natural and democratic evolvement. > Then, it would be time to reconsider the organization, obviously. > >> I'd rather move to either a self-hosted Gitea or Gogs instance, >> or failing that, Github. IMO Gitea is pretty good and fast. As bad >> as that could be, it'll be better than what we have now or could have >> with Gitlab. > > These kinds of proposals have been talked down too often, that's > why I'm suggesting something with a more realistic chance for acceptance > and that won't hurt or affect anybody in his work if he doesn't want. > > Also, the stakes are much lower than with a full migration. > If it wouldn't work out well, it can be abandoned easily, while a > migration is usually a way of no return. Agreed. I mean if anything goes wrong, we just switch it off. There's nothing wrong with trying new things. Trying new things is how ffmpeg, nihav, and all great new software comes into existence. People need to be able to challenge things when they don't make sense in order to be competitive. By the people against softworkz appeal's logic they should never submit a patch to ffmpeg that includes something new or improved, since then there is a very small chance the commit isn't good and has to be reverted. > > softworkz > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Fwd: Re: Subject: [PATCH] Cleanup code in truemotion1 decoder
Mike, i was told you can push this?
August 11, 2021 9:04 AM, ffmpegandmahanstreamer@e.email wrote:
> ping
>
> August 1, 2021 12:22 PM, ffmpegandmahanstreamer@e.email wrote:
>
>> Per Andreas Rheinhardt request i'm splitting the working patches in two.
>> ---
>> This cleans up the code in the decode24bit and decode16bit functions by
>> putting it in way that
>> expresses the true intent while making it easier to read.
>> libavcodec/truemotion1.c | 36
>> 1 file changed, 12 insertions(+), 24 deletions(-)
>>
>> diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
>> index 32d8fb4005..50c90e732d 100644
>> --- a/libavcodec/truemotion1.c
>> +++ b/libavcodec/truemotion1.c
>> @@ -655,25 +655,19 @@ static void
>> truemotion1_decode_16bit(TrueMotion1Context *s)
>> while (pixels_left > 0) {
>>
>> if (keyframe || ((mb_change_byte & mb_change_byte_mask) == 0)) {
>> -
>> +
>> switch (y & 3) {
>> case 0:
>> /* if macroblock width is 2, apply C-Y-C-Y; else
>> * apply C-Y-Y */
>> + APPLY_C_PREDICTOR();
>> + APPLY_Y_PREDICTOR();
>> + OUTPUT_PIXEL_PAIR();
>> if (s->block_width == 2) {
>> APPLY_C_PREDICTOR();
>> - APPLY_Y_PREDICTOR();
>> - OUTPUT_PIXEL_PAIR();
>> - APPLY_C_PREDICTOR();
>> - APPLY_Y_PREDICTOR();
>> - OUTPUT_PIXEL_PAIR();
>> - } else {
>> - APPLY_C_PREDICTOR();
>> - APPLY_Y_PREDICTOR();
>> - OUTPUT_PIXEL_PAIR();
>> - APPLY_Y_PREDICTOR();
>> - OUTPUT_PIXEL_PAIR();
>> }
>> + APPLY_Y_PREDICTOR();
>> + OUTPUT_PIXEL_PAIR();
>> break;
>>
>> case 1:
>> @@ -781,25 +775,19 @@ static void
>> truemotion1_decode_24bit(TrueMotion1Context *s)
>> while (pixels_left > 0) {
>>
>> if (keyframe || ((mb_change_byte & mb_change_byte_mask) == 0)) {
>> -
>> +
>> switch (y & 3) {
>> case 0:
>> /* if macroblock width is 2, apply C-Y-C-Y; else
>> * apply C-Y-Y */
>> + APPLY_C_PREDICTOR_24();
>> + APPLY_Y_PREDICTOR_24();
>> + OUTPUT_PIXEL_PAIR();
>> if (s->block_width == 2) {
>> APPLY_C_PREDICTOR_24();
>> - APPLY_Y_PREDICTOR_24();
>> - OUTPUT_PIXEL_PAIR();
>> - APPLY_C_PREDICTOR_24();
>> - APPLY_Y_PREDICTOR_24();
>> - OUTPUT_PIXEL_PAIR();
>> - } else {
>> - APPLY_C_PREDICTOR_24();
>> - APPLY_Y_PREDICTOR_24();
>> - OUTPUT_PIXEL_PAIR();
>> - APPLY_Y_PREDICTOR_24();
>> - OUTPUT_PIXEL_PAIR();
>> }
>> + APPLY_Y_PREDICTOR_24();
>> + OUTPUT_PIXEL_PAIR();
>> break;
>>
>> case 1:
>> --
>> 2.24.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libaomenc: use ctx->usage to get default cfg
August 13, 2021 10:11 PM, "James Zern" wrote:
> this prevents some mismatches in config values for realtime and all
> intra modes, avoiding failures like:
>
> [libaom-av1 @ ...] Failed to initialize encoder: Invalid parameter
> [libaom-av1 @ ...] Additional information: g_lag_in_frames out of
> range [..0]
> ---
> libavcodec/libaomenc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 9c0317f3b2..800fda0591 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -599,7 +599,7 @@ static av_cold int aom_init(AVCodecContext *avctx,
> av_log(avctx, AV_LOG_INFO, "%s\n", aom_codec_version_str());
> av_log(avctx, AV_LOG_VERBOSE, "%s\n", aom_codec_build_config());
>
> - if ((res = aom_codec_enc_config_default(iface, &enccfg, 0)) !=
> AOM_CODEC_OK) {
> + if ((res = aom_codec_enc_config_default(iface, &enccfg, ctx->usage)) !=
> AOM_CODEC_OK) {
> av_log(avctx, AV_LOG_ERROR, "Failed to get config: %s\n",
> aom_codec_err_to_string(res));
> return AVERROR(EINVAL);
> @@ -623,8 +623,6 @@ static av_cold int aom_init(AVCodecContext *avctx,
> enccfg.g_threads =
> FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), 64);
>
> - enccfg.g_usage = ctx->usage;
> -
> if (ctx->lag_in_frames >= 0)
> enccfg.g_lag_in_frames = ctx->lag_in_frames;
>
LGTM, first email appears not to have sent.
> --
> 2.33.0.rc1.237.g0d66db33f3-goog
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libaomenc: use ctx->usage to get default cfg
August 13, 2021 10:11 PM, "James Zern" wrote:
> this prevents some mismatches in config values for realtime and all
> intra modes, avoiding failures like:
>
> [libaom-av1 @ ...] Failed to initialize encoder: Invalid parameter
> [libaom-av1 @ ...] Additional information: g_lag_in_frames out of
> range [..0]
> ---
> libavcodec/libaomenc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 9c0317f3b2..800fda0591 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -599,7 +599,7 @@ static av_cold int aom_init(AVCodecContext *avctx,
> av_log(avctx, AV_LOG_INFO, "%s\n", aom_codec_version_str());
> av_log(avctx, AV_LOG_VERBOSE, "%s\n", aom_codec_build_config());
>
> - if ((res = aom_codec_enc_config_default(iface, &enccfg, 0)) !=
> AOM_CODEC_OK) {
> + if ((res = aom_codec_enc_config_default(iface, &enccfg, ctx->usage)) !=
> AOM_CODEC_OK) {
> av_log(avctx, AV_LOG_ERROR, "Failed to get config: %s\n",
> aom_codec_err_to_string(res));
> return AVERROR(EINVAL);
> @@ -623,8 +623,6 @@ static av_cold int aom_init(AVCodecContext *avctx,
> enccfg.g_threads =
> FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), 64);
>
> - enccfg.g_usage = ctx->usage;
> -
> if (ctx->lag_in_frames >= 0)
> enccfg.g_lag_in_frames = ctx->lag_in_frames;
>
LGTM
> --
> 2.33.0.rc1.237.g0d66db33f3-goog
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
August 13, 2021 8:42 PM, "Ronald S. Bultje" wrote: > Hi, > > On Thu, Aug 12, 2021 at 4:51 AM Nicolas George wrote: > >> Paul Buxton (12021-08-12): >> From the point of view of someone who is currently developing a filter >> for >> ffmpeg and will be submitting a patch to the list for the first time, I >> think this is a great idea.Whilst following simple instructions to >> prepare >> and submit a patch should't be outside the ability of anyone who is >> capable >> of contributing. Using something like github allows a more automated >> workflow that can make the process smoother and even make lives easier >> for >> the maintainers as it is possible for the automations to catch issues >> before they get sent on to you. >> >> Have you wondered why these periodical threads "we/you should make >> FFmpeg more attractive" usually end up a discussion between disgruntled >> newbies congratulating each other for their great ideas, with only the >> occasional bored experienced developer stepping in? > > Experienced dev speaking here: I absolutely 100% disagree with this > statement. I would be much happier to actively contribute to FFmpeg if it > used gitlab/hub. I find this mailinglist environment beyond horrendous. I > can't understand why anyone would be OK with our current approach. I only > grudgingly use it when I need to because I'm assuming I'm the minority and > I'm willing to accept the majority consensus, but not because I support it > or think it's a good idea. This reminds me: dav1d, gstreamer, nihav, VLC, x265, rav1e, svt-vp9, etc. and other major multimedia projects are now all on Github/Gitlab/some graphical platform. Its' ffmpeg that's mostly stuck in the past. Everyone's moving on. To be fair, all the projects (except gstreamer and vlc) started off that way, but it shows where the general trend it still. Its not just multimedia, major projects from all over the OSS sphere are moving to these graphical platforms. Even webkit and clang, some of the largest codebases. If people loved mailing lists all those projects would start off with those and still use them. Again, why use a slide rule when there are calculators? Again, there are many platforms that are not full blown github/gitlab like gitea, codeberg, gogs, gitbucket etc. that are very nice. To be honest, i do think the mailing list should be eventually phased out. And i think it will be, as fresh blood comes in from younger kids who have been using the graphical platforms for their entire programming career. It may happen next month, it may happen in one year, it may happen in 5 years. But it will happen. > Ronald > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] avcodec/frame_thread_encoder: Free AVCodecContext structure on error during init
Fixes: MemLeak
Fixes: 8281
Fixes: PoC_option158.jpg
Fixes: CVE-2020-22037
Signed-off-by: Michael Niedermayer
---
libavcodec/frame_thread_encoder.c | 11 +++
libavcodec/frame_thread_encoder.h | 4
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/libavcodec/frame_thread_encoder.c
b/libavcodec/frame_thread_encoder.c
index 9cabfc495f..9bc48c7761 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -126,7 +126,7 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
{
int i=0;
ThreadContext *c;
-
+AVCodecContext *thread_avctx = NULL;
if( !(avctx->thread_type & FF_THREAD_FRAME)
|| !(avctx->codec->capabilities & AV_CODEC_CAP_FRAME_THREADS))
@@ -202,16 +202,17 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
for(i=0; ithread_count ; i++){
int ret;
void *tmpv;
-AVCodecContext *thread_avctx = avcodec_alloc_context3(avctx->codec);
+thread_avctx = avcodec_alloc_context3(avctx->codec);
if(!thread_avctx)
goto fail;
tmpv = thread_avctx->priv_data;
*thread_avctx = *avctx;
+thread_avctx->priv_data = tmpv;
+thread_avctx->internal = NULL;
+thread_avctx->hw_frames_ctx = NULL;
ret = av_opt_copy(thread_avctx, avctx);
if (ret < 0)
goto fail;
-thread_avctx->priv_data = tmpv;
-thread_avctx->internal = NULL;
if (avctx->codec->priv_class) {
int ret = av_opt_copy(thread_avctx->priv_data, avctx->priv_data);
if (ret < 0)
@@ -233,6 +234,8 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
return 0;
fail:
+avcodec_close(thread_avctx);
+av_freep(&thread_avctx);
avctx->thread_count = i;
av_log(avctx, AV_LOG_ERROR, "ff_frame_thread_encoder_init failed\n");
ff_frame_thread_encoder_free(avctx);
diff --git a/libavcodec/frame_thread_encoder.h
b/libavcodec/frame_thread_encoder.h
index 2cdc40a830..201cba2a8f 100644
--- a/libavcodec/frame_thread_encoder.h
+++ b/libavcodec/frame_thread_encoder.h
@@ -23,6 +23,10 @@
#include "avcodec.h"
+/**
+ * Initialize frame thread encoder.
+ * @note hardware encoders are not supported
+ */
int ff_frame_thread_encoder_init(AVCodecContext *avctx);
void ff_frame_thread_encoder_free(AVCodecContext *avctx);
int ff_thread_video_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavu/internal: add FF_FIELD_AT().
Nicolas George (12021-07-24): > Signed-off-by: Nicolas George > --- > libavutil/internal.h | 5 + > 1 file changed, 5 insertions(+) Patch series pushed after more time than expected. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Third opinion anybody?: (was: lavu/internal: add hex to int functions.)
Nicolas George (12021-07-28): > You mean make it public? I am not against it, but I would wait for a > third opinion. If there are no third opinion, I will stick with the conservative stance and keep it private. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 09/10] lavf/file: handle standard file:// URLs.
Marton Balint (12021-07-29): > I meant the absolute path case from Appendix B: > >o The minimal representation of a local file with no authority field > and an absolute path that begins with a slash "/". For example: > > * "file:/path/to/file" It is precisely what I call semi-relative. Do you know of any software that outputs this kind of URL? I know software that produces file:/// URLs with percent encoding, so FFmpeg needs to accept them. But file:/ with percent encoding, I do not, and therefore we have freedom over them. > Well, it will break compatiblity for cases like > file://server/share/100%.txt because now percent encoding will be assumed... > > Maybe as the first step percent encoding should only be used for the 3-slash > form, and the deprecation warning should be printed for the > less-than-3-slash form. (People wanting percent encoding may use the 4-slash > form which is also a thing...) Indeed. Or we can make a smarted detection: check if there are percents and they are followed by hex digits. > And after 2 years of deprecation period the warning should be removed and > percent encoded form can be used for all the cases. > > This way eventually the file: handling can be fully RFC compliant. This is the ultimate goal, of course. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Subject: [PATCH] Cleanup code in truemotion1 decoder
On Sun, Aug 01, 2021 at 04:22:28PM +, ffmpegandmahanstreamer@e.email wrote:
> Per Andreas Rheinhardt request i'm splitting the working patches in two.
And this results in a commit message like this:
Author: ffmpegandmahanstreamer@e.email
Date: Sun Aug 1 16:22:28 2021 +
Subject: [PATCH] Cleanup code in truemotion1 decoder
Per Andreas Rheinhardt request i'm splitting the working patches in two.
Thats not good
"Subject: [PATCH]" doesnt belong in it
"Cleanup code in truemotion1 decoder" is too terse, what is cleaned upo why and
how
Your Author name is also missing, is that intended ?
> ---
> This cleans up the code in the decode24bit and decode16bit functions by
> putting it in way that expresses the true intent while making it easier to
> read.
> libavcodec/truemotion1.c | 36
> 1 file changed, 12 insertions(+), 24 deletions(-)
>
> diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
> index 32d8fb4005..50c90e732d 100644
> --- a/libavcodec/truemotion1.c
> +++ b/libavcodec/truemotion1.c
> @@ -655,25 +655,19 @@ static void truemotion1_decode_16bit(TrueMotion1Context
> *s)
> while (pixels_left > 0) {
>
> if (keyframe || ((mb_change_byte & mb_change_byte_mask) == 0)) {
> -
> +
> switch (y & 3) {
unrelated
trailing whitespace
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Nations do behave wisely once they have exhausted all other alternatives.
-- Abba Eban
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
On Sat, Aug 14, 2021 at 2:42 AM Ronald S. Bultje wrote: > > Hi, > > On Thu, Aug 12, 2021 at 4:51 AM Nicolas George wrote: > > > Paul Buxton (12021-08-12): > > > From the point of view of someone who is currently developing a filter > > for > > > ffmpeg and will be submitting a patch to the list for the first time, I > > > think this is a great idea.Whilst following simple instructions to > > prepare > > > and submit a patch should't be outside the ability of anyone who is > > capable > > > of contributing. Using something like github allows a more automated > > > workflow that can make the process smoother and even make lives easier > > for > > > the maintainers as it is possible for the automations to catch issues > > > before they get sent on to you. > > > > Have you wondered why these periodical threads "we/you should make > > FFmpeg more attractive" usually end up a discussion between disgruntled > > newbies congratulating each other for their great ideas, with only the > > occasional bored experienced developer stepping in? > > > > Experienced dev speaking here: I absolutely 100% disagree with this > statement. I would be much happier to actively contribute to FFmpeg if it > used gitlab/hub. I find this mailinglist environment beyond horrendous. I > can't understand why anyone would be OK with our current approach. I only > grudgingly use it when I need to because I'm assuming I'm the minority and > I'm willing to accept the majority consensus, but not because I support it > or think it's a good idea. > As far as I can remember, the number of people that have spoken out in favor of continued use of the ML solution is the minority, some are just rather vocal about it, and the lack of a "perfect" replacement solution has resulted in none being implemented. Personally, I fully support Ronalds and Lynnes arguments. ML is not fun to interact with, neither for maintaining your own patchset, nor reviewing others. So many sets just get lost if the author doesn't actively ping them regularly, and finding the history of a change is always a quite annoying task I'm in favor of any decently working hosted solution. I have worked with GitHub, Gitlab, and bitbucket, and while none are "perfect" (I'm not sure such a thing will ever exist), they are perfectly usable and IMHO a much better experience all around. I don't know if such a "bridge" is the solution, or if we should go back to the discussion of moving the primary development to one of those platforms. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Third opinion? (was: lavf/avio: remove support for proto, , opt, val, , syntax.)
Nicolas George (12021-07-30): > Andreas Rheinhardt (12021-07-29): > > The latter statement is not true: This is public API; anyone can have > > used it for any purpose. Your 2/5 adds a replacement for using it with > > dvd2concat, but there are other usages, too; e.g. concatenating several > > subfile files (each with its own start and end) with the concat protocol > > won't be possible any more with this patch. > > This feature was never documented, and only incidentally mentioned in > the examples for subfile, so I consider it is more akin to avpriv than > to a public API. > > Do you have practical examples where concatenating subfiles is useful? This feature makes several parts of the code harder to understand, see hls.c and dashdec.c. I have also asked on the users mailing-lists: https://ffmpeg.org/pipermail/ffmpeg-user/2021-August/date.html http://ffmpeg.org/pipermail/libav-user/2021-August/012836.html Unless somebody uses it in the real world, I would favor just getting rid of it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/smc: add flush support
Signed-off-by: Paul B Mahol
---
libavcodec/smc.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/smc.c b/libavcodec/smc.c
index 9cd86216a2..2f43984b99 100644
--- a/libavcodec/smc.c
+++ b/libavcodec/smc.c
@@ -459,6 +459,17 @@ static int smc_decode_frame(AVCodecContext *avctx,
return buf_size;
}
+static void smc_decode_flush(AVCodecContext *avctx)
+{
+SmcContext *s = avctx->priv_data;
+
+memset(s->color_pairs, 0, sizeof(s->color_pairs));
+memset(s->color_quads, 0, sizeof(s->color_quads));
+memset(s->color_octets, 0, sizeof(s->color_octets));
+
+av_frame_unref(s->frame);
+}
+
static av_cold int smc_decode_end(AVCodecContext *avctx)
{
SmcContext *s = avctx->priv_data;
@@ -477,6 +488,7 @@ const AVCodec ff_smc_decoder = {
.init = smc_decode_init,
.close = smc_decode_end,
.decode = smc_decode_frame,
+.flush = smc_decode_flush,
.capabilities = AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec: add SMC encoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/smcenc.c| 557 +
3 files changed, 559 insertions(+)
create mode 100644 libavcodec/smcenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 9a6adb9903..0dc564f5dc 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -621,6 +621,7 @@ OBJS-$(CONFIG_SIMBIOSIS_IMX_DECODER) += imx.o
OBJS-$(CONFIG_SMACKAUD_DECODER)+= smacker.o
OBJS-$(CONFIG_SMACKER_DECODER) += smacker.o
OBJS-$(CONFIG_SMC_DECODER) += smc.o
+OBJS-$(CONFIG_SMC_ENCODER) += smcenc.o
OBJS-$(CONFIG_SNOW_DECODER)+= snowdec.o snow.o snow_dwt.o
OBJS-$(CONFIG_SNOW_ENCODER)+= snowenc.o snow.o snow_dwt.o
\
h263.o h263data.o ituh263enc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 71bc21aa05..c087b91148 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -299,6 +299,7 @@ extern const AVCodec ff_sgirle_decoder;
extern const AVCodec ff_sheervideo_decoder;
extern const AVCodec ff_simbiosis_imx_decoder;
extern const AVCodec ff_smacker_decoder;
+extern const AVCodec ff_smc_encoder;
extern const AVCodec ff_smc_decoder;
extern const AVCodec ff_smvjpeg_decoder;
extern const AVCodec ff_snow_encoder;
diff --git a/libavcodec/smcenc.c b/libavcodec/smcenc.c
new file mode 100644
index 00..4d70c76bad
--- /dev/null
+++ b/libavcodec/smcenc.c
@@ -0,0 +1,557 @@
+/*
+ * QuickTime Graphics (SMC) Video Encoder
+ * Copyright (c) 2021 The FFmpeg project
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file smcenc.c
+ * QT SMC Video Encoder by Paul B. Mahol
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/common.h"
+
+#include "avcodec.h"
+#include "encode.h"
+#include "internal.h"
+#include "bytestream.h"
+
+#define CPAIR 2
+#define CQUAD 4
+#define COCTET 8
+
+#define COLORS_PER_TABLE 256
+
+typedef struct SMCContext {
+AVFrame *prev_frame;// buffer for previous source frame
+PutByteContext pb;
+
+uint8_t mono_value;
+int nb_distinct;
+int next_nb_distinct;
+uint8_t distinct_values[16];
+uint8_t next_distinct_values[16];
+
+uint16_t color_pairs[COLORS_PER_TABLE];
+uint32_t color_quads[COLORS_PER_TABLE];
+uint64_t color_octets[COLORS_PER_TABLE];
+
+int first_frame;// flag set to one when the first frame is being
processed
+// so that comparisons with previous frame data in
not attempted
+int key_frame;
+} SMCContext;
+
+#define ADVANCE_BLOCK(pixel_ptr, row_ptr, nb_blocks) \
+{ \
+for (int block = 0; block < nb_blocks && pixel_ptr && row_ptr; block++) { \
+pixel_ptr += 4; \
+if (pixel_ptr - row_ptr >= width) \
+{ \
+row_ptr += stride * 4; \
+pixel_ptr = row_ptr; \
+} \
+} \
+}
+
+static int smc_cmp_values(const void *a, const void *b)
+{
+const uint8_t *aa = a, *bb = b;
+
+return FFDIFFSIGN(aa[0], bb[0]);
+}
+
+static int count_distinct_items(const uint8_t *block_values,
+uint8_t *distinct_values,
+int size)
+{
+int n = 1;
+
+distinct_values[0] = block_values[0];
+for (int i = 1; i < size; i++) {
+if (block_values[i] != block_values[i-1]) {
+distinct_values[n] = block_values[i];
+n++;
+}
+}
+
+return n;
+}
+
+static void smc_encode_stream(SMCContext *s, const AVFrame *frame)
+{
+PutByteContext *pb = &s->pb;
+const uint8_t *src_pixels = (const uint8_t *)frame->data[0];
+const int stride = frame->linesize[0];
+const uint8_t *prev_pixels = (const uint8_t *)s->prev_frame->data[0];
+const uint8_t *pixel_ptr, *row_ptr;
+const int width = frame->width;
+const uint8_t *old_pixel_ptr = NULL;
+const uint8_t *old_row_ptr = NULL;
+uint8_t block_values[16];
+int block_counter = 0;
+int color_pair_index = 0;
+int color_quad_index = 0;
+int color_octet_index = 0;
+int color_table_index; /* indexes to color pair, quad, or octet tables */
+int total_blocks;
+
+memset
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
Hendrik Leppkes (12021-08-14): > As far as I can remember, the number of people that have spoken out in > favor of continued use of the ML solution is the minority, some are > just rather vocal about it, and the lack of a "perfect" replacement > solution has resulted in none being implemented. Do you think this minority statement holds if you ask people who have just given no opinion on this either way, and if you weight by amount of work performed in reviewing and discussing changes? Because when it comes to the way of organizing our work, the opinion of somebody who is actively pulling the project forward by reviewing patches and discussing solutions almost every day in the past fifteen years should count more than the opinion of twenty people who appeared three months ago to discuss a few of their own patches and will probably disappear in three to six months. I have no qualms saying this, since I have not been very active in the recent months, so by this measure my opinion should count for rather little. But this is important: the choice should not be a matter of democracy, it should be a matter of efficiency. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] lavf/concatdec: support per-file options.
Andreas Rheinhardt (12021-07-28):
> > -if ((ret = avformat_open_input(&cat->avf, file->url, NULL, NULL)) < 0
> > ||
> > +ret = av_dict_copy(&options, file->options, 0);
> > +if (ret < 0)
> > +return ret;
> > +
> > +if ((ret = avformat_open_input(&cat->avf, file->url, NULL, &options))
> > < 0 ||
> > (ret = avformat_find_stream_info(cat->avf, NULL)) < 0) {
> > av_log(avf, AV_LOG_ERROR, "Impossible to open '%s'\n", file->url);
> > avformat_close_input(&cat->avf);
> > return ret;
>
> options would leak here.
Fixed.
> > +if (!(key = av_get_token((const char **)&cursor, SPACE_CHARS))
> > ||
> > +!(val = av_get_token((const char **)&cursor,
> > SPACE_CHARS))) {
> > +av_log(avf, AV_LOG_ERROR, "Line %d: key and val
> > required\n", line);
> > +FAIL(AVERROR_INVALIDDATA);
>
> 1. key might leak here.
>
> 2. The error message and the return code are wrong: av_get_token() only
> fails upon allocation error; it does not fail when *cursor == \0.
Fixed.
> (The code already suffers from this misconception.)
I intend to rewrite the parser entirely at some point.
>
> > +}
> > +ret = av_dict_set(&file->options, key, val,
> > + AV_DICT_DONT_STRDUP_KEY |
> > AV_DICT_DONT_STRDUP_VAL);
> > +if (ret < 0) {
> > +av_freep(&key);
> > +av_freep(&val);
>
> Double free.
Uh? Oh, I had the logic backwards. Fixed.
Will send a new series soon.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
August 14, 2021 12:34 AM, "zhilizhao(赵志立)" wrote: >> On Aug 14, 2021, at 11:27 AM, ffmpegandmahanstreamer@e.email wrote: >> >> August 13, 2021 8:42 PM, "Ronald S. Bultje" wrote: >> >>> Hi, >>> >>> On Thu, Aug 12, 2021 at 4:51 AM Nicolas George wrote: >> >> Paul Buxton (12021-08-12): >> From the point of view of someone who is currently developing a filter >> for >> ffmpeg and will be submitting a patch to the list for the first time, I >> think this is a great idea.Whilst following simple instructions to >> prepare >> and submit a patch should't be outside the ability of anyone who is >> capable >> of contributing. Using something like github allows a more automated >> workflow that can make the process smoother and even make lives easier >> for >> the maintainers as it is possible for the automations to catch issues >> before they get sent on to you. >> >> Have you wondered why these periodical threads "we/you should make >> FFmpeg more attractive" usually end up a discussion between disgruntled >> newbies congratulating each other for their great ideas, with only the >> occasional bored experienced developer stepping in? >>> Experienced dev speaking here: I absolutely 100% disagree with this >>> statement. I would be much happier to actively contribute to FFmpeg if it >>> used gitlab/hub. I find this mailinglist environment beyond horrendous. I >>> can't understand why anyone would be OK with our current approach. I only >>> grudgingly use it when I need to because I'm assuming I'm the minority and >>> I'm willing to accept the majority consensus, but not because I support it >>> or think it's a good idea. >> >> This reminds me: dav1d, gstreamer, nihav, VLC, x265, rav1e, svt-vp9, etc. >> and other major >> multimedia projects are now all on Github/Gitlab/some graphical platform. >> Its' ffmpeg that's mostly >> stuck in the past. Everyone's moving on. To be fair, all the projects >> (except gstreamer and vlc) >> started off that way, but it shows where the general trend it still. > I even forgot to add mpv and OBS to that list. > I’m glad VLC development has transfer from mailing list to self hosted > Gitlab, although it’s not > perfect, e.g., gitlab is slow for large patch set. > > I have spent a lot of time on finding a email service provider for mailing > list based development: You can try the two mail providers i've been/or have used. They all work great. But i assume yours is also good, i'll have to try it. > > - All patches are treated as spam by 163.com, I can't sent a single email > (well, patch doesn’t look > like normal conversation…) > - Email backend developer or client developer don’t know about the use case > of mailing list, they > don’t understand my bug report, or don’t care. > - gmail is blocked by GFW, that’s another story… > > I’ve helped my friends to setup email for sending patch. It’s like DIY shoes > before jogging. DIY is > interesting, but definitely time consuming. Coding is a necessary skill for > contributing, debugging > is a necessary skill for contributing, but vim is not, no matter how I like > it. > Exactly. Different times, different people. > Maybe there are some details which are overlooked on the GitGitGadget > solution, but “easy to > contributing and more contributor will lower the patch quality” is not a good > reason to reject the > solution. > >> Its not just multimedia, major projects from all over the OSS sphere are >> moving to these graphical >> platforms. Even webkit and clang, some of the largest codebases. >> >> If people loved mailing lists all those projects would start off with those >> and still use them. >> >> Again, why use a slide rule when there are calculators? >> >> Again, there are many platforms that are not full blown github/gitlab like >> gitea, codeberg, gogs, >> gitbucket etc. that are very nice. >> >> To be honest, i do think the mailing list should be eventually phased out. >> And i think it will be, >> as fresh blood comes in from younger kids who have been using the graphical >> platforms for their >> entire programming career. It may happen next month, it may happen in one >> year, it may happen in 5 >> years. But it will happen. >> >>> Ronald >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email >
Re: [FFmpeg-devel] [PATCH 2/4] avfilter/avfilter: Add numbers of (in|out)pads directly to AVFilter
Andreas Rheinhardt (12021-08-12):
> Up until now, an AVFilter's lists of input and output AVFilterPads
> were terminated by a sentinel and the only way for the user to get
> the length of these lists was by using avfilter_pad_count(). This
> has two drawbacks: first, sizeof(AVFilterPad) is not negligible
> (i.e. 64B on 64bit systems); second, getting the size involves
> a function call instead of just reading the data.
>
> This commit therefore changes this. The sentinels are removed and new
> fields nb_inputs and nb_outputs are added to AVFilter that contain the
> number of elements of the respective AVFilterPad array.
> Given that AVFilter.(in|out)puts are the only arrays of zero-terminated
> AVFilterPads an API user has access to (AVFilterContext.(in|out)put_pads
> are not zero-terminated and they already have a size field) the argument
> to avfilter_pad_count() is always one of these lists, so it just has to
> find the filter the list belongs to and read said number. This is slower
> than before, but users are expected to switch to AVFilter.nb_(in|out)puts;
> and furthermore, avfilter_pad_count() is probably never called in hot
> loops anyway.
>
> This saves about 49KiB from the binary; notice that these sentinels are
> not in .bss despite being zeroed; in fact, they are in .data.rel.ro
> due to the non-sentinels.
>
> Signed-off-by: Andreas Rheinhardt
I think it is a good change.
We could shave ~3.5k extra by making the fields uint16_t; lavfi is
absolutely not ready to handle filters with thousands of inputs, there
are loops everywhere.
OTOH, I do not like the fact that it requires more boilerplate code.
> @@ -330,6 +329,7 @@ const AVFilter ff_asrc_aevalsrc = {
> .priv_size = sizeof(EvalContext),
> .inputs= NULL,
> .outputs = aevalsrc_outputs,
> +.nb_outputs= FF_ARRAY_ELEMS(aevalsrc_outputs),
> .priv_class= &aevalsrc_class,
> };
A macro would solve that:
#define FILTER_INPUTS(array) \
.inputs = (array),
.nb_inputs = FF_ARRAY_ELEMS(array)
Also, I am rather not for using these fields directly. Keeping them
private and leaving avfilter_pad_count() gives us more freedom,
including the freedom to change the type from uint16_t to unsigned later
without break.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
On Fri, Aug 13, 2021 at 11:53:54PM +, Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Michael Niedermayer > > Sent: Friday, 13 August 2021 20:10 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration > > with GitHub > > > > On Fri, Aug 13, 2021 at 03:14:36PM +, Soft Works wrote: > > [...] > > > > You do not need anybody's permission either to set up a gateway > > that > > > > will re-post GitHub's PR and comments to the mailing-list and > > > > reciprocally > > > > > > I would need permission to github/ffmpeg/ffmpeg in order to set > > > up the automation hooks. > > > > what exactly is needed to be done, what exact permission is needed > > are we talking about adding a link /API key somewhere or > > continues maintaince of some parameters which require specific > > permissions? > > This is implemented via typescript functions running on Azure, > so it will be rather a one time setup, at the side of the GitHub > repository and maintenance can be done at the Azure site. > > BTW, do you own https://dev.azure.com/ffmpeg or has somebody else > registered that one? I dont know who created dev.azure.com/ffmpeg nor do i know how/who to ask i just get a "401 - Uh-oh, you do not have access." on that page > > I could register something like ffmpeg_sync or ffmpeg_ggg otherwise > and transfer ownership to the project later (or upfront). > > > > Also I wouldn't do it as long as there is at least some kind > > > of "let's try it out as an experiment" feedback from here. > > > > I think ultimately none of us knows how it would look/behave before > > its done. So its hard to avoid that it would be an experiment > > Surely true. > > But even when it wouldn’t work well in terms of submitting - the > other direction alone would be a great value IMO: being able to > view patches submitted to the ML mirrored as GitHub PRs. > This allows viewing patches in context of the latest master-HEAD > without needing to fetch latest, download patch and apply patch > locally. > > > > I do not know "GGG", but what happens once a PR is submitted to the > > ML? > > People will write replies on the ML to comment, ask for changes and > > so forth. > > Simlarly on github PRs can receive comments, reviews, approvals and > > so on > > is there some routing of such comments between PR and ML ? > > Yes there is, but currently only from mailing list back as a PR comment > PR comments are not yet sent to the ML. Need to find out the reason > why the aren't doing it or add this functionality. > Essentially, developers are still required to reply on the mailing list. > > But what's nice is that developers can make the requested changes > to their PR source branch, /submit again and GGG will automatically > submit this as v2..vN patchset. > > I think it's best to look an example: > > https://github.com/gitgitgadget/git/pull/1006 > > > another thing needed, if we would allow PRs is that automated fate > > testing > > of such PRs should be implemented. Thats a great way to filter out > > bad PRs beyond just a author list > > Yes absolutely. This can be done just normally as GitHub checks/actions: > > - Conformance of submit message > - Compilation (ideally multiple platforms) > - FATE > - Possibly some code style checking > (for GIT, they have set up 46 checks currently) > > They don't make successful completion of all checks a requirement, > but that's something I would possibly change. Yes, i think it would be nice if basic formating of commit message, builf&fate is required to pass before submission. This simply cuts down on message volume as noone has to manually send a mail asking for these changes. > > > What I'm still thinking about is the part about hooking into ML > e-mail reception. They are using https://public-inbox.org/ > for GIT, but it would need to be hosted somewhere. > Either I'll figure out a different way or I'll self-host it for an > initial phase. I think you should talk with Andriy Gelman, he is maintaining the VM with patchwork thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
On Sat, Aug 14, 2021 at 10:43 AM Nicolas George wrote: > > Hendrik Leppkes (12021-08-14): > > As far as I can remember, the number of people that have spoken out in > > favor of continued use of the ML solution is the minority, some are > > just rather vocal about it, and the lack of a "perfect" replacement > > solution has resulted in none being implemented. > > Do you think this minority statement holds if you ask people who have > just given no opinion on this either way, and if you weight by amount of > work performed in reviewing and discussing changes? > I can only judge based on past discussion, and have no insight into those that have never taken part in it. One more factor to consider in this line of thought however is, as Ronald already stated as well, how many developers might have contributed more, be it in reviews or actual changes, if this process was made easier for them? I don't think this part should be entirely ignored, since multiple seasoned developers have stated such an opinion before. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: store parition score instead of partition pointer in metadata
On Wed, 11 Aug 2021, Marton Balint wrote:
Partition struct may be reallocated, so let's store the score directly in order
to avoid use-after-free.
Also mxf->current_partition might be null when reading some local tags.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
Applied.
Regards,
Marton
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 34cbd2cd77..55f2e5c767 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -108,7 +108,7 @@ typedef struct MXFPartition {
typedef struct MXFMetadataSet {
UID uid;
-MXFPartition *partition;
+uint64_t partition_score;
enum MXFMetadataSetType type;
} MXFMetadataSet;
@@ -831,21 +831,25 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
return 0;
}
-static int partition_score(MXFPartition *p)
+static uint64_t partition_score(MXFPartition *p)
{
+uint64_t score;
+if (!p)
+return 0;
if (p->type == Footer)
-return 5;
-if (p->complete)
-return 4;
-if (p->closed)
-return 3;
-return 1;
+score = 5;
+else if (p->complete)
+score = 4;
+else if (p->closed)
+score = 3;
+else
+score = 1;
+return (score << 60) | ((uint64_t)p->this_partition >> 4);
}
static int mxf_add_metadata_set(MXFContext *mxf, MXFMetadataSet **metadata_set)
{
MXFMetadataSet **tmp;
-MXFPartition *new_p = (*metadata_set)->partition;
enum MXFMetadataSetType type = (*metadata_set)->type;
// Index Table is special because it might be added manually without
@@ -854,10 +858,9 @@ static int mxf_add_metadata_set(MXFContext *mxf,
MXFMetadataSet **metadata_set)
if (type != IndexTableSegment) {
for (int i = 0; i < mxf->metadata_sets_count; i++) {
if (!memcmp((*metadata_set)->uid, mxf->metadata_sets[i]->uid, 16) && type
== mxf->metadata_sets[i]->type) {
-MXFPartition *old_p = mxf->metadata_sets[i]->partition;
-int old_s = partition_score(old_p);
-int new_s = partition_score(new_p);
-if (old_s > new_s || old_s == new_s && old_p->this_partition >
new_p->this_partition) {
+uint64_t old_s = mxf->metadata_sets[i]->partition_score;
+uint64_t new_s = (*metadata_set)->partition_score;
+if (old_s > new_s) {
mxf_free_metadataset(metadata_set, 1);
return 0;
}
@@ -2894,7 +2897,7 @@ static const MXFMetadataReadTableEntry
mxf_metadata_read_table[] = {
static int mxf_metadataset_init(MXFMetadataSet *ctx, enum MXFMetadataSetType
type, MXFPartition *partition)
{
ctx->type = type;
-ctx->partition = partition;
+ctx->partition_score = partition_score(partition);
switch (type){
case MultipleDescriptor:
case Descriptor:
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
Hendrik Leppkes (12021-08-14): > I can only judge based on past discussion, and have no insight into > those that have never taken part in it. > > One more factor to consider in this line of thought however is, as > Ronald already stated as well, how many developers might have > contributed more, be it in reviews or actual changes, if this process > was made easier for them? > I don't think this part should be entirely ignored, since multiple > seasoned developers have stated such an opinion before. I agree. But it is important to remember that before seriously considering any deep change, it would be necessary to actively poll the silent individual-minority-work-majority. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/libsrt: use a larger buffer for find_info_tag
The upper limit of strlen(streamid) is 512. Use a larger buffer for
future proof, for example, deal with percent-encoding.
---
libavformat/libsrt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index e5701625b8..a66c85d3a2 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -513,7 +513,7 @@ static int libsrt_open(URLContext *h, const char *uri, int
flags)
{
SRTContext *s = h->priv_data;
const char * p;
-char buf[256];
+char buf[1024];
int ret = 0;
if (srt_startup() < 0) {
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avcodec/h264_sei: fix H.274 film grain parsing
From: Niklas Haas
The current code reads the wrong number of bits for `fg_model_id`, which
causes all of the values downstream of this to contain corrupt values.
Fixes: corrupt SEI values
Fixes: 4ff73add5dbe6c319d693355be44df2e17a0b8bf
Signed-off-by: Niklas Haas
---
libavcodec/h264_sei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 7797f24650..329c2ea4f2 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -424,7 +424,7 @@ static int
decode_film_grain_characteristics(H264SEIFilmGrainCharacteristics *h,
if (h->present) {
memset(h, 0, sizeof(*h));
-h->model_id = get_bits(gb, 8);
+h->model_id = get_bits(gb, 2);
h->separate_colour_description_present_flag = get_bits1(gb);
if (h->separate_colour_description_present_flag) {
h->bit_depth_luma = get_bits(gb, 3) + 8;
--
2.32.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] avcodec/h264_slice: compute and export film grain seed
From: Niklas Haas
>From SMPTE RDD 5-2006, the grain seed is to be computed from the
following definition of `pic_offset`:
> When decoding H.264 | MPEG-4 AVC bitstreams, pic_offset is defined as
> follows:
> - pic_offset = PicOrderCnt(CurrPic) + (PicOrderCnt_offset << 5)
> where:
> - PicOrderCnt(CurrPic) is the picture order count of the current frame,
> which shall be derived from [the video stream].
>
> - PicOrderCnt_offset is set to idr_pic_id on IDR frames. idr_pic_id
> shall be read from the slice header of [the video stream]. On non-IDR I
> frames, PicOrderCnt_offset is set to 0. A frame shall be classified as I
> frame when all its slices are I slices, which may be optionally
> designated by setting primary_pic_type to 0 in the access delimiter NAL
> unit. Otherwise, PicOrderCnt_offset it not changed. PicOrderCnt_offset is
> updated in decoding order.
To forward this information correctly, we need to make a number of
annoying changes to h264_slice:
- We need to keep track of the `PicOrderCnt_offset`, and update it to
the decoded value of `idr_pic_id` on IDR frames.
- We need to keep track of whether or not a frame contained any non-I
slices, so we can detect the "non-IDR I frame" condition, and reset
`PicOrderCnt_offset` back to 0. This is *not* synonymous with existing
fields such as `pic->f->pict_type` because that is somehow only set
based on the first slice in a frame, so we introduce a new field
`picture_intra_only` which is set to 0 when decoding any non-I slice.
- We need to compute this derived `pic_offset` at the *end* of the
frame, rather than at the beginning (where the SEI is decoded/set),
because it now depends on the types of the slices present in the same
frame.
If there's a less ugly way to accomplish the above, I don't see it.
Suggestions welcome(tm).
Signed-off-by: Niklas Haas
---
libavcodec/h264_picture.c | 13 -
libavcodec/h264_slice.c | 11 ++-
libavcodec/h264dec.h | 7 +++
libavutil/film_grain_params.h | 3 +++
4 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
index ff30166b4d..b79944b794 100644
--- a/libavcodec/h264_picture.c
+++ b/libavcodec/h264_picture.c
@@ -27,6 +27,7 @@
#include "libavutil/avassert.h"
#include "libavutil/imgutils.h"
+#include "libavutil/film_grain_params.h"
#include "internal.h"
#include "cabac.h"
#include "cabac_functions.h"
@@ -212,6 +213,8 @@ void ff_h264_set_erpic(ERPicture *dst, H264Picture *src)
int ff_h264_field_end(H264Context *h, H264SliceContext *sl, int in_setup)
{
AVCodecContext *const avctx = h->avctx;
+H264Picture *cur = h->cur_pic_ptr;
+AVFrameSideData *sd;
int err = 0;
h->mb_y = 0;
@@ -225,6 +228,9 @@ int ff_h264_field_end(H264Context *h, H264SliceContext *sl,
int in_setup)
h->poc.prev_frame_num= h->poc.frame_num;
}
+if (!h->picture_idr && h->picture_intra_only)
+h->poc_offset = 0;
+
if (avctx->hwaccel) {
err = avctx->hwaccel->end_frame(avctx);
if (err < 0)
@@ -232,8 +238,13 @@ int ff_h264_field_end(H264Context *h, H264SliceContext
*sl, int in_setup)
"hardware accelerator failed to decode picture\n");
}
+if ((sd = av_frame_get_side_data(cur->f,
AV_FRAME_DATA_FILM_GRAIN_PARAMS))) {
+AVFilmGrainParams *fgp = (AVFilmGrainParams *) sd->data;
+fgp->seed = cur->poc + (h->poc_offset << 5);
+}
+
if (!in_setup && !h->droppable)
-ff_thread_report_progress(&h->cur_pic_ptr->tf, INT_MAX,
+ff_thread_report_progress(&cur->tf, INT_MAX,
h->picture_structure == PICT_BOTTOM_FIELD);
emms_c();
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 0d7107d455..65d0259a71 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -406,6 +406,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
h->next_output_pic = h1->next_output_pic;
h->next_outputed_poc = h1->next_outputed_poc;
+h->poc_offset= h1->poc_offset;
memcpy(h->mmco, h1->mmco, sizeof(h->mmco));
h->nb_mmco = h1->nb_mmco;
@@ -510,6 +511,7 @@ static int h264_frame_start(H264Context *h)
pic->sei_recovery_frame_cnt = h->sei.recovery_point.recovery_frame_cnt;
pic->f->pict_type = h->slice_ctx[0].slice_type;
+h->picture_intra_only = 1; // set to 0 by h264_slice_init
pic->f->crop_left = h->crop_left;
pic->f->crop_right = h->crop_right;
@@ -1335,6 +1337,7 @@ static int h264_export_frame_props(H264Context *h)
return AVERROR(ENOMEM);
fgp->type = AV_FILM_GRAIN_PARAMS_H274;
+/* fgp->seed is set by ff_h264_field_end */
fgp->codec.h274.model_id = fgc->model_id;
if (fgc->separate_colour_description_present_flag) {
@@ -1543,6 +1546,9 @@ static int h264_field_start(H264Context *h, const
[FFmpeg-devel] [PATCH 3/4] avcodec/h274: add film grain synthesis routine
From: Niklas Haas
This could arguably also be a vf, but I decided to put it here since
decoders are technically required to apply film grain during the output
step, and I would rather want to avoid requiring users insert the
correct film grain synthesis filter on their own.
The code, while in C, is written in a way that unrolls/vectorizes fairly
well under -O3, and is reasonably cache friendly. On my CPU, a single
thread pushes about 400 FPS at 1080p.
Apart from hand-written assembly, one possible avenue of improvement
would be to change the access order to compute the grain row-by-row
rather than in 8x8 blocks. This requires some redundant PRNG calls, but
would make the algorithm more cache-oblivious.
The implementation has been written to the wording of SMPTE RDD 5-2006
as faithfully as I can manage. However, apart from passing a visual
inspection, no guarantee of correctness can be made due to the lack of
any publicly available reference implementation against which to
compare it.
---
libavcodec/Makefile | 1 +
libavcodec/h274.c | 811
libavcodec/h274.h | 52 +++
3 files changed, 864 insertions(+)
create mode 100644 libavcodec/h274.c
create mode 100644 libavcodec/h274.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 9a6adb9903..21739b4064 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -42,6 +42,7 @@ OBJS = ac3_parser.o
\
dirac.o \
dv_profile.o \
encode.o \
+ h274.o \
imgconvert.o \
jni.o\
mathtables.o \
diff --git a/libavcodec/h274.c b/libavcodec/h274.c
new file mode 100644
index 00..0efc00ca1d
--- /dev/null
+++ b/libavcodec/h274.c
@@ -0,0 +1,811 @@
+/*
+ * H.274 film grain synthesis
+ * Copyright (c) 2021 Niklas Haas
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * H.274 film grain synthesis.
+ * @author Niklas Haas
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/imgutils.h"
+
+#include "h274.h"
+
+// The code in this file has a lot of loops that vectorize very well, this is
+// about a 40% speedup for no obvious downside.
+#pragma GCC optimize("tree-vectorize")
+
+static const int8_t Gaussian_LUT[2048+256];
+static const uint32_t Seed_LUT[256];
+static const int8_t R64T[64][64];
+
+static void prng_shift(uint32_t *state)
+{
+// Primitive polynomial x^31 + x^3 + 1 (modulo 2)
+uint32_t x = *state;
+uint8_t feedback = (x >> 2) ^ (x >> 30);
+*state = (x << 1) | (feedback & 1u);
+}
+
+static void init_slice_c(int8_t out[64][64], uint8_t h, uint8_t v,
+ int16_t tmp[64][64])
+{
+static const uint8_t deblock_factors[13] = {
+64, 71, 77, 84, 90, 96, 103, 109, 116, 122, 128, 128, 128
+};
+
+const uint8_t deblock_coeff = deblock_factors[v];
+const uint8_t freq_h = ((h + 3) << 2) - 1;
+const uint8_t freq_v = ((v + 3) << 2) - 1;
+uint32_t seed = Seed_LUT[h + v * 13];
+
+// Initialize with random gaussian values, using the output array as a
+// temporary buffer for these intermediate values.
+//
+// Note: To make the subsequent matrix multiplication cache friendlier, we
+// store each *column* of the starting image in a *row* of `out`
+for (int y = 0; y <= freq_v; y++) {
+for (int x = 0; x <= freq_h; x += 4) {
+uint16_t offset = seed % 2048;
+out[x + 0][y] = Gaussian_LUT[offset + 0];
+out[x + 1][y] = Gaussian_LUT[offset + 1];
+out[x + 2][y] = Gaussian_LUT[offset + 2];
+out[x + 3][y] = Gaussian_LUT[offset + 3];
+prng_shift(&seed);
+}
+}
+
+out[0][0] = 0;
+
+// 64x64 inverse integer transform
+for (int y = 0; y < 64; y++) {
+for (int x = 0; x < 64; x++) {
+int32_t sum
[FFmpeg-devel] [PATCH 4/4] avcodec/h264dec: apply H.274 film grain
From: Niklas Haas
Because we need access to ref frames without film grain applied, we have
to add an extra AVFrame to H264Picture to avoid messing with the
original. This requires some amount of overhead to make the reference
moves work out, but it allows us to benefit from frame multithreading
for film grain application "for free".
Unfortunately, this approach requires twice as much RAM to be constantly
allocated, due to the need for an extra buffer per H264Picture. In
theory, we could get away with freeing up this memory as soon as it's no
longer needed, but trying to call ff_thread_release_buffer() from
output_frame() simply deadlocks the decoder and I haven't figured out
why. Patches welcome(tm)
Tested on all three cases of (no fg), (fg present but exported) and (fg
present and not exported), with and without threading.
---
libavcodec/h264_picture.c | 24 +++-
libavcodec/h264_slice.c | 18 +--
libavcodec/h264dec.c | 48 +++
libavcodec/h264dec.h | 6 +
4 files changed, 83 insertions(+), 13 deletions(-)
diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
index b79944b794..8284d12158 100644
--- a/libavcodec/h264_picture.c
+++ b/libavcodec/h264_picture.c
@@ -44,7 +44,7 @@
void ff_h264_unref_picture(H264Context *h, H264Picture *pic)
{
-int off = offsetof(H264Picture, tf) + sizeof(pic->tf);
+int off = offsetof(H264Picture, tf_grain) + sizeof(pic->tf_grain);
int i;
if (!pic->f || !pic->f->buf[0])
@@ -61,6 +61,9 @@ void ff_h264_unref_picture(H264Context *h, H264Picture *pic)
av_buffer_unref(&pic->ref_index_buf[i]);
}
+if (pic->needs_fg)
+ff_thread_release_buffer(h->avctx, &pic->tf_grain);
+
memset((uint8_t*)pic + off, 0, sizeof(*pic) - off);
}
@@ -109,6 +112,15 @@ int ff_h264_ref_picture(H264Context *h, H264Picture *dst,
H264Picture *src)
if (ret < 0)
goto fail;
+if (src->needs_fg) {
+av_assert0(src->tf_grain.f == src->f_grain);
+dst->tf_grain.f = dst->f_grain;
+ret = ff_thread_ref_frame(&dst->tf_grain, &src->tf_grain);
+if (ret < 0)
+goto fail;
+dst->needs_fg = 1;
+}
+
dst->qscale_table_buf = av_buffer_ref(src->qscale_table_buf);
dst->mb_type_buf = av_buffer_ref(src->mb_type_buf);
dst->pps_buf = av_buffer_ref(src->pps_buf);
@@ -160,6 +172,16 @@ int ff_h264_replace_picture(H264Context *h, H264Picture
*dst, const H264Picture
if (ret < 0)
goto fail;
+if (src->needs_fg) {
+av_assert0(src->tf_grain.f == src->f_grain);
+dst->tf_grain.f = dst->f_grain;
+ff_thread_release_buffer(h->avctx, &dst->tf_grain);
+ret = ff_thread_ref_frame(&dst->tf_grain, &src->tf_grain);
+if (ret < 0)
+goto fail;
+dst->needs_fg = 1;
+}
+
ret = av_buffer_replace(&dst->qscale_table_buf, src->qscale_table_buf);
ret |= av_buffer_replace(&dst->mb_type_buf, src->mb_type_buf);
ret |= av_buffer_replace(&dst->pps_buf, src->pps_buf);
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 65d0259a71..2b85f807df 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -197,6 +197,21 @@ static int alloc_picture(H264Context *h, H264Picture *pic)
if (ret < 0)
goto fail;
+if (h->sei.film_grain_characteristics.present &&
+!(h->avctx->export_side_data & AV_CODEC_EXPORT_DATA_FILM_GRAIN))
+{
+// Extra buffer required for film grain synthesis in the decoder
+pic->tf_grain.f = pic->f_grain;
+pic->f_grain->format = pic->f->format;
+pic->f_grain->width = pic->f->width;
+pic->f_grain->height = pic->f->height;
+ret = ff_thread_get_buffer(h->avctx, &pic->tf_grain, 0);
+if (ret < 0)
+goto fail;
+pic->needs_fg = 1;
+}
+
+
if (h->avctx->hwaccel) {
const AVHWAccel *hwaccel = h->avctx->hwaccel;
av_assert0(!pic->hwaccel_picture_private);
@@ -1329,8 +1344,7 @@ static int h264_export_frame_props(H264Context *h)
}
h->sei.unregistered.nb_buf_ref = 0;
-if (h->sei.film_grain_characteristics.present &&
-(h->avctx->export_side_data & AV_CODEC_EXPORT_DATA_FILM_GRAIN)) {
+if (h->sei.film_grain_characteristics.present) {
H264SEIFilmGrainCharacteristics *fgc =
&h->sei.film_grain_characteristics;
AVFilmGrainParams *fgp = av_film_grain_params_create_side_data(out);
if (!fgp)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 38f8967265..d5878b8a13 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -275,9 +275,22 @@ int ff_h264_slice_context_init(H264Context *h,
H264SliceContext *sl)
return 0;
}
+static int h264_init_pic(H264Picture *pic)
+{
+pic->f = av_frame_alloc();
+if (!pic->f)
+return AVERROR(ENOMEM);
+
+pic->f_grain = av_frame_alloc();
+if (!pic->f
Re: [FFmpeg-devel] Subject: [PATCH] Cleanup code in truemotion1 decoder
ffmpegandmahanstreamer (12021-08-14): > Once again this proves the superioity of the graphical stuff. Start with not top-posting and we may take your opinion on the superiority of stuff seriously. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Subject: [PATCH] Cleanup code in truemotion1 decoder
ffmpegandmahanstreamer (12021-08-14): > I top post only when i want to reply to the message as a whole. The rules of the list are clear: DO NOT TOP-POST > Bottom (literally, like way bottom) posting is worse than top posting, > because then you need to scroll all the way down. Then be extra-respectful of your peers and trim your quote, just like I did. > Hence why top-posting was invented Top-posting was not invented, it originally was just laziness and ignorance by people discovering e-mail without being taught. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] lavfi/sine: switch to activate.
PING ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] lavfi: add nlmeans CUDA filter
On 14.08.2021 07:49, Dylan Fernando wrote: On Sat, Aug 14, 2021 at 9:11 AM Timo Rothenpieler wrote: On 13.08.2021 10:42, Dylan Fernando wrote: Any update on this? Kind Regards, Dylan Also, are you sure that exp() function is correct? The CUDA-Function exp() is defined as "double exp(double x)" and calculates the base e exponential. While __nvvm_ex2_approx_f reads to me like it does so for floats, and for base 2. For which the CUDA equivalent would be "float exp2f(float)". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". I wasn't sure about the exp() function. Is there a function like __nvvm_exp_approx_d? I can't seem to find a function for this. Which specific exp function do you actually require? There's a bunch of different ones, depending on precision and the base. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
On Fri, 13. Aug 23:53, Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Michael Niedermayer > > Sent: Friday, 13 August 2021 20:10 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration > > with GitHub > > > > On Fri, Aug 13, 2021 at 03:14:36PM +, Soft Works wrote: > > [...] > > > > You do not need anybody's permission either to set up a gateway > > that > > > > will re-post GitHub's PR and comments to the mailing-list and > > > > reciprocally > > > > > > I would need permission to github/ffmpeg/ffmpeg in order to set > > > up the automation hooks. > > > > what exactly is needed to be done, what exact permission is needed > > are we talking about adding a link /API key somewhere or > > continues maintaince of some parameters which require specific > > permissions? > > This is implemented via typescript functions running on Azure, > so it will be rather a one time setup, at the side of the GitHub > repository and maintenance can be done at the Azure site. > > BTW, do you own https://dev.azure.com/ffmpeg or has somebody else > registered that one? > > I could register something like ffmpeg_sync or ffmpeg_ggg otherwise > and transfer ownership to the project later (or upfront). > > > > Also I wouldn't do it as long as there is at least some kind > > > of "let's try it out as an experiment" feedback from here. > > > > I think ultimately none of us knows how it would look/behave before > > its done. So its hard to avoid that it would be an experiment > > Surely true. > > But even when it wouldn’t work well in terms of submitting - the > other direction alone would be a great value IMO: being able to > view patches submitted to the ML mirrored as GitHub PRs. > This allows viewing patches in context of the latest master-HEAD > without needing to fetch latest, download patch and apply patch > locally. > > > > I do not know "GGG", but what happens once a PR is submitted to the > > ML? > > People will write replies on the ML to comment, ask for changes and > > so forth. > > Simlarly on github PRs can receive comments, reviews, approvals and > > so on > > is there some routing of such comments between PR and ML ? > > Yes there is, but currently only from mailing list back as a PR comment > PR comments are not yet sent to the ML. Need to find out the reason > why the aren't doing it or add this functionality. > Essentially, developers are still required to reply on the mailing list. > > But what's nice is that developers can make the requested changes > to their PR source branch, /submit again and GGG will automatically > submit this as v2..vN patchset. > > I think it's best to look an example: > > https://github.com/gitgitgadget/git/pull/1006 > > > another thing needed, if we would allow PRs is that automated fate > > testing > > of such PRs should be implemented. Thats a great way to filter out > > bad PRs beyond just a author list > > Yes absolutely. This can be done just normally as GitHub checks/actions: > > - Conformance of submit message > - Compilation (ideally multiple platforms) > - FATE > - Possibly some code style checking > (for GIT, they have set up 46 checks currently) > > They don't make successful completion of all checks a requirement, > but that's something I would possibly change. > > What I'm still thinking about is the part about hooking into ML > e-mail reception. They are using https://public-inbox.org/ > for GIT, but it would need to be hosted somewhere. > Either I'll figure out a different way or I'll self-host it for an > initial phase. > Do you need to parse each email and then make post requests back to github? Feel free to send me a python/shell script and I can add to the patchwork vm. -- Andriy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] lavfi: add nlmeans CUDA filter
On 14.08.2021 07:49, Dylan Fernando wrote:
On Sat, Aug 14, 2021 at 9:11 AM Timo Rothenpieler
wrote:
On 13.08.2021 10:42, Dylan Fernando wrote:
Any update on this?
Kind Regards,
Dylan
Also, are you sure that exp() function is correct?
The CUDA-Function exp() is defined as "double exp(double x)" and
calculates the base e exponential.
While __nvvm_ex2_approx_f reads to me like it does so for floats, and
for base 2. For which the CUDA equivalent would be "float exp2f(float)".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
I wasn't sure about the exp() function. Is there a function like
__nvvm_exp_approx_d? I can't seem to find a function for this.
Looking into it some more, that's simply because there is no other fast
approx exp function than ex2.
If I use __expf() with nvcc, it spawns the following code:
ld.param.f32%f1, [param];
mul.f32 %f2, %f1, 0f3FB8AA3B;
ex2.approx.f32 %f3, %f2;
So it multiplies the input value by some factor, and then runs it
through it.
Given by math, this value must be log2(euler_constant), or log2(exp(1)),
for lack of the constant being defined.
So the implementation of __expf() would look like this:
static inline __device__ float __expf(float a) { return __nvvm_ex2_approx_f(a *
(float)__builtin_log2(__builtin_exp(1))); }
With llvm, this now spawns the exact same code:
ld.param.f32%f1, [param];
mul.f32 %f2, %f1, 0f3FB8AA3B;
ex2.approx.f32 %f3, %f2;
I will push that function soon, so you can just use __expf() in your
code. Assuming you want exp to base e.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/h264dec: apply H.274 film grain
On 8/14/2021 8:36 AM, Niklas Haas wrote:
From: Niklas Haas
Because we need access to ref frames without film grain applied, we have
to add an extra AVFrame to H264Picture to avoid messing with the
original. This requires some amount of overhead to make the reference
moves work out, but it allows us to benefit from frame multithreading
for film grain application "for free".
Unfortunately, this approach requires twice as much RAM to be constantly
allocated, due to the need for an extra buffer per H264Picture. In
theory, we could get away with freeing up this memory as soon as it's no
longer needed, but trying to call ff_thread_release_buffer() from
output_frame() simply deadlocks the decoder and I haven't figured out
why. Patches welcome(tm)
Tested on all three cases of (no fg), (fg present but exported) and (fg
present and not exported), with and without threading.
---
libavcodec/h264_picture.c | 24 +++-
libavcodec/h264_slice.c | 18 +--
libavcodec/h264dec.c | 48 +++
libavcodec/h264dec.h | 6 +
4 files changed, 83 insertions(+), 13 deletions(-)
diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
index b79944b794..8284d12158 100644
--- a/libavcodec/h264_picture.c
+++ b/libavcodec/h264_picture.c
@@ -44,7 +44,7 @@
void ff_h264_unref_picture(H264Context *h, H264Picture *pic)
{
-int off = offsetof(H264Picture, tf) + sizeof(pic->tf);
+int off = offsetof(H264Picture, tf_grain) + sizeof(pic->tf_grain);
int i;
if (!pic->f || !pic->f->buf[0])
@@ -61,6 +61,9 @@ void ff_h264_unref_picture(H264Context *h, H264Picture *pic)
av_buffer_unref(&pic->ref_index_buf[i]);
}
+if (pic->needs_fg)
+ff_thread_release_buffer(h->avctx, &pic->tf_grain);
+
memset((uint8_t*)pic + off, 0, sizeof(*pic) - off);
}
@@ -109,6 +112,15 @@ int ff_h264_ref_picture(H264Context *h, H264Picture *dst, H264Picture *src)
if (ret < 0)
goto fail;
+if (src->needs_fg) {
+av_assert0(src->tf_grain.f == src->f_grain);
+dst->tf_grain.f = dst->f_grain;
+ret = ff_thread_ref_frame(&dst->tf_grain, &src->tf_grain);
+if (ret < 0)
+goto fail;
+dst->needs_fg = 1;
+}
+
dst->qscale_table_buf = av_buffer_ref(src->qscale_table_buf);
dst->mb_type_buf = av_buffer_ref(src->mb_type_buf);
dst->pps_buf = av_buffer_ref(src->pps_buf);
@@ -160,6 +172,16 @@ int ff_h264_replace_picture(H264Context *h, H264Picture
*dst, const H264Picture
if (ret < 0)
goto fail;
+if (src->needs_fg) {
+av_assert0(src->tf_grain.f == src->f_grain);
+dst->tf_grain.f = dst->f_grain;
+ff_thread_release_buffer(h->avctx, &dst->tf_grain);
+ret = ff_thread_ref_frame(&dst->tf_grain, &src->tf_grain);
+if (ret < 0)
+goto fail;
+dst->needs_fg = 1;
+}
+
ret = av_buffer_replace(&dst->qscale_table_buf, src->qscale_table_buf);
ret |= av_buffer_replace(&dst->mb_type_buf, src->mb_type_buf);
ret |= av_buffer_replace(&dst->pps_buf, src->pps_buf);
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 65d0259a71..2b85f807df 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -197,6 +197,21 @@ static int alloc_picture(H264Context *h, H264Picture *pic)
if (ret < 0)
goto fail;
+if (h->sei.film_grain_characteristics.present &&
+!(h->avctx->export_side_data & AV_CODEC_EXPORT_DATA_FILM_GRAIN))
+{
+// Extra buffer required for film grain synthesis in the decoder
+pic->tf_grain.f = pic->f_grain;
+pic->f_grain->format = pic->f->format;
+pic->f_grain->width = pic->f->width;
+pic->f_grain->height = pic->f->height;
+ret = ff_thread_get_buffer(h->avctx, &pic->tf_grain, 0);
+if (ret < 0)
+goto fail;
+pic->needs_fg = 1;
+}
+
+
if (h->avctx->hwaccel) {
const AVHWAccel *hwaccel = h->avctx->hwaccel;
av_assert0(!pic->hwaccel_picture_private);
@@ -1329,8 +1344,7 @@ static int h264_export_frame_props(H264Context *h)
}
h->sei.unregistered.nb_buf_ref = 0;
-if (h->sei.film_grain_characteristics.present &&
-(h->avctx->export_side_data & AV_CODEC_EXPORT_DATA_FILM_GRAIN)) {
+if (h->sei.film_grain_characteristics.present) {
H264SEIFilmGrainCharacteristics *fgc =
&h->sei.film_grain_characteristics;
AVFilmGrainParams *fgp = av_film_grain_params_create_side_data(out);
if (!fgp)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 38f8967265..d5878b8a13 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -275,9 +275,22 @@ int ff_h264_slice_context_init(H264Context *h,
H264SliceContext *sl)
return 0;
}
+static int h264_init_pic(H264Picture *pic)
+{
+pic->f = av_frame_alloc();
+if (!pi
Re: [FFmpeg-devel] [PATCH 2/4] avfilter/avfilter: Add numbers of (in|out)pads directly to AVFilter
Nicolas George:
> Andreas Rheinhardt (12021-08-12):
>> Up until now, an AVFilter's lists of input and output AVFilterPads
>> were terminated by a sentinel and the only way for the user to get
>> the length of these lists was by using avfilter_pad_count(). This
>> has two drawbacks: first, sizeof(AVFilterPad) is not negligible
>> (i.e. 64B on 64bit systems); second, getting the size involves
>> a function call instead of just reading the data.
>>
>> This commit therefore changes this. The sentinels are removed and new
>> fields nb_inputs and nb_outputs are added to AVFilter that contain the
>> number of elements of the respective AVFilterPad array.
>> Given that AVFilter.(in|out)puts are the only arrays of zero-terminated
>> AVFilterPads an API user has access to (AVFilterContext.(in|out)put_pads
>> are not zero-terminated and they already have a size field) the argument
>> to avfilter_pad_count() is always one of these lists, so it just has to
>> find the filter the list belongs to and read said number. This is slower
>> than before, but users are expected to switch to AVFilter.nb_(in|out)puts;
>> and furthermore, avfilter_pad_count() is probably never called in hot
>> loops anyway.
>>
>> This saves about 49KiB from the binary; notice that these sentinels are
>> not in .bss despite being zeroed; in fact, they are in .data.rel.ro
>> due to the non-sentinels.
>>
>> Signed-off-by: Andreas Rheinhardt
>
> I think it is a good change.
>
> We could shave ~3.5k extra by making the fields uint16_t; lavfi is
> absolutely not ready to handle filters with thousands of inputs, there
> are loops everywhere.
>
> OTOH, I do not like the fact that it requires more boilerplate code.
When I made this I found it acceptable because it also removed the
boilerplate { NULL } at the end of the structures. And because it could
be easily automated.
>
>> @@ -330,6 +329,7 @@ const AVFilter ff_asrc_aevalsrc = {
>> .priv_size = sizeof(EvalContext),
>> .inputs= NULL,
>> .outputs = aevalsrc_outputs,
>> +.nb_outputs= FF_ARRAY_ELEMS(aevalsrc_outputs),
>> .priv_class= &aevalsrc_class,
>> };
>
> A macro would solve that:
>
> #define FILTER_INPUTS(array) \
> .inputs = (array),
> .nb_inputs = FF_ARRAY_ELEMS(array)
That would indeed be even better.
>
> Also, I am rather not for using these fields directly. Keeping them
> private and leaving avfilter_pad_count() gives us more freedom,
> including the freedom to change the type from uint16_t to unsigned later
> without break.
>
But then I'd rather replace avfilter_pad_count() with something that
does not require to loop over all filters. Something like unsigned
avfilter_pads_count(const AVFilter *filter, int is_input).
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: add SMC encoder
Paul B Mahol: > +/** > + * @file smcenc.c > + * QT SMC Video Encoder by Paul B. Mahol > + */ > + > +#include "libavutil/avassert.h" This file does not use any av_assert > +#include "libavutil/common.h" > + > +#include "avcodec.h" > +#include "encode.h" > +#include "internal.h" > +#include "bytestream.h" > + - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/h264_parser: fix nalsize parser
Fixes: left shift of 16711968 by 8 places cannot be represented in type 'int'
Fixes:
36601/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-6581933285965824
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index d3c56cc188..22111c62a2 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -86,7 +86,7 @@ static int h264_find_frame_end(H264ParseContext *p, const
uint8_t *buf,
int nalsize = 0;
i = next_avc;
for (j = 0; j < p->nal_length_size; j++)
-nalsize = (nalsize << 8) | buf[i++];
+nalsize = ((unsigned)nalsize << 8) | buf[i++];
if (nalsize <= 0 || nalsize > buf_size - i) {
av_log(logctx, AV_LOG_ERROR, "AVC-parser: nal size %d
remaining %d\n", nalsize, buf_size - i);
return buf_size;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Cleanup avmv on errors
Fixes: Assertion failure
Fixes:
36359/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6733238591684608
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/snowdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
index 1355ae6ed1..7ef28c4899 100644
--- a/libavcodec/snowdec.c
+++ b/libavcodec/snowdec.c
@@ -499,7 +499,7 @@ static int decode_frame(AVCodecContext *avctx, void *data,
int *got_frame,
s->avmv_index = 0;
if ((res = decode_blocks(s)) < 0)
-return res;
+goto fail;
for(plane_index=0; plane_index < s->nb_planes; plane_index++){
Plane *p= &s->plane[plane_index];
@@ -618,11 +618,11 @@ static int decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
AVFrameSideData *sd;
sd = av_frame_new_side_data(picture, AV_FRAME_DATA_MOTION_VECTORS,
s->avmv_index * sizeof(AVMotionVector));
-if (!sd)
-return AVERROR(ENOMEM);
-memcpy(sd->data, s->avmv, s->avmv_index * sizeof(AVMotionVector));
+if (sd)
+memcpy(sd->data, s->avmv, s->avmv_index * sizeof(AVMotionVector));
}
+fail:
av_freep(&s->avmv);
if (res < 0)
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Cleanup prediction code in truemotion1_decode_16bit and truemotion1_decode_24bit of truemotion1 decoder
This cleans up the code in the decode24bit and decode16bit functions by putting
it in way that expresses the true intent while making it easier to read.
---
libavcodec/truemotion1.c | 35 ---
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 32d8fb4005..3f13de0ff8 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -660,20 +660,14 @@ static void truemotion1_decode_16bit(TrueMotion1Context
*s)
case 0:
/* if macroblock width is 2, apply C-Y-C-Y; else
* apply C-Y-Y */
+APPLY_C_PREDICTOR();
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
if (s->block_width == 2) {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
+ APPLY_C_PREDICTOR();
}
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
break;
case 1:
@@ -786,22 +780,17 @@ static void truemotion1_decode_24bit(TrueMotion1Context
*s)
case 0:
/* if macroblock width is 2, apply C-Y-C-Y; else
* apply C-Y-Y */
+APPLY_C_PREDICTOR_24();
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
if (s->block_width == 2) {
APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
}
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
break;
+
case 1:
case 3:
/* always apply 2 Y predictors on these iterations */
--
2.24.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Subject: [PATCH] Cleanup code in truemotion1 decoder
Sent new patch.
Once again this proves the superioity of the graphical stuff. The whole host of
issues in the first set of this email would have been avoided, and i wouldnt
have to create the patch all over again to fix something.
August 14, 2021 4:23 AM, "Michael Niedermayer" wrote:
> On Sun, Aug 01, 2021 at 04:22:28PM +, ffmpegandmahanstreamer@e.email
> wrote:
>
>> Per Andreas Rheinhardt request i'm splitting the working patches in two.
>
> And this results in a commit message like this:
> Author: ffmpegandmahanstreamer@e.email
> Date: Sun Aug 1 16:22:28 2021 +
>
> Subject: [PATCH] Cleanup code in truemotion1 decoder
>
> Per Andreas Rheinhardt request i'm splitting the working patches in two.
>
> Thats not good
> "Subject: [PATCH]" doesnt belong in it
> "Cleanup code in truemotion1 decoder" is too terse, what is cleaned upo why
> and how
>
> Your Author name is also missing, is that intended ?
>
>> ---
>> This cleans up the code in the decode24bit and decode16bit functions by
>> putting it in way that
>> expresses the true intent while making it easier to read.
>> libavcodec/truemotion1.c | 36
>> 1 file changed, 12 insertions(+), 24 deletions(-)
>>
>> diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
>> index 32d8fb4005..50c90e732d 100644
>> --- a/libavcodec/truemotion1.c
>> +++ b/libavcodec/truemotion1.c
>> @@ -655,25 +655,19 @@ static void
>> truemotion1_decode_16bit(TrueMotion1Context *s)
>> while (pixels_left > 0) {
>>
>> if (keyframe || ((mb_change_byte & mb_change_byte_mask) == 0)) {
>> -
>> +
>> switch (y & 3) {
>
> unrelated
> trailing whitespace
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Nations do behave wisely once they have exhausted all other alternatives.
> -- Abba Eban
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/truemotion1: Cleanup prediction code in truemotion1_decode_16bit and truemotion1_decode_24bit
This cleans up the code in the decode24bit and decode16bit functions by putting
it in way that expresses the true intent while making it easier to read.
---
libavcodec/truemotion1.c | 35 ---
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 32d8fb4005..3f13de0ff8 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -660,20 +660,14 @@ static void truemotion1_decode_16bit(TrueMotion1Context
*s)
case 0:
/* if macroblock width is 2, apply C-Y-C-Y; else
* apply C-Y-Y */
+APPLY_C_PREDICTOR();
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
if (s->block_width == 2) {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
+ APPLY_C_PREDICTOR();
}
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
break;
case 1:
@@ -786,22 +780,17 @@ static void truemotion1_decode_24bit(TrueMotion1Context
*s)
case 0:
/* if macroblock width is 2, apply C-Y-C-Y; else
* apply C-Y-Y */
+APPLY_C_PREDICTOR_24();
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
if (s->block_width == 2) {
APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
}
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
break;
+
case 1:
case 3:
/* always apply 2 Y predictors on these iterations */
--
2.24.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Cleanup prediction code in truemotion1_decode_16bit and truemotion1_decode_24bit of truemotion1 decoder
The other patch has more subject line aligned to other devs, go to that one
instead.
August 14, 2021 7:24 AM, "ffmpegandmahanstreamer"
wrote:
> This cleans up the code in the decode24bit and decode16bit functions by
> putting it in way that
> expresses the true intent while making it easier to read.
> ---
> libavcodec/truemotion1.c | 35 ---
> 1 file changed, 12 insertions(+), 23 deletions(-)
>
> diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
> index 32d8fb4005..3f13de0ff8 100644
> --- a/libavcodec/truemotion1.c
> +++ b/libavcodec/truemotion1.c
> @@ -660,20 +660,14 @@ static void truemotion1_decode_16bit(TrueMotion1Context
> *s)
> case 0:
> /* if macroblock width is 2, apply C-Y-C-Y; else
> * apply C-Y-Y */
> + APPLY_C_PREDICTOR();
> + APPLY_Y_PREDICTOR();
> + OUTPUT_PIXEL_PAIR();
> if (s->block_width == 2) {
> - APPLY_C_PREDICTOR();
> - APPLY_Y_PREDICTOR();
> - OUTPUT_PIXEL_PAIR();
> - APPLY_C_PREDICTOR();
> - APPLY_Y_PREDICTOR();
> - OUTPUT_PIXEL_PAIR();
> - } else {
> - APPLY_C_PREDICTOR();
> - APPLY_Y_PREDICTOR();
> - OUTPUT_PIXEL_PAIR();
> - APPLY_Y_PREDICTOR();
> - OUTPUT_PIXEL_PAIR();
> + APPLY_C_PREDICTOR();
> }
> + APPLY_Y_PREDICTOR();
> + OUTPUT_PIXEL_PAIR();
> break;
>
> case 1:
> @@ -786,22 +780,17 @@ static void truemotion1_decode_24bit(TrueMotion1Context
> *s)
> case 0:
> /* if macroblock width is 2, apply C-Y-C-Y; else
> * apply C-Y-Y */
> + APPLY_C_PREDICTOR_24();
> + APPLY_Y_PREDICTOR_24();
> + OUTPUT_PIXEL_PAIR();
> if (s->block_width == 2) {
> APPLY_C_PREDICTOR_24();
> - APPLY_Y_PREDICTOR_24();
> - OUTPUT_PIXEL_PAIR();
> - APPLY_C_PREDICTOR_24();
> - APPLY_Y_PREDICTOR_24();
> - OUTPUT_PIXEL_PAIR();
> - } else {
> - APPLY_C_PREDICTOR_24();
> - APPLY_Y_PREDICTOR_24();
> - OUTPUT_PIXEL_PAIR();
> - APPLY_Y_PREDICTOR_24();
> - OUTPUT_PIXEL_PAIR();
> }
> + APPLY_Y_PREDICTOR_24();
> + OUTPUT_PIXEL_PAIR();
> break;
>
> +
> case 1:
> case 3:
> /* always apply 2 Y predictors on these iterations */
> --
> 2.24.3
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Cleanup avmv on errors
> On Aug 14, 2021, at 11:07 PM, Michael Niedermayer
> wrote:
>
> Fixes: Assertion failure
> Fixes:
> 36359/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6733238591684608
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/snowdec.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
> index 1355ae6ed1..7ef28c4899 100644
> --- a/libavcodec/snowdec.c
> +++ b/libavcodec/snowdec.c
> @@ -499,7 +499,7 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
> s->avmv_index = 0;
>
> if ((res = decode_blocks(s)) < 0)
> -return res;
> +goto fail;
>
> for(plane_index=0; plane_index < s->nb_planes; plane_index++){
> Plane *p= &s->plane[plane_index];
> @@ -618,11 +618,11 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
> AVFrameSideData *sd;
>
> sd = av_frame_new_side_data(picture, AV_FRAME_DATA_MOTION_VECTORS,
> s->avmv_index * sizeof(AVMotionVector));
> -if (!sd)
> -return AVERROR(ENOMEM);
> -memcpy(sd->data, s->avmv, s->avmv_index * sizeof(AVMotionVector));
> +if (sd)
> +memcpy(sd->data, s->avmv, s->avmv_index *
> sizeof(AVMotionVector));
res is not assigned to AVERROR(ENOMEM), so the error is just being ignored. Is
it intentional?
> }
>
> +fail:
> av_freep(&s->avmv);
>
> if (res < 0)
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Subject: [PATCH] Cleanup code in truemotion1 decoder
August 14, 2021 7:43 AM, "Nicolas George" wrote: > ffmpegandmahanstreamer (12021-08-14): > >> Once again this proves the superioity of the graphical stuff. > > Start with not top-posting and we may take your opinion on the > superiority of stuff seriously. I top post only when i want to reply to the message as a whole. Here, im bottom posting because im responding to your specific part. Bottom (literally, like way bottom) posting is worse than top posting, because then you need to scroll all the way down. Hence why top-posting was invented > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Cleanup avmv on errors
On Sat, Aug 14, 2021 at 11:45:59PM +0800, "zhilizhao(赵志立)" wrote:
>
>
> > On Aug 14, 2021, at 11:07 PM, Michael Niedermayer
> > wrote:
> >
> > Fixes: Assertion failure
> > Fixes:
> > 36359/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6733238591684608
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/snowdec.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
> > index 1355ae6ed1..7ef28c4899 100644
> > --- a/libavcodec/snowdec.c
> > +++ b/libavcodec/snowdec.c
> > @@ -499,7 +499,7 @@ static int decode_frame(AVCodecContext *avctx, void
> > *data, int *got_frame,
> > s->avmv_index = 0;
> >
> > if ((res = decode_blocks(s)) < 0)
> > -return res;
> > +goto fail;
> >
> > for(plane_index=0; plane_index < s->nb_planes; plane_index++){
> > Plane *p= &s->plane[plane_index];
> > @@ -618,11 +618,11 @@ static int decode_frame(AVCodecContext *avctx, void
> > *data, int *got_frame,
> > AVFrameSideData *sd;
> >
> > sd = av_frame_new_side_data(picture, AV_FRAME_DATA_MOTION_VECTORS,
> > s->avmv_index * sizeof(AVMotionVector));
> > -if (!sd)
> > -return AVERROR(ENOMEM);
> > -memcpy(sd->data, s->avmv, s->avmv_index * sizeof(AVMotionVector));
> > +if (sd)
> > +memcpy(sd->data, s->avmv, s->avmv_index *
> > sizeof(AVMotionVector));
>
> res is not assigned to AVERROR(ENOMEM), so the error is just being ignored.
> Is it intentional?
the frame was decoded correctly, just exporting the vectors failed.
Should we fail and then discard the frame as a result ?
It seemed better to not fail here, but i was a bit undecided here,
what do others think ?
so yes it was intentional but maybe it should be done differently, depends
on what people prefer ...
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Cleanup avmv on errors
> On Aug 14, 2021, at 11:52 PM, Michael Niedermayer
> wrote:
>
> On Sat, Aug 14, 2021 at 11:45:59PM +0800, "zhilizhao(赵志立)" wrote:
>>
>>
>>> On Aug 14, 2021, at 11:07 PM, Michael Niedermayer
>>> wrote:
>>>
>>> Fixes: Assertion failure
>>> Fixes:
>>> 36359/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6733238591684608
>>>
>>> Found-by: continuous fuzzing process
>>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavcodec/snowdec.c | 8
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
>>> index 1355ae6ed1..7ef28c4899 100644
>>> --- a/libavcodec/snowdec.c
>>> +++ b/libavcodec/snowdec.c
>>> @@ -499,7 +499,7 @@ static int decode_frame(AVCodecContext *avctx, void
>>> *data, int *got_frame,
>>>s->avmv_index = 0;
>>>
>>>if ((res = decode_blocks(s)) < 0)
>>> -return res;
>>> +goto fail;
>>>
>>>for(plane_index=0; plane_index < s->nb_planes; plane_index++){
>>>Plane *p= &s->plane[plane_index];
>>> @@ -618,11 +618,11 @@ static int decode_frame(AVCodecContext *avctx, void
>>> *data, int *got_frame,
>>>AVFrameSideData *sd;
>>>
>>>sd = av_frame_new_side_data(picture, AV_FRAME_DATA_MOTION_VECTORS,
>>> s->avmv_index * sizeof(AVMotionVector));
>>> -if (!sd)
>>> -return AVERROR(ENOMEM);
>>> -memcpy(sd->data, s->avmv, s->avmv_index * sizeof(AVMotionVector));
>>> +if (sd)
>>> +memcpy(sd->data, s->avmv, s->avmv_index *
>>> sizeof(AVMotionVector));
>>
>> res is not assigned to AVERROR(ENOMEM), so the error is just being ignored.
>> Is it intentional?
>
> the frame was decoded correctly, just exporting the vectors failed.
> Should we fail and then discard the frame as a result ?
> It seemed better to not fail here, but i was a bit undecided here,
> what do others think ?
> so yes it was intentional but maybe it should be done differently, depends
> on what people prefer ...
Understood. In the ENOMEM case, I prefer simple logic than do the best effort
to give the user a partly success result. Somebody who don’t get the idea may
try to ‘fix’ it again. Although I don’t have a strong opinion on that.
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you drop bombs on a foreign country and kill a hundred thousand
> innocent people, expect your government to call the consequence
> "unprovoked inhuman terrorist attacks" and use it to justify dropping
> more bombs and killing more people. The technology changed, the idea is old.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Third opinion? (was: lavf/avio: remove support for proto, , opt, val, , syntax.)
On Sat, 14 Aug 2021, Nicolas George wrote: Nicolas George (12021-07-30): Andreas Rheinhardt (12021-07-29): The latter statement is not true: This is public API; anyone can have used it for any purpose. Your 2/5 adds a replacement for using it with dvd2concat, but there are other usages, too; e.g. concatenating several subfile files (each with its own start and end) with the concat protocol won't be possible any more with this patch. This feature was never documented, and only incidentally mentioned in the examples for subfile, so I consider it is more akin to avpriv than to a public API. Do you have practical examples where concatenating subfiles is useful? This feature makes several parts of the code harder to understand, see hls.c and dashdec.c. I have also asked on the users mailing-lists: https://ffmpeg.org/pipermail/ffmpeg-user/2021-August/date.html http://ffmpeg.org/pipermail/libav-user/2021-August/012836.html Unless somebody uses it in the real world, I would favor just getting rid of it. I think this is one of those cases when we know that strictly speaking it breaks existing API / behaviour but we go ahead with it anyway because it is minor enough. And the feature to specify options in protocols was ugly in the first place. So I am OK with removing it. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
On Sat, 14 Aug 2021, at 03:13, Soft Works wrote: > The continuing attempt to declare developers who are favoring modern > workflows and tooling as newbies and unexperienced is a really disgusting > rhetoric. I agree. Very complex projects, more complex than FFmpeg are on GitHub and Gitlab and survive very well. It is a question of preference, absolutely not of skillz nor seniority. For your data point, dav1d is developed without mailing list, and has managed to ship a ton of code in 2years. VLC moved from mailing lists (used for 20 years) to Gitlab and it’s mostly doing fine. All options are fine, but are unrelated to skills. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Cleanup avmv on errors
On Sun, 15 Aug 2021, "zhilizhao(赵志立)" wrote:
On Aug 14, 2021, at 11:52 PM, Michael Niedermayer
wrote:
On Sat, Aug 14, 2021 at 11:45:59PM +0800, "zhilizhao(赵志立)" wrote:
On Aug 14, 2021, at 11:07 PM, Michael Niedermayer
wrote:
Fixes: Assertion failure
Fixes:
36359/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6733238591684608
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/snowdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
index 1355ae6ed1..7ef28c4899 100644
--- a/libavcodec/snowdec.c
+++ b/libavcodec/snowdec.c
@@ -499,7 +499,7 @@ static int decode_frame(AVCodecContext *avctx, void *data,
int *got_frame,
s->avmv_index = 0;
if ((res = decode_blocks(s)) < 0)
-return res;
+goto fail;
for(plane_index=0; plane_index < s->nb_planes; plane_index++){
Plane *p= &s->plane[plane_index];
@@ -618,11 +618,11 @@ static int decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
AVFrameSideData *sd;
sd = av_frame_new_side_data(picture, AV_FRAME_DATA_MOTION_VECTORS,
s->avmv_index * sizeof(AVMotionVector));
-if (!sd)
-return AVERROR(ENOMEM);
-memcpy(sd->data, s->avmv, s->avmv_index * sizeof(AVMotionVector));
+if (sd)
+memcpy(sd->data, s->avmv, s->avmv_index * sizeof(AVMotionVector));
res is not assigned to AVERROR(ENOMEM), so the error is just being ignored. Is
it intentional?
the frame was decoded correctly, just exporting the vectors failed.
Should we fail and then discard the frame as a result ?
It seemed better to not fail here, but i was a bit undecided here,
what do others think ?
so yes it was intentional but maybe it should be done differently, depends
on what people prefer ...
Understood. In the ENOMEM case, I prefer simple logic than do the best effort
to give the user a partly success result. Somebody who don’t get the idea may
try to ‘fix’ it again. Although I don’t have a strong opinion on that.
IMHO ignoring ENOMEM errors is just bad practice. Every ENOMEM error
should be propagated back to the user.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] libavformat/isom_tags.c: add ipcm to list of tags
On Sat, 14. Aug 12:14, Stephen Hutchinson wrote:
> ffmpeg | branch: master | Stephen Hutchinson | Wed Jul 14
> 20:16:41 2021 -0400| [1c42fd93236e7869ef4d9fe3650dd3e951387321] | committer:
> Paul B Mahol
>
> libavformat/isom_tags.c: add ipcm to list of tags
>
> Fixes http://trac.ffmpeg.org/ticket/9219
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=1c42fd93236e7869ef4d9fe3650dd3e951387321
> ---
>
> libavformat/isom_tags.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
> index 1666b9d4a5..e2e589b658 100644
> --- a/libavformat/isom_tags.c
> +++ b/libavformat/isom_tags.c
> @@ -312,6 +312,8 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
> { AV_CODEC_ID_PCM_S16LE, MKTAG('s', 'o', 'w', 't') },
> { AV_CODEC_ID_PCM_S16BE, MKTAG('l', 'p', 'c', 'm') },
> { AV_CODEC_ID_PCM_S16LE, MKTAG('l', 'p', 'c', 'm') },
> +{ AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'p', 'c', 'm') },
> +{ AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'p', 'c', 'm') },
> { AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') },
> { AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') },
> { AV_CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') },
>
This break fate for me:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210715001641.2598-1-qyo...@gmail.com/
--
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
Jean-Baptiste Kempf (12021-08-14): > > The continuing attempt to declare developers who are favoring modern > > workflows and tooling as newbies and unexperienced is a really disgusting > > rhetoric. > I agree. Good thing it is not what I wrote, then. I am a little disappointed that you would make a judgement like that without reading carefully and realizing that Soft Works has turned my position on its head. My statement is: newbies ⇒ like newfangled tools. My statement never was: like newfangled tools ⇒ newbies. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
On Sat, Aug 14, 2021, 11:26 Nicolas George wrote: > > I agree. But it is important to remember that before seriously > considering any deep change, it would be necessary to actively poll the > silent individual-minority-work-majority. > Is there a mechanism to trigger such a vote? I hope the core developers have one soon so the project can get moving on this. Cheers, Dee ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
Diederick C. Niehorster (12021-08-14): > Is there a mechanism to trigger such a vote? I hope the core developers > have one soon so the project can get moving on this. There is a mechanism. But as I explained there: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283705.html for this kind of question a simple one person = one vote system would be a grave mistake. This kind of decision has to be taken by weighing opinions by how much developers are impacted. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec: add SMC encoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/smcenc.c| 563 +
3 files changed, 565 insertions(+)
create mode 100644 libavcodec/smcenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 9a6adb9903..0dc564f5dc 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -621,6 +621,7 @@ OBJS-$(CONFIG_SIMBIOSIS_IMX_DECODER) += imx.o
OBJS-$(CONFIG_SMACKAUD_DECODER)+= smacker.o
OBJS-$(CONFIG_SMACKER_DECODER) += smacker.o
OBJS-$(CONFIG_SMC_DECODER) += smc.o
+OBJS-$(CONFIG_SMC_ENCODER) += smcenc.o
OBJS-$(CONFIG_SNOW_DECODER)+= snowdec.o snow.o snow_dwt.o
OBJS-$(CONFIG_SNOW_ENCODER)+= snowenc.o snow.o snow_dwt.o
\
h263.o h263data.o ituh263enc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 71bc21aa05..c087b91148 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -299,6 +299,7 @@ extern const AVCodec ff_sgirle_decoder;
extern const AVCodec ff_sheervideo_decoder;
extern const AVCodec ff_simbiosis_imx_decoder;
extern const AVCodec ff_smacker_decoder;
+extern const AVCodec ff_smc_encoder;
extern const AVCodec ff_smc_decoder;
extern const AVCodec ff_smvjpeg_decoder;
extern const AVCodec ff_snow_encoder;
diff --git a/libavcodec/smcenc.c b/libavcodec/smcenc.c
new file mode 100644
index 00..686b063630
--- /dev/null
+++ b/libavcodec/smcenc.c
@@ -0,0 +1,563 @@
+/*
+ * QuickTime Graphics (SMC) Video Encoder
+ * Copyright (c) 2021 The FFmpeg project
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file smcenc.c
+ * QT SMC Video Encoder by Paul B. Mahol
+ */
+
+#include "libavutil/common.h"
+
+#include "avcodec.h"
+#include "encode.h"
+#include "internal.h"
+#include "bytestream.h"
+
+#define CPAIR 2
+#define CQUAD 4
+#define COCTET 8
+
+#define COLORS_PER_TABLE 256
+
+typedef struct SMCContext {
+AVFrame *prev_frame;// buffer for previous source frame
+PutByteContext pb;
+
+uint8_t mono_value;
+int nb_distinct;
+int next_nb_distinct;
+uint8_t distinct_values[16];
+uint8_t next_distinct_values[16];
+
+uint16_t color_pairs[COLORS_PER_TABLE];
+uint32_t color_quads[COLORS_PER_TABLE];
+uint64_t color_octets[COLORS_PER_TABLE];
+
+int first_frame;// flag set to one when the first frame is being
processed
+// so that comparisons with previous frame data in
not attempted
+int key_frame;
+} SMCContext;
+
+#define ADVANCE_BLOCK(pixel_ptr, row_ptr, nb_blocks) \
+{ \
+for (int block = 0; block < nb_blocks && pixel_ptr && row_ptr; block++) { \
+pixel_ptr += 4; \
+if (pixel_ptr - row_ptr >= width) \
+{ \
+row_ptr += stride * 4; \
+pixel_ptr = row_ptr; \
+} \
+} \
+}
+
+static int smc_cmp_values(const void *a, const void *b)
+{
+const uint8_t *aa = a, *bb = b;
+
+return FFDIFFSIGN(aa[0], bb[0]);
+}
+
+static int count_distinct_items(const uint8_t *block_values,
+uint8_t *distinct_values,
+int size)
+{
+int n = 1;
+
+distinct_values[0] = block_values[0];
+for (int i = 1; i < size; i++) {
+if (block_values[i] != block_values[i-1]) {
+distinct_values[n] = block_values[i];
+n++;
+}
+}
+
+return n;
+}
+
+static void smc_encode_stream(SMCContext *s, const AVFrame *frame)
+{
+PutByteContext *pb = &s->pb;
+const uint8_t *src_pixels = (const uint8_t *)frame->data[0];
+const int stride = frame->linesize[0];
+const uint8_t *prev_pixels = (const uint8_t *)s->prev_frame->data[0];
+const uint8_t *pixel_ptr, *row_ptr;
+const int width = frame->width;
+uint8_t block_values[16];
+int block_counter = 0;
+int color_pair_index = 0;
+int color_quad_index = 0;
+int color_octet_index = 0;
+int color_table_index; /* indexes to color pair, quad, or octet tables */
+int total_blocks;
+
+memset(s->color_pairs, 0, sizeof(s->color_pairs));
+memset(s->color_quads, 0, sizeof(s->color_quads));
+memset(s-
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
ffmpegandmahanstreamer (12021-08-14): > The real person winning here is Soft Works. He must be laughing right now. > Ah, your math degree coming into work here - "if and only if" ;) > Dont make broad generalizations however. > Careful there. Don't you remember anything about the libav split? Do you have a point, or are you just trying to make the discussion more unpleasant than it already is? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] libavformat/isom_tags.c: add ipcm to list of tags
On Sat, Aug 14, 2021 at 7:43 PM Andriy Gelman wrote:
>
> On Sat, 14. Aug 12:14, Stephen Hutchinson wrote:
> > ffmpeg | branch: master | Stephen Hutchinson | Wed Jul
> > 14 20:16:41 2021 -0400| [1c42fd93236e7869ef4d9fe3650dd3e951387321] |
> > committer: Paul B Mahol
> >
> > libavformat/isom_tags.c: add ipcm to list of tags
> >
> > Fixes http://trac.ffmpeg.org/ticket/9219
> >
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=1c42fd93236e7869ef4d9fe3650dd3e951387321
> > ---
> >
> > libavformat/isom_tags.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
> > index 1666b9d4a5..e2e589b658 100644
> > --- a/libavformat/isom_tags.c
> > +++ b/libavformat/isom_tags.c
> > @@ -312,6 +312,8 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
> > { AV_CODEC_ID_PCM_S16LE, MKTAG('s', 'o', 'w', 't') },
> > { AV_CODEC_ID_PCM_S16BE, MKTAG('l', 'p', 'c', 'm') },
> > { AV_CODEC_ID_PCM_S16LE, MKTAG('l', 'p', 'c', 'm') },
> > +{ AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'p', 'c', 'm') },
> > +{ AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'p', 'c', 'm') },
> > { AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') },
> > { AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') },
> > { AV_CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') },
> >
>
> This break fate for me:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210715001641.2598-1-qyo...@gmail.com/
>
Seems like it just wasn't noticed that ff_codec_movaudio_tags is
utilized for both demux and mux; Thus putting ipcm earlier in the list
compared to in24 meant that instead of the standard MOV/QTFF PCM tag
the ipcm one got picked by default (as it was the first matching
identifier).
After a cursory look I cannot find references to ipcm in either QTFF
or ISOBMFF specs, so I'd say we just pull in24 to before ipcm in the
order for signed 24bit audio (both of the lines visible in the
context). This fixes the test as well as makes us default to the QTFF
specified identifier again.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Third opinion? (was: lavf/avio: remove support for proto, , opt, val, , syntax.)
Nicolas George: > Nicolas George (12021-07-30): >> Andreas Rheinhardt (12021-07-29): >>> The latter statement is not true: This is public API; anyone can have >>> used it for any purpose. Your 2/5 adds a replacement for using it with >>> dvd2concat, but there are other usages, too; e.g. concatenating several >>> subfile files (each with its own start and end) with the concat protocol >>> won't be possible any more with this patch. >> >> This feature was never documented, and only incidentally mentioned in >> the examples for subfile, so I consider it is more akin to avpriv than >> to a public API. >> >> Do you have practical examples where concatenating subfiles is useful? > > This feature makes several parts of the code harder to understand, see > hls.c and dashdec.c. > I do not really get that: The option passing syntax is restricted to the subfile protocol, so I don't know why we allow it for the file protocol in dashdec and hls. Unless I am missing something, this could (and should) be removed at once. > I have also asked on the users mailing-lists: > > https://ffmpeg.org/pipermail/ffmpeg-user/2021-August/date.html > http://ffmpeg.org/pipermail/libav-user/2021-August/012836.html > > Unless somebody uses it in the real world, I would favor just getting > rid of it. > I use it to concatenate parts of files: When a DVR of mine has to split files due to the 4GB FAT-32 boundary, it does not do so cleanly; for some reason the first 96256B of the second file are duplicated, i.e. they coincide with bytes 96256-192511. For the third file, about a MB starting from offset 96256 is duplicated. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/isom_tags: prefer in24 for 24bit PCM in MOV
In 1c42fd93236e7869ef4d9fe3650dd3e951387321 the ipcm identifier was
added in order to demux additional raw audio from Sony MP4 files.
Unfortunately, it was not noticed that this same list is utilized
for muxing as well, thus causing ipcm to get preferred compared
to the identifier officially specified in QTFF documentation.
This fixes the order of preference for 24bit PCM, where ipcm is
still allowed, but in24 is the first match - thus being preferred.
Fixes fate-acodec-pcm-s24be.
---
libavformat/isom_tags.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
index e2e589b658..d0400b18fc 100644
--- a/libavformat/isom_tags.c
+++ b/libavformat/isom_tags.c
@@ -312,10 +312,10 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
{ AV_CODEC_ID_PCM_S16LE, MKTAG('s', 'o', 'w', 't') },
{ AV_CODEC_ID_PCM_S16BE, MKTAG('l', 'p', 'c', 'm') },
{ AV_CODEC_ID_PCM_S16LE, MKTAG('l', 'p', 'c', 'm') },
-{ AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'p', 'c', 'm') },
-{ AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'p', 'c', 'm') },
{ AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') },
{ AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') },
+{ AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'p', 'c', 'm') },
+{ AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'p', 'c', 'm') },
{ AV_CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') },
{ AV_CODEC_ID_PCM_S32LE, MKTAG('i', 'n', '3', '2') },
{ AV_CODEC_ID_PCM_S8, MKTAG('s', 'o', 'w', 't') },
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/isom_tags: prefer in24 for 24bit PCM in MOV
Patch is OK, apply at will. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/isom_tags: prefer in24 for 24bit PCM in MOV
On Sat, Aug 14, 2021 at 8:25 PM Paul B Mahol wrote: > > Patch is OK, apply at will. Thanks, applied as 087fbfe5bc2272aa1cfd9f4c49438436b68a1ddc . Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
Hi, On Sat, Aug 14, 2021 at 1:13 PM ffmpegandmahanstreamer wrote: > August 14, 2021 1:01 PM, "Nicolas George" wrote: > > > ffmpegandmahanstreamer (12021-08-14): > > > >> The real person winning here is Soft Works. He must be laughing right > now. > >> > >> Ah, your math degree coming into work here - "if and only if" ;) > >> Dont make broad generalizations however. > >> > >> Careful there. Don't you remember anything about the libav split? > > > > Do you have a point, or are you just trying to make the discussion more > > unpleasant than it already is? > > > I've made my point. The people have spoken. Some multiple times. > The point is you are the only one against the change, the consensus all > seems to be in favor of Soft's proposal. > I'm not sure I support it, I'd have to look closely. I understand the appeal of "dev env wrappers" for drive-by development and would encourage it for that, but I'm not sure I would use it myself unless adopted project-wide. Using a wrapper is always a somewhat suboptimal experience. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 07/10] avfilter/internal: Factor out executing a filter's execute_func
Nicolas George: > Andreas Rheinhardt (12021-08-11): >> The current way of doing it involves writing the ctx parameter twice. >> >> Signed-off-by: Andreas Rheinhardt > > LGTM, but it is not my area of expertise. > > Regards, > Will apply it tomorrow unless there are objections. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
On Sat, 14 Aug 2021, at 11:26, Nicolas George wrote: > Hendrik Leppkes (12021-08-14): > > I can only judge based on past discussion, and have no insight into > > those that have never taken part in it. > > > > One more factor to consider in this line of thought however is, as > > Ronald already stated as well, how many developers might have > > contributed more, be it in reviews or actual changes, if this process > > was made easier for them? > > I don't think this part should be entirely ignored, since multiple > > seasoned developers have stated such an opinion before. > > I agree. But it is important to remember that before seriously > considering any deep change, it would be necessary to actively poll the > silent individual-minority-work-majority. That's why we have a general assembly of developers who can do a vote. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
August 14, 2021 12:40 PM, "Jean-Baptiste Kempf" wrote: > On Sat, 14 Aug 2021, at 03:13, Soft Works wrote: > >> The continuing attempt to declare developers who are favoring modern >> workflows and tooling as newbies and unexperienced is a really disgusting >> rhetoric. > > I agree. > > Very complex projects, more complex than FFmpeg are on GitHub and Gitlab and > survive very well. > It is a question of preference, absolutely not of skillz nor seniority. Exactly. Like i said, game engines and web browsers (most complex projects out there in my opinion) are all hosted on these platforms and are doing well. > > For your data point, dav1d is developed without mailing list, and has managed > to ship a ton of code > in 2years. VLC moved from mailing lists (used for 20 years) to Gitlab and > it’s mostly doing fine. > I mentioned dav1d as one example of multimedia software using gitlab and doing well > All options are fine, but are unrelated to skills. > That's what everyone here has been trying to say. > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Subject: [PATCH] Cleanup code in truemotion1 decoder
August 14, 2021 7:56 AM, "Nicolas George" wrote: > ffmpegandmahanstreamer (12021-08-14): > >> I top post only when i want to reply to the message as a whole. > > The rules of the list are clear: DO NOT TOP-POST The rules of the list also say you should be mean to others. > >> Bottom (literally, like way bottom) posting is worse than top posting, >> because then you need to >> scroll all the way down. > > Then be extra-respectful of your peers and trim your quote, just like I > did. > Why does it matter to you so much anyway? I don't really care about it, if the rules say dont top post, i wont, but again if i do it once in a while it doesnt make big difference. >> Hence why top-posting was invented > > Top-posting was not invented, it originally was just laziness and > ignorance by people discovering e-mail without being taught. > Not true. > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
August 14, 2021 12:47 PM, "Nicolas George" wrote: > Jean-Baptiste Kempf (12021-08-14): > >> The continuing attempt to declare developers who are favoring modern >> workflows and tooling as newbies and unexperienced is a really disgusting >> rhetoric. >> I agree. > > Good thing it is not what I wrote, then. I am a little disappointed that > you would make a judgement like that without reading carefully and > realizing that Soft Works has turned my position on its head. The real person winning here is Soft Works. He must be laughing right now. > > My statement is: newbies ⇒ like newfangled tools. > > My statement never was: like newfangled tools ⇒ newbies. > Ah, your math degree coming into work here - "if and only if" ;) Dont make broad generalizations however. > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
August 14, 2021 12:53 PM, "Nicolas George" wrote: > Diederick C. Niehorster (12021-08-14): > >> Is there a mechanism to trigger such a vote? I hope the core developers >> have one soon so the project can get moving on this. > > There is a mechanism. But as I explained there: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283705.html > > for this kind of question a simple one person = one vote system would be > a grave mistake. This kind of decision has to be taken by weighing > opinions by how much developers are impacted. > Careful there. Don't you remember anything about the libav split? > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
August 14, 2021 1:01 PM, "Nicolas George" wrote: > ffmpegandmahanstreamer (12021-08-14): > >> The real person winning here is Soft Works. He must be laughing right now. >> >> Ah, your math degree coming into work here - "if and only if" ;) >> Dont make broad generalizations however. >> >> Careful there. Don't you remember anything about the libav split? > > Do you have a point, or are you just trying to make the discussion more > unpleasant than it already is? > I've made my point. The people have spoken. Some multiple times. The point is you are the only one against the change, the consensus all seems to be in favor of Soft's proposal. And instead of trying to attack his approach on the method, you attack the people behind it (calling them newbies and unexperienced). We need to focus our efforts on development. Bug fixes, new codecs, etc... are what is truly important. While we're arguing, Gstreamer is developing. So lets stop with the arguments and get back to what we know to do best: make one of the best multimedia frameworks in the world. If we can bring new people in by adding this, thats great. It will only help FFMpeg in the long term. People that find the ML culture hard just won't contribute to ffmpeg, they'll contribute to something else like dav1d or vlc or even mpv which are similar overlaps with ffmpeg and are all on gitlab/hub/graphical platforms. > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
> -Original Message- > From: ffmpeg-devel On Behalf Of Ronald S. > Bultje > Sent: Saturday, 14 August 2021 19:32 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with > GitHub > > I'm not sure I support it, I'd have to look closely. I understand the > appeal of "dev env wrappers" for drive-by development and would encourage > it for that, but I'm not sure I would use it myself unless adopted > project-wide. Using a wrapper is always a somewhat suboptimal experience. I would see it in a slightly different way: it would surely start as an experiment initially, but will quickly become something like a trial without obligations. It allows to step with one foot into GitHub, experience how it works out and see how it will get used and adopted by developers, even though it might not work in all details like with a full migration. But at the same time it avoids doing a full migration from one day to another. It doesn't require a consensus decision and it doesn't require a vote or poll. It can just be opened up as an option to try out, but it doesn't need to stay like this forever. The outcome will be open: it could either be abandoned at some point or it could end up in a full migration. Thinking it the other way round: assume there would be a decision to migrate to GitHub. How could such kind of migration be done smoothly? There are a lot of (partially) good and interesting patches left on patchwork and a hard transition would cause a lot of trouble and dissatisfaction. Essentially - even with an upfront decision to move to GitHub, that suggestion that I have made would still be a good way for making the transition. I just think that starting into something without needing to make hard commitments might be a way that would cause less contradiction, disagreement and dispute. softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add SMC encoder
On 8/14/2021 1:55 PM, Paul B Mahol wrote:
+static int smc_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
+const AVFrame *frame, int *got_packet)
+{
+SMCContext *s = avctx->priv_data;
+const AVFrame *pict = frame;
+uint8_t *pal;
+int ret;
+
+ret = ff_alloc_packet(avctx, pkt, 8LL * avctx->height * avctx->width);
+if (ret < 0)
+return ret;
+
+if (avctx->gop_size == 0 || !s->prev_frame->data[0] ||
+(avctx->frame_number % avctx->gop_size) == 0) {
+s->key_frame = 1;
+} else {
+s->key_frame = 0;
+}
+
+bytestream2_init_writer(&s->pb, pkt->data, pkt->size);
+
+bytestream2_put_be32(&s->pb, 0x00);
+
+if (!s->prev_frame->data[0]) {
+s->first_frame = 1;
+s->prev_frame->format = pict->format;
+s->prev_frame->width = pict->width;
+s->prev_frame->height = pict->height;
+ret = av_frame_get_buffer(s->prev_frame, 0);
This is unnecessary. You're allocating a buffer you'll not use just so
for the next frame the !s->prev_frame->data[0] check above will evaluate
to false.
Get rid of s->first_frame and just look for s->prev_frame->data[0] in
smc_encode_stream() to know if you need to use a previous frame or not.
When you process the second one you'll have called av_frame_ref() on
s->prev_frame at the end of the first, so it will be populated.
+if (ret < 0)
+return ret;
+} else {
+s->first_frame = 0;
+}
+
+pal = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE, AVPALETTE_SIZE);
+memcpy(pal, frame->data[1], AVPALETTE_SIZE);
+
+smc_encode_stream(s, pict);
+
+av_shrink_packet(pkt, bytestream2_tell_p(&s->pb));
+
+pkt->data[0] = 0x0;
+
+// write chunk length
+AV_WB24(pkt->data + 1, pkt->size);
+
+av_frame_unref(s->prev_frame);
+ret = av_frame_ref(s->prev_frame, frame);
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "cannot add reference\n");
+return ret;
+}
+
+if (s->key_frame)
+pkt->flags |= AV_PKT_FLAG_KEY;
+
+*got_packet = 1;
+
+return 0;
+}
+
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
> -Original Message- > From: ffmpeg-devel On Behalf Of Nicolas > George > Sent: Saturday, 14 August 2021 08:31 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with > GitHub > > Soft Works (12021-08-14): > > The continuing attempt to declare developers who are favoring modern > > workflows and tooling as newbies and unexperienced is a really disgusting > > rhetoric. > > Your misrepresentation of my statements is the really disgusting > rhetoric here. > > What I have said is that newbies tend to favor the newfangled tools > because they offer an easier learning curve at the beginning. > > I have not said that those who favor the newfangled are newbies. Yes, you didn’t say that. But you clearly created the impression by using all those many newbie-synonyms in connection with GitHub and all the "positive" words (core devs, experienced developers, etc.) in connection with the mailing list. This is a well-known - rhetorical - strategy. qed. (actually it's also a brain-washing technique when used intensely and repeatingly) > I also resent your recent "Thanks for a reasonable reply this time.", as > it implies my other replies were unreasonable. I have used irony and > imaged language, but at no point have I being unreasonable. Your failed attempt to insult me (stating I should better do some PHP), do you consider that "reasonable"? Speaking of "reasonable" - I'm reading the ffmpeg ML every day since July 2016 and I've read all of your ridiculous conversations with Paul... softworkz PS: To avoid misinterpretation - I don't think that one could be blamed more than the other one. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
> -Original Message- > From: ffmpeg-devel On Behalf Of Soft Works > Sent: Sunday, 15 August 2021 04:12 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with > GitHub > > > Speaking of "reasonable" - I'm reading the ffmpeg ML every day since > July 2016 and I've read all of your ridiculous conversations with > Paul... > > softworkz > > > PS: To avoid misinterpretation - I don't think that one could be > blamed more than the other one. Sorry - should read: I don't think that one could be blamed LESS than the other one. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Cleanup avmv on errors
Marton Balint:
>
>
> On Sun, 15 Aug 2021, "zhilizhao(赵志立)" wrote:
>
>>
>>
>>> On Aug 14, 2021, at 11:52 PM, Michael Niedermayer
>>> wrote:
>>>
>>> On Sat, Aug 14, 2021 at 11:45:59PM +0800, "zhilizhao(赵志立)" wrote:
> On Aug 14, 2021, at 11:07 PM, Michael Niedermayer
> wrote:
>
> Fixes: Assertion failure
> Fixes:
> 36359/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6733238591684608
>
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/snowdec.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
> index 1355ae6ed1..7ef28c4899 100644
> --- a/libavcodec/snowdec.c
> +++ b/libavcodec/snowdec.c
> @@ -499,7 +499,7 @@ static int decode_frame(AVCodecContext *avctx,
> void *data, int *got_frame,
> s->avmv_index = 0;
>
> if ((res = decode_blocks(s)) < 0)
> - return res;
> + goto fail;
>
> for(plane_index=0; plane_index < s->nb_planes; plane_index++){
> Plane *p= &s->plane[plane_index];
> @@ -618,11 +618,11 @@ static int decode_frame(AVCodecContext
> *avctx, void *data, int *got_frame,
> AVFrameSideData *sd;
>
> sd = av_frame_new_side_data(picture,
> AV_FRAME_DATA_MOTION_VECTORS, s->avmv_index * sizeof(AVMotionVector));
> - if (!sd)
> - return AVERROR(ENOMEM);
> - memcpy(sd->data, s->avmv, s->avmv_index *
> sizeof(AVMotionVector));
> + if (sd)
> + memcpy(sd->data, s->avmv, s->avmv_index *
> sizeof(AVMotionVector));
res is not assigned to AVERROR(ENOMEM), so the error is just being
ignored. Is it intentional?
>>>
>>> the frame was decoded correctly, just exporting the vectors failed.
>>> Should we fail and then discard the frame as a result ?
>>> It seemed better to not fail here, but i was a bit undecided here,
>>> what do others think ?
>>> so yes it was intentional but maybe it should be done differently,
>>> depends
>>> on what people prefer ...
>>
>> Understood. In the ENOMEM case, I prefer simple logic than do the best
>> effort
>> to give the user a partly success result. Somebody who don’t get the
>> idea may
>> try to ‘fix’ it again. Although I don’t have a strong opinion on that.
>
> IMHO ignoring ENOMEM errors is just bad practice. Every ENOMEM error
> should be propagated back to the user.
>
I agree. After all, this side data is only exported if the user opted to
do so by setting the appropriate flag, so we already know that the user
is really interested in this.
Obviously the assert that is hit is the av_assert0(!s->avmv), isn't it?
This could be fixed by not throwing away the buffer for each frame, but
by using av_fast_malloc.
- Andreas
PS: Does clusterfuzz now also test memory failures and the related error
paths? Awesome!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
> -Original Message- > From: ffmpeg-devel On Behalf Of > ffmpegandmahanstreamer > Sent: Saturday, 14 August 2021 18:55 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with > GitHub > > August 14, 2021 12:47 PM, "Nicolas George" wrote: > > > Jean-Baptiste Kempf (12021-08-14): > > > >> The continuing attempt to declare developers who are favoring modern > >> workflows and tooling as newbies and unexperienced is a really disgusting > >> rhetoric. > >> I agree. > > > > Good thing it is not what I wrote, then. I am a little disappointed that > > you would make a judgement like that without reading carefully and > > realizing that Soft Works has turned my position on its head. > > The real person winning here is Soft Works. He must be laughing right now. I don't have the slightest idea what I would have won, neither what should make me laugh. I like to laugh, but only about funny things or my own jokes, even when they aren't funny ;-) @ffmpegandmahanstreamer - I appreciate your support on my suggestion and I value your personal opinion as well each other ones opinion. Though, I don’t think that this conversation needs extra moderation messages just repeating what others have posted before or speculating what others might think or do. To be honest, I don't feel comfortable reading that I would be winning or laughing. Thanks for your understanding, softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub
> -Original Message- > From: ffmpeg-devel On Behalf Of Andriy > Gelman > Sent: Saturday, 14 August 2021 14:48 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with > GitHub > > On Fri, 13. Aug 23:53, Soft Works wrote: > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Michael Niedermayer > > > Sent: Friday, 13 August 2021 20:10 > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration > > > with GitHub > > > > > What I'm still thinking about is the part about hooking into ML > > e-mail reception. They are using https://public-inbox.org/ > > for GIT, but it would need to be hosted somewhere. > > Either I'll figure out a different way or I'll self-host it for an > > initial phase. > > > > Do you need to parse each email and then make post requests back to github? > Feel free to send me a python/shell script and I can add to the patchwork vm. Hi Andriy, Thanks for your reply, Patchwork's inbox would be a perfect location to trigger this. I'll analyze the code and contact you off-list, cc-ing Michael (who also knows my identity) Thanks, softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
