Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/libaomenc: fix default value for row-mt option
On 29-03-2019 11:26 PM, James Almer wrote:
ffmpeg | branch: master | James Almer | Fri Mar 29 14:55:00
2019 -0300| [0856c5da0716e9c461d4f73339a2c2390d0a1162] | committer: James Almer
avcodec/libaomenc: fix default value for row-mt option
Signed-off-by: James Almer
-{ "row-mt", "Enable row based multi-threading",
OFFSET(row_mt), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, VE},
+{ "row-mt", "Enable row based multi-threading",
OFFSET(row_mt), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
{ "enable-cdef", "Enable CDEF filtering",
OFFSET(enable_cdef),AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
{ "enable-global-motion", "Enable global motion",
OFFSET(enable_global_motion), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
{ "enable-intrabc", "Enable intra block copy prediction mode",
OFFSET(enable_intrabc), AV_OPT_TYPE_BOOL, {.i64 = -1}, 0, 1, VE},
Shouldn't 'enable-intrabc ' follow the same pattern?
And what are the semantics of the user setting row_mt or enable-intrabc
as -1?
Gyan
___
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/tiff: Multi-page support
On 3/29/19, Nick Renieris wrote: > Στις Παρ, 29 Μαρ 2019 στις 11:05 π.μ., ο/η Paul B Mahol > έγραψε: >> You should also check max number of available pages. >> And issue warning if user requested more than available and than provide >> some >> page. > > Yeah, I _would_ have done that, but the images I've seen don't > actually contain the max number of pages in PageNumber[1]. > Instead, they seem to contain PageNumber[0] + 1. > Here's an example from the file I sent (generated with IrfanView): > https://i.imgur.com/CEWADrD.png > The PageNumber tag from the last IFD couldn't fit in the screenshot, > it's PageNumber[0] = 2 and PageNumber[1] = 3. OK, will apply soon. ___ 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 Amuse Graphics decoder
On 3/28/19, Paul B Mahol wrote: > This work is sponsored by VideoLAN. > > Signed-off-by: Paul B Mahol > --- Will apply soon. ___ 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] avcodec/libaomenc: fix default value for row-mt option
On Sat, Mar 30, 2019 at 16:50:52 +0530, Gyan wrote: > And what are the semantics of the user setting row_mt or enable-intrabc > as -1? The user doesn't set -1, they set 0 or 1 as bool. -1 helps to indicate that nothing was set, and - in these cases - falls back to not setting anything in the libary interface and choosing its own default. In other words, -1 helps to avoid setting a default in the options definition. Cheers, Moritz ___ 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] avcodec/libaomenc: fix default value for row-mt option
On 30-03-2019 06:09 PM, Moritz Barsnick wrote: On Sat, Mar 30, 2019 at 16:50:52 +0530, Gyan wrote: And what are the semantics of the user setting row_mt or enable-intrabc as -1? The user doesn't set -1, they set 0 or 1 as bool. -1 helps to indicate that nothing was set, and - in these cases - falls back to not setting anything in the libary interface and choosing its own default. The commit changed both the default value as well as the allowed range. The option value parser evaluates AV_OPT_TYPE_BOOL same as AV_OPT_TYPE_INT, so user inputs aren't reduced to a binary evaluation. The latter means that the user can assertively set -1, as opposed to it just being the ctx inited value. The same wasn't done for enable-intrabc. I was wondering if the user may ever want to set -1 manually, and if so, what that meant. Gyan ___ 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] avcodec/libaomenc: fix default value for row-mt option
On Sat, Mar 30, 2019 at 2:52 PM Gyan wrote: > > > > On 30-03-2019 06:09 PM, Moritz Barsnick wrote: > > On Sat, Mar 30, 2019 at 16:50:52 +0530, Gyan wrote: > >> And what are the semantics of the user setting row_mt or enable-intrabc > >> as -1? > > The user doesn't set -1, they set 0 or 1 as bool. -1 helps to indicate > > that nothing was set, and - in these cases - falls back to not setting > > anything in the libary interface and choosing its own default. > > The commit changed both the default value as well as the allowed range. > The option value parser evaluates AV_OPT_TYPE_BOOL same as > AV_OPT_TYPE_INT, so user inputs aren't reduced to a binary evaluation. > The latter means that the user can assertively set -1, as opposed to it > just being the ctx inited value. The same wasn't done for > enable-intrabc. I was wondering if the user may ever want to set -1 > manually, and if so, what that meant. > -1 means "auto" - in this case, let the encoder decide, if possible. AV_OPT_TYPE_BOOL is not just a simple alias for INT, because it accepts a variety of string options as well. -1 = auto 0 = false,n,no,disable,disabled,off 1 = true,y,yes,enable,enabled,on In addition to also accepting any numeric input. - 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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage
Am 23.03.19 um 16:11 schrieb Thilo Borgmann: > Hi, > >> FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany! >> This "Chemnitzer Linux Tage" will take place on 16th and 17th of March. >> You can find more details on their homepage: >> >> https://chemnitzer.linux-tage.de/2019/en/ > > we returned from last weekends CLT. We again had a great time there with a > lot of interested users and even some involvement in the capturing and > streaming of the talks. > > We presented the usual demos showing filters and capturing. We could acquire > new hardware for the project during the fair, so we'll be ablte to > significantly update our presentation for the next conference to run on that > hardware. > > Hotel and transportation has been handled like in the years before, so there > will be some requests about that soon. For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me from Berlin to Chemnitz. Lost 1/2 receipts, which makes it cheaper this year. Sending the receipt to Stefano. Thanks, Thilo ___ 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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage
Am 30.03.19 um 16:04 schrieb Thilo Borgmann: > Am 23.03.19 um 16:11 schrieb Thilo Borgmann: >> Hi, >> >>> FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany! >>> This "Chemnitzer Linux Tage" will take place on 16th and 17th of March. >>> You can find more details on their homepage: >>> >>> https://chemnitzer.linux-tage.de/2019/en/ >> >> we returned from last weekends CLT. We again had a great time there with a >> lot of interested users and even some involvement in the capturing and >> streaming of the talks. >> >> We presented the usual demos showing filters and capturing. We could acquire >> new hardware for the project during the fair, so we'll be ablte to >> significantly update our presentation for the next conference to run on that >> hardware. >> >> Hotel and transportation has been handled like in the years before, so there >> will be some requests about that soon. > > For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me from > Berlin to Chemnitz. > Lost 1/2 receipts, which makes it cheaper this year. Correction, it is actually just 55,89 EUR. -Thilo > Sending the receipt to Stefano. > > Thanks, > Thilo > ___ > 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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage
Hi, On Sat, Mar 30, 2019 at 11:04 AM Thilo Borgmann wrote: > Am 23.03.19 um 16:11 schrieb Thilo Borgmann: > > Hi, > > > >> FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany! > >> This "Chemnitzer Linux Tage" will take place on 16th and 17th of March. > >> You can find more details on their homepage: > >> > >> https://chemnitzer.linux-tage.de/2019/en/ > > > > we returned from last weekends CLT. We again had a great time there with > a lot of interested users and even some involvement in the capturing and > streaming of the talks. > > > > We presented the usual demos showing filters and capturing. We could > acquire new hardware for the project during the fair, so we'll be ablte to > significantly update our presentation for the next conference to run on > that hardware. > > > > Hotel and transportation has been handled like in the years before, so > there will be some requests about that soon. > > For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me > from Berlin to Chemnitz. > Lost 1/2 receipts, which makes it cheaper this year. Can't the foundation just reimburse you anyway for the expense-with-no-receipt? This feels kind of silly. (I don't know if this is a foundation rule or not.) 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] avcodec: add Amuse Graphics decoder
Em qui, 28 de mar de 2019 às 18:12, Paul B Mahol escreveu:
>
> +static int decode_motion_vectors(AVCodecContext *avctx, GetBitContext *gb)
> +{
> +AGMContext *s = avctx->priv_data;
> +int nb_mvs = ((avctx->height + 15) >> 4) * ((avctx->width + 15) >> 4);
> +int ret, skip = 0, value, end;
is that line intended?
___
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 Amuse Graphics decoder
On 3/30/19, Pedro Arthur wrote:
> Em qui, 28 de mar de 2019 às 18:12, Paul B Mahol
> escreveu:
>>
>> +static int decode_motion_vectors(AVCodecContext *avctx, GetBitContext
>> *gb)
>> +{
>> +AGMContext *s = avctx->priv_data;
>> +int nb_mvs = ((avctx->height + 15) >> 4) * ((avctx->width + 15) >>
>> 4);
>> +int ret, skip = 0, value, end;
>
> is that line intended?
Yes, what is wrong with it?
___
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 Amuse Graphics decoder
Em sáb, 30 de mar de 2019 às 12:43, Paul B Mahol escreveu:
>
> On 3/30/19, Pedro Arthur wrote:
> > Em qui, 28 de mar de 2019 às 18:12, Paul B Mahol
> > escreveu:
> >>
> >> +static int decode_motion_vectors(AVCodecContext *avctx, GetBitContext
> >> *gb)
> >> +{
> >> +AGMContext *s = avctx->priv_data;
> >> +int nb_mvs = ((avctx->height + 15) >> 4) * ((avctx->width + 15) >>
> >> 4);
> >> +int ret, skip = 0, value, end;
> >
> > is that line intended?
>
> Yes, what is wrong with it?
Just seemed unusual.
> ___
> 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] Reimbursement request for LDP
On date Friday 2019-02-22 22:37:34 +0100, Michael Niedermayer encoded: > On Sun, Feb 10, 2019 at 07:53:50PM +0100, Thilo Borgmann wrote: > > Hi, > > > > I'd like to request reimbursement for my travel to the LDP [1]. > > > > Accomodation was sponsored by the LDP team, so travel costs are rather low: > > 21.90€ > > LGTM Approved, sorry for the delay. -- FFmpeg = Fast and Fundamental Magic Proud Evanescent Ghost ___ 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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage
On date Saturday 2019-03-30 11:19:11 -0400, Ronald S. Bultje encoded: > Hi, > > On Sat, Mar 30, 2019 at 11:04 AM Thilo Borgmann > wrote: [...] > > For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me > > from Berlin to Chemnitz. > > Lost 1/2 receipts, which makes it cheaper this year. > > > Can't the foundation just reimburse you anyway for the > expense-with-no-receipt? This feels kind of silly. (I don't know if this is > a foundation rule or not.) Yes it can (and in the past we got refund even in case there was a missing receipt), even though it's recommended to provide them. For the return travel we can account the same amount as for the outward one. -- FFmpeg = Freak & Faithful Magical Pure Enlightened Governor ___ 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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage
On date Saturday 2019-03-30 16:04:23 +0100, Thilo Borgmann encoded: > Am 23.03.19 um 16:11 schrieb Thilo Borgmann: > > Hi, > > > >> FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany! > >> This "Chemnitzer Linux Tage" will take place on 16th and 17th of March. > >> You can find more details on their homepage: > >> > >> https://chemnitzer.linux-tage.de/2019/en/ > > > > we returned from last weekends CLT. We again had a great time there with a > > lot of interested users and even some involvement in the capturing and > > streaming of the talks. > > > > We presented the usual demos showing filters and capturing. We could > > acquire new hardware for the project during the fair, so we'll be ablte to > > significantly update our presentation for the next conference to run on > > that hardware. > > > > Hotel and transportation has been handled like in the years before, so > > there will be some requests about that soon. > > For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me from > Berlin to Chemnitz. > Lost 1/2 receipts, which makes it cheaper this year. > > Sending the receipt to Stefano. LGTM on all the requests, pending approval from Michael. -- FFmpeg = Fundamental & Fascinating MultiPurpose Educated Gospel ___ 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/mxfenc: support XAVC long gop
Hi Thomas,
> On Mar 29, 2019, at 1:11 PM, Thomas Mundt wrote:
>
>
> […]
>
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x04
>> }, 568832, 122, 0, 1 }, // AVC High 422 Intra RP2027 Class 100 1080/25p
>> +{{
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x08
>> }, 236544, 122, 0, 1 }, // AVC High 422 Intra RP2027 Class 100 720/59.94p
>> +{{
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x09
>> }, 284672, 122, 0, 1 }, // AVC High 422 Intra RP2027 Class 100 720/50p
>>
>
> Maybe i miss something, but doesn´t the setting of the profile for all AVC
> Intra codec ULs make the for-loop to always select the last AVC Intra
> codec UL (720/50p) for AVC High 422 Intra?
The frame size check prevents that.
—
Baptiste Coudurier
signature.asc
Description: Message signed with OpenPGP
___
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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage
Am 30.03.19 um 17:41 schrieb Stefano Sabatini: > On date Saturday 2019-03-30 11:19:11 -0400, Ronald S. Bultje encoded: >> Hi, >> >> On Sat, Mar 30, 2019 at 11:04 AM Thilo Borgmann >> wrote: > [...] >>> For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me >>> from Berlin to Chemnitz. >>> Lost 1/2 receipts, which makes it cheaper this year. >> >> > >> Can't the foundation just reimburse you anyway for the >> expense-with-no-receipt? This feels kind of silly. (I don't know if this is >> a foundation rule or not.) > > Yes it can (and in the past we got refund even in case there was a > missing receipt), even though it's recommended to provide them. > > For the return travel we can account the same amount as for the > outward one. Sounds fair to me. Though, if Stefano encounters any burdon doing so, I'm fine with receipt-only refunding. I'll leave it to you, Stefano. Thanks! -Thilo ___ 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] lavf/movenc: fix tmcd writing for non-MP4/MOV modes
Regression since, I believe, 42cb050a05
From 22620ccaae074700c8c470a78daa7682638cecbf Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Sun, 31 Mar 2019 00:00:50 +0530
Subject: [PATCH] lavf/movenc: fix tmcd writing for non-MP4/MOV modes
write_tmcd allows tmcd track to be created with any mode but in
mov_write_header, index for first tmcd track is only set for modes
MP4 or MOV, causing a crash if tmcd creation is attempted with other
modes.
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 8969d5b170..2d53079cb0 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6381,7 +6381,7 @@ static int mov_write_header(AVFormatContext *s)
nb_tracks++;
}
-if (mov->mode == MODE_MOV || mov->mode == MODE_MP4)
+if (mov->nb_meta_tmcd)
tmcd_track = nb_tracks;
for (i = 0; i < s->nb_streams; i++) {
--
2.19.2___
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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage
On 30.03.19 16:19, Ronald S. Bultje wrote: Hotel and transportation has been handled like in the years before, so there will be some requests about that soon. For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me from Berlin to Chemnitz. Lost 1/2 receipts, which makes it cheaper this year. Can't the foundation just reimburse you anyway for the expense-with-no-receipt? This feels kind of silly. (I don't know if this is a foundation rule or not.) +1 I can confirm that Thilo was there and an estimation of additional 60 Euro should be more than okay. Best regards, Thomas. ___ 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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage
On Sat, Mar 30, 2019 at 05:44:34PM +0100, Stefano Sabatini wrote: > On date Saturday 2019-03-30 16:04:23 +0100, Thilo Borgmann encoded: > > Am 23.03.19 um 16:11 schrieb Thilo Borgmann: > > > Hi, > > > > > >> FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany! > > >> This "Chemnitzer Linux Tage" will take place on 16th and 17th of March. > > >> You can find more details on their homepage: > > >> > > >> https://chemnitzer.linux-tage.de/2019/en/ > > > > > > we returned from last weekends CLT. We again had a great time there with > > > a lot of interested users and even some involvement in the capturing and > > > streaming of the talks. > > > > > > We presented the usual demos showing filters and capturing. We could > > > acquire new hardware for the project during the fair, so we'll be ablte > > > to significantly update our presentation for the next conference to run > > > on that hardware. > > > > > > Hotel and transportation has been handled like in the years before, so > > > there will be some requests about that soon. > > > > For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me > > from Berlin to Chemnitz. > > Lost 1/2 receipts, which makes it cheaper this year. > > > > Sending the receipt to Stefano. > > LGTM on all the requests, pending approval from Michael. If there are no objections from anyone then LGTM as well (we should always give a week or 2 time for people to raise objections, which is why i tend to not approve these requests immedeatly but then i tend to forget ...) thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope 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/6] compat/avisynth: update headers
As part of the update, it is now possible to test 32-bit GCC builds
of AviSynth+ with FFmpeg by using the AVS_WIN32_GCC32 define. Due to
different calling conventions between MSVC and GCC regarding 32-bit
Windows, this is unfortunately necessary.
---
compat/avisynth/avisynth_c.h | 510 ---
compat/avisynth/avs/capi.h | 44 ++-
compat/avisynth/avs/config.h | 17 +-
compat/avisynth/avs/types.h | 6 +
4 files changed, 415 insertions(+), 162 deletions(-)
diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
index 605b92ae62..8d17125adc 100644
--- a/compat/avisynth/avisynth_c.h
+++ b/compat/avisynth/avisynth_c.h
@@ -34,6 +34,22 @@
// NOTE: this is a partial update of the Avisynth C interface to recognize
// new color spaces added in Avisynth 2.60. By no means is this document
// completely Avisynth 2.60 compliant.
+// 170103: added new CPU constants (FMA4, AVX512xx)
+// 171102: define SIZETMOD. do not use yet, experimental. Offsets are size_t
instead of int. Affects x64.
+// 171106: avs_get_row_size calls into avs_get_row_size_p, instead of direct
field access
+// 171106: avs_get_height calls into avs_get_row_size_p, instead of direct
field access
+// 180524: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
+// 180524: avs_is_same_colorspace VideoInfo parameters to const
+// 181230: Readability: functions regrouped to mix less AVSC_API and
AVSC_INLINE, put together Avisynth+ specific stuff
+// 181230: use #ifndef AVSC_NO_DECLSPEC for AVSC_INLINE functions which are
calling API functions
+// 181230: comments on avs_load_library (helper for loading API entries
dynamically into a struct using AVSC_NO_DECLSPEC define)
+// 181230: define alias AVS_FRAME_ALIGN as FRAME_ALIGN
+// 181230: remove unused form of avs_get_rowsize and avs_get_height (kept
earlier for reference)
+// 190104: avs_load_library: smart fallback mechanism for Avisynth+ specific
functions:
+// if they are not loadable, they will work in a classic Avisynth
compatible mode
+// Example#1: e.g. avs_is_444 will call the existing avs_is_yv24
instead
+// Example#2: avs_bits_per_component will return 8 for all colorspaces
(Classic Avisynth supports only 8 bits/pixel)
+// Thus the Avisynth+ specific API functions are safely callable even
when connected to classic Avisynth DLL
#ifndef __AVISYNTH_C__
#define __AVISYNTH_C__
@@ -42,7 +58,7 @@
#include "avs/capi.h"
#include "avs/types.h"
-
+#define AVS_FRAME_ALIGN FRAME_ALIGN
/
//
// Constants
@@ -124,7 +140,7 @@ enum {
AVS_CS_GENERIC_YUVA444 = AVS_CS_PLANAR | AVS_CS_YUVA | AVS_CS_VPLANEFIRST
| AVS_CS_SUB_HEIGHT_1 | AVS_CS_SUB_WIDTH_1 }; // 4:4:4:A planar
- // Specific colorformats
+ // Specific color formats
enum {
AVS_CS_UNKNOWN = 0,
AVS_CS_BGR24 = AVS_CS_RGB_TYPE | AVS_CS_BGR | AVS_CS_INTERLEAVED,
@@ -134,18 +150,18 @@ enum {
// AVS_CS_I420 = 1<<4 Reserved
AVS_CS_RAW32 = 1<<5 | AVS_CS_INTERLEAVED,
- AVS_CS_YV24 = AVS_CS_GENERIC_YUV444 | AVS_CS_SAMPLE_BITS_8, // YVU 4:4:4
planar
- AVS_CS_YV16 = AVS_CS_GENERIC_YUV422 | AVS_CS_SAMPLE_BITS_8, // YVU 4:2:2
planar
- AVS_CS_YV12 = AVS_CS_GENERIC_YUV420 | AVS_CS_SAMPLE_BITS_8, // YVU 4:2:0
planar
+ AVS_CS_YV24 = AVS_CS_GENERIC_YUV444 | AVS_CS_SAMPLE_BITS_8, // YUV 4:4:4
planar
+ AVS_CS_YV16 = AVS_CS_GENERIC_YUV422 | AVS_CS_SAMPLE_BITS_8, // YUV 4:2:2
planar
+ AVS_CS_YV12 = AVS_CS_GENERIC_YUV420 | AVS_CS_SAMPLE_BITS_8, // YUV 4:2:0
planar
AVS_CS_I420 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 |
AVS_CS_UPLANEFIRST | AVS_CS_SUB_HEIGHT_2 | AVS_CS_SUB_WIDTH_2, // YUV 4:2:0
planar
AVS_CS_IYUV = AVS_CS_I420,
- AVS_CS_YV411 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 |
AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_1 | AVS_CS_SUB_WIDTH_4, // YVU 4:1:1
planar
- AVS_CS_YUV9 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 |
AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_4 | AVS_CS_SUB_WIDTH_4, // YVU 4:1:0
planar
+ AVS_CS_YV411 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 |
AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_1 | AVS_CS_SUB_WIDTH_4, // YUV 4:1:1
planar
+ AVS_CS_YUV9 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 |
AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_4 | AVS_CS_SUB_WIDTH_4, // YUV 4:1:0
planar
AVS_CS_Y8= AVS_CS_GENERIC_Y | AVS_CS_SAMPLE_BITS_8, // Y 4:0:0
planar
//-
// AVS16: new planar constants go live! Experimental PF 160613
- // 10-12-14 bit + planar RGB + BRG48/64 160725
+ // 10-12-14-16 bit + planar RGB + BGR48/64 160725
AVS_CS_YUV444P10 = AVS_CS_GENERIC_YUV444 | AVS_CS_SAMPLE_BITS_10, // YUV
4:4:4 10bit samples
AVS_CS_YUV422P10 = AVS_CS_GENERIC_YUV422 | AVS_CS_SAMPLE_BITS_10, // YUV
4:2:2 10bit samples
AVS_CS_YUV420P10 = AVS_CS_GENERIC_YUV420 | AVS_CS_SAMPLE_BITS_10, // YUV
4:2:0 10bit samples
@@ -246,9 +262,9 @
[FFmpeg-devel] [PATCH 6/6] avisynth: adapt 239d02eff3ffe9f7d40caa21dde50fb4a0e94c24 to dlsym
This commit was merged in a couple years ago as a no-op because we had already switched from GetProcAddress to dlsym some time before that. However, not applying the actual cast causes warnings about FARPROC and when attempting to build FFmpeg in MSVC with AviSynth-GCC 32-bit compatibility, those FARPROC warnings turn into FARPROC errors. --- libavformat/avisynth.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c index 2181510c2f..5dfe94ae0c 100644 --- a/libavformat/avisynth.c +++ b/libavformat/avisynth.c @@ -123,7 +123,8 @@ static av_cold int avisynth_load_library(void) return AVERROR_UNKNOWN; #define LOAD_AVS_FUNC(name, continue_on_fail) \ -avs_library.name = dlsym(avs_library.library, #name); \ +avs_library.name = (name ## _func) \ + dlsym(avs_library.library, #name); \ if (!continue_on_fail && !avs_library.name)\ goto fail; -- 2.19.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 3/5] doc/general.texi: remove note about regressed AviSynth+ header
On 3/28/2019 11:41 PM, Stephen Hutchinson wrote: On 3/28/2019 8:29 AM, Gyan wrote: So, there is no permutation of ffmpeg master & avisynth+ that can lead to issues with MSVC builds? If so, LGTM. As a test, I tried building FFmpeg with MSVC (which I never do since I always cross-compile from Linux) and --enable-avisynth, and spotted a couple things in the patches I'll need to address, one of which might be better to squash into the header update patch. I've uploaded the amended 1st patch and added a 6th to deal with the issues I encountered when testing the 'build FFmpeg with MSVC' route. Since git send-email (or Gmail) screwed up the threading when I sent these the first time, this is the proper order: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241922.html <-fixed header update patch http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241502.html <-enabling the additional pix_fmts; nothing has changed on this one http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241507.html <-removing the header warning in the docs; nothing has changed on this one http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241504.html <-updating the project link to point to the AviSynth wiki page on AviSynth+; nothing has changed on this one http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241505.html <-usage note about 32-bit GCC builds of AviSynth+ and the AVSC_WIN32_GCC32 switch; nothing has changed on this one http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241923.html <-new (well, technically old) patch to fix FARPROC warnings/build errors ___ 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 v4] avformat/http, icecast, rtsp: Add option to disable send-100-continue
On Fri, Mar 29, 2019 at 03:59:21PM -0700, Jun Li wrote:
> On Wed, Mar 27, 2019 at 11:27 PM Jun Li wrote:
>
> >
> >
> > On Mon, Mar 25, 2019 at 2:42 PM Jun Li wrote:
> >
> >>
> >>
> >> On Fri, Mar 22, 2019 at 4:12 PM Jun Li wrote:
> >>
> >>> The current setting for send-100-continue option is either
> >>> enabled if applicable or forced enabled, no option to force
> >>> disable the header. This change is to expand the option setting
> >>> to provide more flexibility, which is useful for rstp case.
> >>> ---
> >>> libavformat/http.c| 28 +---
> >>> libavformat/icecast.c | 2 +-
> >>> libavformat/rtsp.c| 1 +
> >>> 3 files changed, 19 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/libavformat/http.c b/libavformat/http.c
> >>> index 74d743850d..5a937994cf 100644
> >>> --- a/libavformat/http.c
> >>> +++ b/libavformat/http.c
> >>> @@ -113,6 +113,7 @@ typedef struct HTTPContext {
> >>> uint8_t *inflate_buffer;
> >>> #endif /* CONFIG_ZLIB */
> >>> AVDictionary *chained_options;
> >>> +/* -1 = try to send if applicable, 0 = always disabled, 1 = always
> >>> enabled */
> >>> int send_expect_100;
> >>> char *method;
> >>> int reconnect;
> >>> @@ -155,7 +156,7 @@ static const AVOption options[] = {
> >>> { "auth_type", "HTTP authentication type",
> >>> OFFSET(auth_state.auth_type), AV_OPT_TYPE_INT, { .i64 = HTTP_AUTH_NONE },
> >>> HTTP_AUTH_NONE, HTTP_AUTH_BASIC, D | E, "auth_type"},
> >>> { "none", "No auth method set, autodetect", 0, AV_OPT_TYPE_CONST, {
> >>> .i64 = HTTP_AUTH_NONE }, 0, 0, D | E, "auth_type"},
> >>> { "basic", "HTTP basic authentication", 0, AV_OPT_TYPE_CONST, {
> >>> .i64 = HTTP_AUTH_BASIC }, 0, 0, D | E, "auth_type"},
> >>> -{ "send_expect_100", "Force sending an Expect: 100-continue header
> >>> for POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1,
> >>> E
> >>> },
> >>> +{ "send_expect_100", "Force sending an Expect: 100-continue header
> >>> for POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1,
> >>> 1,
> >>> E },
> >>> { "location", "The actual location of the data received",
> >>> OFFSET(location), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D | E },
> >>> { "offset", "initial byte offset", OFFSET(off), AV_OPT_TYPE_INT64,
> >>> { .i64 = 0 }, 0, INT64_MAX, D },
> >>> { "end_offset", "try to limit the request to bytes preceding this
> >>> offset", OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D
> >>> },
> >>> @@ -1179,16 +1180,21 @@ static int http_connect(URLContext *h, const
> >>> char *path, const char *local_path,
> >>> local_path, method);
> >>> proxyauthstr = ff_http_auth_create_response(&s->proxy_auth_state,
> >>> proxyauth,
> >>> local_path, method);
> >>> -if (post && !s->post_data) {
> >>> -send_expect_100 = s->send_expect_100;
> >>> -/* The user has supplied authentication but we don't know the
> >>> auth type,
> >>> - * send Expect: 100-continue to get the 401 response including
> >>> the
> >>> - * WWW-Authenticate header, or an 100 continue if no auth
> >>> actually
> >>> - * is needed. */
> >>> -if (auth && *auth &&
> >>> -s->auth_state.auth_type == HTTP_AUTH_NONE &&
> >>> -s->http_code != 401)
> >>> -send_expect_100 = 1;
> >>> +
> >>> + if (post && !s->post_data) {
> >>> +if (s->send_expect_100 != -1) {
> >>> +send_expect_100 = s->send_expect_100;
> >>> +} else {
> >>> +send_expect_100 = 0;
> >>> +/* The user has supplied authentication but we don't know
> >>> the auth type,
> >>> + * send Expect: 100-continue to get the 401 response
> >>> including the
> >>> + * WWW-Authenticate header, or an 100 continue if no auth
> >>> actually
> >>> + * is needed. */
> >>> +if (auth && *auth &&
> >>> +s->auth_state.auth_type == HTTP_AUTH_NONE &&
> >>> +s->http_code != 401)
> >>> +send_expect_100 = 1;
> >>> +}
> >>> }
> >>>
> >>> #if FF_API_HTTP_USER_AGENT
> >>> diff --git a/libavformat/icecast.c b/libavformat/icecast.c
> >>> index c93b06b553..d2198b78ec 100644
> >>> --- a/libavformat/icecast.c
> >>> +++ b/libavformat/icecast.c
> >>> @@ -115,7 +115,7 @@ static int icecast_open(URLContext *h, const char
> >>> *uri, int flags)
> >>> av_dict_set(&opt_dict, "auth_type", "basic", 0);
> >>> av_dict_set(&opt_dict, "headers", headers, 0);
> >>> av_dict_set(&opt_dict, "chunked_post", "0", 0);
> >>> -av_dict_set(&opt_dict, "send_expect_100", s->legacy_icecast ? "0" :
> >>> "1", 0);
> >>> +av_dict_set(&opt_dict, "send_expect_100", s->legacy_icecast ? "-1"
> >>> : "1", 0);
> >>> if (NOT_EMPTY(s->content_type))
> >>> av_dict_set(&opt_dict, "conten
[FFmpeg-devel] [PATCH] prompeg_write() must report data all was written
Previously, prompeg_write() would only report to caller that bytes we
written when a FEC packet was actually created. Not all RTP packets are
expected to generate a FEC packet however, so this behavior was causing
avio to retry writing the RTP packet, eventually forcing the FEC state
machine to send a FEC packet erroneously (and so breaking out of the
retry loop).
This was resulting in incorrect FEC data being generated, and far too
many FEC packets to be sent (~100% FEC overhead).
---
libavformat/prompeg.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
index 94b556d5f1..c3bd5f1249 100644
--- a/libavformat/prompeg.c
+++ b/libavformat/prompeg.c
@@ -387,7 +387,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf,
int size) {
PrompegContext *s = h->priv_data;
uint8_t *bitstring = NULL;
int col_idx, col_out_idx, row_idx;
-int ret, written = 0;
+int ret = 0;
if (s->init && ((ret = prompeg_init(h, buf, size)) < 0))
goto end;
@@ -403,7 +403,6 @@ static int prompeg_write(URLContext *h, const uint8_t *buf,
int size) {
if (!s->first || s->packet_idx > 0) {
if ((ret = prompeg_write_fec(h, s->fec_row, PROMPEG_FEC_ROW)) < 0)
goto end;
-written += ret;
}
memcpy(s->fec_row->bitstring, bitstring, s->bitstring_size);
s->fec_row->sn = AV_RB16(buf + 2);
@@ -431,7 +430,6 @@ static int prompeg_write(URLContext *h, const uint8_t *buf,
int size) {
col_out_idx = s->packet_idx / s->d;
if ((ret = prompeg_write_fec(h, s->fec_col[col_out_idx],
PROMPEG_FEC_COL)) < 0)
goto end;
-written += ret;
}
if (++s->packet_idx >= s->packet_idx_max) {
@@ -440,7 +438,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf,
int size) {
s->first = 0;
}
-ret = written;
+ret = size;
end:
av_free(bitstring);
--
2.19.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] [FFmpeg-cvslog] avcodec/libaomenc: fix default value for row-mt option
On 3/30/2019 8:20 AM, Gyan wrote:
>
>
> On 29-03-2019 11:26 PM, James Almer wrote:
>> ffmpeg | branch: master | James Almer | Fri Mar 29
>> 14:55:00 2019 -0300| [0856c5da0716e9c461d4f73339a2c2390d0a1162] |
>> committer: James Almer
>>
>> avcodec/libaomenc: fix default value for row-mt option
>>
>> Signed-off-by: James Almer
>>
>>
>> - { "row-mt", "Enable row based multi-threading",
>> OFFSET(row_mt), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, VE},
>> + { "row-mt", "Enable row based multi-threading",
>> OFFSET(row_mt), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>> { "enable-cdef", "Enable CDEF filtering",
>> OFFSET(enable_cdef), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>> { "enable-global-motion", "Enable global motion",
>> OFFSET(enable_global_motion), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>> { "enable-intrabc", "Enable intra block copy prediction mode",
>> OFFSET(enable_intrabc), AV_OPT_TYPE_BOOL, {.i64 = -1}, 0, 1, VE},
>
> Shouldn't 'enable-intrabc ' follow the same pattern?
Yes, the range is wrong. Should be -1 to 1.
Will fix it, thanks for pointing it out.
>
> And what are the semantics of the user setting row_mt or enable-intrabc
> as -1?
Moritz and Hendrik already explained what's the meaning and use of -1 here.
>
> Gyan
> ___
> 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/3] avcodec/cbs_av1: add support for Padding OBUs
On 3/25/2019 11:22 AM, James Almer wrote: > Based on itut_t35 Matadata OBU parsing code. > > Signed-off-by: James Almer > --- > libavcodec/cbs_av1.c | 20 + > libavcodec/cbs_av1.h | 7 ++ > libavcodec/cbs_av1_syntax_template.c | 32 > 3 files changed, 59 insertions(+) Ping for set. ___ 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 Amuse Graphics decoder
On 3/28/2019 6:12 PM, Paul B Mahol wrote:
> This work is sponsored by VideoLAN.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 +
> libavcodec/agm.c| 701
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 +
> libavformat/riff.c | 2 +
> 6 files changed, 713 insertions(+)
> create mode 100644 libavcodec/agm.c
[...]
> +static int decode_frame(AVCodecContext *avctx, void *data,
> +int *got_frame, AVPacket *avpkt)
> +{
> +AGMContext *s = avctx->priv_data;
> +GetBitContext *gb = &s->gb;
> +GetByteContext *gbyte = &s->gbyte;
> +AVFrame *frame = data;
> +int w, h, width, height, header;
> +int ret;
> +
> +if (!avpkt->size)
> +return 0;
> +
> +bytestream2_init(gbyte, avpkt->data, avpkt->size);
> +
> +header = bytestream2_get_le32(gbyte);
> +if (header)
> +avpriv_request_sample(avctx, "header %X", header);
> +s->bitstream_size = bytestream2_get_le24(gbyte);
> +if (avpkt->size < s->bitstream_size + 8)
> +return AVERROR_INVALIDDATA;
> +
> +s->key_frame = bytestream2_get_byte(gbyte) == 32;
> +frame->key_frame = s->key_frame;
> +frame->pict_type = s->key_frame ? AV_PICTURE_TYPE_I : AV_PICTURE_TYPE_P;
> +
> +s->flags = 0;
> +w = bytestream2_get_le32(gbyte);
> +if (w < 0) {
> +w = -w;
> +s->flags |= 2;
> +}
> +h = bytestream2_get_le32(gbyte);
> +if (h < 0) {
> +avpriv_request_sample(avctx, "negative coded height");
> +h = -h;
> +s->flags |= 1;
> +}
> +
> +width = avctx->width;
> +height = avctx->height;
> +if (w < width || h < height || w & 7 || h & 7)
> +return AVERROR_INVALIDDATA;
> +
> +ret = ff_set_dimensions(avctx, w, h);
> +if (ret < 0)
> +return ret;
> +avctx->width = width;
> +avctx->height = height;
> +
> +s->compression = bytestream2_get_le32(gbyte);
> +if (s->compression < 0 || s->compression > 100)
> +return AVERROR_INVALIDDATA;
> +
> +for (int i = 0; i < 3; i++)
> +s->size[i] = bytestream2_get_le32(gbyte);
> +if (32LL + s->size[0] + s->size[1] + s->size[2] > avpkt->size)
> +return AVERROR_INVALIDDATA;
> +
> +if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
> +return ret;
> +
> +if (frame->key_frame) {
> +ret = decode_intra(avctx, gb, frame);
> +} else {
> +if (!s->prev_frame->data[0]) {
You should add a flush() function to unref s->prev_frame. Nothing
guarantees that the first frame sent after an avcodec_flush_buffers()
call (AKA, seeking) will be a keyframe, and if it's not, decode_inter()
will be called with bogus frame data.
> +av_log(avctx, AV_LOG_ERROR, "Missing reference frame.\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (!(s->flags & 2)) {
> +ret = av_frame_copy(frame, s->prev_frame);
> +if (ret < 0)
> +return ret;
> +}
> +
> +ret = decode_inter(avctx, gb, frame, s->prev_frame);
> +}
> +if (ret < 0)
> +return ret;
> +
> +av_frame_unref(s->prev_frame);
> +if ((ret = av_frame_ref(s->prev_frame, frame)) < 0)
> +return ret;
> +
> +frame->crop_top = avctx->coded_height - avctx->height;
> +frame->crop_left = avctx->coded_width - avctx->width;
Setting these fields means you need to set the
FF_CODEC_CAP_EXPORTS_CROPPING caps_internal flag.
> +
> +*got_frame = 1;
> +
> +return avpkt->size;
> +}
> +
> +static av_cold int decode_init(AVCodecContext *avctx)
> +{
> +AGMContext *s = avctx->priv_data;
> +
> +avctx->pix_fmt = AV_PIX_FMT_YUV420P;
> +s->avctx = avctx;
> +s->plus = avctx->codec_tag == MKTAG('A', 'G', 'M', '3');
> +
> +avctx->idct_algo = FF_IDCT_SIMPLE;
> +ff_idctdsp_init(&s->idsp, avctx);
> +ff_init_scantable(s->idsp.idct_permutation, &s->scantable,
> ff_zigzag_direct);
> +
> +s->prev_frame = av_frame_alloc();
> +if (!s->prev_frame)
> +return AVERROR(ENOMEM);
> +
> +return 0;
> +}
> +
> +static av_cold int decode_close(AVCodecContext *avctx)
> +{
> +AGMContext *s = avctx->priv_data;
> +
> +av_frame_free(&s->prev_frame);
> +av_freep(&s->mvectors);
> +s->mvectors_size = 0;
> +
> +return 0;
> +}
> +
> +AVCodec ff_agm_decoder = {
> +.name = "agm",
> +.long_name= NULL_IF_CONFIG_SMALL("Amuse Graphics Movie"),
> +.type = AVMEDIA_TYPE_VIDEO,
> +.id = AV_CODEC_ID_AGM,
> +.priv_data_size = sizeof(AGMContext),
> +.init = decode_init,
> +.close= decode_close,
> +.decode = decode_frame,
> +.capabilities = AV_CODEC_CAP_DR1,
> +.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> +FF_CODEC_CAP_INIT_CLEA
[FFmpeg-devel] [PATCH v5] avformat/doc, http, icecast, rtsp: Add option to disable send-expect-100
Fix ticket #7297
The current setting for send-expect-100 option is either
enabled if applicable or forced enabled, no option to force
disable the header. This change is to expand the option setting
to provide more flexibility, which is useful for rstp case.
---
doc/protocols.texi| 5 +
libavformat/http.c| 28 +---
libavformat/icecast.c | 2 +-
libavformat/rtsp.c| 1 +
4 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index f0fd344ce9..e1caa049a5 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -385,6 +385,11 @@ ffmpeg -i somefile.ogg -chunked_post 0 -c copy -f ogg
http://@var{server}:@var{p
wget --post-file=somefile.ogg http://@var{server}:@var{port}
@end example
+@item send_expect_100
+Send an Expect: 100-continue header for POST. If set to 1 it will send, if set
+to 0 it won't, if set to -1 it will try to send if it is applicable. Default
+value is -1.
+
@end table
@subsection HTTP Cookies
diff --git a/libavformat/http.c b/libavformat/http.c
index 74d743850d..5a937994cf 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -113,6 +113,7 @@ typedef struct HTTPContext {
uint8_t *inflate_buffer;
#endif /* CONFIG_ZLIB */
AVDictionary *chained_options;
+/* -1 = try to send if applicable, 0 = always disabled, 1 = always enabled
*/
int send_expect_100;
char *method;
int reconnect;
@@ -155,7 +156,7 @@ static const AVOption options[] = {
{ "auth_type", "HTTP authentication type", OFFSET(auth_state.auth_type),
AV_OPT_TYPE_INT, { .i64 = HTTP_AUTH_NONE }, HTTP_AUTH_NONE, HTTP_AUTH_BASIC, D
| E, "auth_type"},
{ "none", "No auth method set, autodetect", 0, AV_OPT_TYPE_CONST, { .i64 =
HTTP_AUTH_NONE }, 0, 0, D | E, "auth_type"},
{ "basic", "HTTP basic authentication", 0, AV_OPT_TYPE_CONST, { .i64 =
HTTP_AUTH_BASIC }, 0, 0, D | E, "auth_type"},
-{ "send_expect_100", "Force sending an Expect: 100-continue header for
POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
+{ "send_expect_100", "Force sending an Expect: 100-continue header for
POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, E },
{ "location", "The actual location of the data received",
OFFSET(location), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D | E },
{ "offset", "initial byte offset", OFFSET(off), AV_OPT_TYPE_INT64, { .i64
= 0 }, 0, INT64_MAX, D },
{ "end_offset", "try to limit the request to bytes preceding this offset",
OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
@@ -1179,16 +1180,21 @@ static int http_connect(URLContext *h, const char
*path, const char *local_path,
local_path, method);
proxyauthstr = ff_http_auth_create_response(&s->proxy_auth_state,
proxyauth,
local_path, method);
-if (post && !s->post_data) {
-send_expect_100 = s->send_expect_100;
-/* The user has supplied authentication but we don't know the auth
type,
- * send Expect: 100-continue to get the 401 response including the
- * WWW-Authenticate header, or an 100 continue if no auth actually
- * is needed. */
-if (auth && *auth &&
-s->auth_state.auth_type == HTTP_AUTH_NONE &&
-s->http_code != 401)
-send_expect_100 = 1;
+
+ if (post && !s->post_data) {
+if (s->send_expect_100 != -1) {
+send_expect_100 = s->send_expect_100;
+} else {
+send_expect_100 = 0;
+/* The user has supplied authentication but we don't know the auth
type,
+ * send Expect: 100-continue to get the 401 response including the
+ * WWW-Authenticate header, or an 100 continue if no auth actually
+ * is needed. */
+if (auth && *auth &&
+s->auth_state.auth_type == HTTP_AUTH_NONE &&
+s->http_code != 401)
+send_expect_100 = 1;
+}
}
#if FF_API_HTTP_USER_AGENT
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
index c93b06b553..d2198b78ec 100644
--- a/libavformat/icecast.c
+++ b/libavformat/icecast.c
@@ -115,7 +115,7 @@ static int icecast_open(URLContext *h, const char *uri, int
flags)
av_dict_set(&opt_dict, "auth_type", "basic", 0);
av_dict_set(&opt_dict, "headers", headers, 0);
av_dict_set(&opt_dict, "chunked_post", "0", 0);
-av_dict_set(&opt_dict, "send_expect_100", s->legacy_icecast ? "0" : "1",
0);
+av_dict_set(&opt_dict, "send_expect_100", s->legacy_icecast ? "-1" : "1",
0);
if (NOT_EMPTY(s->content_type))
av_dict_set(&opt_dict, "content_type", s->content_type, 0);
else
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 4661654967..033095905d 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1797,6 +1797,7 @@ redirect:
Re: [FFmpeg-devel] [PATCH v4] avformat/http, icecast, rtsp: Add option to disable send-100-continue
Thanks Michael for review.
I updated the iteration to address your feedback:
https://patchwork.ffmpeg.org/patch/12540/
Best Regards,
-Jun
On Sat, Mar 30, 2019 at 6:14 PM Michael Niedermayer
wrote:
> On Fri, Mar 29, 2019 at 03:59:21PM -0700, Jun Li wrote:
> > On Wed, Mar 27, 2019 at 11:27 PM Jun Li wrote:
> >
> > >
> > >
> > > On Mon, Mar 25, 2019 at 2:42 PM Jun Li wrote:
> > >
> > >>
> > >>
> > >> On Fri, Mar 22, 2019 at 4:12 PM Jun Li wrote:
> > >>
> > >>> The current setting for send-100-continue option is either
> > >>> enabled if applicable or forced enabled, no option to force
> > >>> disable the header. This change is to expand the option setting
> > >>> to provide more flexibility, which is useful for rstp case.
> > >>> ---
> > >>> libavformat/http.c| 28 +---
> > >>> libavformat/icecast.c | 2 +-
> > >>> libavformat/rtsp.c| 1 +
> > >>> 3 files changed, 19 insertions(+), 12 deletions(-)
> > >>>
> > >>> diff --git a/libavformat/http.c b/libavformat/http.c
> > >>> index 74d743850d..5a937994cf 100644
> > >>> --- a/libavformat/http.c
> > >>> +++ b/libavformat/http.c
> > >>> @@ -113,6 +113,7 @@ typedef struct HTTPContext {
> > >>> uint8_t *inflate_buffer;
> > >>> #endif /* CONFIG_ZLIB */
> > >>> AVDictionary *chained_options;
> > >>> +/* -1 = try to send if applicable, 0 = always disabled, 1 =
> always
> > >>> enabled */
> > >>> int send_expect_100;
> > >>> char *method;
> > >>> int reconnect;
> > >>> @@ -155,7 +156,7 @@ static const AVOption options[] = {
> > >>> { "auth_type", "HTTP authentication type",
> > >>> OFFSET(auth_state.auth_type), AV_OPT_TYPE_INT, { .i64 =
> HTTP_AUTH_NONE },
> > >>> HTTP_AUTH_NONE, HTTP_AUTH_BASIC, D | E, "auth_type"},
> > >>> { "none", "No auth method set, autodetect", 0,
> AV_OPT_TYPE_CONST, {
> > >>> .i64 = HTTP_AUTH_NONE }, 0, 0, D | E, "auth_type"},
> > >>> { "basic", "HTTP basic authentication", 0, AV_OPT_TYPE_CONST, {
> > >>> .i64 = HTTP_AUTH_BASIC }, 0, 0, D | E, "auth_type"},
> > >>> -{ "send_expect_100", "Force sending an Expect: 100-continue
> header
> > >>> for POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = 0 },
> 0, 1, E
> > >>> },
> > >>> +{ "send_expect_100", "Force sending an Expect: 100-continue
> header
> > >>> for POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = -1 },
> -1, 1,
> > >>> E },
> > >>> { "location", "The actual location of the data received",
> > >>> OFFSET(location), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D | E },
> > >>> { "offset", "initial byte offset", OFFSET(off),
> AV_OPT_TYPE_INT64,
> > >>> { .i64 = 0 }, 0, INT64_MAX, D },
> > >>> { "end_offset", "try to limit the request to bytes preceding
> this
> > >>> offset", OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0,
> INT64_MAX, D
> > >>> },
> > >>> @@ -1179,16 +1180,21 @@ static int http_connect(URLContext *h, const
> > >>> char *path, const char *local_path,
> > >>> local_path, method);
> > >>> proxyauthstr =
> ff_http_auth_create_response(&s->proxy_auth_state,
> > >>> proxyauth,
> > >>> local_path, method);
> > >>> -if (post && !s->post_data) {
> > >>> -send_expect_100 = s->send_expect_100;
> > >>> -/* The user has supplied authentication but we don't know
> the
> > >>> auth type,
> > >>> - * send Expect: 100-continue to get the 401 response
> including
> > >>> the
> > >>> - * WWW-Authenticate header, or an 100 continue if no auth
> > >>> actually
> > >>> - * is needed. */
> > >>> -if (auth && *auth &&
> > >>> -s->auth_state.auth_type == HTTP_AUTH_NONE &&
> > >>> -s->http_code != 401)
> > >>> -send_expect_100 = 1;
> > >>> +
> > >>> + if (post && !s->post_data) {
> > >>> +if (s->send_expect_100 != -1) {
> > >>> +send_expect_100 = s->send_expect_100;
> > >>> +} else {
> > >>> +send_expect_100 = 0;
> > >>> +/* The user has supplied authentication but we don't
> know
> > >>> the auth type,
> > >>> + * send Expect: 100-continue to get the 401 response
> > >>> including the
> > >>> + * WWW-Authenticate header, or an 100 continue if no
> auth
> > >>> actually
> > >>> + * is needed. */
> > >>> +if (auth && *auth &&
> > >>> +s->auth_state.auth_type == HTTP_AUTH_NONE &&
> > >>> +s->http_code != 401)
> > >>> +send_expect_100 = 1;
> > >>> +}
> > >>> }
> > >>>
> > >>> #if FF_API_HTTP_USER_AGENT
> > >>> diff --git a/libavformat/icecast.c b/libavformat/icecast.c
> > >>> index c93b06b553..d2198b78ec 100644
> > >>> --- a/libavformat/icecast.c
> > >>> +++ b/libavformat/icecast.c
> > >>> @@ -115,7 +115,7 @@ static int icecast_open(URLContext *h, const char
> > >>> *uri, int flags)
> > >>> av_dict_set(&opt_dict,
