date:20180426

Kieran Kunhya (2018-04-25):
> It was objected heavily to at the time

And eventually a decision was made. This is one of the problems of this
project: developers pulling in every direction without consistency nor
leadership. One step forward, two steps on the side, one step backward;
iterate.

>and if I recall correctly we agreed
> to review its presence later.

I do not remember any such agreement, but I may be mistaken. Please
provide a reference.

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] [PATCH v2 3/3] avformat/dashenc: Set mp4 as the default format for VP9

2018-04-26 Thread Jeyapal, Karthick



On 4/23/18 11:40 AM, Karthick J wrote:
> From: Karthick Jeyapal 
>
> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in 
> DASH.
> Hence in this muxer we will focus on supporting VP9 in MP4
> Have verified playout support of VP9+MP4 in Chrome and Firefox.
> ---
>  libavformat/dashenc.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index a5f58d4..211ef23 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -959,11 +959,10 @@ static int dash_init(AVFormatContext *s)
>  if (!ctx)
>  return AVERROR(ENOMEM);
>  
> -// choose muxer based on codec: webm for VP8/9 and opus, mp4 
> otherwise
> +// choose muxer based on codec: webm for VP8 and opus, mp4 otherwise
>  // note: os->format_name is also used as part of the mimetype of the
>  //   representation, e.g. video/
>  if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP9 ||
>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
>  snprintf(os->format_name, sizeof(os->format_name), "webm");

Pushed the patchset

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] FFserver further development direction


On 2018/04/25 23:18, Nicolas George wrote:

Josh de Kock (2018-04-25):

  If anything, this should have never been added and a suitable
external library should have been picked.


This opinion should have been expressed three years ago. It was decided
then that lavf deserved a HTTP server. It is done.



If I was part of this project three years ago, I most certainly would 
have done so. It's also not impossible, nor irrational to be removing 
code which doesn't fit or could be written better if an alternative is 
provided, the need was never there or removal can otherwise be justified.


--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

Josh de Kock (2018-04-26):
>  It's also not impossible, nor irrational to be removing code which
> doesn't fit or could be written better if an alternative is provided, the
> need was never there or removal can otherwise be justified.

Then justify. But you will need to address all the arguments that were
given three years ago.

The policy of this project has always been that for its core features it
must not depend on external libraries, apart from system libraries. What
exactly constitutes a "system library" is up for discussion, but in this
particular case there is no doubt.

What constitutes a "core feature" is also up for debate, but ffserver
have been part of the project for much more time than not, have many
users that are upset by its removal, and was only removed because the
code was an obsolete mess and nobody had the courage to rework it. It
seems unambiguous to me that ffserver IS a core feature of the project.

I will add two considerations:

First, the actual objections to having an HTTP server in the project are
about the maintenance burden, are they not? In that case, it seems to me
that the most weight in the decision should be given to people who have
an accurate idea of what it involves. So I ask: Do you consider yourself
skilled in network programming? Are you familiar with the RFCs
describing the HTTP protocol? Have you in the past implemented HTTP
servers?

Second, the habit of endlessly going back on past decisions is really
hurting the project. I know I have several ambitious goals for FFmpeg,
including a fully-typed option system with minimum string escaping. But
under the current conditions, there is no way I would ever start working
on them: we could decide today that the goal is worthy, but by the time
the first batch of development is done, some people will start
bieshedding it to death, and if it ever gets applied they will start
yapping "revert, revert" each time it causes a tiny bug.

Speaking for myself, I can say this: I will not perform anything more
than basic maintenance on code under my responsibility as long as this
project has this "one step forward, two steps on the side, one step
backward" mentality; that would be a waste of my time. So if you think
that my past work (especially the rework of the lavfi scheduling) had
merit, you should help finding a solution.

Electing a leader that can make final decisions and give the project
direction (no steps backward) would be one.

I will finish by saying the same thing in a shorter way:

Shut up, work and let people work.

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] [PATCH 4/4] avcodec/mediacodecdec: restructure mediacodec_receive_frame

2018-04-26 Thread Matthieu Bouron

