[FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters
Signed-off-by: Haihao Xiang
---
libavcodec/hevcdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index c8877626d2..13d868bb4f 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -344,6 +344,11 @@ static void export_stream_params(AVCodecContext *avctx,
const HEVCParamSets *ps,
avctx->colorspace = AVCOL_SPC_UNSPECIFIED;
}
+if (sps->vui.chroma_loc_info_present_flag)
+avctx->chroma_sample_location =
sps->vui.chroma_sample_loc_type_top_field + 1;
+else
+avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
+
if (vps->vps_timing_info_present_flag) {
num = vps->vps_num_units_in_tick;
den = vps->vps_time_scale;
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] ffmpeg: Use the colour properties from the input stream when doing transcode
In lavc/hevec_vaapi, colour properties in AVCodecContext are needed to
write the sequence header
Tested by the command below:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
-hwaccel_output_format vaapi -i input-with-hdr.mkv -c:v hevc_vaapi
-profile:v main10 output.h265
Signed-off-by: Haihao Xiang
---
fftools/ffmpeg.c | 4
1 file changed, 4 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5a19a09d9a..80b5441f8f 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3298,6 +3298,10 @@ static int init_output_stream_encode(OutputStream *ost)
dec_ctx = ist->dec_ctx;
enc_ctx->chroma_sample_location = dec_ctx->chroma_sample_location;
+enc_ctx->color_range= dec_ctx->color_range;
+enc_ctx->color_primaries= dec_ctx->color_primaries;
+enc_ctx->color_trc = dec_ctx->color_trc;
+enc_ctx->colorspace = dec_ctx->colorspace;
} else {
for (j = 0; j < oc->nb_streams; j++) {
AVStream *st = oc->streams[j];
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/xwddec: fix palette alpha
On 5/15/18, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > libavcodec/xwddec.c | 2 +- > tests/ref/lavf/xwd | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Fix errors in version script list
On Wed, May 16, 2018 at 2:39 AM, Peter Bennett wrote:
> From: Peter Bennett
>
> libavformat.v has url_open, url_close and url_write. These
> should be ffurl_ in each case.
> ---
> libavformat/libavformat.v | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
> index cf2055f..7df12d3 100644
> --- a/libavformat/libavformat.v
> +++ b/libavformat/libavformat.v
> @@ -6,9 +6,9 @@ LIBAVFORMAT_MAJOR {
> ffurl_seek;
> ffurl_size;
> ffurl_protocol_next;
> -url_open;
> -url_close;
> -url_write;
> +ffurl_open;
> +ffurl_close;
> +ffurl_write;
> url_*;
> ff_timefilter_destroy;
> ff_timefilter_new;
> --
> 2.7.4
>
libavformat.v contains none of these entries anymore.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters
On Wed, May 16, 2018 at 9:19 AM, Haihao Xiang wrote: > Signed-off-by: Haihao Xiang > --- > libavcodec/hevcdec.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c > index c8877626d2..13d868bb4f 100644 > --- a/libavcodec/hevcdec.c > +++ b/libavcodec/hevcdec.c > @@ -344,6 +344,11 @@ static void export_stream_params(AVCodecContext *avctx, > const HEVCParamSets *ps, > avctx->colorspace = AVCOL_SPC_UNSPECIFIED; > } > > +if (sps->vui.chroma_loc_info_present_flag) > +avctx->chroma_sample_location = > sps->vui.chroma_sample_loc_type_top_field + 1; > +else > +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED; > This change is incomplete, refer to the patch I proposed earlier: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228100.html - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
ons 2018-05-16 klockan 10:18 +0800 skrev Zhao Zhili:
> The av_err2str macro in libavutil/error.h use compound literal:
>
> #define av_err2str(errnum) \
> av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0},
> AV_ERROR_MAX_STRING_SIZE, errnum)
>
> C++ compiler may not support it or treat the usage as invalid.
> For example, g++ 5.4 raise an error: taking address of temporary
> array.
>
> 1. Should the macro be defined for C only?
> 2. Or make it as valid C++? (I don't know how to do that)
First of all, this shouldn't matter since av_err2str is not actually
used in any header. libavutil/timer.h makes use of it in another macro,
so that also doesn't matter.
Second, libavutil is a C library, not a C++ library. However, it might
be nicer to make that a static inline function, if possible. Or move it
to an internal header, since it doesn't look like something that should
be exposed as part of the public API.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters
On Wed, 2018-05-16 at 10:17 +0200, Hendrik Leppkes wrote: > On Wed, May 16, 2018 at 9:19 AM, Haihao Xiang wrote: > > Signed-off-by: Haihao Xiang > > --- > > libavcodec/hevcdec.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c > > index c8877626d2..13d868bb4f 100644 > > --- a/libavcodec/hevcdec.c > > +++ b/libavcodec/hevcdec.c > > @@ -344,6 +344,11 @@ static void export_stream_params(AVCodecContext *avctx, > > const HEVCParamSets *ps, > > avctx->colorspace = AVCOL_SPC_UNSPECIFIED; > > } > > > > +if (sps->vui.chroma_loc_info_present_flag) > > +avctx->chroma_sample_location = sps- > > >vui.chroma_sample_loc_type_top_field + 1; > > +else > > +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED; > > > > This change is incomplete, refer to the patch I proposed earlier: > http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228100.html > Sorry I didn't see your proposal before. Per spec, once chroma_loc_info_present_flag is set, chroma_format_idc should be 1. I think it would be better to add some checks when parsing the sequence parameters. Thanks Haihao > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
On 16.05.2018 10:29, Tomas Härdin wrote:
ons 2018-05-16 klockan 10:18 +0800 skrev Zhao Zhili:
The av_err2str macro in libavutil/error.h use compound literal:
#define av_err2str(errnum) \
av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0},
AV_ERROR_MAX_STRING_SIZE, errnum)
C++ compiler may not support it or treat the usage as invalid.
For example, g++ 5.4 raise an error: taking address of temporary
array.
1. Should the macro be defined for C only?
2. Or make it as valid C++? (I don't know how to do that)
First of all, this shouldn't matter since av_err2str is not actually
used in any header. libavutil/timer.h makes use of it in another macro,
so that also doesn't matter.
Second, libavutil is a C library, not a C++ library. However, it might
be nicer to make that a static inline function, if possible. Or move it
to an internal header, since it doesn't look like something that should
be exposed as part of the public API.
ffmpeg.c/ffprobe.c is using it for assembling log messages and I'm using
it in my private tools, too. As it is a convenient utility function I
would prefer to keep it in the public headers of libavutil.
Regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters
On Wed, May 16, 2018 at 10:49 AM, Xiang, Haihao wrote: > On Wed, 2018-05-16 at 10:17 +0200, Hendrik Leppkes wrote: >> On Wed, May 16, 2018 at 9:19 AM, Haihao Xiang wrote: >> > Signed-off-by: Haihao Xiang >> > --- >> > libavcodec/hevcdec.c | 5 + >> > 1 file changed, 5 insertions(+) >> > >> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c >> > index c8877626d2..13d868bb4f 100644 >> > --- a/libavcodec/hevcdec.c >> > +++ b/libavcodec/hevcdec.c >> > @@ -344,6 +344,11 @@ static void export_stream_params(AVCodecContext >> > *avctx, >> > const HEVCParamSets *ps, >> > avctx->colorspace = AVCOL_SPC_UNSPECIFIED; >> > } >> > >> > +if (sps->vui.chroma_loc_info_present_flag) >> > +avctx->chroma_sample_location = sps- >> > >vui.chroma_sample_loc_type_top_field + 1; >> > +else >> > +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED; >> > >> >> This change is incomplete, refer to the patch I proposed earlier: >> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228100.html >> > > Sorry I didn't see your proposal before. Per spec, once > chroma_loc_info_present_flag is set, chroma_format_idc should be 1. I think it > would be better to add some checks when parsing the sequence parameters. > It makes no real difference because you still need the check to be able to set the LEFT default value for 4:2:0 only. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
ons 2018-05-16 klockan 11:16 +0200 skrev Tobias Rapp:
> On 16.05.2018 10:29, Tomas Härdin wrote:
> > ons 2018-05-16 klockan 10:18 +0800 skrev Zhao Zhili:
> > > The av_err2str macro in libavutil/error.h use compound literal:
> > >
> > > #define av_err2str(errnum) \
> > > av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0},
> > > AV_ERROR_MAX_STRING_SIZE, errnum)
> > >
> > > C++ compiler may not support it or treat the usage as invalid.
> > > For example, g++ 5.4 raise an error: taking address of temporary
> > > array.
> > >
> > > 1. Should the macro be defined for C only?
> > > 2. Or make it as valid C++? (I don't know how to do that)
> >
> > First of all, this shouldn't matter since av_err2str is not actually
> > used in any header. libavutil/timer.h makes use of it in another macro,
> > so that also doesn't matter.
> >
> > Second, libavutil is a C library, not a C++ library. However, it might
> > be nicer to make that a static inline function, if possible. Or move it
> > to an internal header, since it doesn't look like something that should
> > be exposed as part of the public API.
>
> ffmpeg.c/ffprobe.c is using it for assembling log messages and I'm using
> it in my private tools, too. As it is a convenient utility function I
> would prefer to keep it in the public headers of libavutil.
ffmpeg.c/ffprobe.c are C.. :)
If you're in C++, why don't you just write your own variant that
returns std::string?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
On 16.05.2018 11:27, Tomas Härdin wrote:
ons 2018-05-16 klockan 11:16 +0200 skrev Tobias Rapp:
On 16.05.2018 10:29, Tomas Härdin wrote:
ons 2018-05-16 klockan 10:18 +0800 skrev Zhao Zhili:
The av_err2str macro in libavutil/error.h use compound literal:
#define av_err2str(errnum) \
av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0},
AV_ERROR_MAX_STRING_SIZE, errnum)
C++ compiler may not support it or treat the usage as invalid.
For example, g++ 5.4 raise an error: taking address of temporary
array.
1. Should the macro be defined for C only?
2. Or make it as valid C++? (I don't know how to do that)
First of all, this shouldn't matter since av_err2str is not actually
used in any header. libavutil/timer.h makes use of it in another macro,
so that also doesn't matter.
Second, libavutil is a C library, not a C++ library. However, it might
be nicer to make that a static inline function, if possible. Or move it
to an internal header, since it doesn't look like something that should
be exposed as part of the public API.
ffmpeg.c/ffprobe.c is using it for assembling log messages and I'm using
it in my private tools, too. As it is a convenient utility function I
would prefer to keep it in the public headers of libavutil.
ffmpeg.c/ffprobe.c are C.. :)
If you're in C++, why don't you just write your own variant that
returns std::string?
Yes, I am referring to usage of the libavutil headers in C. If the macro
is only hidden for C++ and available in C, that would be OK for me. But
if the static inline function variant would support both C and C++, this
would look like a solution where C++ users are not forced to implement a
more "integrated" replacement but of course have the option to do so.
Regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:
> Yes, I am referring to usage of the libavutil headers in C. If the macro is
> only hidden for C++ and available in C, that would be OK for me. But if the
> static inline function variant would support both C and C++, this would look
> like a solution where C++ users are not forced to implement a more
> "integrated" replacement but of course have the option to do so.
While we're at it, would it be possible to have extern "C" { for the headers,
too? :-) (Wrapped in #ifdef __cplusplus, of course.)
/* Steinar */
--
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
On 2018年05月16日 17:47, Steinar H. Gunderson wrote:
On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:
Yes, I am referring to usage of the libavutil headers in C. If the macro is
only hidden for C++ and available in C, that would be OK for me. But if the
static inline function variant would support both C and C++, this would look
like a solution where C++ users are not forced to implement a more
"integrated" replacement but of course have the option to do so.
While we're at it, would it be possible to have extern "C" { for the headers,
too? :-) (Wrapped in #ifdef __cplusplus, of course.)
/* Steinar */
This is what I thought. Although let the C++ programmer use it and fail
and learn something new is cool, I prefer less surprise.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
ons 2018-05-16 klockan 11:47 +0200 skrev Steinar H. Gunderson:
> On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:
> > Yes, I am referring to usage of the libavutil headers in C. If the macro is
> > only hidden for C++ and available in C, that would be OK for me. But if the
> > static inline function variant would support both C and C++, this would look
> > like a solution where C++ users are not forced to implement a more
> > "integrated" replacement but of course have the option to do so.
>
> While we're at it, would it be possible to have extern "C" { for the headers,
> too? :-) (Wrapped in #ifdef __cplusplus, of course.)
This comes up every now and then, and I know there was great opposition
to it previously from people who have since left the project. If you're
willing to be the person officially dealing with all "C++-isms" in the
headers then I wouldn't be too opposed. Maybe someone else has stronger
feelings
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
On Wed, May 16, 2018 at 12:41:05PM +0200, Tomas Härdin wrote:
> This comes up every now and then, and I know there was great opposition
> to it previously from people who have since left the project. If you're
> willing to be the person officially dealing with all "C++-isms" in the
> headers then I wouldn't be too opposed. Maybe someone else has stronger
> feelings
FWIW, I use FFmpeg from C++ code, and the only thing I really need to worry
about seems to be adding extern "C" {} around every FFmpeg include. There
doesn't seem to be much more to it than that, at least for basic use.
/* Steinar */
--
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement
On Mon, May 14, 2018 at 5:50 PM, Derek Buitenhuis wrote: > This is a little rambling / stream of thought, but take it as you will, > and perhaps some discussion or change comes of it. Or, more likely, personal > attacks, flames, and no change. Or 1 few will reply and then the thread will > die and people will go on like it never happened. Sorry to be pessimistic, > but history speaks for itself. 48 hours later and: - Some votes for repealing the CoC. - One vote for keeping - Some replies that do neither, but prefer to attack the example rather than the actual point of the email. - As suspected, a large chunk of the project's developers have simply not replied, hoping it just goes away or blows over, or don't care. I'd say the prediction was pretty accurated. I don't forsee any change, as per usual. Just some flames, and nothing happens, as is tradition. Can't change a community who are not interested and/or actively hostile to trying to be less toxic. (inb4 'I just want to write code and not do politics/etc." replies, which really mean 'I am OK with the way it is and can't be arsed to make it less toxic for others.') Cheers, - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement
On 5/16/2018 11:07 AM, Derek Buitenhuis wrote: > On Mon, May 14, 2018 at 5:50 PM, Derek Buitenhuis > wrote: >> This is a little rambling / stream of thought, but take it as you will, >> and perhaps some discussion or change comes of it. Or, more likely, personal >> attacks, flames, and no change. Or 1 few will reply and then the thread will >> die and people will go on like it never happened. Sorry to be pessimistic, >> but history speaks for itself. > > 48 hours later and: > - Some votes for repealing the CoC. > - One vote for keeping I think the issue is not the lack of clear enforcement rules, but a lack of a proactive enforcer, be it a person or a body. The CoC has done nothing but give people something to say when they want to be passive aggressive in a discussion. Changing it to a more strict one like Videolan's will not affect that. This lack of interest you mentioned is exactly the issue. If it all depends on the coordinated action and involvement of a dozen or so developers, then nothing will happen. As i said, the one time action was called for a developer's behavior, no voter showed up. I'm up for keeping it or making it stricter. But it needs to be enforced. So how do we get a dozen or so people to stop looking away every time someone is a dick in a thread? > - Some replies that do neither, but prefer to attack the example > rather than the actual point of the email. > - As suspected, a large chunk of the project's developers have > simply not replied, hoping it just goes away or blows over, or > don't care. > > I'd say the prediction was pretty accurated. I don't forsee any change, as per > usual. Just some flames, and nothing happens, as is tradition. Can't change > a community who are not interested and/or actively hostile to trying to be > less toxic. (inb4 'I just want to write code and not do politics/etc." > replies, > which really mean 'I am OK with the way it is and can't be arsed to make > it less toxic for others.') > > Cheers, > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement
On Wed, May 16, 2018 at 3:25 PM, James Almer wrote: > I think the issue is not the lack of clear enforcement rules, but a lack > of a proactive enforcer, be it a person or a body. The CoC has done > nothing but give people something to say when they want to be passive > aggressive in a discussion. > Changing it to a more strict one like Videolan's will not affect that. > > This lack of interest you mentioned is exactly the issue. If it all > depends on the coordinated action and involvement of a dozen or so > developers, then nothing will happen. As i said, the one time action was > called for a developer's behavior, no voter showed up. So how does one fix a toxic environment where most of the members don't care, or don't even aknowledge it's an issue? Let it hemmorage people, keeping a few here and there who can "take it" (which IMO is a load of gross gatekeeping BS)? (Yes, As far as I'm concerned, staying away / not replying / doing nothing si just an implicit way of saying "I'm fine with the community as it is". ) I actually don't have much of a solution to the "nobody willing to step up" problem, though, no. The offical documents should at least reflect that reality then, though. A CoC that is ignored, is not a CoC. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement
On Wed, May 16, 2018 at 4:25 PM, James Almer wrote: > On 5/16/2018 11:07 AM, Derek Buitenhuis wrote: >> On Mon, May 14, 2018 at 5:50 PM, Derek Buitenhuis >> wrote: >>> This is a little rambling / stream of thought, but take it as you will, >>> and perhaps some discussion or change comes of it. Or, more likely, personal >>> attacks, flames, and no change. Or 1 few will reply and then the thread will >>> die and people will go on like it never happened. Sorry to be pessimistic, >>> but history speaks for itself. >> >> 48 hours later and: >> - Some votes for repealing the CoC. >> - One vote for keeping > > I think the issue is not the lack of clear enforcement rules, but a lack > of a proactive enforcer, be it a person or a body. The CoC has done > nothing but give people something to say when they want to be passive > aggressive in a discussion. > Changing it to a more strict one like Videolan's will not affect that. > > This lack of interest you mentioned is exactly the issue. If it all > depends on the coordinated action and involvement of a dozen or so > developers, then nothing will happen. As i said, the one time action was > called for a developer's behavior, no voter showed up. > > I'm up for keeping it or making it stricter. But it needs to be > enforced. So how do we get a dozen or so people to stop looking away > every time someone is a dick in a thread? > Maybe the solution should be something that does not require all those people to convene everytime there is some petty trolling going on again. There is a big difference between "not caring" and not wanting to get involved with this on a daily basis, even if you guys seem to throw all of those into the same pile. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement
On 16.05.2018 17:14, Hendrik Leppkes wrote: > On Wed, May 16, 2018 at 4:25 PM, James Almer wrote: >> On 5/16/2018 11:07 AM, Derek Buitenhuis wrote: >>> On Mon, May 14, 2018 at 5:50 PM, Derek Buitenhuis >>> wrote: This is a little rambling / stream of thought, but take it as you will, and perhaps some discussion or change comes of it. Or, more likely, personal attacks, flames, and no change. Or 1 few will reply and then the thread will die and people will go on like it never happened. Sorry to be pessimistic, but history speaks for itself. >>> 48 hours later and: >>> - Some votes for repealing the CoC. >>> - One vote for keeping >> I think the issue is not the lack of clear enforcement rules, but a lack >> of a proactive enforcer, be it a person or a body. The CoC has done >> nothing but give people something to say when they want to be passive >> aggressive in a discussion. >> Changing it to a more strict one like Videolan's will not affect that. >> >> This lack of interest you mentioned is exactly the issue. If it all >> depends on the coordinated action and involvement of a dozen or so >> developers, then nothing will happen. As i said, the one time action was >> called for a developer's behavior, no voter showed up. >> >> I'm up for keeping it or making it stricter. But it needs to be >> enforced. So how do we get a dozen or so people to stop looking away >> every time someone is a dick in a thread? >> > Maybe the solution should be something that does not require all those > people to convene everytime there is some petty trolling going on > again. Yes. > > There is a big difference between "not caring" and not wanting to get > involved with this on a daily basis, Correct. > even if you guys seem to throw > all of those into the same pile. Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
Tomas Härdin (2018-05-16): > However, it might > be nicer to make that a static inline function, if possible. Not possible, it has to be a macro. But macros do not cause compatibility problems. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement
On Wed, May 16, 2018 at 4:42 PM, Thomas Volkert wrote: >> Maybe the solution should be something that does not require all those >> people to convene everytime there is some petty trolling going on >> again. > Yes. Suggestions welcome... >> There is a big difference between "not caring" and not wanting to get >> involved with this on a daily basis, > Correct. There is also a difference between not wanting to get involved on a daily basis, and *never* getting involved, even once, to hash a system that can handle it. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement
Hi, On Wed, May 16, 2018 at 10:07 AM, Derek Buitenhuis < derek.buitenh...@gmail.com> wrote: > On Mon, May 14, 2018 at 5:50 PM, Derek Buitenhuis > wrote: > > This is a little rambling / stream of thought, but take it as you will, > > and perhaps some discussion or change comes of it. Or, more likely, > personal > > attacks, flames, and no change. Or 1 few will reply and then the thread > will > > die and people will go on like it never happened. Sorry to be > pessimistic, > > but history speaks for itself. > [..] > - As suspected, a large chunk of the project's developers have > simply not replied, hoping it just goes away or blows over, or > don't care. Maybe this is included in the "not care", but I don't think any of this will change. I've tried, I'm tired and have given up. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] cmdutils - don't search for option 'default'
From 20a0544d66b5b3b9ebc3e03049a134d13706bda9 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Wed, 16 May 2018 20:18:30 +0530
Subject: [PATCH] cmdutils - don't search for option 'default'
The option 'default' was removed in
af4b1c02acf6923489d30349c4813a0d73b2f114 - Dec 20 2012.
---
fftools/cmdutils.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 8ffc9d240b..7fca78cb97 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -362,8 +362,6 @@ int parse_option(void *optctx, const char *opt, const char
*arg,
} else if (po->flags & OPT_BOOL)
arg = "1";
-if (!po->name)
-po = find_option(options, "default");
if (!po->name) {
av_log(NULL, AV_LOG_ERROR, "Unrecognized option '%s'\n", opt);
return AVERROR(EINVAL);
--
2.12.2.windows.2___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hls: tag as AVFMT_TS_DISCONT
From: Aman Gupta
HLS streams can contain discontinuities. Mark the format as such.
This triggers various discontinuity fixes in lavf/utils.c and fftools
Signed-off-by: Aman Gupta
---
libavformat/hls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 4ee4be769d..3199b0ac8d 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2277,7 +2277,7 @@ AVInputFormat ff_hls_demuxer = {
.long_name = NULL_IF_CONFIG_SMALL("Apple HTTP Live Streaming"),
.priv_class = &hls_class,
.priv_data_size = sizeof(HLSContext),
-.flags = AVFMT_NOGENSEARCH,
+.flags = AVFMT_NOGENSEARCH | AVFMT_TS_DISCONT,
.read_probe = hls_probe,
.read_header= hls_read_header,
.read_packet= hls_read_packet,
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement
On Wed, 16 May 2018 15:44:36 +0100 Derek Buitenhuis wrote: > On Wed, May 16, 2018 at 3:25 PM, James Almer wrote: > > I think the issue is not the lack of clear enforcement rules, but a lack > > of a proactive enforcer, be it a person or a body. The CoC has done > > nothing but give people something to say when they want to be passive > > aggressive in a discussion. > > Changing it to a more strict one like Videolan's will not affect that. > > > > This lack of interest you mentioned is exactly the issue. If it all > > depends on the coordinated action and involvement of a dozen or so > > developers, then nothing will happen. As i said, the one time action was > > called for a developer's behavior, no voter showed up. > > So how does one fix a toxic environment where most of the members > don't care, or don't even aknowledge it's an issue? Let it hemmorage > people, keeping a few here and there who can "take it" (which IMO is > a load of gross gatekeeping BS)? > > (Yes, As far as I'm concerned, staying away / not replying / doing nothing > si just an implicit way of saying "I'm fine with the community as it is". ) > > I actually don't have much of a solution to the "nobody willing to step > up" problem, though, no. The offical documents should at least reflect > that reality then, though. A CoC that is ignored, is not a CoC. True, in that case it's better to remove the CoC because it's completely misleading about our community. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Fix errors in version script list
On Wed, 16 May 2018 10:13:44 +0200
Hendrik Leppkes wrote:
> On Wed, May 16, 2018 at 2:39 AM, Peter Bennett wrote:
> > From: Peter Bennett
> >
> > libavformat.v has url_open, url_close and url_write. These
> > should be ffurl_ in each case.
> > ---
> > libavformat/libavformat.v | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
> > index cf2055f..7df12d3 100644
> > --- a/libavformat/libavformat.v
> > +++ b/libavformat/libavformat.v
> > @@ -6,9 +6,9 @@ LIBAVFORMAT_MAJOR {
> > ffurl_seek;
> > ffurl_size;
> > ffurl_protocol_next;
> > -url_open;
> > -url_close;
> > -url_write;
> > +ffurl_open;
> > +ffurl_close;
> > +ffurl_write;
> > url_*;
> > ff_timefilter_destroy;
> > ff_timefilter_new;
> > --
> > 2.7.4
> >
>
> libavformat.v contains none of these entries anymore.
Also the url API (why does it even exist?) hasn't been public API for
years.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
On Wed, 16 May 2018 17:58:46 +0800
Zhao Zhili wrote:
> On 2018年05月16日 17:47, Steinar H. Gunderson wrote:
> > On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:
> >> Yes, I am referring to usage of the libavutil headers in C. If the macro is
> >> only hidden for C++ and available in C, that would be OK for me. But if the
> >> static inline function variant would support both C and C++, this would
> >> look
> >> like a solution where C++ users are not forced to implement a more
> >> "integrated" replacement but of course have the option to do so.
> > While we're at it, would it be possible to have extern "C" { for the
> > headers,
> > too? :-) (Wrapped in #ifdef __cplusplus, of course.)
> >
> > /* Steinar */
>
> This is what I thought. Although let the C++ programmer use it and fail
> and learn something new is cool, I prefer less surprise.
More people should be educated about which of C and C++ is the inferior
language.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
On Wed, 16 May 2018 11:47:36 +0200
"Steinar H. Gunderson" wrote:
> On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:
> > Yes, I am referring to usage of the libavutil headers in C. If the macro is
> > only hidden for C++ and available in C, that would be OK for me. But if the
> > static inline function variant would support both C and C++, this would look
> > like a solution where C++ users are not forced to implement a more
> > "integrated" replacement but of course have the option to do so.
>
> While we're at it, would it be possible to have extern "C" { for the headers,
> too? :-) (Wrapped in #ifdef __cplusplus, of course.)
That would probably not harm anything. It's pretty standard for C
libraries to have this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters
On Wed, 16 May 2018 15:19:44 +0800
Haihao Xiang wrote:
> Signed-off-by: Haihao Xiang
> ---
> libavcodec/hevcdec.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index c8877626d2..13d868bb4f 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -344,6 +344,11 @@ static void export_stream_params(AVCodecContext *avctx,
> const HEVCParamSets *ps,
> avctx->colorspace = AVCOL_SPC_UNSPECIFIED;
> }
>
> +if (sps->vui.chroma_loc_info_present_flag)
> +avctx->chroma_sample_location =
> sps->vui.chroma_sample_loc_type_top_field + 1;
> +else
> +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
> +
> if (vps->vps_timing_info_present_flag) {
> num = vps->vps_num_units_in_tick;
> den = vps->vps_time_scale;
Wouldn't this prevent an API user from setting the field to a container
value as a fallback? Although maybe that's not necessary because
there's an "unspecified" special value anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: tag as AVFMT_TS_DISCONT
On Wed, 16 May 2018 10:17:58 -0700
Aman Gupta wrote:
> From: Aman Gupta
>
> HLS streams can contain discontinuities. Mark the format as such.
>
> This triggers various discontinuity fixes in lavf/utils.c and fftools
>
> Signed-off-by: Aman Gupta
> ---
> libavformat/hls.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 4ee4be769d..3199b0ac8d 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2277,7 +2277,7 @@ AVInputFormat ff_hls_demuxer = {
> .long_name = NULL_IF_CONFIG_SMALL("Apple HTTP Live Streaming"),
> .priv_class = &hls_class,
> .priv_data_size = sizeof(HLSContext),
> -.flags = AVFMT_NOGENSEARCH,
> +.flags = AVFMT_NOGENSEARCH | AVFMT_TS_DISCONT,
> .read_probe = hls_probe,
> .read_header= hls_read_header,
> .read_packet= hls_read_packet,
I think I'm against this. HLS streams do not typically contain
timestamp resets (even if they could). Otherwise you might as well add
this flag to the Matroska demuxer. Besides, it would break some of my
code, which uses this flag as a heuristic to detect mpeg-ts style
non-container formats.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement
On 05/16/2018 08:06 PM, wm4 wrote: I actually don't have much of a solution to the "nobody willing to step up" problem, though, no. The offical documents should at least reflect that reality then, though. A CoC that is ignored, is not a CoC. True, in that case it's better to remove the CoC because it's completely misleading about our community. +1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters
On Wed, May 16, 2018 at 8:11 PM, wm4 wrote:
> On Wed, 16 May 2018 15:19:44 +0800
> Haihao Xiang wrote:
>
>> Signed-off-by: Haihao Xiang
>> ---
>> libavcodec/hevcdec.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>> index c8877626d2..13d868bb4f 100644
>> --- a/libavcodec/hevcdec.c
>> +++ b/libavcodec/hevcdec.c
>> @@ -344,6 +344,11 @@ static void export_stream_params(AVCodecContext *avctx,
>> const HEVCParamSets *ps,
>> avctx->colorspace = AVCOL_SPC_UNSPECIFIED;
>> }
>>
>> +if (sps->vui.chroma_loc_info_present_flag)
>> +avctx->chroma_sample_location =
>> sps->vui.chroma_sample_loc_type_top_field + 1;
>> +else
>> +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
>> +
>> if (vps->vps_timing_info_present_flag) {
>> num = vps->vps_num_units_in_tick;
>> den = vps->vps_time_scale;
>
> Wouldn't this prevent an API user from setting the field to a container
> value as a fallback? Although maybe that's not necessary because
> there's an "unspecified" special value anyway.
The decoder always manages that value, if the SPS/PPS/VPS changed
mid-stream and the value vanishes, that also needs to be able to be
communicated.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: tag as AVFMT_TS_DISCONT
On Wed, May 16, 2018 at 11:14 AM, wm4 wrote:
> On Wed, 16 May 2018 10:17:58 -0700
> Aman Gupta wrote:
>
> > From: Aman Gupta
> >
> > HLS streams can contain discontinuities. Mark the format as such.
> >
> > This triggers various discontinuity fixes in lavf/utils.c and fftools
> >
> > Signed-off-by: Aman Gupta
> > ---
> > libavformat/hls.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index 4ee4be769d..3199b0ac8d 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -2277,7 +2277,7 @@ AVInputFormat ff_hls_demuxer = {
> > .long_name = NULL_IF_CONFIG_SMALL("Apple HTTP Live Streaming"),
> > .priv_class = &hls_class,
> > .priv_data_size = sizeof(HLSContext),
> > -.flags = AVFMT_NOGENSEARCH,
> > +.flags = AVFMT_NOGENSEARCH | AVFMT_TS_DISCONT,
> > .read_probe = hls_probe,
> > .read_header= hls_read_header,
> > .read_packet= hls_read_packet,
>
> I think I'm against this. HLS streams do not typically contain
> timestamp resets (even if they could). Otherwise you might as well add
>
mpegts timestamps wrap every 26 hours, so any live continuous HLS broadcast
is guaranteed to have a timestamp reset.
Users have reported seeing these resets on various streams (
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html), plus
the HLS spec itself defines a EXT-X-DISCONTINUITY tag to signal
discontinuities. So I don't think it's fair to say that discontinuities
don't typically occur and can be ignored.
> this flag to the Matroska demuxer. Besides, it would break some of my
> code, which uses this flag as a heuristic to detect mpeg-ts style
> non-container formats.
>
I'm working on a patchset with a new -remove_ts_discont option which will
remove discontinuities and normalize timestamps. This
option would only kick in for formats marked as AVFMT_TS_DISCONT, so I
would like to see any formats where timestamp
discontinuities are possible to be marked as such.
Maybe we can add another AVFMT flag that can be used as your heuristic?
Aman
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: tag as AVFMT_TS_DISCONT
On Wed, 16 May 2018 11:45:58 -0700
Aman Gupta wrote:
> On Wed, May 16, 2018 at 11:14 AM, wm4 wrote:
>
> > On Wed, 16 May 2018 10:17:58 -0700
> > Aman Gupta wrote:
> >
> > > From: Aman Gupta
> > >
> > > HLS streams can contain discontinuities. Mark the format as such.
> > >
> > > This triggers various discontinuity fixes in lavf/utils.c and fftools
> > >
> > > Signed-off-by: Aman Gupta
> > > ---
> > > libavformat/hls.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > > index 4ee4be769d..3199b0ac8d 100644
> > > --- a/libavformat/hls.c
> > > +++ b/libavformat/hls.c
> > > @@ -2277,7 +2277,7 @@ AVInputFormat ff_hls_demuxer = {
> > > .long_name = NULL_IF_CONFIG_SMALL("Apple HTTP Live Streaming"),
> > > .priv_class = &hls_class,
> > > .priv_data_size = sizeof(HLSContext),
> > > -.flags = AVFMT_NOGENSEARCH,
> > > +.flags = AVFMT_NOGENSEARCH | AVFMT_TS_DISCONT,
> > > .read_probe = hls_probe,
> > > .read_header= hls_read_header,
> > > .read_packet= hls_read_packet,
> >
> > I think I'm against this. HLS streams do not typically contain
> > timestamp resets (even if they could). Otherwise you might as well add
> >
>
> mpegts timestamps wrap every 26 hours, so any live continuous HLS broadcast
> is guaranteed to have a timestamp reset.
> Users have reported seeing these resets on various streams (
> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html), plus
> the HLS spec itself defines a EXT-X-DISCONTINUITY tag to signal
> discontinuities. So I don't think it's fair to say that discontinuities
> don't typically occur and can be ignored.
Wouldn't it be better to introduce a discontinuity notification then?
Then adding the discont flag would be redundant and could be avoided.
It looks like the HLS tag would map cleanly to this.
>
> > this flag to the Matroska demuxer. Besides, it would break some of my
> > code, which uses this flag as a heuristic to detect mpeg-ts style
> > non-container formats.
> >
>
> I'm working on a patchset with a new -remove_ts_discont option which will
> remove discontinuities and normalize timestamps. This
> option would only kick in for formats marked as AVFMT_TS_DISCONT, so I
> would like to see any formats where timestamp
> discontinuities are possible to be marked as such.
My suggestion would probably not block this.
> Maybe we can add another AVFMT flag that can be used as your heuristic?
Well, my heuristic is probably messed up and nonsense anyway. I'd just
find it nice if this isn't enabled to avoid currently released
versions, but I guess my argument is weak.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] configure: error out on unsupported MSVC versions
The FATE tests for MSVC versions older than 2013 are untested in FATE
and apparently are no longer supported.
This commit makes the configure process error out in case an older version
is used, and suggests to use a supported version of MSVC to compile.
This also changes the documentation to reflect this.
As discussed on IRC:
2018-05-12 19:45:16 jamrial then again, most of those were for old msvc,
and i think we're not supporting versions older than 2013 (first one c99
compliant) anymore
2018-05-12 19:45:43 +JEEB yea, I think 2013 update 2 is needed
22:53 <@atomnuker> nevcairiel: which commit broke/unsupported support for msvc
2013?
23:23 <@atomnuker> okay, it was JEEB
23:25 <+JEEB> which was for 2012 and older
23:25 <+JEEB> and IIRC we no longer test those in FATE so that was my assumption
23:26 <+JEEB> 2013 is when MS got trolled enough to actually update their C part
23:26 <+JEEB> aand actually advertised FFmpeg support
23:26 <+JEEB> (although it was semi-failing until VS2013 update 1 or 2)
Signed-off-by: Rostislav Pehlivanov
---
configure | 3 +--
doc/platform.texi | 16 +++-
2 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/configure b/configure
index 1f7d0140e3..e52f8f850b 100755
--- a/configure
+++ b/configure
@@ -3988,8 +3988,7 @@ case "$toolchain" in
cc_default="cl"
cxx_default="cl"
else
-cc_default="c99wrap cl"
-cxx_default="c99wrap cl"
+die "Unsupported MSVC version (2013 or newer required)"
fi
ld_default="$source_path/compat/windows/mslink"
nm_default="dumpbin -symbols"
diff --git a/doc/platform.texi b/doc/platform.texi
index bdfb6fd6a5..4090b85670 100644
--- a/doc/platform.texi
+++ b/doc/platform.texi
@@ -148,16 +148,11 @@ To target 32 bits replace @code{x86_64} with @code{i686}
in the command above.
@section Microsoft Visual C++ or Intel C++ Compiler for Windows
-FFmpeg can be built with MSVC 2012 or earlier using a C99-to-C89 conversion
utility
-and wrapper, or with MSVC 2013 and ICL natively.
+FFmpeg can be built with MSVC 2013 or later.
You will need the following prerequisites:
@itemize
-@item @uref{https://github.com/libav/c99-to-c89/, C99-to-C89 Converter &
Wrapper}
-(if using MSVC 2012 or earlier)
-@item @uref{http://code.google.com/p/msinttypes/, msinttypes}
-(if using MSVC 2012 or earlier)
@item @uref{http://msys2.github.io/, MSYS2}
@item @uref{http://www.nasm.us/, NASM}
(Also available via MSYS2's package manager.)
@@ -166,16 +161,13 @@ You will need the following prerequisites:
To set up a proper environment in MSYS2, you need to run @code{msys_shell.bat}
from
the Visual Studio or Intel Compiler command prompt.
-Place @code{yasm.exe} somewhere in your @code{PATH}. If using MSVC 2012 or
-earlier, place @code{c99wrap.exe} and @code{c99conv.exe} somewhere in your
-@code{PATH} as well.
+Place @code{yasm.exe} somewhere in your @code{PATH}.
Next, make sure any other headers and libs you want to use, such as zlib, are
located in a spot that the compiler can see. Do so by modifying the @code{LIB}
and @code{INCLUDE} environment variables to include the @strong{Windows-style}
paths to these directories. Alternatively, you can try to use the
-@code{--extra-cflags}/@code{--extra-ldflags} configure options. If using MSVC
-2012 or earlier, place @code{inttypes.h} somewhere the compiler can see too.
+@code{--extra-cflags}/@code{--extra-ldflags} configure options.
Finally, run:
@@ -217,8 +209,6 @@ can see.
@item FFmpeg has been tested with the following on i686 and x86_64:
@itemize
-@item Visual Studio 2010 Pro and Express
-@item Visual Studio 2012 Pro and Express
@item Visual Studio 2013 Pro and Express
@item Intel Composer XE 2013
@item Intel Composer XE 2013 SP1
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add skip_estimate_duration_from_pts
On Tue, May 15, 2018 at 04:06:24PM -0700, Aman Gupta wrote: > From: Aman Gupta > > For seekable mpegts streams, duration is calculated from > pts by seeking to the end of the file for a pts and subtracting > the initial pts to compute a duration. > > This can be expensive in terms of added latency during > probe, especially when streaming over a network. This new > option lets you skip the duration calculation, which is useful > when you don't care about the value and want to save some overhead. > > This patch is particularly useful when dealing with live mpegts > streams. Normally such streams are not seekable, so durations > are not calculated. However in my case I am dealing with a seekable > live mpegts stream (networked access to a .ts file which is still > being appended to). > > Signed-off-by: Aman Gupta > --- > libavformat/avformat.h | 7 +++ > libavformat/options_table.h | 1 + > libavformat/utils.c | 6 ++ > 3 files changed, 14 insertions(+) LGTM it may make sense to design a more generic system in the future where the user can specify what fields she needs (like duration) which fields she could use and which are completely useless. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: tag video streams with still images
On Tue, May 15, 2018 at 11:29:47AM -0700, Aman Gupta wrote: > From: Aman Gupta > > Parses the video_stream_descriptor (H.222 2.6.2) to look > for the still_picture_flag. This is exposed to the user > via a new AV_DISPOSITION_STILL_IMAGE. > > See for example https://tmm1.s3.amazonaws.com/music-choice.ts, > whose video stream only updates every ~6 seconds. > > Signed-off-by: Aman Gupta > --- > libavformat/avformat.h | 1 + > libavformat/dump.c | 2 ++ > libavformat/mpegts.c | 5 + > 3 files changed, 8 insertions(+) version needs to be updated also AV_DISPOSITION_STILL_IMAGE should be added to APIChanges should be ok otherwise thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: Fallback to duration if sample rate is unavailable
On Wed, May 02, 2018 at 02:57:11AM +0200, wm4 wrote:
> On Tue, 1 May 2018 22:44:07 +0200
> Michael Niedermayer wrote:
>
> > Regression since: af1761f7
> > Fixes: Division by 0
> > Fixes: ffmpeg_crash_1
> >
> > Found-by: Thuan Pham, Marcel Böhme, Andrew Santosa and Alexandru Razvan
> > Caciulescu with AFLSmart
> > Signed-off-by: Michael Niedermayer
> > ---
> > fftools/ffmpeg.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 5dc198f933..15fa54f24e 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -2706,8 +2706,12 @@ static int process_input_packet(InputStream *ist,
> > const AVPacket *pkt, int no_eo
> > ist->dts = ist->next_dts;
> > switch (ist->dec_ctx->codec_type) {
> > case AVMEDIA_TYPE_AUDIO:
> > -ist->next_dts += ((int64_t)AV_TIME_BASE *
> > ist->dec_ctx->frame_size) /
> > - ist->dec_ctx->sample_rate;
> > +if (ist->dec_ctx->sample_rate) {
> > +ist->next_dts += ((int64_t)AV_TIME_BASE *
> > ist->dec_ctx->frame_size) /
> > + ist->dec_ctx->sample_rate;
> > +} else {
> > +ist->next_dts += av_rescale_q(pkt->duration,
> > ist->st->time_base, AV_TIME_BASE_Q);
> > +}
> > break;
> > case AVMEDIA_TYPE_VIDEO:
> > if (ist->framerate.num) {
>
> Wouldn't it be better to error out here, instead of using yet another
> unreliable value and "hoping for the best"?
>
> Also I'm not sure, but I think unknown durations are sometimes set to
> -1 instead of 0.
The same update this patch would add is also done in the AVMEDIA_TYPE_VIDEO
below the changed AVMEDIA_TYPE_AUDIO.
I can add a special case and error out but then audio and video differ more
about -1, ill add a assert, the existing code prior to the patch would
already misbehave (in some cases) if its -1. So i will have to fix this
even without the patch if it happens
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/g2meet: Check RGB upper limit
On Sun, Apr 29, 2018 at 06:44:23PM +0200, Tomas Härdin wrote:
> sön 2018-04-29 klockan 16:41 +0200 skrev Michael Niedermayer:
> > On Fri, Apr 27, 2018 at 09:44:05PM +0200, Michael Niedermayer wrote:
> > > Fixes: runtime error: left shift of 1876744317 by 16 places cannot
> > > be represented in type 'int'
> > > Fixes: 6799/clusterfuzz-testcase-minimized-
> > > ffmpeg_AV_CODEC_ID_G2M_fuzzer-5115274731716608
> > >
> > > Found-by: continuous fuzzing process https://github.com/google/oss-
> > > fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavcodec/g2meet.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c
> > > index b409dae813..105a40278f 100644
> > > --- a/libavcodec/g2meet.c
> > > +++ b/libavcodec/g2meet.c
> > > @@ -556,7 +556,7 @@ static uint32_t
> > > epic_decode_pixel_pred(ePICContext *dc, int x, int y,
> > > B = ((pred >> B_shift) & 0xFF) - TOSIGNED(delta);
> > > }
> > >
> > > -if (R<0 || G<0 || B<0) {
> > > +if (R<0 || G<0 || B<0 || R > 255 || G > 255 || B > 255) {
> > > av_log(NULL, AV_LOG_ERROR, "RGB %d %d %d is out of
> > > range\n", R, G, B);
> > > return 0;
> >
> > i saw someone asked why this doesnt clip on the IRC backlog
> >
> > There is AFAIK no public spec so theres nothing really solid to base
> > a
> > preferrance on.
> >
> > I favor a hard error as it is easier t debug in case it misbehaves.
> > silently cliping (if its wrong) leads to more difficult to trace
> > issues.
> >
> > But if people prefer i can change it to clip of course.
>
> Be as strict as possible and ask for samples if someone has a file that
> breaks these expectations
>
ok will do
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/xwddec: fix palette alpha
On Wed, 16 May 2018, Paul B Mahol wrote: On 5/15/18, Marton Balint wrote: Signed-off-by: Marton Balint --- libavcodec/xwddec.c | 2 +- tests/ref/lavf/xwd | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) LGTM Thanks, applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/mpeg4videodec: Do not corrupt bits_per_raw_sample
On Sun, Apr 29, 2018 at 08:26:47PM +, Kieran Kunhya wrote: > On Sun, 29 Apr 2018 at 20:20 Michael Niedermayer > wrote: > > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/mpeg4videodec.c | 8 +--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > OK will apply (sorry for delay, this depended on the other patch) thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] avcodec/mpeg4videodec: Check bps (VOL header) before VOP for studio profile
On Sun, Apr 29, 2018 at 09:19:18PM +0200, Michael Niedermayer wrote: > Fixes: runtime error: shift exponent -1 is negative > Fixes: > 7486/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-4977380939530240 > > Fixes: runtime error: index 36 out of bounds for type 'const uint8_t [32]' > Fixes: > 7566/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-6536620682510336 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/mpeg4videodec.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/mpeg4video: Detect reference studio streams as studio streams
On Sun, Apr 29, 2018 at 11:21:58PM +, Kieran Kunhya wrote:
> On Sun, 29 Apr 2018 at 22:57 Michael Niedermayer
> wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/mpeg4video.h| 2 ++
> > libavcodec/mpeg4videodec.c | 25 -
> > 2 files changed, 18 insertions(+), 9 deletions(-)
> >
> > diff --git a/libavcodec/mpeg4video.h b/libavcodec/mpeg4video.h
> > index f974792887..dd0a59038d 100644
> > --- a/libavcodec/mpeg4video.h
> > +++ b/libavcodec/mpeg4video.h
> > @@ -41,6 +41,8 @@
> > #define NBIT_VO_TYPE 5
> > #define ARTS_VO_TYPE10
> > #define ACE_VO_TYPE 12
> > +#define SIMPLE_STUDIO_VO_TYPE 14
> > +#define CORE_STUDIO_VO_TYPE 15
> > #define ADV_SIMPLE_VO_TYPE 17
> >
> > #define VOT_VIDEO_ID 1
> > diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> > index ada5cdc6fa..d2b5e90331 100644
> > --- a/libavcodec/mpeg4videodec.c
> > +++ b/libavcodec/mpeg4videodec.c
> > @@ -46,6 +46,8 @@
> > #define MB_TYPE_B_VLC_BITS 4
> > #define STUDIO_INTRA_BITS 9
> >
> > +static int decode_studio_vol_header(Mpeg4DecContext *ctx, GetBitContext
> > *gb);
> > +
> > static VLC dc_lum, dc_chrom;
> > static VLC sprite_trajectory;
> > static VLC mb_type_b_vlc;
> > @@ -2049,6 +2051,18 @@ static int decode_vol_header(Mpeg4DecContext *ctx,
> > GetBitContext *gb)
> > /* vol header */
> > skip_bits(gb, 1); /* random access */
> > s->vo_type = get_bits(gb, 8);
> > +
> > +if (s->vo_type == CORE_STUDIO_VO_TYPE ||
> > +s->vo_type == SIMPLE_STUDIO_VO_TYPE) {
> > +if (s->avctx->profile != FF_PROFILE_UNKNOWN && s->avctx->profile
> > != FF_PROFILE_MPEG4_SIMPLE_STUDIO)
> > +return AVERROR_INVALIDDATA;
> > +s->studio_profile = 1;
> > +s->avctx->profile = FF_PROFILE_MPEG4_SIMPLE_STUDIO;
> > +return decode_studio_vol_header(ctx, gb);
> > +} else if (s->studio_profile) {
> > +return AVERROR_PATCHWELCOME;
> > +}
> > +
> > if (get_bits1(gb) != 0) { /* is_ol_id */
> > vo_ver_id = get_bits(gb, 4);/* vo_ver_id */
> > skip_bits(gb, 3); /* vo_priority */
> > @@ -3001,8 +3015,6 @@ static int decode_studio_vol_header(Mpeg4DecContext
> > *ctx, GetBitContext *gb)
> > int width, height;
> > int bits_per_raw_sample;
> >
> > -skip_bits1(gb); /* random_accessible_vol */
> > -skip_bits(gb, 8); /* video_object_type_indication */
> > skip_bits(gb, 4); /* video_object_layer_verid */
> >
>
> Please add a comment explaining what you've done here, someone might look
> at this code in 10 years time (exactly like I did) and not understand why
> you are mixing normal vol header and studio vol header.
yes, this is a good idea
Ill add some comments and apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/fic: Check available input space for cursor
On Sun, May 06, 2018 at 12:47:25AM +0200, Michael Niedermayer wrote:
> On Sat, May 05, 2018 at 11:12:06PM +0200, Paul B Mahol wrote:
> > On 5/5/18, wm4 wrote:
> > > On Sat, 5 May 2018 22:47:37 +0200
> > > Michael Niedermayer wrote:
> > >
> > >> Fixes: out of array read
> > >> Fixes:
> > >> 6546/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FIC_fuzzer-6317064647081984
> > >>
> > >> Found-by: continuous fuzzing process
> > >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > >> Signed-off-by: Michael Niedermayer
> > >> ---
> > >> libavcodec/fic.c | 5 +
> > >> 1 file changed, 5 insertions(+)
> > >>
> > >> diff --git a/libavcodec/fic.c b/libavcodec/fic.c
> > >> index d7ee370423..6824a5683c 100644
> > >> --- a/libavcodec/fic.c
> > >> +++ b/libavcodec/fic.c
> > >> @@ -337,6 +337,11 @@ static int fic_decode_frame(AVCodecContext *avctx,
> > >> void *data,
> > >> skip_cursor = 1;
> > >> }
> > >>
> > >> +if (!skip_cursor && avpkt->size < 59 + 32 * 32 * 4) {
> > >> +av_log(avctx, AV_LOG_WARNING, "Input is cursorless\n");
> > >> +skip_cursor = 1;
> > >> +}
> > >> +
> > >> /* Slice height for all but the last slice. */
> > >> ctx->slice_h = 16 * (ctx->aligned_height >> 4) / nslices;
> > >> if (ctx->slice_h % 16)
> > >
> > > No warning needed.
> >
> > Agreed.
>
> Do you prefer i remove the message completely or make it a debug level one ?
> Note, it seems every other case that sets skip_cursor in result of a
> unexpected condition prints something
will apply without the error message
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0 / COMPOSE_DD137iL0
On Mon, May 14, 2018 at 01:07:56AM +0200, Michael Niedermayer wrote: > Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka > 'int'); > Fixes: > 6500/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-4523620274536448 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/dirac_dwt.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compound literal in public header file
2018-05-16 11:47 GMT+02:00, Steinar H. Gunderson :
> On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:
>> Yes, I am referring to usage of the libavutil headers in C. If the macro
>> is
>> only hidden for C++ and available in C, that would be OK for me. But if
>> the
>> static inline function variant would support both C and C++, this would
>> look
>> like a solution where C++ users are not forced to implement a more
>> "integrated" replacement but of course have the option to do so.
>
> While we're at it, would it be possible to have extern "C" { for the
> headers,
> too? :-) (Wrapped in #ifdef __cplusplus, of course.)
No, because it would give the users of the headers the impression
that they are tested with c++ which - as you found out - they are not.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement
On Wed, May 16, 2018 at 11:25:01AM -0300, James Almer wrote: > On 5/16/2018 11:07 AM, Derek Buitenhuis wrote: > > On Mon, May 14, 2018 at 5:50 PM, Derek Buitenhuis > > wrote: > >> This is a little rambling / stream of thought, but take it as you will, > >> and perhaps some discussion or change comes of it. Or, more likely, > >> personal > >> attacks, flames, and no change. Or 1 few will reply and then the thread > >> will > >> die and people will go on like it never happened. Sorry to be pessimistic, > >> but history speaks for itself. > > > > 48 hours later and: > > - Some votes for repealing the CoC. > > - One vote for keeping > > I think the issue is not the lack of clear enforcement rules, but a lack > of a proactive enforcer, be it a person or a body. The CoC has done > nothing but give people something to say when they want to be passive > aggressive in a discussion. > Changing it to a more strict one like Videolan's will not affect that. > > This lack of interest you mentioned is exactly the issue. If it all > depends on the coordinated action and involvement of a dozen or so > developers, then nothing will happen. As i said, the one time action was > called for a developer's behavior, no voter showed up. > > I'm up for keeping it or making it stricter. But it needs to be > enforced. So how do we get a dozen or so people to stop looking away > every time someone is a dick in a thread? I have no magic bullet sadly, which is why i didnt reply. But if there is a consensus to enforce some CoC. Then it will be enforced. I think there is no such consensus though. And i dont (just) mean we lack consensus to kick people and close accounts, no not at all, it starts before that. Compare this to a case that has consensus. Like someone posting spam everyone will agree thats not ok or stay silent. Theres no lack of solutions and noone will need to write rules on how to deal with it. OTOH, when someone acts hostile. Most stay silent, someone might voice their opposition and chances are a few people will join either side depending on who they are better friends with. Now you have a problem and its difficult to handle with penalties, as there are 2 parties each beliving they are the good side and the other has done wrong. I think people should try to interpret others statements in a friendly way. Always try to act friendly and respectful towards others and try to help resolve conflicts and misunderstanings when they occur. When 2 people fight dont join the fight on the side of ones friend but try to resolve / stop the issue between the people ... Also iam not sure you are aware of it, but you have IMO been quite good at defusing / helping when there where conflicts/hostilities between people. I think we need more people with this talent [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fftools/ffmpeg: Check AVPacket->duration for being positive not just non zero
Some demuxers (mov, microdvd at least) set duration negative.
Signed-off-by: Michael Niedermayer
---
fftools/ffmpeg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5a19a09d9a..3aa2175b5d 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2619,7 +2619,7 @@ static int process_input_packet(InputStream *ist, const
AVPacket *pkt, int no_eo
ret = decode_video(ist, repeating ? NULL : &avpkt,
&got_output, &duration_pts, !pkt,
&decode_failed);
if (!repeating || !pkt || got_output) {
-if (pkt && pkt->duration) {
+if (pkt && pkt->duration > 0) {
duration_dts = av_rescale_q(pkt->duration,
ist->st->time_base, AV_TIME_BASE_Q);
} else if(ist->dec_ctx->framerate.num != 0 &&
ist->dec_ctx->framerate.den != 0) {
int ticks= av_stream_get_parser(ist->st) ?
av_stream_get_parser(ist->st)->repeat_pict+1 : ist->dec_ctx->ticks_per_frame;
@@ -2715,7 +2715,7 @@ static int process_input_packet(InputStream *ist, const
AVPacket *pkt, int no_eo
AVRational time_base_q = AV_TIME_BASE_Q;
int64_t next_dts = av_rescale_q(ist->next_dts, time_base_q,
av_inv_q(ist->framerate));
ist->next_dts = av_rescale_q(next_dts + 1,
av_inv_q(ist->framerate), time_base_q);
-} else if (pkt->duration) {
+} else if (pkt->duration > 0) {
ist->next_dts += av_rescale_q(pkt->duration,
ist->st->time_base, AV_TIME_BASE_Q);
} else if(ist->dec_ctx->framerate.num != 0) {
int ticks= av_stream_get_parser(ist->st) ?
av_stream_get_parser(ist->st)->repeat_pict + 1 : ist->dec_ctx->ticks_per_frame;
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/error: hidden macro av_err2str for C++
---
libavutil/error.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/error.h b/libavutil/error.h
index 71df4da..8a35fef 100644
--- a/libavutil/error.h
+++ b/libavutil/error.h
@@ -116,8 +116,10 @@ static inline char *av_make_error_string(char *errbuf,
size_t errbuf_size, int e
* Convenience macro, the return value should be used only directly in
* function arguments but never stand-alone.
*/
+#ifndef __cplusplus
#define av_err2str(errnum) \
av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0},
AV_ERROR_MAX_STRING_SIZE, errnum)
+#endif
/**
* @}
--
2.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/error: hidden macro av_err2str for C++
On 17 May 2018 at 05:46, Zhao Zhili wrote:
> ---
> libavutil/error.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavutil/error.h b/libavutil/error.h
> index 71df4da..8a35fef 100644
> --- a/libavutil/error.h
> +++ b/libavutil/error.h
> @@ -116,8 +116,10 @@ static inline char *av_make_error_string(char
> *errbuf, size_t errbuf_size, int e
> * Convenience macro, the return value should be used only directly in
> * function arguments but never stand-alone.
> */
> +#ifndef __cplusplus
> #define av_err2str(errnum) \
> av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0},
> AV_ERROR_MAX_STRING_SIZE, errnum)
> +#endif
>
> /**
> * @}
> --
> 2.9.5
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
NAK
Chopping off parts of the API because it doesn't play well when included in
a different language is not a good idea.
Just do #undef av_make_error_string in your own code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] examples/filtering_video: fix memory leak
On 2018年05月14日 20:17, Zhao Zhili wrote:
From: Zhao Zhili
---
doc/examples/filtering_video.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index 38ff9bb..225dccc 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -233,6 +233,7 @@ int main(int argc, char **argv)
if (packet.stream_index == video_stream_index) {
ret = avcodec_send_packet(dec_ctx, &packet);
+av_packet_unref(&packet);
if (ret < 0) {
av_log(NULL, AV_LOG_ERROR, "Error while sending a packet to the
decoder\n");
break;
@@ -269,8 +270,9 @@ int main(int argc, char **argv)
av_frame_unref(frame);
}
}
+} else {
+av_packet_unref(&packet);
}
-av_packet_unref(&packet);
}
end:
avfilter_graph_free(&filter_graph);
Ping for review.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters
On Wed, 2018-05-16 at 11:27 +0200, Hendrik Leppkes wrote: > On Wed, May 16, 2018 at 10:49 AM, Xiang, Haihao > wrote: > > On Wed, 2018-05-16 at 10:17 +0200, Hendrik Leppkes wrote: > > > On Wed, May 16, 2018 at 9:19 AM, Haihao Xiang > > > wrote: > > > > Signed-off-by: Haihao Xiang > > > > --- > > > > libavcodec/hevcdec.c | 5 + > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c > > > > index c8877626d2..13d868bb4f 100644 > > > > --- a/libavcodec/hevcdec.c > > > > +++ b/libavcodec/hevcdec.c > > > > @@ -344,6 +344,11 @@ static void export_stream_params(AVCodecContext > > > > *avctx, > > > > const HEVCParamSets *ps, > > > > avctx->colorspace = AVCOL_SPC_UNSPECIFIED; > > > > } > > > > > > > > +if (sps->vui.chroma_loc_info_present_flag) > > > > +avctx->chroma_sample_location = sps- > > > > > vui.chroma_sample_loc_type_top_field + 1; > > > > > > > > +else > > > > +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED; > > > > > > > > > > This change is incomplete, refer to the patch I proposed earlier: > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228100.html > > > > > > > Sorry I didn't see your proposal before. Per spec, once > > chroma_loc_info_present_flag is set, chroma_format_idc should be 1. I think > > it > > would be better to add some checks when parsing the sequence parameters. > > > > It makes no real difference because you still need the check to be > able to set the LEFT default value for 4:2:0 only. If chroma_sample_loc_type_top_field is set correctly when parsing SPS, we may set chroma_sample_loc_type_top_field + 1 for 4:2:0 below no matter the present flag if (sps->chroma_format_idc == 1) avctx->chroma_sample_location = sps->vui.chroma_sample_loc_type_top_field + 1; else avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED; Thanks Haihao > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] add support for parsing pssh box
Use structure AVEncryptionInitInfo to provide CENC initialization information
for the application.
Signed-off-by: Chen Zewu
---
libavformat/isom.h | 1 +
libavformat/mov.c | 64 ++
2 files changed, 65 insertions(+)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index fb36112..f0f5b2c 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -274,6 +274,7 @@ typedef struct MOVContext {
MOVFragmentIndex frag_index;
int atom_depth;
unsigned int aax_mode; ///< 'aax' file has been detected
+AVEncryptionInitInfo *cenc_init_info;
uint8_t file_key[20];
uint8_t file_iv[20];
void *activation_bytes;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1975011..f87f10b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6165,6 +6165,52 @@ static int mov_read_schm(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return 0;
}
+static int mov_read_pssh(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+int i, err;
+int64_t start_pos;
+uint8_t version = 0;
+uint32_t num_key_ids = 0;
+uint32_t data_size = 0;
+
+if (c->fc->nb_streams < 1)
+return AVERROR_INVALIDDATA;
+
+version = avio_r8(pb);
+avio_skip(pb, 3); /* flags */
+
+start_pos = avio_tell(pb);
+
+avio_skip(pb, 16); /* system id */
+
+if (version > 0) {
+num_key_ids = avio_rb32(pb);
+avio_skip(pb, 16*num_key_ids); /* KIDs */
+}
+
+data_size = avio_rb32(pb);
+
+if (c->cenc_init_info)
+av_log(c->fc, AV_LOG_WARNING, "Duplicated PSSH atom\n");
+av_free(c->cenc_init_info);
+c->cenc_init_info = av_encryption_init_info_alloc(16, num_key_ids, 16,
data_size);
+if (!c->cenc_init_info)
+return AVERROR(ENOMEM);
+
+avio_seek(pb, start_pos, SEEK_SET);
+avio_read(pb, c->cenc_init_info->system_id, 16);
+
+if (version > 0)
+avio_skip(pb, 4); /* kid_count */
+for (i = 0; i < num_key_ids; i++)
+avio_read(pb, c->cenc_init_info->key_ids[i], 16);
+
+avio_skip(pb, 4); /* data_size */
+avio_read(pb, c->cenc_init_info->data, data_size);
+
+return err;
+}
+
static int mov_read_tenc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
AVStream *st;
@@ -6507,6 +6553,7 @@ static const MOVParseTableEntry mov_default_parse_table[]
= {
{ MKTAG('s','a','i','z'), mov_read_saiz },
{ MKTAG('s','a','i','o'), mov_read_saio },
{ MKTAG('s','c','h','m'), mov_read_schm },
+{ MKTAG('p','s','s','h'), mov_read_pssh },
{ MKTAG('s','c','h','i'), mov_read_default },
{ MKTAG('t','e','n','c'), mov_read_tenc },
{ MKTAG('d','f','L','a'), mov_read_dfla },
@@ -6982,6 +7029,7 @@ static int mov_read_close(AVFormatContext *s)
}
av_freep(&mov->frag_index.item);
+av_freep(&mov->cenc_init_info);
av_freep(&mov->aes_decrypt);
av_freep(&mov->chapter_tracks);
@@ -7263,6 +7311,22 @@ static int mov_read_header(AVFormatContext *s)
ff_rfps_calculate(s);
+if (mov->cenc_init_info) {
+for (i = 0; i < s->nb_streams; i++) {
+AVStream *st = s->streams[i];
+uint8_t *info;
+size_t info_size;
+
+info = av_encryption_init_info_add_side_data(mov->cenc_init_info,
&info_size);
+if (!info)
+return AVERROR(ENOMEM);
+
+err = av_stream_add_side_data(st,
AV_PKT_DATA_ENCRYPTION_INIT_INFO, info, info_size);
+if (err < 0)
+break;
+}
+}
+
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
MOVStreamContext *sc = st->priv_data;
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