On Tue, Apr 24, 2018 at 01:59:26PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> This fixes issues reported on some devices where both
> avcodec_send_packet and avcodec_receive_frame can return EAGAIN
> at the same time, instead of one or the other blocking.
> 
> The new logic follows a recommendation by @rcombs to use
> dequeueInputBuffer with a timeout of 0 as a way to detect
> whether the codec wants more data. The dequeued buffer index is
> kept in MediaCodecDecContext until it can be used next.
> 
> A similar technique is also used by the Google's official media
> player Exoplayer: see MediaCodecRenderer.feedInputBuffer().
> ---
>  libavcodec/mediacodecdec.c| 78 
> ---
>  libavcodec/mediacodecdec_common.c | 28 --
>  libavcodec/mediacodecdec_common.h |  4 +-
>  3 files changed, 59 insertions(+), 51 deletions(-)
> 
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index e5d3e6a0af..1a681d771e 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -391,33 +391,11 @@ done:
>  return ret;
>  }
>  
> -static int mediacodec_send_receive(AVCodecContext *avctx,
> -   MediaCodecH264DecContext *s,
> -   AVFrame *frame, bool wait)
> -{
> -int ret;
> -
> -/* send any pending data from buffered packet */
> -while (s->buffered_pkt.size) {
> -ret = ff_mediacodec_dec_send(avctx, s->ctx, &s->buffered_pkt);
> -if (ret == AVERROR(EAGAIN))
> -break;
> -else if (ret < 0)
> -return ret;
> -s->buffered_pkt.size -= ret;
> -s->buffered_pkt.data += ret;
> -if (s->buffered_pkt.size <= 0)
> -av_packet_unref(&s->buffered_pkt);
> -}
> -
> -/* check for new frame */
> -return ff_mediacodec_dec_receive(avctx, s->ctx, frame, wait);
> -}
> -
>  static int mediacodec_receive_frame(AVCodecContext *avctx, AVFrame *frame)
>  {
>  MediaCodecH264DecContext *s = avctx->priv_data;
>  int ret;
> +ssize_t index;
>  
>  /* in delay_flush mode, wait until the user has released or rendered
> all retained frames. */
> @@ -427,28 +405,52 @@ static int mediacodec_receive_frame(AVCodecContext 
> *avctx, AVFrame *frame)
>  }
>  }
>  
> -/* flush buffered packet and check for new frame */
> -ret = mediacodec_send_receive(avctx, s, frame, false);
> +/* poll for new frame */
> +ret = ff_mediacodec_dec_receive(avctx, s->ctx, frame, false);
>  if (ret != AVERROR(EAGAIN))
>  return ret;
>  
> -/* skip fetching new packet if we still have one buffered */
> -if (s->buffered_pkt.size > 0)
> -return mediacodec_send_receive(avctx, s, frame, true);
> +/* feed decoder */
> +while (1) {
> +if (s->ctx->current_input_buffer < 0) {
> +/* poll for input space */
> +index = ff_AMediaCodec_dequeueInputBuffer(s->ctx->codec, 0);
> +if (index < 0) {
> +/* no space, wait a while for an output frame to appear */
> +return ff_mediacodec_dec_receive(avctx, s->ctx, frame, true);
> +}
> +s->ctx->current_input_buffer = index;
> +}
>  
> -/* fetch new packet or eof */
> -ret = ff_decode_get_packet(avctx, &s->buffered_pkt);
> -if (ret == AVERROR_EOF) {
> -AVPacket null_pkt = { 0 };
> -ret = ff_mediacodec_dec_send(avctx, s->ctx, &null_pkt);
> -if (ret < 0)
> +/* try to flush any buffered packet data */
> +if (s->buffered_pkt.size > 0) {
> +ret = ff_mediacodec_dec_send(avctx, s->ctx, &s->buffered_pkt, 
> false);
> +if (ret > 0) {
> +s->buffered_pkt.size -= ret;
> +s->buffered_pkt.data += ret;
> +if (s->buffered_pkt.size <= 0)
> +av_packet_unref(&s->buffered_pkt);
> +} else if (ret < 0 && ret == AVERROR(EAGAIN)) {
> +return ret;
> +}
> +continue;
> +}
> +
> +/* fetch new packet or eof */
> +ret = ff_decode_get_packet(avctx, &s->buffered_pkt);
> +if (ret == AVERROR_EOF) {
> +AVPacket null_pkt = { 0 };
> +ret = ff_mediacodec_dec_send(avctx, s->ctx, &null_pkt, true);
> +if (ret < 0)
> +return ret;
> +}
> +else if (ret == AVERROR(EAGAIN) && s->ctx->current_input_buffer < 0)
> +return ff_mediacodec_dec_receive(avctx, s->ctx, frame, true);

If the input is starved on the FFmpeg side, we shouldn't block on trying
to receive a new frame from MediaCodec as it causes a performance
regression while the decoder is still not buffered enough to output its
first frame (after init or after a flush) as the function will end up
waiting 8ms for each new packet (for each call to avcodec_send_packet()).

Returning directly EAGAIN fro

Re: [FFmpeg-devel] [GSoC] FFserver further development direction


On 2018/04/24 22:33, Stephan Holljes wrote:

Hi all,

I've discussed this on IRC a bit, but I don't want to exclude those
views that are not present there.

The consensus seems to be that there are more disadvantages in using
the http server of libavformat than there are advantages.


I honestly think that it was misguided to add an HTTP server in its 
current form to FFmpeg and this isn't a job for libavformat.



This arose partly out of the discussion that there is no way to get a
connected peer's address through the public API (as the filedescriptor
is hidden in private structs).


Generally, adding more things to public API is a bad move, but I am 
unsure in this case (how would it work cross-platform anyway?)



The alternatives that were discussed were libmicrohttpd or writing the
whole project as an nginx module.


There is already an nginx module (with a more permissive 2-Clause BSD 
license, see: https://github.com/arut/nginx-rtmp-module) which seemingly 
does most of what you would want from a streaming server:


- RTMP/HLS/MPEG-DASH live streaming
- Stream relay support for distributed streaming: push & pull models
- Online transcoding with FFmpeg
- Recording streams


Both have their share of advantages and disadvantages. While I have
started to read the documentation on both of these, I can't clearly
point out which is the better choice.


It may be a good idea to make a list (or point me to one you've already 
made if I have missed it) which highlights all the features which an 
ideal FFserver would have, then look again at both of these options. 
Check how far this ideal is from the current nginx module.



Most people (including my mentor) spoke out in favor of utilizing nginx
As others have pointed out before, this, of course, excludes users who 
would like to use something like Apache, or even not run a separate 
web-server at all--however, how many users this affect and the actual 
impact not directly supporting those would have is debatable. There are 
already guides on how to use the nginx-rtmp module + Apache together in 
a streaming setup, for those whose setups are so large they must 
continue to use Apache.



I'd like to know what the rest of the developers think is best for the
project. Any pointers to good alternatives to look at or things to
think of we are missing are appreciated!


My suggestion would be to revisit all the current HTTP code in FFmpeg, 
and evaluate how much of it *actually* needs to be within the libraries, 
and how much of it can be delegated to good external libraries. (Someone 
recently made me aware of https://github.com/nodejs/http-parser it may 
be useful in some regards).



I am already not sure how to incorporate rtp into an nginx module
(since it is one of the goals on the roadmap). Maybe someone knows how
to either work around it or knows a project where that was done?


There doesn't seem to be any current project which implemented RTSP as a 
nginx module, but remember that nginx is a reverse proxy in itself and 
if it cannot be done within nginx as a module then you could implement a 
RTSP server which is then sent through nginx (I'm unsure why RTSP 
couldn't be implemented as a module though, but whatever). As for how to 
write an nginx module to do it, I honestly have no idea, but I would be 
happy to learn and support you along with your official mentor if you wish.


--
Josh

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

Josh de Kock (2018-04-26):
> Generally, adding more things to public API is a bad move

I do not accept this statement as is. Please justify it.

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] [PATCH 1/3] avformat/utils: function to get the formatted ntp time

2018-04-26 Thread Dixit, Vishwanath



On 4/26/18 1:04 AM, Michael Niedermayer wrote:
> On Tue, Apr 24, 2018 at 02:46:56PM +0530, vdi...@akamai.com wrote:
>> From: Vishwanath Dixit 
>>
>> This utility function creates 64-bit NTP time format as per the RFC
>> 5905.
>> A simple explaination of 64-bit NTP time format is here
>> http://www.beaglesoft.com/Manual/page53.htm
>> ---
>>  libavformat/internal.h |  8 
>>  libavformat/utils.c| 20 
>>  2 files changed, 28 insertions(+)
>>
>> diff --git a/libavformat/internal.h b/libavformat/internal.h
>> index 3582682..e9f758f 100644
>> --- a/libavformat/internal.h
>> +++ b/libavformat/internal.h
>> @@ -240,6 +240,14 @@ void ff_read_frame_flush(AVFormatContext *s);
>>  uint64_t ff_ntp_time(void);
>>  
>>  /**
>> + * Get the NTP time stamp formatted as per the RFC-5905.
>> + *
>> + * @param ntp_time NTP time in micro seconds (since NTP epoch)
>> + * @return the formatted NTP time stamp
>> + */
>> +uint64_t ff_time_ntp_format(uint64_t ntp_time);
>> +
>> +/**
>>   * Append the media-specific SDP fragment for the media stream c
>>   * to the buffer buff.
>>   *
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index c25eab4..b59d426 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -4637,6 +4637,26 @@ uint64_t ff_ntp_time(void)
>>  return (av_gettime() / 1000) * 1000 + NTP_OFFSET_US;
>>  }
>>  
>> +uint64_t ff_time_ntp_format(uint64_t ntp_time)
>> +{
>> +uint64_t ntp_ts, frac_part;
>> +uint32_t sec, usec;
>> +
>> +//current ntp time in seconds and micro seconds
>
>> +sec = ntp_time / 100;
>
> This can be truncated
Yes, but the truncated part is not getting discarded, as the following line is 
taking care of that. Please correct me if I have not understood what you have 
intended to say here.
>
>
>> +usec = ntp_time % 100;
>> +
>> +//encoding in ntp timestamp format
>> +frac_part = usec * 0xULL;
>> +frac_part /= 100;
>> +
>> +ntp_ts = (uint64_t) sec;
>> +ntp_ts <<= 32;
>> +ntp_ts |= frac_part;
>> +
>> +return ntp_ts;
>
> this looks similar to what av_rescale does.
Not really. This is a unique format as defined in RFC 5905. (please see this 
page for high level understanding of this format 
http://www.beaglesoft.com/Manual/page53.htm )
>
>
> also ff_time_ntp_format() is a bad name. It does not give any hint
> on if ntp time is the input or output of the call
Okay. I will submit a revised patch with a more meaningful function name. How 
does 'ff_get_formatted_ntp_time' sound like?
>
> [...]
>
>
>
> ___
> 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] [GSoC] FFserver further development direction


On 2018/04/26 11:56, Nicolas George wrote:

Josh de Kock (2018-04-26):

Generally, adding more things to public API is a bad move


I do not accept this statement as is. Please justify it.



What I mean by this is making private fields public is generally a bad 
move. They were initially made private for a reason, and if you suddenly 
need to modify them outside then you must ask: What does this new code 
do differently to all the other code which makes it require a private 
field?


It's a matter of consistency, if some new code could be written without 
requiring a private field to become public then this is better.
It's also a matter of complexity, the API is less complex if there are 
less public field. If it wasn't better then please submit a patch which 
makes all private fields public. Of course, this doesn't apply to 
everything sometimes there are genuine reasons for new API fields to be 
added but *generally* a smaller API leads to a better experience. I did 
say that in this case I was unsure.


--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove anatoliy prores encoder


On 2017/06/26 15:09, Paul B Mahol wrote:

Rationale:
- Slower then other encoder
- Less configurable
- Does not support alpha profile
- Does not set interlaced flag
- Worse output quality
- No need for 2 encoders

Signed-off-by: Paul B Mahol 

Is there any reason this was not pushed? I can't seem to see any 
argument against it.


--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] github

Hello,

I was wondering if there is any chance to move development to github? I.e. not 
just mirror, but as primary development repo, with issues and pull requests? 
Would make collaboration a *lot* easier (think of submitting a pr instead of 
having to generate/format/split patches).

Best

Daniel


signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove anatoliy prores encoder

2018-04-26 13:17 GMT+02:00, Josh de Kock :
> On 2017/06/26 15:09, Paul B Mahol wrote:
>> Rationale:
>> - Slower then other encoder
>> - Less configurable
>> - Does not support alpha profile
>> - Does not set interlaced flag
>> - Worse output quality
>> - No need for 2 encoders
>>
>> Signed-off-by: Paul B Mahol 
>>
> Is there any reason this was not pushed?
> I can't seem to see any argument against it.

It was shown in the past that this encoder is faster,
more efficient and produces better quality.

I don't know when this has changed.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github


> On 26 Apr 2018, at 12:15, Daniel Oberhoff  
> wrote:
> 
> Hello,
> 
> I was wondering if there is any chance to move development to github? I.e. 
> not just mirror, but as primary development repo, with issues and pull 
> requests? Would make collaboration a *lot* easier (think of submitting a pr 
> instead of having to generate/format/split patches).

While I wouldn't be against it, I think most other developers would be very 
strongly against it. And to that end, I would say there is no or an extremely 
small chance that we would move to github

Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

On Thu, 26 Apr 2018 12:47:58 +0200
Nicolas George  wrote:

> Josh de Kock (2018-04-26):
> >It's also not impossible, nor irrational to be removing code which
> > doesn't fit or could be written better if an alternative is provided, the
> > need was never there or removal can otherwise be justified.  
> 
> Then justify. But you will need to address all the arguments that were
> given three years ago.
> 
> The policy of this project has always been that for its core features it
> must not depend on external libraries, apart from system libraries. What
> exactly constitutes a "system library" is up for discussion, but in this
> particular case there is no doubt.
> 
> What constitutes a "core feature" is also up for debate, but ffserver
> have been part of the project for much more time than not, have many
> users that are upset by its removal, and was only removed because the
> code was an obsolete mess and nobody had the courage to rework it. It
> seems unambiguous to me that ffserver IS a core feature of the project.

So the whole argument is: we need a HTTP server, because a "core
feature" (which is really a separate program that uses that libav*
libs) needs it? That's a pretty rigid rule.

There are other external libraries we're relying on for relatively
important functionality, and which can not really be called system libs:
we support 3 or 4 TLS wrapper libs for HTTPS, libass for subtitle
rendering, some libs for reading and rendering MIDI-like file formats,
libx264 for h264 encoding (the most commonly used codec!), SDL for
ffplay, and some other codec libs for which we have builtin
implementations, because the builtin ones were too bad (AAC encoding
used to be one). There's probably more.

> I will add two considerations:
> 
> First, the actual objections to having an HTTP server in the project are
> about the maintenance burden, are they not? In that case, it seems to me
> that the most weight in the decision should be given to people who have
> an accurate idea of what it involves. So I ask: Do you consider yourself
> skilled in network programming? Are you familiar with the RFCs
> describing the HTTP protocol? Have you in the past implemented HTTP
> servers?

The HTTP _client_ in lavf is rather bad. I know because I get to use
it with a lot of websites. And it doesn't even support HTTP 2. Just
using libcurl or such would probably have saved us a lot of pain. API
users can't just use their own HTTP client btw., because other lavf
components depend on the native one too much.

I have no doubt the server code would end up with even poorer support.
The server code seems even barely used and was probably not
battle-tested with a large number of different clients.

Besides, it's a bad idea to extend the server APIs while the
libavformat I/O API is in its current state that is much in need for
cleanup, especially API-wise. Isn't the argument that we should not
add premature API up your alley?

In general badly NIH-ing something sufficiently complicated and that is
not quite in the central focus of the project will end up worse than
relying on completed external components that have spend a lot of time
to complete it, including fixing any bugs and issues.

> Second, the habit of endlessly going back on past decisions is really
> hurting the project. I know I have several ambitious goals for FFmpeg,

It was because the past decisions were not actually unanimous, so the
contra-forces, who didn't accept or even recognize the past decisions,
sometimes win back ground later. This happens because FFmpeg is a
project full of in-fighting.

> including a fully-typed option system with minimum string escaping. But
> under the current conditions, there is no way I would ever start working
> on them: we could decide today that the goal is worthy, but by the time
> the first batch of development is done, some people will start
> bieshedding it to death, and if it ever gets applied they will start
> yapping "revert, revert" each time it causes a tiny bug.
> 
> Speaking for myself, I can say this: I will not perform anything more
> than basic maintenance on code under my responsibility as long as this
> project has this "one step forward, two steps on the side, one step
> backward" mentality; that would be a waste of my time. So if you think

Well I don't think you're entirely innocent in that.

> that my past work (especially the rework of the lavfi scheduling) had
> merit, you should help finding a solution.

That's some kind of passive aggressive threat. Please don't do this,
because things like that only make the project more... difficult.

> Electing a leader that can make final decisions and give the project
> direction (no steps backward) would be one.
> 
> I will finish by saying the same thing in a shorter way:
> 
> Shut up, work and let people work.

You never follow that though. You participate in endless flames, until
the other side is tired and gives up.

> Regards,
> 

__

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove anatoliy prores encoder


On 2018/04/26 12:26, Carl Eugen Hoyos wrote:

2018-04-26 13:17 GMT+02:00, Josh de Kock :

On 2017/06/26 15:09, Paul B Mahol wrote:

Rationale:
- Slower then other encoder
- Less configurable
- Does not support alpha profile
- Does not set interlaced flag
- Worse output quality
- No need for 2 encoders

Signed-off-by: Paul B Mahol 


Is there any reason this was not pushed?
I can't seem to see any argument against it.


It was shown in the past that this encoder is faster,
more efficient and produces better quality.

I don't know when this has changed.



Ok, there was some discussion on IRC, so I was unsure. I will look into 
it again.


--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove anatoliy prores encoder

On 4/26/18, Carl Eugen Hoyos  wrote:
> 2018-04-26 13:17 GMT+02:00, Josh de Kock :
>> On 2017/06/26 15:09, Paul B Mahol wrote:
>>> Rationale:
>>> - Slower then other encoder
>>> - Less configurable
>>> - Does not support alpha profile
>>> - Does not set interlaced flag
>>> - Worse output quality
>>> - No need for 2 encoders
>>>
>>> Signed-off-by: Paul B Mahol 
>>>
>> Is there any reason this was not pushed?
>> I can't seem to see any argument against it.
>
> It was shown in the past that this encoder is faster,
> more efficient and produces better quality.

Why are you not telling real truth?

None of your claims are really true.

I wonder why.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/rtmpcrypt: Add a cast to silence a warning

2018-04-26 Thread Reino Wijnsma

On 22-4-2018 0:52, Reino Wijnsma  wrote:
> On 16-4-2018 0:19, Carl Eugen Hoyos  wrote:
>> rtmpe_write() exploits knowledge about av_rc4_crypt() internals and
>> passes the same
>> pointer as src and dst. I assume this is intentional for performance
>> reasons, the only
>> way to silence the resulting warning is a cast afaict.
>>
>> Please comment, Carl Eugen
> $ make libavformat/rtmpcrypt.o
> CC  libavformat/rtmpcrypt.o
>
> No more warning.
Hello Carl,

Are you going to push this patch as well?

-- Reino
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

2018-04-26 5:02 GMT+02:00, Aman Gupta :
> On Wed, Apr 25, 2018 at 5:30 PM Carl Eugen Hoyos  wrote:
>
>> 2018-04-25 4:07 GMT+02:00, Aman Gupta :
>>
>> > Processes only teletext pages marked as subtitles, so
>> > depending on the stream it might not produce any output.
>>
>> Shouldn't there be at least an option to output whatever
>> page was requested?
>
> The decoder will only parse subtitle pages, and there
> is no way to select a page by design.

What about several subtitle pages (for several languages)?

> One of the reasons I wrote this is because I wanted
> subtitles to just work without having to figure out
> which page to decode first.

And this appears like a very useful default but I assumed
it makes no big difference to "decode" a chosen page
instead of the default subtitle page.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

On Thu, 26 Apr 2018 13:15:52 +0200
Daniel Oberhoff  wrote:

> Hello,
> 
> I was wondering if there is any chance to move development to github? I.e. 
> not just mirror, but as primary development repo, with issues and pull 
> requests? Would make collaboration a *lot* easier (think of submitting a pr 
> instead of having to generate/format/split patches).

Using git send-email is actually simpler than sending a github PR. Also
github will delete or hide review comments once you force-push the PR
branch (after you've fixed things that were pointed out).

It would force everyone to use a complex and slow web interface.
There's no easily searchable archive of past reviews, like the mailing
list archive.

There is also this aspect that github is an US company and a single
point of failure. If there's a problem we couldn't just move the server
somewhere else. Github would also be in control who's allowed to
register and make posts, which seems rather strange to me.

Another small aspect is that we've seen really awful low quality
contributions on our github repository, even though we explicitly state
that we don't do PRs. There have been 130 pull requests ever since we
made a dummy PR that we ignore pull requests. Why open the flood gates?

So I have doubts that it would work for us.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove anatoliy prores encoder

On Thu, 26 Apr 2018 13:34:12 +0200
Paul B Mahol  wrote:

> On 4/26/18, Carl Eugen Hoyos  wrote:
> > 2018-04-26 13:17 GMT+02:00, Josh de Kock :  
> >> On 2017/06/26 15:09, Paul B Mahol wrote:  
> >>> Rationale:
> >>> - Slower then other encoder
> >>> - Less configurable
> >>> - Does not support alpha profile
> >>> - Does not set interlaced flag
> >>> - Worse output quality
> >>> - No need for 2 encoders
> >>>
> >>> Signed-off-by: Paul B Mahol 
> >>>  
> >> Is there any reason this was not pushed?
> >> I can't seem to see any argument against it.  
> >
> > It was shown in the past that this encoder is faster,
> > more efficient and produces better quality.  
> 
> Why are you not telling real truth?
> 
> None of your claims are really true.
> 
> I wonder why.

Can any of you post numbers?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove anatoliy prores encoder

2018-04-26 13:34 GMT+02:00, Paul B Mahol :
> On 4/26/18, Carl Eugen Hoyos  wrote:
>> 2018-04-26 13:17 GMT+02:00, Josh de Kock :
>>> On 2017/06/26 15:09, Paul B Mahol wrote:
 Rationale:
 - Slower then other encoder
 - Less configurable
 - Does not support alpha profile
 - Does not set interlaced flag
 - Worse output quality
 - No need for 2 encoders

 Signed-off-by: Paul B Mahol 

>>> Is there any reason this was not pushed?
>>> I can't seem to see any argument against it.
>>
>> It was shown in the past that this encoder is faster,
>> more efficient and produces better quality.
>
> Why are you not telling real truth?

This is surprisingly rude:
I am always trying to tell the truth, one of the things
that make me less happy about contributing here is
both that I am not allowed to write the truth anymore.

Anyway: In the discussion about adding one of the
features you mention above, tests were posted that
showed this encoder to produce better (objective,
with all its disadvantages) quality using measurably
less cycles.

> None of your claims are really true.

Given how much you embarrassed us in the prores
discussion, I wonder why you make this claim;-)

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/rtmpcrypt: Add a cast to silence a warning

2018-04-26 13:34 GMT+02:00, Reino Wijnsma :
> On 22-4-2018 0:52, Reino Wijnsma  wrote:
>> On 16-4-2018 0:19, Carl Eugen Hoyos  wrote:
>>> rtmpe_write() exploits knowledge about av_rc4_crypt() internals and
>>> passes the same
>>> pointer as src and dst. I assume this is intentional for performance
>>> reasons, the only
>>> way to silence the resulting warning is a cast afaict.
>>>
>>> Please comment, Carl Eugen
>> $ make libavformat/rtmpcrypt.o
>> CC  libavformat/rtmpcrypt.o
>>
>> No more warning.
> Hello Carl,
>
> Are you going to push this patch as well?

I wanted to request a documentation update
for av_rc4_crypt() first but I realize it is
already there;-)

Will push, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove anatoliy prores encoder

On 4/26/18, Carl Eugen Hoyos  wrote:
> 2018-04-26 13:34 GMT+02:00, Paul B Mahol :
>> On 4/26/18, Carl Eugen Hoyos  wrote:
>>> 2018-04-26 13:17 GMT+02:00, Josh de Kock :
 On 2017/06/26 15:09, Paul B Mahol wrote:
> Rationale:
> - Slower then other encoder
> - Less configurable
> - Does not support alpha profile
> - Does not set interlaced flag
> - Worse output quality
> - No need for 2 encoders
>
> Signed-off-by: Paul B Mahol 
>
 Is there any reason this was not pushed?
 I can't seem to see any argument against it.
>>>
>>> It was shown in the past that this encoder is faster,
>>> more efficient and produces better quality.
>>
>> Why are you not telling real truth?
>
> This is surprisingly rude:
> I am always trying to tell the truth, one of the things
> that make me less happy about contributing here is
> both that I am not allowed to write the truth anymore.
>
> Anyway: In the discussion about adding one of the
> features you mention above, tests were posted that
> showed this encoder to produce better (objective,
> with all its disadvantages) quality using measurably
> less cycles.

That was with default configuration for both of them.
That's like comparing apples and oranges.

I fail to see how that makes your statements true.

>
>> None of your claims are really true.
>
> Given how much you embarrassed us in the prores
> discussion, I wonder why you make this claim;-)

Now, this is just rude. I expected this all the time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove anatoliy prores encoder

On Thu, 26 Apr 2018 13:39:56 +0200
Carl Eugen Hoyos  wrote:

> 2018-04-26 13:34 GMT+02:00, Paul B Mahol :
> > On 4/26/18, Carl Eugen Hoyos  wrote:  
> >> 2018-04-26 13:17 GMT+02:00, Josh de Kock :  
> >>> On 2017/06/26 15:09, Paul B Mahol wrote:  
>  Rationale:
>  - Slower then other encoder
>  - Less configurable
>  - Does not support alpha profile
>  - Does not set interlaced flag
>  - Worse output quality
>  - No need for 2 encoders
> 
>  Signed-off-by: Paul B Mahol 
>   
> >>> Is there any reason this was not pushed?
> >>> I can't seem to see any argument against it.  
> >>
> >> It was shown in the past that this encoder is faster,
> >> more efficient and produces better quality.  
> >
> > Why are you not telling real truth?  
> 
> This is surprisingly rude:
> I am always trying to tell the truth, one of the things
> that make me less happy about contributing here is
> both that I am not allowed to write the truth anymore.

What would those truths be? Note: insults are not truths.

> Anyway: In the discussion about adding one of the
> features you mention above, tests were posted that
> showed this encoder to produce better (objective,
> with all its disadvantages) quality using measurably
> less cycles.
> 
> > None of your claims are really true.  
> 
> Given how much you embarrassed us in the prores
> discussion, I wonder why you make this claim;-)

That is surprisingly rude.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

Daniel Oberhoff (2018-04-26):
> I was wondering if there is any chance to move development to github?
> I.e. not just mirror, but as primary development repo, with issues and
> pull requests? Would make collaboration a *lot* easier (think of
> submitting a pr instead of having to generate/format/split patches).

If development involves working in a web browser a lot, count me out.
Can you point me to the command-line interface to GitHub?

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] [PATCH 2/2] avcodec: remove anatoliy prores encoder

2018-04-26 13:48 GMT+02:00, Paul B Mahol :
> On 4/26/18, Carl Eugen Hoyos  wrote:
>> 2018-04-26 13:34 GMT+02:00, Paul B Mahol :
>>> On 4/26/18, Carl Eugen Hoyos  wrote:
 2018-04-26 13:17 GMT+02:00, Josh de Kock :
> On 2017/06/26 15:09, Paul B Mahol wrote:
>> Rationale:
>> - Slower then other encoder
>> - Less configurable
>> - Does not support alpha profile
>> - Does not set interlaced flag
>> - Worse output quality
>> - No need for 2 encoders
>>
>> Signed-off-by: Paul B Mahol 
>>
> Is there any reason this was not pushed?
> I can't seem to see any argument against it.

 It was shown in the past that this encoder is faster,
 more efficient and produces better quality.
>>>
>>> Why are you not telling real truth?
>>
>> This is surprisingly rude:
>> I am always trying to tell the truth, one of the things
>> that make me less happy about contributing here is
>> both that I am not allowed to write the truth anymore.
>>
>> Anyway: In the discussion about adding one of the
>> features you mention above, tests were posted that
>> showed this encoder to produce better (objective,
>> with all its disadvantages) quality using measurably
>> less cycles.
>
> That was with default configuration for both of them.

Which is not the most likely usecase?

> That's like comparing apples and oranges.
>
> I fail to see how that makes your statements true.

You seem to remember the situation even better
than I do, so I really don't understand your
comments...

>>> None of your claims are really true.
>>
>> Given how much you embarrassed us in the prores
>> discussion, I wonder why you make this claim;-)
>
> Now, this is just rude.

No?

> I expected this all the time.

You expected all the time that prores actually is 12bit?
(I didn't)

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github


> Am 26.04.2018 um 13:52 schrieb Nicolas George :
> 
> Daniel Oberhoff (2018-04-26):
>> I was wondering if there is any chance to move development to github?
>> I.e. not just mirror, but as primary development repo, with issues and
>> pull requests? Would make collaboration a *lot* easier (think of
>> submitting a pr instead of having to generate/format/split patches).
> 
> If development involves working in a web browser a lot, count me out.
> Can you point me to the command-line 

https://hub.github.com/hub.1.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove anatoliy prores encoder

Paul B Mahol (2018-04-26):
> That was with default configuration for both of them.

Then please post a patch to enhance the default configuration.

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] [PATCH 2/2] avcodec: remove anatoliy prores encoder

On 4/26/18, Carl Eugen Hoyos  wrote:
> 2018-04-26 13:48 GMT+02:00, Paul B Mahol :
>> On 4/26/18, Carl Eugen Hoyos  wrote:
>>> 2018-04-26 13:34 GMT+02:00, Paul B Mahol :
 On 4/26/18, Carl Eugen Hoyos  wrote:
> 2018-04-26 13:17 GMT+02:00, Josh de Kock :
>> On 2017/06/26 15:09, Paul B Mahol wrote:
>>> Rationale:
>>> - Slower then other encoder
>>> - Less configurable
>>> - Does not support alpha profile
>>> - Does not set interlaced flag
>>> - Worse output quality
>>> - No need for 2 encoders
>>>
>>> Signed-off-by: Paul B Mahol 
>>>
>> Is there any reason this was not pushed?
>> I can't seem to see any argument against it.
>
> It was shown in the past that this encoder is faster,
> more efficient and produces better quality.

 Why are you not telling real truth?
>>>
>>> This is surprisingly rude:
>>> I am always trying to tell the truth, one of the things
>>> that make me less happy about contributing here is
>>> both that I am not allowed to write the truth anymore.
>>>
>>> Anyway: In the discussion about adding one of the
>>> features you mention above, tests were posted that
>>> showed this encoder to produce better (objective,
>>> with all its disadvantages) quality using measurably
>>> less cycles.
>>
>> That was with default configuration for both of them.
>
> Which is not the most likely usecase?

Even if it is, that is unfair comparison.
Because options and settings are incompatible.

I hope you understand this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

Daniel Oberhoff (2018-04-26):
> https://hub.github.com/hub.1.html

Thanks. So, how do I read a comment in an issue without a browser?

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] github


> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff 
> :
> 
> 
>> Am 26.04.2018 um 13:52 schrieb Nicolas George :
>> 
>> Daniel Oberhoff (2018-04-26):
>>> I was wondering if there is any chance to move development to github?
>>> I.e. not just mirror, but as primary development repo, with issues and
>>> pull requests? Would make collaboration a *lot* easier (think of
>>> submitting a pr instead of having to generate/format/split patches).
>> 
>> If development involves working in a web browser a lot, count me out.
>> Can you point me to the command-line 
> 
> https://hub.github.com/hub.1.html

But you can’t really do reviews that way, so the criticism stands.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github


> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff 
> :
> 
> 
>> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff 
>> :
>> 
>> 
>>> Am 26.04.2018 um 13:52 schrieb Nicolas George :
>>> 
>>> Daniel Oberhoff (2018-04-26):
 I was wondering if there is any chance to move development to github?
 I.e. not just mirror, but as primary development repo, with issues and
 pull requests? Would make collaboration a *lot* easier (think of
 submitting a pr instead of having to generate/format/split patches).
>>> 
>>> If development involves working in a web browser a lot, count me out.
>>> Can you point me to the command-line 
>> 
>> https://hub.github.com/hub.1.html
> 
> But you can’t really do reviews that way, so the criticism stands.

BTW, is there any kind of issue tracking?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Access to cuda functions

Hello,

I just started programming to directly use the cuda decoded frames on the gpu 
(working off master). Would it be possible to publicly expose the loaded cuda 
functions? This way I can inherit the possibility to build with cuda support 
but run in absence of cuda on the target. Currently these are hidden from the 
public interface.

Gruß!

Daniel Oberhoff
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Access to cuda functions

2018-04-26 Thread Hendrik Leppkes

On Thu, Apr 26, 2018 at 2:06 PM, Daniel Oberhoff
 wrote:
> Hello,
>
> I just started programming to directly use the cuda decoded frames on the gpu 
> (working off master). Would it be possible to publicly expose the loaded cuda 
> functions? This way I can inherit the possibility to build with cuda support 
> but run in absence of cuda on the target. Currently these are hidden from the 
> public interface.
>

This doesn't belong into the API, so thats not going to happen, but
the CUDA loader we use is public and you can just use it to do the
same thing:
http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

2018-04-26 Thread Hendrik Leppkes

On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
 wrote:
>
>> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff 
>> :
>>
>>
>>> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff 
>>> :
>>>
>>>
 Am 26.04.2018 um 13:52 schrieb Nicolas George :

 Daniel Oberhoff (2018-04-26):
> I was wondering if there is any chance to move development to github?
> I.e. not just mirror, but as primary development repo, with issues and
> pull requests? Would make collaboration a *lot* easier (think of
> submitting a pr instead of having to generate/format/split patches).

 If development involves working in a web browser a lot, count me out.
 Can you point me to the command-line
>>>
>>> https://hub.github.com/hub.1.html
>>
>> But you can’t really do reviews that way, so the criticism stands.
>
> BTW, is there any kind of issue tracking?

https://trac.ffmpeg.org/

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

2018-04-26 Thread James Darnley

On 2018-04-26 13:15, Daniel Oberhoff wrote:
> I was wondering if there is any chance to move development to github?
> I.e. not just mirror, but as primary development repo, with issues and
> pull requests? Would make collaboration a *lot* easier (think of
> submitting a pr instead of having to generate/format/split patches).

Github is proprietary software.  It encourages non-linear history which
we already suffer from due to merges from Libav.  It encourages bad
commits and really bad commit messages.  It requires a web browser and a
web browser with javascript.

If I wasn't clear, I would be against it.

signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

Josh de Kock (2018-04-26):
> >>Generally, adding more things to public API is a bad move

> What I mean by this is making private fields public is generally a bad move.
> They were initially made private for a reason, and if you suddenly need to
> modify them outside then you must ask: What does this new code do
> differently to all the other code which makes it require a private field?
> 
> It's a matter of consistency, if some new code could be written without
> requiring a private field to become public then this is better.
> It's also a matter of complexity, the API is less complex if there are less
> public field. If it wasn't better then please submit a patch which makes all
> private fields public. Of course, this doesn't apply to everything sometimes
> there are genuine reasons for new API fields to be added but *generally* a
> smaller API leads to a better experience. I did say that in this case I was
> unsure.

I think the statement you justified here is:

"Generally, adding more things to public API *without need* is a bad
move."

I agree with that statement. But I also agree with the statement:

Generally, adding more thing to public API when needed is a good move.

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] [GSoC] FFserver further development direction

On Thu, 26 Apr 2018 14:19:51 +0200
Nicolas George  wrote:

> Josh de Kock (2018-04-26):
> > >>Generally, adding more things to public API is a bad move  
> 
> > What I mean by this is making private fields public is generally a bad move.
> > They were initially made private for a reason, and if you suddenly need to
> > modify them outside then you must ask: What does this new code do
> > differently to all the other code which makes it require a private field?
> > 
> > It's a matter of consistency, if some new code could be written without
> > requiring a private field to become public then this is better.
> > It's also a matter of complexity, the API is less complex if there are less
> > public field. If it wasn't better then please submit a patch which makes all
> > private fields public. Of course, this doesn't apply to everything sometimes
> > there are genuine reasons for new API fields to be added but *generally* a
> > smaller API leads to a better experience. I did say that in this case I was
> > unsure.  
> 
> I think the statement you justified here is:
> 
> "Generally, adding more things to public API *without need* is a bad
> move."
> 
> I agree with that statement. But I also agree with the statement:
> 
> Generally, adding more thing to public API when needed is a good move.

All public API was added because someone felt a need for it at one time
in the past.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

>> 
>> BTW, is there any kind of issue tracking?
> 
> https://trac.ffmpeg.org/

oh, 1784 issues...


signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

On Thu, 26 Apr 2018 14:12:14 +0200
Hendrik Leppkes  wrote:

> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
>  wrote:
> >  
> >> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff 
> >> :
> >>
> >>  
> >>> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff 
> >>> :
> >>>
> >>>  
>  Am 26.04.2018 um 13:52 schrieb Nicolas George :
> 
>  Daniel Oberhoff (2018-04-26):  
> > I was wondering if there is any chance to move development to github?
> > I.e. not just mirror, but as primary development repo, with issues and
> > pull requests? Would make collaboration a *lot* easier (think of
> > submitting a pr instead of having to generate/format/split patches).  
> 
>  If development involves working in a web browser a lot, count me out.
>  Can you point me to the command-line  
> >>>
> >>> https://hub.github.com/hub.1.html  
> >>
> >> But you can’t really do reviews that way, so the criticism stands.  
> >
> > BTW, is there any kind of issue tracking?  
> 
> https://trac.ffmpeg.org/

To be fair, I'd prefer the github issue tracker over TRAC any day.
Still has the other problems I mentioned.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github


> On 26. Apr 2018, at 14:40, wm4  wrote:
> 
> On Thu, 26 Apr 2018 14:12:14 +0200
> Hendrik Leppkes mailto:h.lepp...@gmail.com>> wrote:
> 
>> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
>>  wrote:
>>> 
 Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff 
 :
 
 
> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff 
> :
> 
> 
>> Am 26.04.2018 um 13:52 schrieb Nicolas George :
>> 
>> Daniel Oberhoff (2018-04-26):
>>> I was wondering if there is any chance to move development to github?
>>> I.e. not just mirror, but as primary development repo, with issues and
>>> pull requests? Would make collaboration a *lot* easier (think of
>>> submitting a pr instead of having to generate/format/split patches).
>> 
>> If development involves working in a web browser a lot, count me out.
>> Can you point me to the command-line
> 
> https://hub.github.com/hub.1.html
 
 But you can’t really do reviews that way, so the criticism stands.
>>> 
>>> BTW, is there any kind of issue tracking?
>> 
>> https://trac.ffmpeg.org/
> 
> To be fair, I'd prefer the github issue tracker over TRAC any day.
> Still has the other problems I mentioned.

gitlab?



signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

2018-04-26 Thread Kieran O Leary

On Thu, 26 Apr 2018, 14:42 Daniel Oberhoff, 
wrote:

>
> > On 26. Apr 2018, at 14:40, wm4  wrote:
> >
> > On Thu, 26 Apr 2018 14:12:14 +0200
> > Hendrik Leppkes mailto:h.lepp...@gmail.com>>
> wrote:
> >
> >> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
> >>  wrote:
> >>>
>  Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff <
> danieloberh...@googlemail.com>:
> 
> 
> > Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff <
> danieloberh...@googlemail.com>:
> >
> >
> >> Am 26.04.2018 um 13:52 schrieb Nicolas George :
> >>
> >> Daniel Oberhoff (2018-04-26):
> >>> I was wondering if there is any chance to move development to
> github?
> >>> I.e. not just mirror, but as primary development repo, with issues
> and
> >>> pull requests? Would make collaboration a *lot* easier (think of
> >>> submitting a pr instead of having to generate/format/split
> patches).
> >>
> >> If development involves working in a web browser a lot, count me
> out.
> >> Can you point me to the command-line
> >
> > https://hub.github.com/hub.1.html
> 
>  But you can’t really do reviews that way, so the criticism stands.
> >>>
> >>> BTW, is there any kind of issue tracking?
> >>
> >> https://trac.ffmpeg.org/
> >
> > To be fair, I'd prefer the github issue tracker over TRAC any day.
> > Still has the other problems I mentioned.
>
> gitlab?
>


Mkvtoolnix moved to gitlab from GitHub due to some of the concerns raised
in this thread. The comments in this blog by Moritz Bunkus are worth
reading. https://www.bunkus.org/blog/2017/12/mkvtoolnix-moves-to-gitlab/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/1] make ffnvcodec headers work in c++ mode

Daniel Oberhoff (1):
  make headers compile in c++ mode

 include/ffnvcodec/dynlink_loader.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.14.3 (Apple Git-98)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/1] make headers compile in c++ mode

---
 include/ffnvcodec/dynlink_loader.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/ffnvcodec/dynlink_loader.h 
b/include/ffnvcodec/dynlink_loader.h
index 352a0c8..3b0a284 100644
--- a/include/ffnvcodec/dynlink_loader.h
+++ b/include/ffnvcodec/dynlink_loader.h
@@ -114,7 +114,7 @@
  \
 n##_free_functions(functions);   \
  \
-f = *functions = calloc(1, sizeof(*f));  \
+f = *functions = (T*)calloc(1, sizeof(*f));  \
 if (!f)  \
 return -1;   \
  \
-- 
2.14.3 (Apple Git-98)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] make headers compile in c++ mode

Daniel Oberhoff (2018-04-26):
> ---
>  include/ffnvcodec/dynlink_loader.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I may be missing something obvious, but I am not seeing this file in our
repository.

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] [PATCH 1/1] make headers compile in c++ mode


> On 26. Apr 2018, at 14:49, Nicolas George  wrote:
> 
> Daniel Oberhoff (2018-04-26):
>> ---
>> include/ffnvcodec/dynlink_loader.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> I may be missing something obvious, but I am not seeing this file in our
> repository.

sorry, its from the nv-codec-headers repo. Should have stated that in the 
subject. Is this not the right list for patches there?

Daniel


signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] make headers compile in c++ mode

On Thu, 26 Apr 2018 14:51:09 +0200
Daniel Oberhoff  wrote:

> > On 26. Apr 2018, at 14:49, Nicolas George  wrote:
> > 
> > Daniel Oberhoff (2018-04-26):  
> >> ---
> >> include/ffnvcodec/dynlink_loader.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)  
> > 
> > I may be missing something obvious, but I am not seeing this file in our
> > repository.  
> 
> sorry, its from the nv-codec-headers repo. Should have stated that in the 
> subject. Is this not the right list for patches there?

The repository is a ffmpeg project, so this is the right place.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec: remove duplicate prores decoder

Removed slower one, couldn't figure out why it is slower.

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |   1 -
 libavcodec/allcodecs.c  |   1 -
 libavcodec/proresdec_lgpl.c | 786 
 3 files changed, 788 deletions(-)
 delete mode 100644 libavcodec/proresdec_lgpl.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 4b8ad121db..d727b218dc 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -508,7 +508,6 @@ OBJS-$(CONFIG_PNG_ENCODER) += png.o pngenc.o
 OBJS-$(CONFIG_PPM_DECODER) += pnmdec.o pnm.o
 OBJS-$(CONFIG_PPM_ENCODER) += pnmenc.o
 OBJS-$(CONFIG_PRORES_DECODER)  += proresdec2.o proresdsp.o proresdata.o
-OBJS-$(CONFIG_PRORES_LGPL_DECODER) += proresdec_lgpl.o proresdsp.o 
proresdata.o
 OBJS-$(CONFIG_PRORES_ENCODER)  += proresenc_anatoliy.o
 OBJS-$(CONFIG_PRORES_AW_ENCODER)   += proresenc_anatoliy.o
 OBJS-$(CONFIG_PRORES_KS_ENCODER)   += proresenc_kostya.o proresdata.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 4d4ef530e4..102d99b7ea 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -234,7 +234,6 @@ extern AVCodec ff_prores_encoder;
 extern AVCodec ff_prores_decoder;
 extern AVCodec ff_prores_aw_encoder;
 extern AVCodec ff_prores_ks_encoder;
-extern AVCodec ff_prores_lgpl_decoder;
 extern AVCodec ff_psd_decoder;
 extern AVCodec ff_ptx_decoder;
 extern AVCodec ff_qdraw_decoder;
diff --git a/libavcodec/proresdec_lgpl.c b/libavcodec/proresdec_lgpl.c
deleted file mode 100644
index 3dbfb29011..00
--- a/libavcodec/proresdec_lgpl.c
+++ /dev/null
@@ -1,786 +0,0 @@
-/*
- * Apple ProRes compatible decoder
- *
- * Copyright (c) 2010-2011 Maxim Poliakovski
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-/**
- * @file
- * This is a decoder for Apple ProRes 422 SD/HQ/LT/Proxy and ProRes .
- * It is used for storing and editing high definition video data in Apple's 
Final Cut Pro.
- *
- * @see http://wiki.multimedia.cx/index.php?title=Apple_ProRes
- */
-
-#define LONG_BITSTREAM_READER // some ProRes vlc codes require up to 28 bits 
to be read at once
-
-#include 
-
-#include "libavutil/intmath.h"
-#include "avcodec.h"
-#include "idctdsp.h"
-#include "internal.h"
-#include "proresdata.h"
-#include "proresdsp.h"
-#include "get_bits.h"
-
-typedef struct ProresThreadData {
-const uint8_t *index;///< pointers to the data of this slice
-int slice_num;
-int x_pos, y_pos;
-int slice_width;
-int prev_slice_sf;   ///< scalefactor of the previous decoded 
slice
-DECLARE_ALIGNED(16, int16_t, blocks)[8 * 4 * 64];
-DECLARE_ALIGNED(16, int16_t, qmat_luma_scaled)[64];
-DECLARE_ALIGNED(16, int16_t, qmat_chroma_scaled)[64];
-} ProresThreadData;
-
-typedef struct ProresContext {
-ProresDSPContext dsp;
-AVFrame*frame;
-ScanTable  scantable;
-intscantable_type;   ///< -1 = uninitialized, 0 = 
progressive, 1/2 = interlaced
-
-intframe_type;   ///< 0 = progressive, 1 = top-field 
first, 2 = bottom-field first
-intpic_format;   ///< 2 = 422, 3 = 444
-uint8_tqmat_luma[64];///< dequantization matrix for luma
-uint8_tqmat_chroma[64];  ///< dequantization matrix for chroma
-intqmat_changed; ///< 1 - global quantization matrices 
changed
-inttotal_slices;///< total number of slices in a 
picture
-ProresThreadData *slice_data;
-intpic_num;
-intchroma_factor;
-intmb_chroma_factor;
-intnum_chroma_blocks;   ///< number of chrominance blocks in a 
macroblock
-intnum_x_slices;
-intnum_y_slices;
-intslice_width_factor;
-intslice_height_factor;
-intnum_x_mbs;
-intnum_y_mbs;
-intalpha_info;
-} ProresContext;
-
-
-static av_cold int decode_init(AVCodecContext *avctx)
-{
-ProresContext *ctx = avctx->priv_data;
-
-ctx->total_slices = 0;
-ctx->slice_data   = NULL;
-
-avctx->bits_per_raw_sample = PRORES_BITS_PER_SAMPLE;
-ff_proresdsp_init(&ctx->dsp, avctx);
-

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

On 4/26/2018 12:29 PM, wm4 wrote:
> You never follow that though. You participate in endless flames, until
> the other side is tired and gives up.

This. The one who has endless energy to argue their point wins on ffmpeg-devel,
not the one with the correct or even most-supported point. Observed numerous,
numerous times.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: add tmix filter

On 4/24/18, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi |  15 +
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/vf_mix.c | 158
> +++
>  4 files changed, 136 insertions(+), 39 deletions(-)
>

Will apply.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] make headers compile in c++ mode

2018-04-26 Thread Timo Rothenpieler

On 26.04.2018 14:47, Daniel Oberhoff wrote:
> ---
>  include/ffnvcodec/dynlink_loader.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/ffnvcodec/dynlink_loader.h 
> b/include/ffnvcodec/dynlink_loader.h
> index 352a0c8..3b0a284 100644
> --- a/include/ffnvcodec/dynlink_loader.h
> +++ b/include/ffnvcodec/dynlink_loader.h
> @@ -114,7 +114,7 @@
>   \
>  n##_free_functions(functions);   \
>   \
> -f = *functions = calloc(1, sizeof(*f));  \
> +f = *functions = (T*)calloc(1, sizeof(*f));  \
>  if (!f)  \
>  return -1;   \
>   \

applied



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] mov: Properly abide by the track's media duration

On 4/25/2018 4:07 PM, Derek Buitenhuis wrote:
> Ping.
> 
> If there are no further comments, I plan to push tomorrow evening.

It's been over 10 days, and the sole comment was addressed.

Pushed.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fftools/ffmpeg: properly initialize output stream field order

2018-04-26 Thread Tobias Rapp

Fixes stream field order written by avformat_write_header when "top"
option is specified on the command-line.

Signed-off-by: Tobias Rapp 
---
 fftools/ffmpeg.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4dbe721..a28786a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3379,6 +3379,12 @@ static int init_output_stream_encode(OutputStream *ost)
 enc_ctx->bits_per_raw_sample = frame_bits_per_raw_sample;
 }
 
+if (ost->top_field_first == 0) {
+enc_ctx->field_order = AV_FIELD_BB;
+} else if (ost->top_field_first == 1) {
+enc_ctx->field_order = AV_FIELD_TT;
+}
+
 if (ost->forced_keyframes) {
 if (!strncmp(ost->forced_keyframes, "expr:", 5)) {
 ret = av_expr_parse(&ost->forced_keyframes_pexpr, 
ost->forced_keyframes+5,
-- 
2.7.4


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Access to cuda functions

> On 26. Apr 2018, at 14:08, Hendrik Leppkes  wrote:
> 
> On Thu, Apr 26, 2018 at 2:06 PM, Daniel Oberhoff
>  wrote:
>> Hello,
>> 
>> I just started programming to directly use the cuda decoded frames on the 
>> gpu (working off master). Would it be possible to publicly expose the loaded 
>> cuda functions? This way I can inherit the possibility to build with cuda 
>> support but run in absence of cuda on the target. Currently these are hidden 
>> from the public interface.
>> 
> 
> This doesn't belong into the API, so thats not going to happen, but
> the CUDA loader we use is public and you can just use it to do the
> same thing:
> http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary

Hmm, what is the rationale? You do expose the cuda context, so you do expose 
the fact that you use the cuda library. Also this will only work if i load the 
same library (there may be multiple on one system). I guess using 
nv-codec-headers that would be given, but then I am exploiting an 
implementation detail. It seems so much cleaner to just expose the functions in 
the AVCUDADeviceContext...

signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Access to cuda functions

2018-04-26 Thread Timo Rothenpieler

I can't think of a situation where there'd possibly be more than one
nvidia driver installed on a system.
And even if, the same application loading a lib of the same name will
internally hit its reference counter and just use the exact same one again.



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: properly initialize output stream field order

On 4/26/2018 3:06 PM, Tobias Rapp wrote:
> +if (ost->top_field_first == 0) {
> +enc_ctx->field_order = AV_FIELD_BB;
> +} else if (ost->top_field_first == 1) {
> +enc_ctx->field_order = AV_FIELD_TT;
> +}

This doesn't look correct; ost->top_field_first is only
valid if ost->interlaced_frame is set. Wouldn't this
incorrectly set field_order on progressive streams,
which should be set to AV_FIELD_PROGRESSIVE?

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/1] nv-codec-headers: add flag enum for gl interop

*** BLURB HERE ***

Daniel Oberhoff (1):
  add CUgraphicsRegisterFlags enum

 include/ffnvcodec/dynlink_cuda.h | 8 
 1 file changed, 8 insertions(+)

-- 
2.14.3 (Apple Git-98)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/1] add CUgraphicsRegisterFlags enum

---
 include/ffnvcodec/dynlink_cuda.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvcodec/dynlink_cuda.h
index 2cc50bb..df1d316 100644
--- a/include/ffnvcodec/dynlink_cuda.h
+++ b/include/ffnvcodec/dynlink_cuda.h
@@ -68,6 +68,14 @@ typedef enum CUlimit_enum {
 CU_LIMIT_DEV_RUNTIME_PENDING_LAUNCH_COUNT = 4
 } CUlimit;
 
+typedef enum CUgraphicsRegisterFlags_enum {
+CU_GRAPHICS_REGISTER_FLAGS_NONE   = 0x00,
+CU_GRAPHICS_REGISTER_FLAGS_READ_ONLY  = 0x01,
+CU_GRAPHICS_REGISTER_FLAGS_WRITE_DISCARD  = 0x02,
+CU_GRAPHICS_REGISTER_FLAGS_SURFACE_LDST   = 0x04,
+CU_GRAPHICS_REGISTER_FLAGS_TEXTURE_GATHER = 0x08
+} CUgraphicsRegisterFlags;
+
 typedef struct CUDA_MEMCPY2D_st {
 size_t srcXInBytes;
 size_t srcY;
-- 
2.14.3 (Apple Git-98)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/vc1: fix out of bounds access of overlap filter

2018-04-26 Thread Jerome Borsboom

Overlap filtering of the first row and first column must be guarded
for out of bounds access of v->over_flags_plane.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1_loopfilter.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vc1_loopfilter.c b/libavcodec/vc1_loopfilter.c
index bab28a649f..4c0de7c025 100644
--- a/libavcodec/vc1_loopfilter.c
+++ b/libavcodec/vc1_loopfilter.c
@@ -110,19 +110,19 @@ void ff_vc1_i_overlap_filter(VC1Context *v)
  * we run the put_pixels loop, i.e. delayed by one row and one column. */
 for (i = 0; i < block_count; i++)
 if (v->pq >= 9 || v->condover == CONDOVER_ALL ||
-(v->over_flags_plane[mb_pos] && ((i & 5) == 1 || 
v->over_flags_plane[mb_pos - 1])))
+(v->over_flags_plane[mb_pos] && ((i & 5) == 1 || (s->mb_x && 
v->over_flags_plane[mb_pos - 1]
 vc1_h_overlap_filter(v, s->mb_x ? left_blk : cur_blk, cur_blk, i);
 
 if (v->fcm != ILACE_FRAME)
 for (i = 0; i < block_count; i++) {
 if (s->mb_x && (v->pq >= 9 || v->condover == CONDOVER_ALL ||
 (v->over_flags_plane[mb_pos - 1] &&
- ((i & 2) || v->over_flags_plane[mb_pos - 1 - s->mb_stride]
+ ((i & 2) || (!s->first_slice_line && 
v->over_flags_plane[mb_pos - 1 - s->mb_stride])
 vc1_v_overlap_filter(v, s->first_slice_line ? left_blk : 
topleft_blk, left_blk, i);
 if (s->mb_x == s->mb_width - 1)
 if (v->pq >= 9 || v->condover == CONDOVER_ALL ||
 (v->over_flags_plane[mb_pos] &&
- ((i & 2) || v->over_flags_plane[mb_pos - s->mb_stride])))
+ ((i & 2) || (!s->first_slice_line && 
v->over_flags_plane[mb_pos - s->mb_stride]
 vc1_v_overlap_filter(v, s->first_slice_line ? cur_blk : 
top_blk, cur_blk, i);
 }
 }
-- 
2.13.6

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: properly initialize output stream field order

2018-04-26 Thread Tobias Rapp


On 26.04.2018 16:11, Derek Buitenhuis wrote:

On 4/26/2018 3:06 PM, Tobias Rapp wrote:

+if (ost->top_field_first == 0) {
+enc_ctx->field_order = AV_FIELD_BB;
+} else if (ost->top_field_first == 1) {
+enc_ctx->field_order = AV_FIELD_TT;
+}


This doesn't look correct; ost->top_field_first is only
valid if ost->interlaced_frame is set. Wouldn't this
incorrectly set field_order on progressive streams,
which should be set to AV_FIELD_PROGRESSIVE?


"ost" is of type OutputStream here, which only has top_field_first with 
values auto=-1/bff=0/tff=1. AVFrame has the 
interlaced_frame/top_field_first pair you mentioned, while 
AVCodecContext has field_order.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Access to cuda functions

2018-04-26 Thread Hendrik Leppkes

On Thu, Apr 26, 2018 at 4:12 PM, Daniel Oberhoff
 wrote:
>
>> On 26. Apr 2018, at 14:08, Hendrik Leppkes  wrote:
>>
>> On Thu, Apr 26, 2018 at 2:06 PM, Daniel Oberhoff
>>  wrote:
>>> Hello,
>>>
>>> I just started programming to directly use the cuda decoded frames on the 
>>> gpu (working off master). Would it be possible to publicly expose the 
>>> loaded cuda functions? This way I can inherit the possibility to build with 
>>> cuda support but run in absence of cuda on the target. Currently these are 
>>> hidden from the public interface.
>>>
>>
>> This doesn't belong into the API, so thats not going to happen, but
>> the CUDA loader we use is public and you can just use it to do the
>> same thing:
>> http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary
>
> Hmm, what is the rationale? You do expose the cuda context, so you do expose 
> the fact that you use the cuda library. Also this will only work if i load 
> the same library (there may be multiple on one system). I guess using 
> nv-codec-headers that would be given, but then I am exploiting an 
> implementation detail. It seems so much cleaner to just expose the functions 
> in the AVCUDADeviceContext...
>

You could make this argument for every library. We expose the data,
how we access CUDA is an implementation detail, it might as well be
linked in instead of loaded at runtime and the user should not care.
We're not going to include the CUDA API/ABI in our public headers.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: properly initialize output stream field order

On 4/26/2018 3:49 PM, Tobias Rapp wrote:
> "ost" is of type OutputStream here, which only has top_field_first with 
> values auto=-1/bff=0/tff=1. AVFrame has the 
> interlaced_frame/top_field_first pair you mentioned, while 
> AVCodecContext has field_order.

Ah, I misunderstood the type and values of ost. Confusing naming...

Seems OK then, I suppose.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

2018-04-26 Thread Aman Gupta

On Thu, Apr 26, 2018 at 4:35 AM, Carl Eugen Hoyos 
wrote:

> 2018-04-26 5:02 GMT+02:00, Aman Gupta :
> > On Wed, Apr 25, 2018 at 5:30 PM Carl Eugen Hoyos 
> wrote:
> >
> >> 2018-04-25 4:07 GMT+02:00, Aman Gupta :
> >>
> >> > Processes only teletext pages marked as subtitles, so
> >> > depending on the stream it might not produce any output.
> >>
> >> Shouldn't there be at least an option to output whatever
> >> page was requested?
> >
> > The decoder will only parse subtitle pages, and there
> > is no way to select a page by design.
>
> What about several subtitle pages (for several languages)?
>
> > One of the reasons I wrote this is because I wanted
> > subtitles to just work without having to figure out
> > which page to decode first.
>
> And this appears like a very useful default but I assumed
> it makes no big difference to "decode" a chosen page
> instead of the default subtitle page.
>

Sure, that's a reasonable option to add for users who know they want a
specific page.


>
> Carl Eugen
> ___
> 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/1] add CUgraphicsRegisterFlags enum


> On 26. Apr 2018, at 16:20, Daniel Oberhoff  wrote:
> 
> ---
> include/ffnvcodec/dynlink_cuda.h | 8 
> 1 file changed, 8 insertions(+)
> 
> diff --git a/include/ffnvcodec/dynlink_cuda.h 
> b/include/ffnvcodec/dynlink_cuda.h
> index 2cc50bb..df1d316 100644
> --- a/include/ffnvcodec/dynlink_cuda.h
> +++ b/include/ffnvcodec/dynlink_cuda.h
> @@ -68,6 +68,14 @@ typedef enum CUlimit_enum {
> CU_LIMIT_DEV_RUNTIME_PENDING_LAUNCH_COUNT = 4
> } CUlimit;
> 
> +typedef enum CUgraphicsRegisterFlags_enum {
> +CU_GRAPHICS_REGISTER_FLAGS_NONE   = 0x00,
> +CU_GRAPHICS_REGISTER_FLAGS_READ_ONLY  = 0x01,
> +CU_GRAPHICS_REGISTER_FLAGS_WRITE_DISCARD  = 0x02,
> +CU_GRAPHICS_REGISTER_FLAGS_SURFACE_LDST   = 0x04,
> +CU_GRAPHICS_REGISTER_FLAGS_TEXTURE_GATHER = 0x08
> +} CUgraphicsRegisterFlags;
> +
> typedef struct CUDA_MEMCPY2D_st {
> size_t srcXInBytes;
> size_t srcY;
> --
> 2.14.3 (Apple Git-98)
> 


also need this

---
 include/ffnvcodec/dynlink_cuda.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvcodec/dynlink_cuda.h
index df1d316..24c37a7 100644
--- a/include/ffnvcodec/dynlink_cuda.h
+++ b/include/ffnvcodec/dynlink_cuda.h
@@ -107,8 +107,6 @@ typedef enum CUGLDeviceList_enum {
 CU_GL_DEVICE_LIST_NEXT_FRAME = 3,
 } CUGLDeviceList;

-#define CU_GRAPHICS_REGISTER_FLAGS_WRITE_DISCARD 2
-
 typedef CUresult CUDAAPI tcuInit(unsigned int Flags);
 typedef CUresult CUDAAPI tcuDeviceGetCount(int *count);
 typedef CUresult CUDAAPI tcuDeviceGet(CUdevice *device, int ordinal);
--
2.14.3 (Apple Git-98)



signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

2018-04-26 Thread Aman Gupta

On Wed, Apr 25, 2018 at 9:17 PM, Aman Gupta  wrote:

>
> On Wed, Apr 25, 2018 at 6:15 PM Marton Balint  wrote:
>
>>
>>
>> On Thu, 26 Apr 2018, Carl Eugen Hoyos wrote:
>>
>> > 2018-04-25 4:07 GMT+02:00, Aman Gupta :
>> >
>> >> Processes only teletext pages marked as subtitles, so
>> >> depending on the stream it might not produce any output.
>> >
>> > Shouldn't there be at least an option to output whatever
>> > page was requested?
>> >
>> > +1 for not needing an external dependency.
>>
>> Why? Libzvbi is LGPL. We might as well include *that* in the ffmpeg
>> codebase...
>
>
> I was under the impression that libzvbi was GPL2 like the rest of zapping.
> If I had known it was LGPL I probably wouldn't have gone down this route.
>

Another reason I discounted libzvbi is because it seems unmaintained,
without a new release is over 5 years. It is also not readily available on
macOS via homebrew because of this reason, so I wasn't easily able to try
it out (https://github.com/Homebrew/legacy-homebrew/pull/26315).


>
> It might make sense to merge this back into the zvbi based decoder, but
> I've never used zvbi so I'm not sure how it compares to the features I've
> implemented here. I will try to find some time to investigate, but to be
> honest this version is working very well for my needs and I'm not
> particularly motivated to add a dependency to my project.
>
> Aman
>
>
>>
>> I thought having a decoder which is inferior in features to an existing
>> one or re-inventing yet something again in ffmpeg code are two things we
>> are trying to avoid.
>>
>> Regards,
>> Marton
>> ___
>> 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] avcodec: add minimal teletext subtitle decoder

Aman Gupta (2018-04-26):
> Another reason I discounted libzvbi is because it seems unmaintained,
> without a new release is over 5 years.

Did the teletext standard evolve in the past five years?

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] [PATCH] avcodec/vc1: fix out of bounds access of overlap filter

2018-04-26 Thread James Almer

On 4/26/2018 11:49 AM, Jerome Borsboom wrote:
> Overlap filtering of the first row and first column must be guarded
> for out of bounds access of v->over_flags_plane.
> 
> Signed-off-by: Jerome Borsboom 
> ---
>  libavcodec/vc1_loopfilter.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/vc1_loopfilter.c b/libavcodec/vc1_loopfilter.c
> index bab28a649f..4c0de7c025 100644
> --- a/libavcodec/vc1_loopfilter.c
> +++ b/libavcodec/vc1_loopfilter.c
> @@ -110,19 +110,19 @@ void ff_vc1_i_overlap_filter(VC1Context *v)
>   * we run the put_pixels loop, i.e. delayed by one row and one column. */
>  for (i = 0; i < block_count; i++)
>  if (v->pq >= 9 || v->condover == CONDOVER_ALL ||
> -(v->over_flags_plane[mb_pos] && ((i & 5) == 1 || 
> v->over_flags_plane[mb_pos - 1])))
> +(v->over_flags_plane[mb_pos] && ((i & 5) == 1 || (s->mb_x && 
> v->over_flags_plane[mb_pos - 1]
>  vc1_h_overlap_filter(v, s->mb_x ? left_blk : cur_blk, cur_blk, 
> i);
>  
>  if (v->fcm != ILACE_FRAME)
>  for (i = 0; i < block_count; i++) {
>  if (s->mb_x && (v->pq >= 9 || v->condover == CONDOVER_ALL ||
>  (v->over_flags_plane[mb_pos - 1] &&
> - ((i & 2) || v->over_flags_plane[mb_pos - 1 - 
> s->mb_stride]
> + ((i & 2) || (!s->first_slice_line && 
> v->over_flags_plane[mb_pos - 1 - s->mb_stride])
>  vc1_v_overlap_filter(v, s->first_slice_line ? left_blk : 
> topleft_blk, left_blk, i);
>  if (s->mb_x == s->mb_width - 1)
>  if (v->pq >= 9 || v->condover == CONDOVER_ALL ||
>  (v->over_flags_plane[mb_pos] &&
> - ((i & 2) || v->over_flags_plane[mb_pos - 
> s->mb_stride])))
> + ((i & 2) || (!s->first_slice_line && 
> v->over_flags_plane[mb_pos - s->mb_stride]
>  vc1_v_overlap_filter(v, s->first_slice_line ? cur_blk : 
> top_blk, cur_blk, i);
>  }
>  }

Can confirm this fixes the Valgrind failures.

Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add support for unequal duration for VOD playlist

2018-04-26 Thread Somsak Sriprayoonsakul

Hello,

Do I need to do any other things to get this patch accepted?

Best Regards,

Somsak

soms...@gmail.com

On Fri, Apr 20, 2018 at 5:05 PM, Somsak Sriprayoonsakul 
wrote:

> (Sorry for spamming, forgot the sign off part)
>
> This patch make ffmpeg able to create a single HLS m3u8 with different
> duration in the same manifest for VOD playlist ype.
>
> This has benefit on optimizing HLS stream to start faster, having
> initially shorter duration. The later part of the
> stream could have longer duration, which lower server load (less number
> of files, less
> connection initiation needed on server side which is very significant in
> this HTTPS era).
>
> The similar capability was already exists in ffmpeg hlsenc.c, but only
> for
> live playlist. I just fix it a little bit to make it support VOD
> playlist..
>
> To create such VOD stream
>
> ffmpeg -i input -c:v libx264 -c:a aac \
>   -hls_init_time 2 -hls_time 8 \
>   -hls_list_size 5 -hls_playlist_type vod \
>   -f hls output_vod.m3u8
>
> VOD playlist will use hls_list_size as the intended number of chunk to
> use the hls_init_time.
>
> Signed-off-by: Somsak Sriprayoonsakul 
> ---
>  libavformat/hlsenc.c | 30 --
>  1 file changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index c27a66ea79..b6260b262d 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1026,26 +1026,28 @@ static int hls_append_segment(struct
> AVFormatContext *s, HLSContext *hls,
>
>  vs->last_segment = en;
>
> -// EVENT or VOD playlists imply sliding window cannot be used
> -if (hls->pl_type != PLAYLIST_TYPE_NONE)
> +// EVENT playlists imply sliding window cannot be used
> +if ( (hls->pl_type == PLAYLIST_TYPE_EVENT) || (hls->pl_type ==
> PLAYLIST_TYPE_NB) )
>  hls->max_nb_segments = 0;
>
>  if (hls->max_nb_segments && vs->nb_entries >= hls->max_nb_segments) {
> -en = vs->segments;
> -vs->initial_prog_date_time += en->duration;
> -vs->segments = en->next;
> -if (en && hls->flags & HLS_DELETE_SEGMENTS &&
> +if( hls->pl_type != PLAYLIST_TYPE_VOD ) {
> +en = vs->segments;
> +vs->initial_prog_date_time += en->duration;
> +vs->segments = en->next;
> +if (en && hls->flags & HLS_DELETE_SEGMENTS &&
>  #if FF_API_HLS_WRAP
> -!(hls->flags & HLS_SINGLE_FILE || hls->wrap)) {
> +!(hls->flags & HLS_SINGLE_FILE || hls->wrap)) {
>  #else
> -!(hls->flags & HLS_SINGLE_FILE)) {
> +!(hls->flags & HLS_SINGLE_FILE)) {
>  #endif
> -en->next = vs->old_segments;
> -vs->old_segments = en;
> -if ((ret = hls_delete_old_segments(s, hls, vs)) < 0)
> -return ret;
> -} else
> -av_free(en);
> +en->next = vs->old_segments;
> +vs->old_segments = en;
> +if ((ret = hls_delete_old_segments(s, hls, vs)) < 0)
> +return ret;
> +} else
> +av_free(en);
> +}
>  } else
>  vs->nb_entries++;
>
> --
> 2.14.1
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/vc1: fix out of bounds access of overlap filter

On 4/26/18, Jerome Borsboom  wrote:
> Overlap filtering of the first row and first column must be guarded
> for out of bounds access of v->over_flags_plane.
>
> Signed-off-by: Jerome Borsboom 
> ---
>  libavcodec/vc1_loopfilter.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

2018-04-26 Thread Aman Gupta

On Thu, Apr 26, 2018 at 8:12 AM, Nicolas George  wrote:

> Aman Gupta (2018-04-26):
> > Another reason I discounted libzvbi is because it seems unmaintained,
> > without a new release is over 5 years.
>
> Did the teletext standard evolve in the past five years?
>

I don't know, but there it is atleast one bug causing tests to fail on
macOS which has been unfixed for 4 years.

I managed to install libzvbi by hand and try it out. With `-txt_format
text`, the generated output text is the same but without positions/colors.
The ASS positioning code could be ported over, but it looks like
vbi_print_page_region() strips out all the color information so there
doesn't seem to be an obvious way to support text coloring.

The zvbi decoder also hardcodes a (configurable) 30s end time per subtitle,
which causes them to pile up on the screen and not disappear when they're
supposed to. The logic from my decoder could also probably be ported over,
under a new `-real_time 1` flag like I added to ccaption_dec last year.

Here's a side by side comparison:
https://dzwonsemrish7.cloudfront.net/items/2x1z3k0C0X3v0Z2j1F3b/teletext-sub-comparison.jpg

I agree it would be ideal to have only one teletext decoder that works for
everyone. However I'm done with my teletext project, and don't have time
right now to redo all that work in the zvbi encoder. I also live in an ATSC
region and don't use teletext myself, so I don't really care whether or not
my decoder is merged into ffmpeg. I only shared it because some people on
IRC expressed interest.

Aman

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> 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] avcodec: add minimal teletext subtitle decoder

2018-04-26 Thread Michael Niedermayer

On Thu, Apr 26, 2018 at 03:15:08AM +0200, Marton Balint wrote:
> 
> 
> On Thu, 26 Apr 2018, Carl Eugen Hoyos wrote:
> 
> >2018-04-25 4:07 GMT+02:00, Aman Gupta :
> >
> >>Processes only teletext pages marked as subtitles, so
> >>depending on the stream it might not produce any output.
> >
> >Shouldn't there be at least an option to output whatever
> >page was requested?
> >
> >+1 for not needing an external dependency.
> 
> Why? Libzvbi is LGPL. We might as well include *that* in the ffmpeg
> codebase...

iam not against including it at all, if its unmaintained outside and
not widely available and someone wants to maintain it in ffmpeg.

I mean if its usefull to us and would without action die, it surely
would make sense ...

some mails in this thread sound a bit in this direction but i do not
know ...

> 
> I thought having a decoder which is inferior in features to an existing one
> or re-inventing yet something again in ffmpeg code are two things we are
> trying to avoid.

Its important that our code is feature complete in relation to what our users
expect.
I do not know how libzvbi compares here to the patch.

also my personal contact with teletext very very long ago didnt give me the
impression that it was complex. This may have changed so my view may be
drawn toward a misconception that this is not that complex ...

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates

signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

2018-04-26 Thread Lou Logan

On Thu, Apr 26, 2018, at 4:40 AM, wm4 wrote:
>
> To be fair, I'd prefer the github issue tracker over TRAC any day.

At least it isn't Bugzilla. What are some of the problems with trac? Is there a 
self-hostable bug tracker you prefer?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-04-26 Thread Oscar Amoros Huguet

Thanks Mark,

You are right, we can implement in our code a sort of "av_hwdevice_ctx_set" 
(which does not exist), by using av_hwdevice_ctx_alloc() + 
av_hwdevice_ctx_init(). We actually use av_hwdevice_ctx_alloc in our code to 
use the feature we implemented already. We are not sure about license 
implications though, we link dynamically to work with LGPL. I guess both calls 
are public, since they are not in "internal" labelled files.

We are perfectly ok with using av_hwdevice_ctx_alloc() + av_hwdevice_ctx_init() 
outside ffmpeg, to use our own CUDA context. By doing so, in the current ffmpeg 
code, there is an internal flag " AVCUDADeviceContextInternal.is_allocated" 
that is not set to 1, therefore, the cuda context is not destroyed by ffmpeg in 
"cuda_device_uninit", which is the desired behavior.

In fact, this flag implies that the context was not allocated by ffmpeg. Maybe 
this is the right flag to be used to avoid push/pop pairs when the CUDA context 
is not created by ffmpeg. What do you think?

We can adapt all of the push/pop pairs on the code, to follow this policy, 
whichever flag is used.

About the performance effects of this push/pop calls, we have seen with NVIDIA 
profiling tools (NSIGHT for Visual Studio plugin), that the CUDA runtime 
detects that the context you wat to set is the same as the one currently set, 
so the push call does nothing and lasts 0.0016 ms in average (CPU time). But 
for some reason, the cuCtxPopCurrent call, does take some more time, and uses 
0.02 ms of CPU time per call. This is 0,16 ms total per frame when decoding 8 
feeds. This is small, but it's easy to remove. 

Additionally, could you give your opinion on the feature we also may want to 
add in the future, that we mentioned in the previous email? Basically, we may 
want to add one more CUDA function, specifically cuMemcpy2DAsync, and the 
possibility to set a CUStream in AVCUDADeviceContext, so it is used with 
cuMemcpy2DAsync instead of cuMemcpy2D in "nvdec_retrieve_data" in file 
libavcodec/nvdec.c. In our use case this would save up to  0.72 ms (GPU time) 
per frame, in case of decoding 8 fullhd frames, and up to 0.5 ms (GPU time) per 
frame, in case of decoding two 4k frames. This may sound too little, but for us 
is significant. Our software needs to do many things in a maximum of 33ms with 
CUDA on the GPU per frame, and we have little GPU time left.

You can see all the explained above, in the following image: 
https://ibb.co/hASLZH

Thank you for your time.

Oscar

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

On Thu, 26 Apr 2018 08:59:03 -0800
Lou Logan  wrote:

> On Thu, Apr 26, 2018, at 4:40 AM, wm4 wrote:
> >
> > To be fair, I'd prefer the github issue tracker over TRAC any day.  
> 
> At least it isn't Bugzilla. What are some of the problems with trac? Is there 
> a self-hostable bug tracker you prefer?

It's very slow, and the GUI sucks. It has no usable search functions,
and trying to get a ticket list is a horror. Also its UI is cluttered
bugzilla-style, although not as horribly as bugzilla.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu/threadmessage: add av_thread_message_queue_nelem()

2018-04-26 Thread Clément Bœsch

On Mon, Apr 23, 2018 at 02:13:41AM +0200, Michael Niedermayer wrote:
[...]
> doesnt document the AVERROR case
> 

added

> should be ok otherwise, no more comments from me
> 

thx, applied

-- 
Clément B.


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/2] lavu/opt: add AV_OPT_FLAG_DEPRECATED

2018-04-26 Thread Clément Bœsch

On Sun, Apr 22, 2018 at 05:00:45PM +0200, wm4 wrote:
> On Sun, 22 Apr 2018 16:38:08 +0200
> Clément Bœsch  wrote:
> 
> > ---
> > TODO: APIChanges + lavu minor bump (not done yet because it will
> > conflict with the threadmessage patch)
> > ---
> >  libavutil/opt.c | 6 ++
> >  libavutil/opt.h | 1 +
> >  2 files changed, 7 insertions(+)
> > 
> > diff --git a/libavutil/opt.c b/libavutil/opt.c
> > index 3b0aab4ee8..99282605f5 100644
> > --- a/libavutil/opt.c
> > +++ b/libavutil/opt.c
> > @@ -463,6 +463,9 @@ int av_opt_set(void *obj, const char *name, const char 
> > *val, int search_flags)
> >  if (o->flags & AV_OPT_FLAG_READONLY)
> >  return AVERROR(EINVAL);
> >  
> > +if (o->flags & AV_OPT_FLAG_DEPRECATED)
> > +av_log(obj, AV_LOG_WARNING, "The \"%s\" option is deprecated: 
> > %s\n", name, o->help);
> > +
> >  dst = ((uint8_t *)target_obj) + o->offset;
> >  switch (o->type) {
> >  case AV_OPT_TYPE_BOOL:
> > @@ -759,6 +762,9 @@ int av_opt_get(void *obj, const char *name, int 
> > search_flags, uint8_t **out_val)
> >  if (!o || !target_obj || (o->offset<=0 && o->type != 
> > AV_OPT_TYPE_CONST))
> >  return AVERROR_OPTION_NOT_FOUND;
> >  
> > +if (o->flags & AV_OPT_FLAG_DEPRECATED)
> > +av_log(obj, AV_LOG_WARNING, "The \"%s\" option is deprecated: 
> > %s\n", name, o->help);
> > +
> >  dst = (uint8_t *)target_obj + o->offset;
> >  
> >  buf[0] = 0;
> > diff --git a/libavutil/opt.h b/libavutil/opt.h
> > index 07da68ea23..1352741fb6 100644
> > --- a/libavutil/opt.h
> > +++ b/libavutil/opt.h
> > @@ -289,6 +289,7 @@ typedef struct AVOption {
> >  #define AV_OPT_FLAG_READONLY128
> >  #define AV_OPT_FLAG_BSF_PARAM   (1<<8) ///< a generic parameter which 
> > can be set by the user for bit stream filtering
> >  #define AV_OPT_FLAG_FILTERING_PARAM (1<<16) ///< a generic parameter which 
> > can be set by the user for filtering
> > +#define AV_OPT_FLAG_DEPRECATED  (1<<17)
> >  //FIXME think about enc-audio, ... style flags
> >  
> >  /**
> 
> Seems like a good idea.

documented & applied.

thx

-- 
Clément B.


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: add minimal teletext subtitle decoder

2018-04-26 Thread Michael Niedermayer

On Tue, Apr 24, 2018 at 07:07:58PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Based largely on VLC's modules/codec/telx.c.
> 
> Processes only teletext pages marked as subtitles, so depending
> on the stream it might not produce any output.
> 
> Subtitles are rendered directly to ASS, with support for background
> colors and a best-effort at screen positioning. The ASS packets
> are emitted in real time (similar to ccaption_dec's real_time
> option), with -1 durations. The decoder expects that the player
> will remove all existing subtitles whenever a new packet arrives.
> 
> The teletext clear command is implemented using an empty subtitle,
> which removes existing subtitles but does not render anything new.
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/teletextsubdec.c | 522 
> 
>  3 files changed, 524 insertions(+)
>  create mode 100644 libavcodec/teletextsubdec.c

this produces some warnings:
libavcodec/teletextsubdec.c: In function ‘teletext_decode_frame’:
libavcodec/teletextsubdec.c:439:77: warning: variable ‘f_news’ set but not used 
[-Wunused-but-set-variable]
libavcodec/teletextsubdec.c:439:67: warning: variable ‘f_update’ set but not 
used [-Wunused-but-set-variable]
libavcodec/teletextsubdec.c:439:55: warning: variable ‘f_suppress’ set but not 
used [-Wunused-but-set-variable]
libavcodec/teletextsubdec.c:439:44: warning: variable ‘f_inhibit’ set but not 
used [-Wunused-but-set-variable]
libavcodec/teletextsubdec.c:438:24: warning: variable ‘page’ set but not used 
[-Wunused-but-set-variable]

[...]
-- 
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

[FFmpeg-devel] [PATCH] lavu, lavc/amf: hwcontext_amf phase 1. move AMF library and AMF device management from amfenc to hwcontext_amf

2018-04-26 Thread Alexander Kravchenko

This patch moves AMF library and AMF device management from amfenc to 
hwcontext_amf.
Now av_hwdevice_ctx API is used for AMF library/context creation/destroying
Phase 2 probably will include frame interop/map functions using hwframe_ctx API

---
 libavcodec/amfenc.c| 250 ---
 libavcodec/amfenc.h|  27 +---
 libavutil/Makefile |   2 +
 libavutil/hwcontext.c  |   4 +
 libavutil/hwcontext.h  |   1 +
 libavutil/hwcontext_amf.c  | 329 +
 libavutil/hwcontext_amf.h  |  43 ++
 libavutil/hwcontext_internal.h |   1 +
 8 files changed, 418 insertions(+), 239 deletions(-)
 create mode 100644 libavutil/hwcontext_amf.c
 create mode 100644 libavutil/hwcontext_amf.h

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 384d8efc92..a8186c7b86 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -21,13 +21,7 @@
 #include "libavutil/avassert.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/hwcontext.h"
-#if CONFIG_D3D11VA
-#include "libavutil/hwcontext_d3d11va.h"
-#endif
-#if CONFIG_DXVA2
-#define COBJMACROS
-#include "libavutil/hwcontext_dxva2.h"
-#endif
+
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/time.h"
@@ -35,14 +29,12 @@
 #include "amfenc.h"
 #include "internal.h"
 
-#if CONFIG_D3D11VA
-#include 
+#if CONFIG_DXVA2
+#include 
 #endif
 
-#ifdef _WIN32
-#include "compat/w32dlfcn.h"
-#else
-#include 
+#if CONFIG_D3D11VA
+#include 
 #endif
 
 #define FFMPEG_AMF_WRITER_ID L"ffmpeg_amf"
@@ -88,34 +80,17 @@ static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum 
AVPixelFormat fmt)
 return AMF_SURFACE_UNKNOWN;
 }
 
-static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter *pThis,
-const wchar_t *scope, const wchar_t *message)
-{
-AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
-av_log(tracer->avctx, AV_LOG_DEBUG, "%ls: %ls", scope, message); // \n is 
provided from AMF
-}
 
-static void AMF_CDECL_CALL AMFTraceWriter_Flush(AMFTraceWriter *pThis)
-{
-}
-
-static AMFTraceWriterVtbl tracer_vtbl =
-{
-.Write = AMFTraceWriter_Write,
-.Flush = AMFTraceWriter_Flush,
-};
-
-static int amf_load_library(AVCodecContext *avctx)
+static int amf_init_context(AVCodecContext *avctx)
 {
-AmfContext*ctx = avctx->priv_data;
-AMFInit_Fn init_fun;
-AMFQueryVersion_Fn version_fun;
-AMF_RESULT res;
+AmfContext *ctx = avctx->priv_data;
+av_unused int ret;
 
 ctx->delayed_frame = av_frame_alloc();
 if (!ctx->delayed_frame) {
 return AVERROR(ENOMEM);
 }
+
 // hardcoded to current HW queue size - will realloc in 
timestamp_queue_enqueue() if too small
 ctx->timestamp_list = av_fifo_alloc((avctx->max_b_frames + 16) * 
sizeof(int64_t));
 if (!ctx->timestamp_list) {
@@ -123,119 +98,9 @@ static int amf_load_library(AVCodecContext *avctx)
 }
 ctx->dts_delay = 0;
 
-
-ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW | RTLD_LOCAL);
-AMF_RETURN_IF_FALSE(ctx, ctx->library != NULL,
-AVERROR_UNKNOWN, "DLL %s failed to open\n", AMF_DLL_NAMEA);
-
-init_fun = (AMFInit_Fn)dlsym(ctx->library, AMF_INIT_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed 
to find function %s\n", AMF_DLL_NAMEA, AMF_INIT_FUNCTION_NAME);
-
-version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library, 
AMF_QUERY_VERSION_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, version_fun != NULL, AVERROR_UNKNOWN, "DLL %s 
failed to find function %s\n", AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);
-
-res = version_fun(&ctx->version);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_QUERY_VERSION_FUNCTION_NAME, res);
-res = init_fun(AMF_FULL_VERSION, &ctx->factory);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_INIT_FUNCTION_NAME, res);
-res = ctx->factory->pVtbl->GetTrace(ctx->factory, &ctx->trace);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetTrace() 
failed with error %d\n", res);
-res = ctx->factory->pVtbl->GetDebug(ctx->factory, &ctx->debug);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetDebug() 
failed with error %d\n", res);
-return 0;
-}
-
-#if CONFIG_D3D11VA
-static int amf_init_from_d3d11_device(AVCodecContext *avctx, 
AVD3D11VADeviceContext *hwctx)
-{
-AmfContext *ctx = avctx->priv_data;
-AMF_RESULT res;
-
-res = ctx->context->pVtbl->InitDX11(ctx->context, hwctx->device, 
AMF_DX11_1);
-if (res != AMF_OK) {
-if (res == AMF_NOT_SUPPORTED)
-av_log(avctx, AV_LOG_ERROR, "AMF via D3D11 is not supported on the 
given device.\n");
-else
-av_log(avctx, AV_LOG_ERROR, "AMF failed to initialise on the given 
D3D11 device: %d.\n", res);
-return AVERROR(ENODEV);
-}
-
-return 0;
-}
-#endif
-
-#if CONFIG_DXVA2

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

2018-04-26 Thread Marton Balint

On Thu, 26 Apr 2018, Aman Gupta wrote:

On Thu, Apr 26, 2018 at 8:12 AM, Nicolas George wrote:

Aman Gupta (2018-04-26):
> Another reason I discounted libzvbi is because it seems unmaintained,
> without a new release is over 5 years.

Did the teletext standard evolve in the past five years?

I don't know, but there it is atleast one bug causing tests to fail on
macOS which has been unfixed for 4 years.

I managed to install libzvbi by hand and try it out. With `-txt_format
text`, the generated output text is the same but without positions/colors.
The ASS positioning code could be ported over, but it looks like
vbi_print_page_region() strips out all the color information so there
doesn't seem to be an obvious way to support text coloring.

The zvbi decoder also hardcodes a (configurable) 30s end time per subtitle,
which causes them to pile up on the screen and not disappear when they're
supposed to. The logic from my decoder could also probably be ported over,
under a new `-real_time 1` flag like I added to ccaption_dec last year.

Here's a side by side comparison:
https://dzwonsemrish7.cloudfront.net/items/2x1z3k0C0X3v0Z2j1F3b/teletext-sub-comparison.jpg

I agree it would be ideal to have only one teletext decoder that works for
everyone. However I'm done with my teletext project, and don't have time
right now to redo all that work in the zvbi encoder. I also live in an ATSC
region and don't use teletext myself, so I don't really care whether or not
my decoder is merged into ffmpeg. I only shared it because some people on
IRC expressed interest.

I will try integrating the ASS formatting part of your patch to the
libzvbi decoder, and see how it goes.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add system and real time to benchmarking.

2018-04-26 Thread Mark Wachsler

Friendly ping. Could someone please take a look? Thanks!

On Mon, Apr 23, 2018 at 2:29 PM, Mark Wachsler  wrote:

> Ping.
>
> On Fri, Apr 20, 2018 at 4:21 PM, Mark Wachsler 
> wrote:
>
>> The -benchmark and -benchmark_all options now show user, system, and real
>> time,
>> instead of just user time.
>> ---
>>  fftools/ffmpeg.c | 50 ++--
>>  1 file changed, 36 insertions(+), 14 deletions(-)
>>
>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
>> index 4dbe72186d..d37171d567 100644
>> --- a/fftools/ffmpeg.c
>> +++ b/fftools/ffmpeg.c
>> @@ -120,8 +120,14 @@ const char *const forced_keyframes_const_names[] = {
>>  NULL
>>  };
>>
>> +typedef struct TimeStamps {
>> +  int64_t real_usec;
>> +  int64_t user_usec;
>> +  int64_t sys_usec;
>> +} TimeStamps;
>> +
>>  static void do_video_stats(OutputStream *ost, int frame_size);
>> -static int64_t getutime(void);
>> +static TimeStamps get_time_stamps(void);
>>  static int64_t getmaxrss(void);
>>  static int ifilter_has_all_input_formats(FilterGraph *fg);
>>
>> @@ -133,7 +139,7 @@ static int64_t decode_error_stat[2];
>>
>>  static int want_sdp = 1;
>>
>> -static int current_time;
>> +static TimeStamps current_time;
>>  AVIOContext *progress_avio = NULL;
>>
>>  static uint8_t *subtitle_out;
>> @@ -653,7 +659,7 @@ static void abort_codec_experimental(AVCodec *c, int
>> encoder)
>>  static void update_benchmark(const char *fmt, ...)
>>  {
>>  if (do_benchmark_all) {
>> -int64_t t = getutime();
>> +TimeStamps t = get_time_stamps();
>>  va_list va;
>>  char buf[1024];
>>
>> @@ -661,7 +667,11 @@ static void update_benchmark(const char *fmt, ...)
>>  va_start(va, fmt);
>>  vsnprintf(buf, sizeof(buf), fmt, va);
>>  va_end(va);
>> -av_log(NULL, AV_LOG_INFO, "bench: %8"PRIu64" %s \n", t -
>> current_time, buf);
>> +av_log(NULL, AV_LOG_INFO,
>> +   "bench: %8" PRIu64 " user %8" PRIu64 " sys %8" PRIu64
>> " real %s \n",
>> +   t.user_usec - current_time.user_usec,
>> +   t.sys_usec - current_time.sys_usec,
>> +   t.real_usec - current_time.real_usec, buf);
>>  }
>>  current_time = t;
>>  }
>> @@ -4715,23 +4725,30 @@ static int transcode(void)
>>  return ret;
>>  }
>>
>> -
>> -static int64_t getutime(void)
>> -{
>> +static TimeStamps get_time_stamps(void) {
>> +  TimeStamps time_stamps;
>> +  time_stamps.real_usec = av_gettime_relative();
>>  #if HAVE_GETRUSAGE
>>  struct rusage rusage;
>>
>>  getrusage(RUSAGE_SELF, &rusage);
>> -return (rusage.ru_utime.tv_sec * 100LL) +
>> rusage.ru_utime.tv_usec;
>> +time_stamps.user_usec =
>> +(rusage.ru_utime.tv_sec * 100LL) + rusage.ru_utime.tv_usec;
>> +time_stamps.sys_usec =
>> +(rusage.ru_stime.tv_sec * 100LL) + rusage.ru_stime.tv_usec;
>>  #elif HAVE_GETPROCESSTIMES
>>  HANDLE proc;
>>  FILETIME c, e, k, u;
>>  proc = GetCurrentProcess();
>>  GetProcessTimes(proc, &c, &e, &k, &u);
>> -return ((int64_t) u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
>> +time_stamps.user_usec =
>> +((int64_t)u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
>> +time_stamps.sys_usec =
>> +((int64_t)k.dwHighDateTime << 32 | k.dwLowDateTime) / 10;
>>  #else
>> -return av_gettime_relative();
>> +time_stamps.user_usec = time_stamps.sys_usec = 0;
>>  #endif
>> +return time_stamps;
>>  }
>>
>>  static int64_t getmaxrss(void)
>> @@ -4759,7 +4776,7 @@ static void log_callback_null(void *ptr, int level,
>> const char *fmt, va_list vl)
>>  int main(int argc, char **argv)
>>  {
>>  int i, ret;
>> -int64_t ti;
>> +TimeStamps ti;
>>
>>  init_dynload();
>>
>> @@ -4811,12 +4828,17 @@ int main(int argc, char **argv)
>>  want_sdp = 0;
>>  }
>>
>> -current_time = ti = getutime();
>> +current_time = ti = get_time_stamps();
>>  if (transcode() < 0)
>>  exit_program(1);
>> -ti = getutime() - ti;
>>  if (do_benchmark) {
>> -av_log(NULL, AV_LOG_INFO, "bench: utime=%0.3fs\n", ti /
>> 100.0);
>> +  current_time = get_time_stamps();
>> +  int64_t utime = current_time.user_usec - ti.user_usec;
>> +  int64_t stime = current_time.sys_usec - ti.sys_usec;
>> +  int64_t rtime = current_time.real_usec - ti.real_usec;
>> +  av_log(NULL, AV_LOG_INFO,
>> + "bench: utime=%0.3fs stime=%0.3fs rtime=%0.3fs\n",
>> + utime / 100.0, stime / 100.0, rtime / 100.0);
>>  }
>>  av_log(NULL, AV_LOG_DEBUG, "%"PRIu64" frames successfully decoded,
>> %"PRIu64" decoding errors\n",
>> decode_error_stat[0], decode_error_stat[1]);
>> --
>> 2.17.0.484.g0c8726318c-goog
>>
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/anm: fix palette alpha

2018-04-26 Thread Marton Balint




On Tue, 24 Apr 2018, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
libavcodec/anm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/anm.c b/libavcodec/anm.c
index 72684189bb..ab6a3994e9 100644
--- a/libavcodec/anm.c
+++ b/libavcodec/anm.c
@@ -54,7 +54,7 @@ static av_cold int decode_init(AVCodecContext *avctx)

bytestream2_skipu(&s->gb, 16 * 8);
for (i = 0; i < 256; i++)
-s->palette[i] = bytestream2_get_le32u(&s->gb);
+s->palette[i] = (0xFFU << 24) | bytestream2_get_le32u(&s->gb);

return 0;
}


Meanwhile I found some "documentation" about the file format:

http://ftp.textmod.es/mirror/ftp.shroo.ms/textfiles.com/programming/FORMATS/animfile.txt

It says:

Following the anim file header is the color palette:

ULONG palette[256] Color palette arranged as 3 bytes each of Red Green
   & Blue and one unused byte.

So the extra byte indeed seems unused and it is not related to 
transparency.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add system and real time to benchmarking.

On Fri, 20 Apr 2018 16:21:13 -0400
Mark Wachsler  wrote:

> The -benchmark and -benchmark_all options now show user, system, and real 
> time,
> instead of just user time.
> ---
>  fftools/ffmpeg.c | 50 ++--
>  1 file changed, 36 insertions(+), 14 deletions(-)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 4dbe72186d..d37171d567 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -120,8 +120,14 @@ const char *const forced_keyframes_const_names[] = {
>  NULL
>  };
>  
> +typedef struct TimeStamps {
> +  int64_t real_usec;
> +  int64_t user_usec;
> +  int64_t sys_usec;
> +} TimeStamps;
> +
>  static void do_video_stats(OutputStream *ost, int frame_size);
> -static int64_t getutime(void);
> +static TimeStamps get_time_stamps(void);
>  static int64_t getmaxrss(void);
>  static int ifilter_has_all_input_formats(FilterGraph *fg);
>  
> @@ -133,7 +139,7 @@ static int64_t decode_error_stat[2];
>  
>  static int want_sdp = 1;
>  
> -static int current_time;
> +static TimeStamps current_time;
>  AVIOContext *progress_avio = NULL;
>  
>  static uint8_t *subtitle_out;
> @@ -653,7 +659,7 @@ static void abort_codec_experimental(AVCodec *c, int 
> encoder)
>  static void update_benchmark(const char *fmt, ...)
>  {
>  if (do_benchmark_all) {
> -int64_t t = getutime();
> +TimeStamps t = get_time_stamps();
>  va_list va;
>  char buf[1024];
>  
> @@ -661,7 +667,11 @@ static void update_benchmark(const char *fmt, ...)
>  va_start(va, fmt);
>  vsnprintf(buf, sizeof(buf), fmt, va);
>  va_end(va);
> -av_log(NULL, AV_LOG_INFO, "bench: %8"PRIu64" %s \n", t - 
> current_time, buf);
> +av_log(NULL, AV_LOG_INFO,
> +   "bench: %8" PRIu64 " user %8" PRIu64 " sys %8" PRIu64 " 
> real %s \n",
> +   t.user_usec - current_time.user_usec,
> +   t.sys_usec - current_time.sys_usec,
> +   t.real_usec - current_time.real_usec, buf);
>  }
>  current_time = t;
>  }
> @@ -4715,23 +4725,30 @@ static int transcode(void)
>  return ret;
>  }
>  
> -
> -static int64_t getutime(void)
> -{
> +static TimeStamps get_time_stamps(void) {
> +  TimeStamps time_stamps;
> +  time_stamps.real_usec = av_gettime_relative();
>  #if HAVE_GETRUSAGE
>  struct rusage rusage;
>  
>  getrusage(RUSAGE_SELF, &rusage);
> -return (rusage.ru_utime.tv_sec * 100LL) + rusage.ru_utime.tv_usec;
> +time_stamps.user_usec =
> +(rusage.ru_utime.tv_sec * 100LL) + rusage.ru_utime.tv_usec;
> +time_stamps.sys_usec =
> +(rusage.ru_stime.tv_sec * 100LL) + rusage.ru_stime.tv_usec;
>  #elif HAVE_GETPROCESSTIMES
>  HANDLE proc;
>  FILETIME c, e, k, u;
>  proc = GetCurrentProcess();
>  GetProcessTimes(proc, &c, &e, &k, &u);
> -return ((int64_t) u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
> +time_stamps.user_usec =
> +((int64_t)u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
> +time_stamps.sys_usec =
> +((int64_t)k.dwHighDateTime << 32 | k.dwLowDateTime) / 10;
>  #else
> -return av_gettime_relative();
> +time_stamps.user_usec = time_stamps.sys_usec = 0;
>  #endif
> +return time_stamps;
>  }
>  
>  static int64_t getmaxrss(void)
> @@ -4759,7 +4776,7 @@ static void log_callback_null(void *ptr, int level, 
> const char *fmt, va_list vl)
>  int main(int argc, char **argv)
>  {
>  int i, ret;
> -int64_t ti;
> +TimeStamps ti;
>  
>  init_dynload();
>  
> @@ -4811,12 +4828,17 @@ int main(int argc, char **argv)
>  want_sdp = 0;
>  }
>  
> -current_time = ti = getutime();
> +current_time = ti = get_time_stamps();
>  if (transcode() < 0)
>  exit_program(1);
> -ti = getutime() - ti;
>  if (do_benchmark) {
> -av_log(NULL, AV_LOG_INFO, "bench: utime=%0.3fs\n", ti / 100.0);
> +  current_time = get_time_stamps();
> +  int64_t utime = current_time.user_usec - ti.user_usec;
> +  int64_t stime = current_time.sys_usec - ti.sys_usec;
> +  int64_t rtime = current_time.real_usec - ti.real_usec;
> +  av_log(NULL, AV_LOG_INFO,
> + "bench: utime=%0.3fs stime=%0.3fs rtime=%0.3fs\n",
> + utime / 100.0, stime / 100.0, rtime / 100.0);
>  }
>  av_log(NULL, AV_LOG_DEBUG, "%"PRIu64" frames successfully decoded, 
> %"PRIu64" decoding errors\n",
> decode_error_stat[0], decode_error_stat[1]);

Is there any reason you you can't just use /usr/bin/time?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add system and real time to benchmarking.

2018-04-26 Thread Mark Wachsler

-benchmark_all separately measures time spent encoding video, decoding
video, encoding audio, and decoding audio. You can't do that with
/usr/bin/time.

It is true that -benchmark could be replaced with /usr/bin/time, but that's
always been true. It seemed to make sense to -benchmark and -benchmark_all
continue to measure the same things.

Regards,
Mark

On Thu, Apr 26, 2018 at 12:28 PM, wm4  wrote:

> On Fri, 20 Apr 2018 16:21:13 -0400
> Mark Wachsler  wrote:
>
> > The -benchmark and -benchmark_all options now show user, system, and
> real time,
> > instead of just user time.
> > ---
> >  fftools/ffmpeg.c | 50 ++--
> >  1 file changed, 36 insertions(+), 14 deletions(-)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 4dbe72186d..d37171d567 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -120,8 +120,14 @@ const char *const forced_keyframes_const_names[] = {
> >  NULL
> >  };
> >
> > +typedef struct TimeStamps {
> > +  int64_t real_usec;
> > +  int64_t user_usec;
> > +  int64_t sys_usec;
> > +} TimeStamps;
> > +
> >  static void do_video_stats(OutputStream *ost, int frame_size);
> > -static int64_t getutime(void);
> > +static TimeStamps get_time_stamps(void);
> >  static int64_t getmaxrss(void);
> >  static int ifilter_has_all_input_formats(FilterGraph *fg);
> >
> > @@ -133,7 +139,7 @@ static int64_t decode_error_stat[2];
> >
> >  static int want_sdp = 1;
> >
> > -static int current_time;
> > +static TimeStamps current_time;
> >  AVIOContext *progress_avio = NULL;
> >
> >  static uint8_t *subtitle_out;
> > @@ -653,7 +659,7 @@ static void abort_codec_experimental(AVCodec *c,
> int encoder)
> >  static void update_benchmark(const char *fmt, ...)
> >  {
> >  if (do_benchmark_all) {
> > -int64_t t = getutime();
> > +TimeStamps t = get_time_stamps();
> >  va_list va;
> >  char buf[1024];
> >
> > @@ -661,7 +667,11 @@ static void update_benchmark(const char *fmt, ...)
> >  va_start(va, fmt);
> >  vsnprintf(buf, sizeof(buf), fmt, va);
> >  va_end(va);
> > -av_log(NULL, AV_LOG_INFO, "bench: %8"PRIu64" %s \n", t -
> current_time, buf);
> > +av_log(NULL, AV_LOG_INFO,
> > +   "bench: %8" PRIu64 " user %8" PRIu64 " sys %8"
> PRIu64 " real %s \n",
> > +   t.user_usec - current_time.user_usec,
> > +   t.sys_usec - current_time.sys_usec,
> > +   t.real_usec - current_time.real_usec, buf);
> >  }
> >  current_time = t;
> >  }
> > @@ -4715,23 +4725,30 @@ static int transcode(void)
> >  return ret;
> >  }
> >
> > -
> > -static int64_t getutime(void)
> > -{
> > +static TimeStamps get_time_stamps(void) {
> > +  TimeStamps time_stamps;
> > +  time_stamps.real_usec = av_gettime_relative();
> >  #if HAVE_GETRUSAGE
> >  struct rusage rusage;
> >
> >  getrusage(RUSAGE_SELF, &rusage);
> > -return (rusage.ru_utime.tv_sec * 100LL) +
> rusage.ru_utime.tv_usec;
> > +time_stamps.user_usec =
> > +(rusage.ru_utime.tv_sec * 100LL) + rusage.ru_utime.tv_usec;
> > +time_stamps.sys_usec =
> > +(rusage.ru_stime.tv_sec * 100LL) + rusage.ru_stime.tv_usec;
> >  #elif HAVE_GETPROCESSTIMES
> >  HANDLE proc;
> >  FILETIME c, e, k, u;
> >  proc = GetCurrentProcess();
> >  GetProcessTimes(proc, &c, &e, &k, &u);
> > -return ((int64_t) u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
> > +time_stamps.user_usec =
> > +((int64_t)u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
> > +time_stamps.sys_usec =
> > +((int64_t)k.dwHighDateTime << 32 | k.dwLowDateTime) / 10;
> >  #else
> > -return av_gettime_relative();
> > +time_stamps.user_usec = time_stamps.sys_usec = 0;
> >  #endif
> > +return time_stamps;
> >  }
> >
> >  static int64_t getmaxrss(void)
> > @@ -4759,7 +4776,7 @@ static void log_callback_null(void *ptr, int
> level, const char *fmt, va_list vl)
> >  int main(int argc, char **argv)
> >  {
> >  int i, ret;
> > -int64_t ti;
> > +TimeStamps ti;
> >
> >  init_dynload();
> >
> > @@ -4811,12 +4828,17 @@ int main(int argc, char **argv)
> >  want_sdp = 0;
> >  }
> >
> > -current_time = ti = getutime();
> > +current_time = ti = get_time_stamps();
> >  if (transcode() < 0)
> >  exit_program(1);
> > -ti = getutime() - ti;
> >  if (do_benchmark) {
> > -av_log(NULL, AV_LOG_INFO, "bench: utime=%0.3fs\n", ti /
> 100.0);
> > +  current_time = get_time_stamps();
> > +  int64_t utime = current_time.user_usec - ti.user_usec;
> > +  int64_t stime = current_time.sys_usec - ti.sys_usec;
> > +  int64_t rtime = current_time.real_usec - ti.real_usec;
> > +  av_log(NULL, AV_LOG_INFO,
> > + "bench: utime=%0.3fs stime=%0.3fs rtime=%0.3fs\n",
> > + utime / 100.0, stime / 100.0, rtime / 1

Re: [FFmpeg-devel] github

2018-04-26 Thread Tomas Härdin

tor 2018-04-26 klockan 13:15 +0200 skrev Daniel Oberhoff:
> Hello,
> 
> I was wondering if there is any chance to move development to github?
> I.e. not just mirror, but as primary development repo, with issues
> and pull requests? Would make collaboration a *lot* easier (think of
> submitting a pr instead of having to generate/format/split patches).

There is no reason to move to a siren server like github when we
already have working infrastructure. There's also the issue of not
being able to take one's data and go. While the code can be moved,
tickets cannot.

PR quality is an issue too, as others have noted.

GitLab might be nice however, but we'd need a way to import all trac
tickets, with ticket numbers and URLs intact. But I don't think we'd
gain much from that.

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/dashenc: Set mp4 as the default format for VP9

2018-04-26 Thread Jan Ekström

On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick  wrote:
>
>
> On 4/23/18 11:40 AM, Karthick J wrote:
>> From: Karthick Jeyapal 
>>
>> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in 
>> DASH.
>> Hence in this muxer we will focus on supporting VP9 in MP4
>> Have verified playout support of VP9+MP4 in Chrome and Firefox.
>> ---
>>  libavformat/dashenc.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index a5f58d4..211ef23 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -959,11 +959,10 @@ static int dash_init(AVFormatContext *s)
>>  if (!ctx)
>>  return AVERROR(ENOMEM);
>>
>> -// choose muxer based on codec: webm for VP8/9 and opus, mp4 
>> otherwise
>> +// choose muxer based on codec: webm for VP8 and opus, mp4 otherwise
>>  // note: os->format_name is also used as part of the mimetype of the
>>  //   representation, e.g. video/
>>  if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
>> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP9 ||
>>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
>>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
>>  snprintf(os->format_name, sizeof(os->format_name), "webm");
>
> Pushed the patchset
>

Hi,

First of all, I would prefer the patch to actually mention what it is
doing. It is removing the webm override from the muxer for VP9. There
is as far as I know no option to switch between modes in current git,
so the commit message is blindly misleading at best and just plain
trying to look harmless (in order to get a free pass) if taken the
wrong way. Not saying you meant it that way, but the commit message
does not say what it does as far as I can see.

Also the patch does not mention the reason why it is doing this other
than the fact that there's a separate webm DASH muxer. That is true,
but the real reason you were switching this default is because the
WebM mode does not work. Now, fixing segfaults is good. And, for the
record, I actually agree with the change since with the profile string
it works in dash.js on various browsers (Firefox, Chromium, Edge).

But begesus... If it is done like this you might as well be honest and
just remove the WebM mode! Because right now you left it there to
segfault for VP8, Opus, Vorbis. Another alternative would have been to
apply the small change to Rodger Combs's patch
(https://patchwork.ffmpeg.org/patch/7984/), which you even commented
on before! Maybe it still doesn't work in browsers, but at least it
would have gotten to that point.

Really, I am thankful that you are contributing, but I really do not
want to see things like these after long days of work when I have not
noticed or wasn't able to write a long reply. You waited for two days,
and pushed without reviews even though I had shown interest in the
patch in its first iteration. If you are interested in getting quick
comments from someone (including me when I am awake and available),
please join the IRC channel #ffmpeg-devel if only possible. Even if it
is just for pokes and links to patchwork towards someone who has shown
interest to related patches before. I try as much as possible to poke
relevant people when I post patches, and I would prefer it if others
would do that as well. We're not perfect and issues can and do go
through peoples' eyes (esp. if the change set is of the larger size
issues tend to get hidden in plain sight, unfortunately), but let's
try to make this work.

Best regards,
Jan

P.S. I am sorry if my way of speech came out bad, it is just past
midnight here and I was trying to get a reply to this written after
noticing this mail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 23/26] lavc/cbs: Add JPEG support

2018-04-26 Thread Mark Thompson

On 25/04/18 23:23, James Almer wrote:
> On 4/25/2018 6:31 PM, Mark Thompson wrote:
>> +static int cbs_jpeg_split_fragment(CodedBitstreamContext *ctx,
>> +   CodedBitstreamFragment *frag,
>> +   int header)
>> +{
>> +AVBufferRef *data_ref;
>> +uint8_t *data;
>> +size_t data_size;
>> +int unit, start, end, marker, next_start, next_marker;
>> +int err, i, j, length;
>> +
>> +if (frag->data_size < 4) {
>> +// Definitely too short to be meaningful.
>> +return AVERROR_INVALIDDATA;
>> +}
>> +
>> +for (i = 0; i + 1 < frag->data_size && frag->data[i] != 0xff; i++);
>> +if (i > 0) {
>> +av_log(ctx->log_ctx, AV_LOG_WARNING, "Discarding %d bytes at "
>> +   "beginning of image.\n", i);
>> +}
>> +for (++i; i + 1 < frag->data_size && frag->data[i] == 0xff; i++);
>> +if (i + 1 >= frag->data_size && frag->data[i]) {
>> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
>> +   "no SOI marker found.\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>> +marker = frag->data[i];
>> +if (marker != JPEG_MARKER_SOI) {
>> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: first "
>> +   "marker is %02x, should be SOI.\n", marker);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +for (++i; i + 1 < frag->data_size && frag->data[i] == 0xff; i++);
>> +if (i + 1 >= frag->data_size) {
>> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
>> +   "no image content found.\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>> +marker = frag->data[i];
>> +start  = i + 1;
>> +
>> +for (unit = 0;; unit++) {
>> +if (marker == JPEG_MARKER_EOI) {
>> +break;
>> +} else if (marker == JPEG_MARKER_SOS) {
>> +for (i = start; i + 1 < frag->data_size; i++) {
>> +if (frag->data[i] != 0xff)
>> +continue;
>> +end = i;
>> +for (++i; i + 1 < frag->data_size &&
>> +  frag->data[i] == 0xff; i++);
>> +if (i + 1 >= frag->data_size) {
>> +next_marker = -1;
>> +} else {
>> +if (frag->data[i] == 0x00)
>> +continue;
>> +next_marker = frag->data[i];
>> +next_start  = i + 1;
>> +}
>> +break;
>> +}
>> +} else {
>> +i = start;
>> +if (i + 2 > frag->data_size) {
>> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
>> +   "truncated at %02x marker.\n", marker);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +length = AV_RB16(frag->data + i);
>> +if (i + length > frag->data_size) {
>> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
>> +   "truncated at %02x marker segment.\n", marker);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +end = start + length;
>> +
>> +i = end;
>> +if (frag->data[i] != 0xff) {
>> +next_marker = -1;
>> +} else {
>> +for (++i; i + 1 < frag->data_size &&
>> +  frag->data[i] == 0xff; i++);
>> +if (i + 1 >= frag->data_size) {
>> +next_marker = -1;
>> +} else {
>> +next_marker = frag->data[i];
>> +next_start  = i + 1;
>> +}
>> +}
>> +}
>> +
>> +if (marker == JPEG_MARKER_SOS) {
>> +length = AV_RB16(frag->data + start);
>> +
>> +data_ref = av_buffer_alloc(end - start +
>> +   AV_INPUT_BUFFER_PADDING_SIZE);
> 
> Allocating an AVBufferRef here, letting ff_cbs_insert_unit_data()
> generate a new reference to it, then unreffing the first one seems
> wasteful/redundant.
> 
> Use av_malloc(), set data_ref to NULL, and let ff_cbs_insert_unit_data()
> create the AVBufferRef by taking ownership of the malloc'd data array
> instead. You'd then only need to free said data array if
> ff_cbs_insert_unit_data() fails.

Right, yes.  Changed locally.

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: remove duplicate prores decoder


On 2018/04/26 14:14, Paul B Mahol wrote:

Removed slower one, couldn't figure out why it is slower.

Signed-off-by: Paul B Mahol 
---
[...]


I agree with this patch in principle (no need to have two decoders which 
do the same thing), though it might be nice to show some numbers in the 
commit message.


--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cbs_mpeg2: use existing buffer reference when splitting fragments

2018-04-26 Thread Mark Thompson

On 25/04/18 23:42, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/cbs_mpeg2.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
> index 94b9591b21..30d2bb6fbf 100644
> --- a/libavcodec/cbs_mpeg2.c
> +++ b/libavcodec/cbs_mpeg2.c
> @@ -146,16 +146,11 @@ static int 
> cbs_mpeg2_split_fragment(CodedBitstreamContext *ctx,
>  unit_size = (end - 4) - (start - 1);
>  }
>  
> -unit_data = av_malloc(unit_size + AV_INPUT_BUFFER_PADDING_SIZE);
> -if (!unit_data)
> -return AVERROR(ENOMEM);
> -memcpy(unit_data, start - 1, unit_size);
> -memset(unit_data + unit_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +unit_data = (uint8_t *)start - 1;
>  
>  err = ff_cbs_insert_unit_data(ctx, frag, i, unit_type,
> -  unit_data, unit_size, NULL);
> +  unit_data, unit_size, frag->data_ref);
>  if (err < 0) {
> -av_freep(&unit_data);

Could remove the braces here too.

>  return err;
>  }
>  
> 

Much nicer :)  Both patches tested, LGTM.

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 13/26] vaapi_encode: Add quality level to common options

2018-04-26 Thread Mark Thompson

On 26/04/18 06:34, Xiang, Haihao wrote:
> On Sun, 2018-04-22 at 16:29 +0100, Mark Thompson wrote:
>> This was previously accessible only via AVCodecContext.compression_level
>> for all encoders except H.264 where it was also a private option.  This
>> makes it an explicit option everywhere.
>> ---
>>  libavcodec/vaapi_encode.c  | 87 
>> ++---
>> -
>>  libavcodec/vaapi_encode.h  |  8 
>>  libavcodec/vaapi_encode_h264.c |  6 ---
>>  3 files changed, 62 insertions(+), 39 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>> index 9c39bcdeff..a5eb072843 100644
>> --- a/libavcodec/vaapi_encode.c
>> +++ b/libavcodec/vaapi_encode.c
>> @@ -1381,6 +1381,52 @@ static av_cold int
>> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>>  return 0;
>>  }
>>  
>> +static av_cold int vaapi_encode_init_quality(AVCodecContext *avctx)
>> +{
>> +#if VA_CHECK_VERSION(0, 36, 0)
>> +VAAPIEncodeContext *ctx = avctx->priv_data;
>> +VAStatus vas;
>> +VAConfigAttrib attr = { VAConfigAttribEncQualityRange };
>> +
>> +vas = vaGetConfigAttributes(ctx->hwctx->display,
>> +ctx->va_profile,
>> +ctx->va_entrypoint,
>> +&attr, 1);
>> +if (vas != VA_STATUS_SUCCESS) {
>> +av_log(avctx, AV_LOG_ERROR, "Failed to query quality "
>> +   "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
>> +return AVERROR_EXTERNAL;
>> +}
>> +
>> +if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
>> +if (ctx->quality != 0) {
>> +av_log(avctx, AV_LOG_WARNING, "Quality attribute is not "
>> +   "supported: will use default quality level.\n");
>> +}
>> +} else {
>> +if (ctx->quality > attr.value) {
>> +av_log(avctx, AV_LOG_WARNING, "Invalid quality level: "
>> +   "valid range is 0-%d, using %d.\n",
>> +   attr.value, attr.value);
>> +ctx->quality = attr.value;
>> +}
>> +
>> +ctx->quality_params.misc.type =
>> +VAEncMiscParameterTypeQualityLevel;
>> +ctx->quality_params.quality.quality_level =
>> +ctx->quality;
>> +
>> +vaapi_encode_add_global_param(avctx, &ctx->quality_params.misc,
>> +  sizeof(ctx->quality_params));
>> +}
>> +#else
>> +av_log(avctx, AV_LOG_WARNING, "The encode quality option is "
>> +   "not supported with this VAAPI version.\n");
>> +#endif
>> +
>> +return 0;
>> +}
>> +
>>  static void vaapi_encode_free_output_buffer(void *opaque,
>>  uint8_t *data)
>>  {
>> @@ -1562,6 +1608,14 @@ av_cold int ff_vaapi_encode_init(AVCodecContext 
>> *avctx)
>>  if (err < 0)
>>  goto fail;
>>  
>> +if (!ctx->quality)
>> +ctx->quality = avctx->compression_level;
> 
> 
> 0 means the default quality level in use in VAAPI, so does it make sense to
> assign avctx->compression_level which is not FF_COMPRESSION_DEFAULT to ctx-
>> quality?

Right, the default for the quality option should also be -1 (meaning unset), 
because otherwise it will always try to set it (including on drivers which 
don't support the option).

>> +if (ctx->quality >= 0) {
>> +err = vaapi_encode_init_quality(avctx);
>> +if (err < 0)
>> +goto fail;
>> +}
>> +
>>  vas = vaCreateConfig(ctx->hwctx->display,
>>   ctx->va_profile, ctx->va_entrypoint,
>>   ctx->config_attributes, ctx->nb_config_attributes,
>> @@ -1611,39 +1665,6 @@ av_cold int ff_vaapi_encode_init(AVCodecContext 
>> *avctx)
>>  goto fail;
>>  }
>>  
>> -if (avctx->compression_level >= 0) {
>> -#if VA_CHECK_VERSION(0, 36, 0)
>> -VAConfigAttrib attr = { VAConfigAttribEncQualityRange };
>> -
>> -vas = vaGetConfigAttributes(ctx->hwctx->display,
>> -ctx->va_profile,
>> -ctx->va_entrypoint,
>> -&attr, 1);
>> -if (vas != VA_STATUS_SUCCESS) {
>> -av_log(avctx, AV_LOG_WARNING, "Failed to query quality "
>> -   "attribute: will use default compression level.\n");
>> -} else {
>> -if (avctx->compression_level > attr.value) {
>> -av_log(avctx, AV_LOG_WARNING, "Invalid compression "
>> -   "level: valid range is 0-%d, using %d.\n",
>> -   attr.value, attr.value);
>> -avctx->compression_level = attr.value;
>> -}
>> -
>> -ctx->quality_params.misc.type =
>> -VAEncMiscParameterTypeQualityLevel;
>> -ctx->quality_params.quality.quality_level =
>> -avctx->compression_level;
>> -
>> -vaapi_encode_add_glob

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/anm: fix palette alpha

2018-04-24 21:04 GMT+02:00, Marton Balint :
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/anm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/anm.c b/libavcodec/anm.c
> index 72684189bb..ab6a3994e9 100644
> --- a/libavcodec/anm.c
> +++ b/libavcodec/anm.c
> @@ -54,7 +54,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
>
>  bytestream2_skipu(&s->gb, 16 * 8);
>  for (i = 0; i < 256; i++)
> -s->palette[i] = bytestream2_get_le32u(&s->gb);
> +s->palette[i] = (0xFFU << 24) | bytestream2_get_le32u(&s->gb);

This is also ok just by looking at our samples.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

On Thu, 26 Apr 2018 14:41:55 +0200
Daniel Oberhoff  wrote:

> > On 26. Apr 2018, at 14:40, wm4  wrote:
> > 
> > On Thu, 26 Apr 2018 14:12:14 +0200
> > Hendrik Leppkes mailto:h.lepp...@gmail.com>> wrote:
> >   
> >> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
> >>  wrote:  
> >>>   
>  Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff 
>  :
>  
>    
> > Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff 
> > :
> > 
> >   
> >> Am 26.04.2018 um 13:52 schrieb Nicolas George :
> >> 
> >> Daniel Oberhoff (2018-04-26):  
> >>> I was wondering if there is any chance to move development to github?
> >>> I.e. not just mirror, but as primary development repo, with issues and
> >>> pull requests? Would make collaboration a *lot* easier (think of
> >>> submitting a pr instead of having to generate/format/split patches).  
> >> 
> >> If development involves working in a web browser a lot, count me out.
> >> Can you point me to the command-line  
> > 
> > https://hub.github.com/hub.1.html  
>  
>  But you can’t really do reviews that way, so the criticism stands.  
> >>> 
> >>> BTW, is there any kind of issue tracking?  
> >> 
> >> https://trac.ffmpeg.org/  
> > 
> > To be fair, I'd prefer the github issue tracker over TRAC any day.
> > Still has the other problems I mentioned.  
> 
> gitlab?
> 

That would mostly get rid of the centralization argument. But I've
heard bad things from someone who wanted to setup a private instance of
it. Apparently it has a large number of dependencies, is extremely hard
to deploy (unless you use their docker container), and it's SLOW.

In fact even gitlab.com seems to have severe performance problems
occasionally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/dashenc: Set mp4 as the default format for VP9

2018-04-26 Thread Michael Niedermayer

On Fri, Apr 27, 2018 at 12:35:42AM +0300, Jan Ekström wrote:
> On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick  
> wrote:
> >
> >
> > On 4/23/18 11:40 AM, Karthick J wrote:
> >> From: Karthick Jeyapal 
> >>
> >> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in 
> >> DASH.
> >> Hence in this muxer we will focus on supporting VP9 in MP4
> >> Have verified playout support of VP9+MP4 in Chrome and Firefox.
> >> ---
> >>  libavformat/dashenc.c | 3 +--
> >>  1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> >> index a5f58d4..211ef23 100644
> >> --- a/libavformat/dashenc.c
> >> +++ b/libavformat/dashenc.c
> >> @@ -959,11 +959,10 @@ static int dash_init(AVFormatContext *s)
> >>  if (!ctx)
> >>  return AVERROR(ENOMEM);
> >>
> >> -// choose muxer based on codec: webm for VP8/9 and opus, mp4 
> >> otherwise
> >> +// choose muxer based on codec: webm for VP8 and opus, mp4 
> >> otherwise
> >>  // note: os->format_name is also used as part of the mimetype of 
> >> the
> >>  //   representation, e.g. video/
> >>  if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
> >> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP9 ||
> >>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
> >>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
> >>  snprintf(os->format_name, sizeof(os->format_name), "webm");
> >
> > Pushed the patchset
> >
> 
> Hi,
> 
> First of all, I would prefer the patch to actually mention what it is
> doing. It is removing the webm override from the muxer for VP9. There
> is as far as I know no option to switch between modes in current git,
> so the commit message is blindly misleading at best and just plain
> trying to look harmless (in order to get a free pass) if taken the
> wrong way. Not saying you meant it that way, but the commit message
> does not say what it does as far as I can see.
> 
> Also the patch does not mention the reason why it is doing this other
> than the fact that there's a separate webm DASH muxer. That is true,
> but the real reason you were switching this default is because the
> WebM mode does not work. Now, fixing segfaults is good. And, for the
> record, I actually agree with the change since with the profile string
> it works in dash.js on various browsers (Firefox, Chromium, Edge).
> 
> But begesus... If it is done like this you might as well be honest and
> just remove the WebM mode! Because right now you left it there to
> segfault for VP8, Opus, Vorbis. Another alternative would have been to
> apply the small change to Rodger Combs's patch
> (https://patchwork.ffmpeg.org/patch/7984/), which you even commented
> on before! Maybe it still doesn't work in browsers, but at least it
> would have gotten to that point.
> 
> Really, I am thankful that you are contributing, but I really do not
> want to see things like these after long days of work when I have not
> noticed or wasn't able to write a long reply. You waited for two days,
> and pushed without reviews even though I had shown interest in the
> patch in its first iteration. If you are interested in getting quick
> comments from someone (including me when I am awake and available),
> please join the IRC channel #ffmpeg-devel if only possible. Even if it
> is just for pokes and links to patchwork towards someone who has shown
> interest to related patches before. I try as much as possible to poke
> relevant people when I post patches, and I would prefer it if others
> would do that as well. We're not perfect and issues can and do go
> through peoples' eyes (esp. if the change set is of the larger size
> issues tend to get hidden in plain sight, unfortunately), but let's
> try to make this work.
> 
> Best regards,
> Jan
> 
> P.S. I am sorry if my way of speech came out bad, it is just past
> midnight here and I was trying to get a reply to this written after
> noticing this mail.

I can confirm that there still is a segfault occuring
./ffmpeg -i ~/fatesamples/fate/fate-suite/vp8/RRSF49-short.webm -c copy -b:v 2M 
out.mpd

Jeyapal, do you have time to look at these segfaults?
ffmpeg should not segfault!
Its also very important that no invalid files are generated (just saying so
we dont end with a quick segfault fix that then produces bad files)

Also, does this affect any release branches ?
If so the fixes need to be backported or something else done to make
the releases free of such bugs.

And i have to admit that i did not follow this too closely it was
rather the discussion about it on IRC that pointed me to it.
But if "this" commit was intended to fix the vp9 segfault then its
commit message was incomplete.
And it certainly was confusing multiple people, including me.
Commit messages should clearly describe what is changed, why it
is changed, and so forth. So that others looking at it both
b

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cbs_mpeg2: use existing buffer reference when splitting fragments

2018-04-26 Thread James Almer

On 4/26/2018 7:30 PM, Mark Thompson wrote:
> On 25/04/18 23:42, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/cbs_mpeg2.c | 9 ++---
>>  1 file changed, 2 insertions(+), 7 deletions(-)
>>
>> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
>> index 94b9591b21..30d2bb6fbf 100644
>> --- a/libavcodec/cbs_mpeg2.c
>> +++ b/libavcodec/cbs_mpeg2.c
>> @@ -146,16 +146,11 @@ static int 
>> cbs_mpeg2_split_fragment(CodedBitstreamContext *ctx,
>>  unit_size = (end - 4) - (start - 1);
>>  }
>>  
>> -unit_data = av_malloc(unit_size + AV_INPUT_BUFFER_PADDING_SIZE);
>> -if (!unit_data)
>> -return AVERROR(ENOMEM);
>> -memcpy(unit_data, start - 1, unit_size);
>> -memset(unit_data + unit_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
>> +unit_data = (uint8_t *)start - 1;
>>  
>>  err = ff_cbs_insert_unit_data(ctx, frag, i, unit_type,
>> -  unit_data, unit_size, NULL);
>> +  unit_data, unit_size, frag->data_ref);
>>  if (err < 0) {
>> -av_freep(&unit_data);
> 
> Could remove the braces here too.

Sure, changed.

> 
>>  return err;
>>  }
>>  
>>
> 
> Much nicer :)  Both patches tested, LGTM.
> 
> Thanks,

Pushed, thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

The postproc library is only used in a single filter, so should be moved into 
the filter itself if the filter was to stay, but the filter has all of its 
internal filters now in lavfi itself. (Also it's a bit weird to have a separate 
library of filters which is used in a filter in the filter library).
---
 configure | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 9fa1665496..1e00c3e7a4 100755
--- a/configure
+++ b/configure
@@ -130,7 +130,7 @@ Component options:
   --disable-avformat   disable libavformat build
   --disable-swresample disable libswresample build
   --disable-swscaledisable libswscale build
-  --disable-postproc   disable libpostproc build
+  --enable-postprocdisable libpostproc build (deprecated) [no]
   --disable-avfilter   disable libavfilter build
   --enable-avresample  enable libavresample build (deprecated) [no]
   --disable-pthreads   disable pthreads [autodetect]
@@ -3529,7 +3529,7 @@ intrinsics="none"
 enable $PROGRAM_LIST
 enable $DOCUMENT_LIST
 enable $EXAMPLE_LIST
-enable $(filter_out avresample $LIBRARY_LIST)
+enable $(filter_out postproc $(filter_out avresample $LIBRARY_LIST))
 enable stripping
 
 enable asm
@@ -6674,6 +6674,8 @@ check_deps $CONFIG_LIST   \
 
 enabled threads && ! enabled pthreads && ! enabled atomics_native && die "non 
pthread threading without atomics not supported, try adding --enable-pthreads 
or --cpu=i486 or higher if you are on x86"
 enabled avresample && warn "Building with deprecated library libavresample"
+enabled postproc && warn "Building with deprecated library libpostproc"
+enabled pp_filter && warn "Building with deprecated filter pp"
 
 if test $target_os = "haiku"; then
 disable memalign
-- 
2.15.1 (Apple Git-101)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

2018-04-26 Thread James Almer

On 4/26/2018 8:08 PM, Josh de Kock wrote:
> The postproc library is only used in a single filter, so should be moved into 
> the filter itself if the filter was to stay, but the filter has all of its 
> internal filters now in lavfi itself. (Also it's a bit weird to have a 
> separate library of filters which is used in a filter in the filter library).

If libpostproc can't be merged into the filter (or nobody bothers to do
it), then it could be moved to a separate repository, much like the
nvidia headers.

> ---
>  configure | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index 9fa1665496..1e00c3e7a4 100755
> --- a/configure
> +++ b/configure
> @@ -130,7 +130,7 @@ Component options:
>--disable-avformat   disable libavformat build
>--disable-swresample disable libswresample build
>--disable-swscaledisable libswscale build
> -  --disable-postproc   disable libpostproc build
> +  --enable-postprocdisable libpostproc build (deprecated) [no]
>--disable-avfilter   disable libavfilter build
>--enable-avresample  enable libavresample build (deprecated) [no]
>--disable-pthreads   disable pthreads [autodetect]
> @@ -3529,7 +3529,7 @@ intrinsics="none"
>  enable $PROGRAM_LIST
>  enable $DOCUMENT_LIST
>  enable $EXAMPLE_LIST
> -enable $(filter_out avresample $LIBRARY_LIST)
> +enable $(filter_out postproc $(filter_out avresample $LIBRARY_LIST))
>  enable stripping
>  
>  enable asm
> @@ -6674,6 +6674,8 @@ check_deps $CONFIG_LIST   \
>  
>  enabled threads && ! enabled pthreads && ! enabled atomics_native && die 
> "non pthread threading without atomics not supported, try adding 
> --enable-pthreads or --cpu=i486 or higher if you are on x86"
>  enabled avresample && warn "Building with deprecated library libavresample"
> +enabled postproc && warn "Building with deprecated library libpostproc"
> +enabled pp_filter && warn "Building with deprecated filter pp"

Superfluous warning, the first one is enough. You don't see a warning
for resample_filter below the one for libavresample.

>  
>  if test $target_os = "haiku"; then
>  disable memalign
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

2018-04-27 1:08 GMT+02:00, Josh de Kock :
> The postproc library is only used in a single filter

Is libswscale used in more filters? Are you planning to
deprecate it?

Seriously: The library is needed for compliance with
multimedia standards, it should not be deprecated.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter


On 2018/04/27 0:19, Carl Eugen Hoyos wrote:

2018-04-27 1:08 GMT+02:00, Josh de Kock :

The postproc library is only used in a single filter


Is libswscale used in more filters? Are you planning to
deprecate it?


No, libswscale does not suffer from the same issue of being a secondary 
filter library. See for example how libavresample is the secondary 
resampling library, which has been deprecated for being regarded as 
worse than libswscale. libpostproc is just another filtering library 
(which was shoved into lavfi instead of its filters being moved into 
lavfi). Some of the postproc filters seemingly have equivalents in lavfi 
(just going off of names), so I think removal of postproc while making 
sure equivalent filters will be available is the best way to solve this.



Seriously: The library is needed for compliance with
multimedia standards, it should not be deprecated.


I'm unsure of which multimedia standards you refer to.

--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter