Re: [FFmpeg-devel] FFmpeg 3.3

2017-01-22 Thread Jörn Heusipp 


On 01/23/2017 02:11 AM, Michael Niedermayer wrote:

I also intend to make some new point releases from the currently
maintained branches if someone wants to backport something


https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/367cac7827870054ae3bd6d4517e7b13f4f3f72c
needs to be applied to the 3.2 branch.

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

Re: [FFmpeg-devel] [PATCH] libavformat/rtmppkt.c ff_rtmp_packet_write write RTMP_PS_ONEBYTE chunks based on hypothesis than channel_id < 64.

2017-01-22 Thread Steven Liu 
2017-01-23 13:55 GMT+08:00 Wentao Tang :

> Although ffmpeg use internel defined video and audio channel ids that are
> than less than 64, I think it's better to patch ff_rtmp_packet_write write
> chunk logic for more clearness?
>
> here is the patch(already tested by changing RTMP_VIDEO_CHANNEL >64 even
> >256):
>
> diff --git a/libavformat/rtmppkt.c b/libavformat/rtmppkt.c
> index cde0da7..51288ad 100644
> --- a/libavformat/rtmppkt.c
> +++ b/libavformat/rtmppkt.c
> @@ -310,6 +310,18 @@ int ff_rtmp_packet_read_internal(URLContext *h,
> RTMPPacket *p, int chunk_size,
>  }
>  }
>
> +static void ff_rtmp_packet_write_chunk_basic_header(uint8_t **p, int
> mode, int channel_id) {
> +if (channel_id < 64) {
> +bytestream_put_byte(p, channel_id | (mode << 6));
> +} else if (channel_id < 64 + 256) {
> +bytestream_put_byte(p, 0  | (mode << 6));
> +bytestream_put_byte(p, channel_id - 64);
> +} else {
> +bytestream_put_byte(p, 1  | (mode << 6));
> +bytestream_put_le16(p, channel_id - 64);
> +}
> +}
> +
>  int ff_rtmp_packet_write(URLContext *h, RTMPPacket *pkt,
>   int chunk_size, RTMPPacket **prev_pkt_ptr,
>   int *nb_prev_pkt)
> @@ -354,15 +366,8 @@ int ff_rtmp_packet_write(URLContext *h, RTMPPacket
> *pkt,
>  }
>  }
>
> -if (pkt->channel_id < 64) {
> -bytestream_put_byte(, pkt->channel_id | (mode << 6));
> -} else if (pkt->channel_id < 64 + 256) {
> -bytestream_put_byte(, 0   | (mode << 6));
> -bytestream_put_byte(, pkt->channel_id - 64);
> -} else {
> -bytestream_put_byte(, 1   | (mode << 6));
> -bytestream_put_le16(, pkt->channel_id - 64);
> -}
> +ff_rtmp_packet_write_chunk_basic_header(, mode, pkt->channel_id);
> +
>  if (mode != RTMP_PS_ONEBYTE) {
>  bytestream_put_be24(, pkt->ts_field);
>  if (mode != RTMP_PS_FOURBYTES) {
> @@ -391,10 +396,12 @@ int ff_rtmp_packet_write(URLContext *h, RTMPPacket
> *pkt,
>  return ret;
>  off += towrite;
>  if (off < pkt->size) {
> -uint8_t marker = 0xC0 | pkt->channel_id;
> -if ((ret = ffurl_write(h, , 1)) < 0)
> +p = pkt_hdr;
> +ff_rtmp_packet_write_chunk_basic_header(, RTMP_PS_ONEBYTE,
> pkt->channel_id);
> +if ((ret = ffurl_write(h, pkt_hdr, p - pkt_hdr)) < 0)
>  return ret;
> -written++;
> +written += p - pkt_hdr;
> +
>  if (pkt->ts_field == 0xFF) {
>  uint8_t ts_header[4];
>  AV_WB32(ts_header, timestamp);
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



http://ffmpeg.org/git-howto.html


use git format-patch make patch please.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Contribute to ffmpeg

2017-01-22 Thread Steven Liu 
2017-01-20 15:45 GMT+08:00 Mayank Agarwal :

> Hi all,
>
> I want to contribute to ffmpeg.How can i start.
> First i want to modify some testcases.
>
> In which modules/files i can look into to do the same.
>
http://ffmpeg.org/developer.html
http://ffmpeg.org/git-howto.html
http://ffmpeg.org/fate.html
read there documentation at first, all the documentation is in
http://ffmpeg.org/documentation.html

>
>
> Regards
> Mayank
> ___
> 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] FFmpeg 3.3

2017-01-22 Thread Reto Kromer 
Michael Niedermayer wrote:

>Its a while since the last relase so ill make 3.3 within
>the next week(s)

Thank you, Michael!

>I also intend to make some new point releases from the
>currently maintained branches if someone wants to backport
>something

I suggest to switch "Nash" 2.7.7 to the old releases (the
last update has been made on 2016-04-30).

Best regards, Reto

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

[FFmpeg-devel] Contribute to ffmpeg

2017-01-22 Thread Mayank Agarwal 
Hi all,

I want to contribute to ffmpeg.How can i start.
First i want to modify some testcases.

In which modules/files i can look into to do the same.


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

[FFmpeg-devel] [PATCH] libavformat/rtmppkt.c ff_rtmp_packet_write write RTMP_PS_ONEBYTE chunks based on hypothesis than channel_id < 64.

2017-01-22 Thread Wentao Tang 
Although ffmpeg use internel defined video and audio channel ids that are than 
less than 64, I think it's better to patch ff_rtmp_packet_write write chunk 
logic for more clearness?

here is the patch(already tested by changing RTMP_VIDEO_CHANNEL >64 even >256):

diff --git a/libavformat/rtmppkt.c b/libavformat/rtmppkt.c
index cde0da7..51288ad 100644
--- a/libavformat/rtmppkt.c
+++ b/libavformat/rtmppkt.c
@@ -310,6 +310,18 @@ int ff_rtmp_packet_read_internal(URLContext *h, RTMPPacket 
*p, int chunk_size,
 }
 }

+static void ff_rtmp_packet_write_chunk_basic_header(uint8_t **p, int mode, int 
channel_id) {
+if (channel_id < 64) {
+bytestream_put_byte(p, channel_id | (mode << 6));
+} else if (channel_id < 64 + 256) {
+bytestream_put_byte(p, 0  | (mode << 6));
+bytestream_put_byte(p, channel_id - 64);
+} else {
+bytestream_put_byte(p, 1  | (mode << 6));
+bytestream_put_le16(p, channel_id - 64);
+}
+}
+
 int ff_rtmp_packet_write(URLContext *h, RTMPPacket *pkt,
  int chunk_size, RTMPPacket **prev_pkt_ptr,
  int *nb_prev_pkt)
@@ -354,15 +366,8 @@ int ff_rtmp_packet_write(URLContext *h, RTMPPacket *pkt,
 }
 }

-if (pkt->channel_id < 64) {
-bytestream_put_byte(, pkt->channel_id | (mode << 6));
-} else if (pkt->channel_id < 64 + 256) {
-bytestream_put_byte(, 0   | (mode << 6));
-bytestream_put_byte(, pkt->channel_id - 64);
-} else {
-bytestream_put_byte(, 1   | (mode << 6));
-bytestream_put_le16(, pkt->channel_id - 64);
-}
+ff_rtmp_packet_write_chunk_basic_header(, mode, pkt->channel_id);
+
 if (mode != RTMP_PS_ONEBYTE) {
 bytestream_put_be24(, pkt->ts_field);
 if (mode != RTMP_PS_FOURBYTES) {
@@ -391,10 +396,12 @@ int ff_rtmp_packet_write(URLContext *h, RTMPPacket *pkt,
 return ret;
 off += towrite;
 if (off < pkt->size) {
-uint8_t marker = 0xC0 | pkt->channel_id;
-if ((ret = ffurl_write(h, , 1)) < 0)
+p = pkt_hdr;
+ff_rtmp_packet_write_chunk_basic_header(, RTMP_PS_ONEBYTE, 
pkt->channel_id);
+if ((ret = ffurl_write(h, pkt_hdr, p - pkt_hdr)) < 0)
 return ret;
-written++;
+written += p - pkt_hdr;
+
 if (pkt->ts_field == 0xFF) {
 uint8_t ts_header[4];
 AV_WB32(ts_header, timestamp);

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

Re: [FFmpeg-devel] [PATCH] lavformat/utils: Fix a memleak that st->codec->hw_frames_ctx

2017-01-22 Thread Chao Liu 
On Sun, Jan 22, 2017 at 9:03 PM, Mark Thompson  wrote:

> On 20/01/17 02:06, Huang, Zhengxu wrote:
> > From 9ceb2ac6a89246f2e686eb3ad3448fbaff5328f7 Mon Sep 17 00:00:00 2001
> > From: Zhengxu 
> > Date: Fri, 13 Jan 2017 10:33:05 +0800
> > Subject: [PATCH] lavformat/utils: Fix a memleak that
> st->codec->hw_frames_ctx
> >  is not released.
> >
> > Signed-off-by: ChaoX A Liu 
> > Signed-off-by: Huang, Zhengxu 
> > Signed-off-by: Andrew, Zhang 
> > ---
> >  libavformat/utils.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index d5dfca7..cadec15 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -4127,6 +4127,7 @@ static void free_stream(AVStream **pst)
> >  FF_DISABLE_DEPRECATION_WARNINGS
> >  av_freep(>codec->extradata);
> >  av_freep(>codec->subtitle_header);
> > +av_buffer_unref(>codec->hw_frames_ctx);
> >  av_freep(>codec);
> >  FF_ENABLE_DEPRECATION_WARNINGS
> >  #endif
> > --
> > 1.8.3.1
> >
>
> As stated elsewhere, this should never happen in a sane program
> (AVStream.codec was deprecated before AVCodecContext.hw_frames_ctx was
> introduced), but I admit that ffmpeg.c cannot be said to be a sane program.
>
> I think the patch is probably ok, but it is very difficult to tell.  Why
> doesn't the code here already call avcodec_free_context() here to free
> st->codec properly, including unreffing hw_frames_ctx?  I imagine there is
> some crazy reason for this (some fields have been copied somewhere else,
> maybe?), and without knowing that I don't think this patch should be
> applied.
>
> So, I mostly agree with Hendrik that it is probably better to fix ffmpeg.c
> to not cause the problem in the first place rather than changing this
> deprecated code in lavf.
>
> Thanks,
>
> - Mark


OK. Let's end this topic till we find out a graceful way to fix it.

Thanks for all your patient explaining.

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

[FFmpeg-devel] FFmpeg 3.3

2017-01-22 Thread Michael Niedermayer 
Hi all

Its a while since the last relase so ill make 3.3 within the next
week(s)
Name suggestions needed like always

I also intend to make some new point releases from the currently
maintained branches if someone wants to backport something

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

[FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video resolution (v5)

2017-01-22 Thread pkoshevoy 
From: Pavel Koshevoy 

CUVID on GeForce GT 730 and GeForce GTX 1060 does not report any when
decoding 8K h264 packets.  However, it does return an error during
cuvidCreateDecoder call if the indicated video resolution is not
supported.

Given that stream resolution is typically known as a result of probing
it is better to use this information during avcodec_open2 call to fail
immediately, rather than proceeding to decode and never receiving any
frames from the decoder nor receiving any indication of decode failure.
---
 libavcodec/cuvid.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 8fc713d..9b35476 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -612,7 +612,10 @@ static av_cold int cuvid_decode_end(AVCodecContext *avctx)
 return 0;
 }
 
-static int cuvid_test_dummy_decoder(AVCodecContext *avctx, CUVIDPARSERPARAMS 
*cuparseinfo)
+static int cuvid_test_dummy_decoder(AVCodecContext *avctx,
+const CUVIDPARSERPARAMS *cuparseinfo,
+int probed_width,
+int probed_height)
 {
 CuvidContext *ctx = avctx->priv_data;
 CUVIDDECODECREATEINFO cuinfo;
@@ -625,8 +628,8 @@ static int cuvid_test_dummy_decoder(AVCodecContext *avctx, 
CUVIDPARSERPARAMS *cu
 cuinfo.ChromaFormat = cudaVideoChromaFormat_420;
 cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12;
 
-cuinfo.ulWidth = 1280;
-cuinfo.ulHeight = 720;
+cuinfo.ulWidth = probed_width;
+cuinfo.ulHeight = probed_height;
 cuinfo.ulTargetWidth = cuinfo.ulWidth;
 cuinfo.ulTargetHeight = cuinfo.ulHeight;
 
@@ -669,6 +672,9 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
AV_PIX_FMT_NV12,
AV_PIX_FMT_NONE };
 
+int probed_width = avctx->coded_width ? avctx->coded_width : 1280;
+int probed_height = avctx->coded_height ? avctx->coded_height : 720;
+
 // Accelerated transcoding scenarios with 'ffmpeg' require that the
 // pix_fmt be set to AV_PIX_FMT_CUDA early. The sw_pix_fmt, and the
 // pix_fmt for non-accelerated transcoding, do not need to be correct
@@ -824,7 +830,9 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
 if (ret < 0)
 goto error;
 
-ret = cuvid_test_dummy_decoder(avctx, >cuparseinfo);
+ret = cuvid_test_dummy_decoder(avctx, >cuparseinfo,
+   probed_width,
+   probed_height);
 if (ret < 0)
 goto error;
 
-- 
2.6.6

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

Re: [FFmpeg-devel] [PATCH 1/8] libavformat/dashenc: use avio_dynbuf instead of packet_write callback

2017-01-22 Thread Michael Niedermayer 
On Sun, Jan 22, 2017 at 01:33:19PM +0100, Peter Große wrote:
> On Sat, 21 Jan 2017 22:53:56 +0100
> Moritz Barsnick  wrote:
> 
> > When adding new code, please stick to "if (" with a space. (Also in
> > some of your other patches.)
> >...
> > Two different ways of doing the same thing. ;-) (Assignment to ret
> > embedded in the "if"-clause versus before it.)
> 
> Thanks for pointing that out.
> 
> The mess with "ret" exists already in the old code, so I'm not sure, whether 
> I should fix it only in lines I touch or at all occurances.
> 

> Another question: the patcheck tool "complains" about "non doxy comments".
> What is the correct way of annotating segments of code? Or is it not 
> recommend at all?

Public and private interface should be documented in the header with
doxy compatible comments

static functions are often not documented, but more documentation
certainly is a good thing unless its totally obvious what a function
does and everything surrounding

sections in funtions are generally documented with normal comments
(thats how its done in the codebase not neccessarily the best or
only choice)

but you may want to consider spliting a function into multiple if
it has sections that need documentation

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCHv3 2/3] lavfi/loudnorm: add an internal libebur128 library

2017-01-22 Thread Michael Niedermayer 
On Sun, Jan 22, 2017 at 04:30:15PM +0100, Marton Balint wrote:
> 
> On Sat, 21 Jan 2017, Michael Niedermayer wrote:
> 
> >On Tue, Nov 01, 2016 at 09:08:16PM +0100, Marton Balint wrote:
> >>Also contains the following changes to the library:
> >>- add ff_ prefix to functions
> >>- remove cplusplus defines.
> >>- add FF_ prefix to contants and some structs
> >>- remove true peak calculation feature, since it uses its own resampler, and
> >>  af_loudnorm does not need it.
> >>- remove version info and some fprintf(stderr) functions
> >>- convert to use av_malloc
> >>- always use histogram mode for LRA calculation, otherwise LRA data is 
> >>slowly
> >>  consuming memory making af_loudnorm unfit for 24/7 operation. It also 
> >> uses a
> >>  BSD style linked list implementation which is probably not available on 
> >> all
> >>  platforms. So let's just remove the classic mode which not uses histogram.
> >>- add ff_thread_once for calculating static histogram tables
> >>- convert some functions to void which cannot fail
> >>- remove intrinsics and some unused headers
> >>- add support for planar audio
> >>- remove channel / sample rate changer function, in ffmpeg usually we simply
> >>  alloc a new context
> >>- convert some static variables to defines
> >>- declare static histogram variables as aligned
> >>- convert some initalizations to mallocz
> >>- add window size parameter to init function and remove window size setter
> >>  function
> >>- convert return codes to AVERROR
> >>- fix indentation
> >>
> >>Signed-off-by: Marton Balint 
> >>---
> >> Changelog |   1 +
> >> configure |   5 -
> >> doc/filters.texi  |   3 -
> >> libavfilter/Makefile  |   2 +-
> >> libavfilter/af_loudnorm.c |  60 ++--
> >> libavfilter/ebur128.c | 782 
> >> ++
> >> libavfilter/ebur128.h | 296 ++
> >> libavfilter/version.h |   2 +-
> >> 8 files changed,  insertions(+), 40 deletions(-)
> >> create mode 100644 libavfilter/ebur128.c
> >> create mode 100644 libavfilter/ebur128.h
> >[...]
> >
> >>+int ff_ebur128_relative_threshold(FFEBUR128State * st, double *out)
> >>+{
> >>+double relative_threshold;
> >>+size_t above_thresh_counter;
> >>+
> >>+if (st && (st->mode & FF_EBUR128_MODE_I) != FF_EBUR128_MODE_I)
> >>+return AVERROR(EINVAL);
> >>+
> >>+ebur128_calc_relative_threshold(st, _thresh_counter,
> >>+_threshold);
> >
> >Coverity dislikes this
> >See: 1396246 Dereference after null check
> >
> 
> Yeah, the current code is not very consistent across the functions,
> sometimes it returns an error if it gets a NULL FFEBUR128State *,
> sometimes it simply dereferences it, making it the callers
> responsibility to not use these functions with a NULL context.
> 
> I prefer to simply remove the checks for NULL, making it the callers
> responsibility the check the success of an FFEBUR128State context
> creation. Objection?

anything thats reasoable consistent and makes the
Coverity warning disppear so it doesnt "hide" more serious issues
LGTM

thx

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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/alsdec.c: testing MPEG-4 ALS decoder with floating point audio data

2017-01-22 Thread Michael Niedermayer 
On Sun, Jan 22, 2017 at 01:17:20PM +0100, Thilo Borgmann wrote:
> Am 21.01.17 um 13:33 schrieb Michael Niedermayer:
> > On Fri, Jan 20, 2017 at 10:32:14PM -0800, Thomas Turner wrote:
> >> If als_07_2ch192k32bF.mp4 isn't already located in 
> >> fate-suite/lossless-audio/, you can download at:
> >>
> >>
> >> http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-26_2010_Bitstreams/DVD1/mpeg4audio-conformance/compressedMp4/als_07_2ch192k32bF.mp4
> >>
> >> Reference file can be found at:
> >>
> >>https://dl.dropboxusercontent.com/u/1519724/als_07_2ch192k32bF.f32
> > 
> > is the (8mb) length needed to achive full coverage ?
> > or would a shorter reference be enough ?
> 
> A shorter one should work but IIRC we also use other (large) ALS conformance 
> files for FATE.
> 
> There are especially issues with unspecified behavior during the last frames 
> which is why I'd like to keep these files for regression tests. So this one 
> should also be taken as is if at all possible.

ok, uploaded as it was in the link above

the issue with large files and growing fatesamples is that some fate
clients will run out of space if the samples grow too much.
As far as my fate clients are concerned its not a real problem, just
some work setting bigger VMs up and maybe getting a bigger SSD
eventually.

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters

2017-01-22 Thread Philip Langdale 
On Sun, 22 Jan 2017 12:12:26 -0700
Pavel Koshevoy  wrote:

> Yeah, but I don't even get a 1st frame failure with YUV420P 8K from 
> h264_cuvid -- all I ever get is a 0 from avcodec_send_packet and 
> AVERROR(EAGAIN) from avcodec_receive_frame.  This is what I've
> observed with GeForce GT 730 and GeForce GTX 1060 on openSUSE 42.2
> and Ubuntu 16.04 with latest nvidia drivers.
>
I tested the 8K h.264 sample, and my experience is the same as yours.
It really does just stall out.

Given that, it looks like the dimensions check can only be done in the
way that you've done it. But we shouldn't add the chroma format check;
we already have the check after the parser calls handle_video_sequence
so that the first frame will fail - and that's reliable because it uses
the cuvid parser and doesn't rely on the externally probed values.

So, can you update the patch to just check the dimensions?

 
> I will try to make my application more robust too -- I will have to 
> buffer all the packets sent to the decoder until the 1st frame either 
> succeeds or fails, so I can re-send the same packets to another
> decoder in case of 1st frame failure.

Yeah. It's not fun but it is necessary. wm4 did this for mpv.

Thanks,

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

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters

2017-01-22 Thread Pavel Koshevoy 

On 1/22/17 11:13 AM, Philip Langdale wrote:

On Sat, 21 Jan 2017 10:27:30 -0700
pkoshe...@gmail.com wrote:


From: Pavel Koshevoy 

Evidently CUVID doesn't support decoding 422 or 444 chroma formats,
and only a limited set of resolutions per codec are supported.

Unfortunately CUVID silently drops packets for video of unsupported
resolution.  However, it will error-out at cuvidCreateDecoder call
if the indicated video resolution is not supported.

Given that stream resolution and pixel format are typically known as
a result of probing it is better to use this information during
avcodec_open2 call to fail immediately, rather than proceeding to
decode and never receiving any frames from the decoder nor receiving
any indication of decode failure.

So I'm confused. I agree that these errors do not emerge early enough
to induce failure at decoder init time, but they should all trigger
errors at first-frame decode time. That's certainly true for the
chroma format error, because I added that logic.

Assuming that is true, you should just be dealing with first-frame
failure and then falling back to SW decoding, or whatever policy
you want in your app (I assume 8K SW decoding won't go well...).



Yeah, but I don't even get a 1st frame failure with YUV420P 8K from 
h264_cuvid -- all I ever get is a 0 from avcodec_send_packet and 
AVERROR(EAGAIN) from avcodec_receive_frame.  This is what I've observed 
with GeForce GT 730 and GeForce GTX 1060 on openSUSE 42.2 and Ubuntu 
16.04 with latest nvidia drivers.


I will try to make my application more robust too -- I will have to 
buffer all the packets sent to the decoder until the 1st frame either 
succeeds or fails, so I can re-send the same packets to another decoder 
in case of 1st frame failure.


  Pavel.

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

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters

2017-01-22 Thread Pavel Koshevoy 
On Sun, Jan 22, 2017 at 9:37 AM, Pavel Koshevoy  wrote:
> On 01/22/2017 07:05 AM, Timo Rothenpieler wrote:
>>>
>>> Despite wm4 objections I am resubmitting this patch, because I can
>>> find no other reasonable method for rejecting ffmpeg cuvid decoder
>>> when it can't handle a given video stream.  An unreasonable
>>> alternative would be to duplicate the work that cuvid.c does
>>> internally on my application side, and that would be of little benefit
>>> to me and to ffmpeg -- I might as well use the nvenc APIs directly
>>> then.  I still see this patch as an improvement.
>>
>> Cuvid should still return an error, just not on init, while some stream
>> parameters are still unknown, but when decoding the first (couple)
>> frame(s).
>> If there is a case where it doesn't, I'd much rather fix that.
>
>
>
> It didn't return an error.  I was testing with 5K and 8K h264 samples
> mentioned at http://kodi.wiki/view/Samples on a GeForce GT 730 which only
> supports 4K 8-bit h264 -- ctx->cvdl->cuvidParseVideoData never returned an
> error, and cuvid_handle_video_sequence callback was never called.   The only
> indication I ever got from cuvid that it won't work was during
> ctx->cvdl->cuvidCreateDecoder call (after my patch).
>

I've just tested on GeForce GTX 1060 with PATAGONIA 8K mp4 sample and
I see the same behavior -- packets are accepted but the callbacks are
not called.

With the Snow Monkeys in Japan 5K Retina 60p (Ultra HD).mp4 on GeForce
1060 it actually does call the callbacks and logs errors, so that's
different from GeForce 730:

[h264_cuvid @ 0x7fff9c000980]
ctx->cvdl->cuvidDecodePicture(ctx->cudecoder, picparams) failed ->
CUDA_ERROR_INVALID_HANDLE: invalid resource handle
[h264_cuvid @ 0x7fff9c000980] cuvid decode callback error

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

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters

2017-01-22 Thread Philip Langdale 
On Sat, 21 Jan 2017 10:27:30 -0700
pkoshe...@gmail.com wrote:

> From: Pavel Koshevoy 
> 
> Evidently CUVID doesn't support decoding 422 or 444 chroma formats,
> and only a limited set of resolutions per codec are supported.
> 
> Unfortunately CUVID silently drops packets for video of unsupported
> resolution.  However, it will error-out at cuvidCreateDecoder call
> if the indicated video resolution is not supported.
> 
> Given that stream resolution and pixel format are typically known as
> a result of probing it is better to use this information during
> avcodec_open2 call to fail immediately, rather than proceeding to
> decode and never receiving any frames from the decoder nor receiving
> any indication of decode failure.

So I'm confused. I agree that these errors do not emerge early enough
to induce failure at decoder init time, but they should all trigger
errors at first-frame decode time. That's certainly true for the
chroma format error, because I added that logic.

Assuming that is true, you should just be dealing with first-frame
failure and then falling back to SW decoding, or whatever policy
you want in your app (I assume 8K SW decoding won't go well...).

Sure, it's not great that you can't get failures at init time, but
you have to be prepared to encounter fatal errors on frame decode
with dealing with hardware decoders. Most, if not all, have failure
cases that only emerge when decoding a real frame.

There's a useful discussion to have about clearly indicating how
fatal an error is from that frame decode failure (so we know that
it's due to unsupported characteristics rather than a single bad
frame), but this change won't help us get there.

And I'll repeat wm4's warning that these tests depend on the presence
of probed data that cannot be assumed in the general case; it may work
for your app, but other applications may not fill in those fields, so
it cannot be considered reliable functionality.

Thanks,

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

Re: [FFmpeg-devel] [PATCH 1/6] lavc: Add device context field to AVCodecContext

2017-01-22 Thread Timo Rothenpieler 
This would also be very useful for cuvid, and would remove some ugly
hacks and confusing corner cases from both cuvid.c and ffmpeg_cuvid.c.

patch looks fine to me as well
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters

2017-01-22 Thread Pavel Koshevoy 

On 01/22/2017 05:28 AM, Mark Thompson wrote:

On 21/01/17 17:35, Pavel Koshevoy wrote:

On Sat, Jan 21, 2017 at 10:27 AM,   wrote:

From: Pavel Koshevoy 

Evidently CUVID doesn't support decoding 422 or 444 chroma formats,
and only a limited set of resolutions per codec are supported.

Unfortunately CUVID silently drops packets for video of unsupported
resolution.  However, it will error-out at cuvidCreateDecoder call
if the indicated video resolution is not supported.

Given that stream resolution and pixel format are typically known as
a result of probing it is better to use this information during
avcodec_open2 call to fail immediately, rather than proceeding to
decode and never receiving any frames from the decoder nor receiving
any indication of decode failure.
---
  libavcodec/cuvid.c | 62 +-
  1 file changed, 57 insertions(+), 5 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 8fc713d..f9c29a1 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -612,7 +612,11 @@ static av_cold int cuvid_decode_end(AVCodecContext *avctx)
  return 0;
  }

-static int cuvid_test_dummy_decoder(AVCodecContext *avctx, CUVIDPARSERPARAMS 
*cuparseinfo)
+static int cuvid_test_dummy_decoder(AVCodecContext *avctx,
+const CUVIDPARSERPARAMS *cuparseinfo,
+cudaVideoChromaFormat probed_chroma_format,
+int probed_width,
+int probed_height)
  {
  CuvidContext *ctx = avctx->priv_data;
  CUVIDDECODECREATEINFO cuinfo;
@@ -622,11 +626,11 @@ static int cuvid_test_dummy_decoder(AVCodecContext 
*avctx, CUVIDPARSERPARAMS *cu
  memset(, 0, sizeof(cuinfo));

  cuinfo.CodecType = cuparseinfo->CodecType;
-cuinfo.ChromaFormat = cudaVideoChromaFormat_420;
+cuinfo.ChromaFormat = probed_chroma_format;
  cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12;

-cuinfo.ulWidth = 1280;
-cuinfo.ulHeight = 720;
+cuinfo.ulWidth = probed_width;
+cuinfo.ulHeight = probed_height;
  cuinfo.ulTargetWidth = cuinfo.ulWidth;
  cuinfo.ulTargetHeight = cuinfo.ulHeight;

@@ -653,6 +657,36 @@ static int cuvid_test_dummy_decoder(AVCodecContext *avctx, 
CUVIDPARSERPARAMS *cu
  return 0;
  }

+static int convert_to_cuda_video_chroma_format(enum AVPixelFormat pix_fmt,
+   cudaVideoChromaFormat *out)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
+if (!(out && desc &&
+  (desc->nb_components == 1 || desc->nb_components == 3) &&
+  (desc->log2_chroma_w < 2 && desc->log2_chroma_h < 2)))
+{
+return AVERROR(EINVAL);
+}
+
+if (desc->nb_components == 1)
+{
+*out = cudaVideoChromaFormat_Monochrome;
+}
+else if (desc->flags == AV_PIX_FMT_FLAG_PLANAR)
+{
+*out = ((desc->log2_chroma_w == 0) ? cudaVideoChromaFormat_444 :
+(desc->log2_chroma_h == 0) ? cudaVideoChromaFormat_422 :
+cudaVideoChromaFormat_420);
+}
+else
+{
+return AVERROR(EINVAL);
+}
+
+// unfortunately, 420 is the only one that works:
+return (*out == cudaVideoChromaFormat_420) ? 0 : AVERROR_EXTERNAL;
+}
+
  static av_cold int cuvid_decode_init(AVCodecContext *avctx)
  {
  CuvidContext *ctx = avctx->priv_data;
@@ -663,12 +697,27 @@ static av_cold int cuvid_decode_init(AVCodecContext 
*avctx)
  CUcontext cuda_ctx = NULL;
  CUcontext dummy;
  const AVBitStreamFilter *bsf;
+cudaVideoChromaFormat probed_chroma_format;
+int probed_width;
+int probed_height;
  int ret = 0;

  enum AVPixelFormat pix_fmts[3] = { AV_PIX_FMT_CUDA,
 AV_PIX_FMT_NV12,
 AV_PIX_FMT_NONE };

+enum AVPixelFormat probed_pix_fmt = (avctx->pix_fmt <= 0 ?
+ AV_PIX_FMT_YUV420P :
+ avctx->pix_fmt);
+
+ret = convert_to_cuda_video_chroma_format(probed_pix_fmt, 
_chroma_format);
+if (ret < 0) {
+// pixel format is not supported:
+return ret;
+}
+probed_width = avctx->coded_width ? avctx->coded_width : 1280;
+probed_height = avctx->coded_height ? avctx->coded_height : 720;
+
  // Accelerated transcoding scenarios with 'ffmpeg' require that the
  // pix_fmt be set to AV_PIX_FMT_CUDA early. The sw_pix_fmt, and the
  // pix_fmt for non-accelerated transcoding, do not need to be correct
@@ -824,7 +873,10 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
  if (ret < 0)
  goto error;

-ret = cuvid_test_dummy_decoder(avctx, >cuparseinfo);
+ret = cuvid_test_dummy_decoder(avctx, >cuparseinfo,
+   probed_chroma_format,
+

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters

2017-01-22 Thread Pavel Koshevoy 

On 01/22/2017 04:58 AM, wm4 wrote:

On Sat, 21 Jan 2017 10:35:50 -0700
Pavel Koshevoy  wrote:


On Sat, Jan 21, 2017 at 10:27 AM,   wrote:

From: Pavel Koshevoy 





-ret = cuvid_test_dummy_decoder(avctx, >cuparseinfo);
+ret = cuvid_test_dummy_decoder(avctx, >cuparseinfo,
+   probed_chroma_format,
+   probed_width,
+   probed_height);
  if (ret < 0)
  goto error;

--
2.9.2
  


Despite wm4 objections I am resubmitting this patch, because I can
find no other reasonable method for rejecting ffmpeg cuvid decoder
when it can't handle a given video stream.  An unreasonable
alternative would be to duplicate the work that cuvid.c does
internally on my application side, and that would be of little benefit
to me and to ffmpeg -- I might as well use the nvenc APIs directly
then.  I still see this patch as an improvement.

PS:

Actually, cuvid is a bit different from normal hwaccel and I confused
that (blame Sunday "morning").

In this case, do you just want the cuvid to gracefully exit the ffmpeg.c
process if decoding is not supported? In that case, this would be much
simpler:

1. Return a special error code from cuvid that signals unsupported
format
2. Make ffmpeg.c check for this error code, and stop transcoding with
an error if it's encountered



I am not working with ffmpeg.c -- I am calling ffmpeg public APIs from my 
application.  The 1. point above is essentially what my patch does.  The real 
problem is that CUVID only reports an error at cuvidCreateDecoder time, and not 
later when I attempt to decode 8K or 5K video -- it just swallows packets and 
never outputs anything (no errors, no callbacks, nothing).


Pavel.

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

Re: [FFmpeg-devel] [PATCH 1/2] ffplay: do not preallocate video texture

2017-01-22 Thread Marton Balint 


On Sun, 15 Jan 2017, Marton Balint wrote:


Since the uploads happen in the main display function, it does not matter much.

Signed-off-by: Marton Balint 
---
ffplay.c | 120 +++
1 file changed, 20 insertions(+), 100 deletions(-)


I have applied the series.

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

Re: [FFmpeg-devel] [PATCHv3 2/3] lavfi/loudnorm: add an internal libebur128 library

2017-01-22 Thread Marton Balint 


On Sat, 21 Jan 2017, Michael Niedermayer wrote:


On Tue, Nov 01, 2016 at 09:08:16PM +0100, Marton Balint wrote:

Also contains the following changes to the library:
- add ff_ prefix to functions
- remove cplusplus defines.
- add FF_ prefix to contants and some structs
- remove true peak calculation feature, since it uses its own resampler, and
  af_loudnorm does not need it.
- remove version info and some fprintf(stderr) functions
- convert to use av_malloc
- always use histogram mode for LRA calculation, otherwise LRA data is slowly
  consuming memory making af_loudnorm unfit for 24/7 operation. It also uses a
  BSD style linked list implementation which is probably not available on all
  platforms. So let's just remove the classic mode which not uses histogram.
- add ff_thread_once for calculating static histogram tables
- convert some functions to void which cannot fail
- remove intrinsics and some unused headers
- add support for planar audio
- remove channel / sample rate changer function, in ffmpeg usually we simply
  alloc a new context
- convert some static variables to defines
- declare static histogram variables as aligned
- convert some initalizations to mallocz
- add window size parameter to init function and remove window size setter
  function
- convert return codes to AVERROR
- fix indentation

Signed-off-by: Marton Balint 
---
 Changelog |   1 +
 configure |   5 -
 doc/filters.texi  |   3 -
 libavfilter/Makefile  |   2 +-
 libavfilter/af_loudnorm.c |  60 ++--
 libavfilter/ebur128.c | 782 ++
 libavfilter/ebur128.h | 296 ++
 libavfilter/version.h |   2 +-
 8 files changed,  insertions(+), 40 deletions(-)
 create mode 100644 libavfilter/ebur128.c
 create mode 100644 libavfilter/ebur128.h

[...]


+int ff_ebur128_relative_threshold(FFEBUR128State * st, double *out)
+{
+double relative_threshold;
+size_t above_thresh_counter;
+
+if (st && (st->mode & FF_EBUR128_MODE_I) != FF_EBUR128_MODE_I)
+return AVERROR(EINVAL);
+
+ebur128_calc_relative_threshold(st, _thresh_counter,
+_threshold);


Coverity dislikes this
See: 1396246 Dereference after null check



Yeah, the current code is not very consistent across the functions, 
sometimes it returns an error if it gets a NULL FFEBUR128State *, 
sometimes it simply dereferences it, making it the callers responsibility 
to not use these functions with a NULL context.


I prefer to simply remove the checks for NULL, making it the callers 
responsibility the check the success of an FFEBUR128State context 
creation. Objection?


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

Re: [FFmpeg-devel] [PATCHv2 3/3] avfilter/formats: do not allow unknown layouts in ff_parse_channel_layout if nret is not set

2017-01-22 Thread Marton Balint 


On Tue, 10 Jan 2017, Marton Balint wrote:



On Mon, 2 Jan 2017, Marton Balint wrote:

Current code returned the number of channels as channel layout in that 

case,

and if nret is not set then unknown layouts are typically not supported.

Also use the common parsing code. Use a temporary workaround to parse an
unknown channel layout such as '13c', after a 1 year grace period only 

'13C'

will work.

Signed-off-by: Marton Balint 
---
libavfilter/formats.c | 26 +++---
libavfilter/tests/formats.c   |  3 +++
tests/ref/fate/filter-formats |  3 +++
3 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 840780d..d4de862 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -664,22 +664,26 @@ int ff_parse_channel_layout(int64_t *ret, int *nret, 

const char *arg,

{
char *tail;
int64_t chlayout;
-
-chlayout = av_get_channel_layout(arg);
-if (chlayout == 0) {
-chlayout = strtol(arg, , 10);
-if (!(*tail == '\0' || *tail == 'c' && *(tail + 1) == '\0') || 

chlayout <= 0 || chlayout > 63) {

+int nb_channels;
+
+if (av_get_extended_channel_layout(arg, , _channels) < 0) 

{

+/* [TEMPORARY 2016-12 -> 2017-12]*/
+nb_channels = strtol(arg, , 10);
+if (!errno && *tail == 'c' && *(tail + 1) == '\0' && nb_channels > 

0 && nb_channels < 64) {

+chlayout = 0;
+av_log(log_ctx, AV_LOG_WARNING, "Deprecated channel count 
specification '%s'. This will stop working in releases made in 2018 and 
after.\n", arg);

+} else {
av_log(log_ctx, AV_LOG_ERROR, "Invalid channel layout '%s'\n", 

arg);

return AVERROR(EINVAL);
}
-if (nret) {
-*nret = chlayout;
-*ret = 0;
-return 0;
-}
+}
+if (!chlayout && !nret) {
+av_log(log_ctx, AV_LOG_ERROR, "Unknown channel layout '%s' is not 

supported.\n", arg);

+return AVERROR(EINVAL);
}
*ret = chlayout;
if (nret)
-*nret = av_get_channel_layout_nb_channels(chlayout);
+*nret = nb_channels;
+
return 0;
}
diff --git a/libavfilter/tests/formats.c b/libavfilter/tests/formats.c
index 0e8ba4a..5450742 100644
--- a/libavfilter/tests/formats.c
+++ b/libavfilter/tests/formats.c
@@ -39,6 +39,9 @@ int main(void)
"-1c",
"60c",
"65c",
+"2C",
+"60C",
+"65C",
"5.1",
"stereo",
"1+1+1+1",
diff --git a/tests/ref/fate/filter-formats b/tests/ref/fate/filter-formats
index 4c303d8..ea85eed 100644
--- a/tests/ref/fate/filter-formats
+++ b/tests/ref/fate/filter-formats
@@ -77,6 +77,9 @@ quad(side)
-1 = ff_parse_channel_layout(, -1, -1c);
0 = ff_parse_channel_layout(, 60, 60c);
-1 = ff_parse_channel_layout(, -1, 65c);
+0 = ff_parse_channel_layout(,  2, 2C);
+0 = ff_parse_channel_layout(, 60, 60C);
+-1 = ff_parse_channel_layout(, -1, 65C);
0 = ff_parse_channel_layout(003F,  6, 5.1);
0 = ff_parse_channel_layout(0003,  2, stereo);
0 = ff_parse_channel_layout(0001,  1, 1+1+1+1);


Ping...


I will apply the series in a day or two if I get no further comments.

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

Re: [FFmpeg-devel] [PATCH 1/8] libavformat/dashenc: use avio_dynbuf instead of packet_write callback

2017-01-22 Thread Peter Große 
On Sat, 21 Jan 2017 22:53:56 +0100
Moritz Barsnick  wrote:

> When adding new code, please stick to "if (" with a space. (Also in
> some of your other patches.)
>...
> Two different ways of doing the same thing. ;-) (Assignment to ret
> embedded in the "if"-clause versus before it.)

Thanks for pointing that out.

The mess with "ret" exists already in the old code, so I'm not sure, whether I 
should fix it only in lines I touch or at all occurances.

Another question: the patcheck tool "complains" about "non doxy comments".
What is the correct way of annotating segments of code? Or is it not recommend 
at all?

Regards,
Peter


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

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters

2017-01-22 Thread Mark Thompson 
On 21/01/17 17:35, Pavel Koshevoy wrote:
> On Sat, Jan 21, 2017 at 10:27 AM,   wrote:
>> From: Pavel Koshevoy 
>>
>> Evidently CUVID doesn't support decoding 422 or 444 chroma formats,
>> and only a limited set of resolutions per codec are supported.
>>
>> Unfortunately CUVID silently drops packets for video of unsupported
>> resolution.  However, it will error-out at cuvidCreateDecoder call
>> if the indicated video resolution is not supported.
>>
>> Given that stream resolution and pixel format are typically known as
>> a result of probing it is better to use this information during
>> avcodec_open2 call to fail immediately, rather than proceeding to
>> decode and never receiving any frames from the decoder nor receiving
>> any indication of decode failure.
>> ---
>>  libavcodec/cuvid.c | 62 
>> +-
>>  1 file changed, 57 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
>> index 8fc713d..f9c29a1 100644
>> --- a/libavcodec/cuvid.c
>> +++ b/libavcodec/cuvid.c
>> @@ -612,7 +612,11 @@ static av_cold int cuvid_decode_end(AVCodecContext 
>> *avctx)
>>  return 0;
>>  }
>>
>> -static int cuvid_test_dummy_decoder(AVCodecContext *avctx, 
>> CUVIDPARSERPARAMS *cuparseinfo)
>> +static int cuvid_test_dummy_decoder(AVCodecContext *avctx,
>> +const CUVIDPARSERPARAMS *cuparseinfo,
>> +cudaVideoChromaFormat 
>> probed_chroma_format,
>> +int probed_width,
>> +int probed_height)
>>  {
>>  CuvidContext *ctx = avctx->priv_data;
>>  CUVIDDECODECREATEINFO cuinfo;
>> @@ -622,11 +626,11 @@ static int cuvid_test_dummy_decoder(AVCodecContext 
>> *avctx, CUVIDPARSERPARAMS *cu
>>  memset(, 0, sizeof(cuinfo));
>>
>>  cuinfo.CodecType = cuparseinfo->CodecType;
>> -cuinfo.ChromaFormat = cudaVideoChromaFormat_420;
>> +cuinfo.ChromaFormat = probed_chroma_format;
>>  cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12;
>>
>> -cuinfo.ulWidth = 1280;
>> -cuinfo.ulHeight = 720;
>> +cuinfo.ulWidth = probed_width;
>> +cuinfo.ulHeight = probed_height;
>>  cuinfo.ulTargetWidth = cuinfo.ulWidth;
>>  cuinfo.ulTargetHeight = cuinfo.ulHeight;
>>
>> @@ -653,6 +657,36 @@ static int cuvid_test_dummy_decoder(AVCodecContext 
>> *avctx, CUVIDPARSERPARAMS *cu
>>  return 0;
>>  }
>>
>> +static int convert_to_cuda_video_chroma_format(enum AVPixelFormat pix_fmt,
>> +   cudaVideoChromaFormat *out)
>> +{
>> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
>> +if (!(out && desc &&
>> +  (desc->nb_components == 1 || desc->nb_components == 3) &&
>> +  (desc->log2_chroma_w < 2 && desc->log2_chroma_h < 2)))
>> +{
>> +return AVERROR(EINVAL);
>> +}
>> +
>> +if (desc->nb_components == 1)
>> +{
>> +*out = cudaVideoChromaFormat_Monochrome;
>> +}
>> +else if (desc->flags == AV_PIX_FMT_FLAG_PLANAR)
>> +{
>> +*out = ((desc->log2_chroma_w == 0) ? cudaVideoChromaFormat_444 :
>> +(desc->log2_chroma_h == 0) ? cudaVideoChromaFormat_422 :
>> +cudaVideoChromaFormat_420);
>> +}
>> +else
>> +{
>> +return AVERROR(EINVAL);
>> +}
>> +
>> +// unfortunately, 420 is the only one that works:
>> +return (*out == cudaVideoChromaFormat_420) ? 0 : AVERROR_EXTERNAL;
>> +}
>> +
>>  static av_cold int cuvid_decode_init(AVCodecContext *avctx)
>>  {
>>  CuvidContext *ctx = avctx->priv_data;
>> @@ -663,12 +697,27 @@ static av_cold int cuvid_decode_init(AVCodecContext 
>> *avctx)
>>  CUcontext cuda_ctx = NULL;
>>  CUcontext dummy;
>>  const AVBitStreamFilter *bsf;
>> +cudaVideoChromaFormat probed_chroma_format;
>> +int probed_width;
>> +int probed_height;
>>  int ret = 0;
>>
>>  enum AVPixelFormat pix_fmts[3] = { AV_PIX_FMT_CUDA,
>> AV_PIX_FMT_NV12,
>> AV_PIX_FMT_NONE };
>>
>> +enum AVPixelFormat probed_pix_fmt = (avctx->pix_fmt <= 0 ?
>> + AV_PIX_FMT_YUV420P :
>> + avctx->pix_fmt);
>> +
>> +ret = convert_to_cuda_video_chroma_format(probed_pix_fmt, 
>> _chroma_format);
>> +if (ret < 0) {
>> +// pixel format is not supported:
>> +return ret;
>> +}
>> +probed_width = avctx->coded_width ? avctx->coded_width : 1280;
>> +probed_height = avctx->coded_height ? avctx->coded_height : 720;
>> +
>>  // Accelerated transcoding scenarios with 'ffmpeg' require that the
>>  // pix_fmt be set to AV_PIX_FMT_CUDA early. The sw_pix_fmt, and the
>>  // pix_fmt for non-accelerated transcoding, do not need to be correct
>> @@ -824,7 +873,10 @@ static

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters

2017-01-22 Thread wm4 
On Sat, 21 Jan 2017 10:35:50 -0700
Pavel Koshevoy  wrote:

> On Sat, Jan 21, 2017 at 10:27 AM,   wrote:
> > From: Pavel Koshevoy 
> >
> > Evidently CUVID doesn't support decoding 422 or 444 chroma formats,
> > and only a limited set of resolutions per codec are supported.
> >
> > Unfortunately CUVID silently drops packets for video of unsupported
> > resolution.  However, it will error-out at cuvidCreateDecoder call
> > if the indicated video resolution is not supported.
> >
> > Given that stream resolution and pixel format are typically known as
> > a result of probing it is better to use this information during
> > avcodec_open2 call to fail immediately, rather than proceeding to
> > decode and never receiving any frames from the decoder nor receiving
> > any indication of decode failure.
> > ---
> >  libavcodec/cuvid.c | 62 
> > +-
> >  1 file changed, 57 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
> > index 8fc713d..f9c29a1 100644
> > --- a/libavcodec/cuvid.c
> > +++ b/libavcodec/cuvid.c
> > @@ -612,7 +612,11 @@ static av_cold int cuvid_decode_end(AVCodecContext 
> > *avctx)
> >  return 0;
> >  }
> >
> > -static int cuvid_test_dummy_decoder(AVCodecContext *avctx, 
> > CUVIDPARSERPARAMS *cuparseinfo)
> > +static int cuvid_test_dummy_decoder(AVCodecContext *avctx,
> > +const CUVIDPARSERPARAMS *cuparseinfo,
> > +cudaVideoChromaFormat 
> > probed_chroma_format,
> > +int probed_width,
> > +int probed_height)
> >  {
> >  CuvidContext *ctx = avctx->priv_data;
> >  CUVIDDECODECREATEINFO cuinfo;
> > @@ -622,11 +626,11 @@ static int cuvid_test_dummy_decoder(AVCodecContext 
> > *avctx, CUVIDPARSERPARAMS *cu
> >  memset(, 0, sizeof(cuinfo));
> >
> >  cuinfo.CodecType = cuparseinfo->CodecType;
> > -cuinfo.ChromaFormat = cudaVideoChromaFormat_420;
> > +cuinfo.ChromaFormat = probed_chroma_format;
> >  cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12;
> >
> > -cuinfo.ulWidth = 1280;
> > -cuinfo.ulHeight = 720;
> > +cuinfo.ulWidth = probed_width;
> > +cuinfo.ulHeight = probed_height;
> >  cuinfo.ulTargetWidth = cuinfo.ulWidth;
> >  cuinfo.ulTargetHeight = cuinfo.ulHeight;
> >
> > @@ -653,6 +657,36 @@ static int cuvid_test_dummy_decoder(AVCodecContext 
> > *avctx, CUVIDPARSERPARAMS *cu
> >  return 0;
> >  }
> >
> > +static int convert_to_cuda_video_chroma_format(enum AVPixelFormat pix_fmt,
> > +   cudaVideoChromaFormat *out)
> > +{
> > +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
> > +if (!(out && desc &&
> > +  (desc->nb_components == 1 || desc->nb_components == 3) &&
> > +  (desc->log2_chroma_w < 2 && desc->log2_chroma_h < 2)))
> > +{
> > +return AVERROR(EINVAL);
> > +}
> > +
> > +if (desc->nb_components == 1)
> > +{
> > +*out = cudaVideoChromaFormat_Monochrome;
> > +}
> > +else if (desc->flags == AV_PIX_FMT_FLAG_PLANAR)
> > +{
> > +*out = ((desc->log2_chroma_w == 0) ? cudaVideoChromaFormat_444 :
> > +(desc->log2_chroma_h == 0) ? cudaVideoChromaFormat_422 :
> > +cudaVideoChromaFormat_420);
> > +}
> > +else
> > +{
> > +return AVERROR(EINVAL);
> > +}
> > +
> > +// unfortunately, 420 is the only one that works:
> > +return (*out == cudaVideoChromaFormat_420) ? 0 : AVERROR_EXTERNAL;
> > +}
> > +
> >  static av_cold int cuvid_decode_init(AVCodecContext *avctx)
> >  {
> >  CuvidContext *ctx = avctx->priv_data;
> > @@ -663,12 +697,27 @@ static av_cold int cuvid_decode_init(AVCodecContext 
> > *avctx)
> >  CUcontext cuda_ctx = NULL;
> >  CUcontext dummy;
> >  const AVBitStreamFilter *bsf;
> > +cudaVideoChromaFormat probed_chroma_format;
> > +int probed_width;
> > +int probed_height;
> >  int ret = 0;
> >
> >  enum AVPixelFormat pix_fmts[3] = { AV_PIX_FMT_CUDA,
> > AV_PIX_FMT_NV12,
> > AV_PIX_FMT_NONE };
> >
> > +enum AVPixelFormat probed_pix_fmt = (avctx->pix_fmt <= 0 ?
> > + AV_PIX_FMT_YUV420P :
> > + avctx->pix_fmt);
> > +
> > +ret = convert_to_cuda_video_chroma_format(probed_pix_fmt, 
> > _chroma_format);
> > +if (ret < 0) {
> > +// pixel format is not supported:
> > +return ret;
> > +}
> > +probed_width = avctx->coded_width ? avctx->coded_width : 1280;
> > +probed_height = avctx->coded_height ? avctx->coded_height : 720;
> > +
> >  // Accelerated transcoding scenarios with 'ffmpeg' require that the
> >  // pix_fmt be set

Re: [FFmpeg-devel] [PATCH] lavformat/utils: Fix a memleak that st->codec->hw_frames_ctx

2017-01-22 Thread wm4 
On Sun, 22 Jan 2017 10:26:58 +0800
"Huang, Zhengxu"  wrote:

> 在 2017/1/20 17:56, wm4 写道:
> 
> > On Fri, 20 Jan 2017 17:35:33 +0800
> > Chao Liu  wrote:
> >  
> >> Have you ever used valgrind? Please just run the command below:
> >> valgrind --leak-check=full --log-file=out.log ffmpeg -hwaccel qsv
> >> -qsv_device /dev/dri/renderD128 -c:v h264_qsv -i a.h264 -c:v h264_qsv -b:v
> >> 2M  -y out.h264
> >>
> >> See line 3323 of ffmpeg.c,
> >>  ret = avcodec_copy_context(ost->st->codec, ost->enc_ctx);
> >> and see what have been done in avcodec_copy_context:
> >>  if (src->hw_frames_ctx) {
> >>  dest->hw_frames_ctx = av_buffer_ref(src->hw_frames_ctx);
> >>  if (!dest->hw_frames_ctx)
> >>  goto fail;
> >>  }
> >> However, that is not freed when calling avformat_free_context.
> >>  
> > The hardware decoder should never be created in the demuxer.  
> I quite can't understand why this related to the "demuxer". Firstly we 
> should admint that if
> there is a memleak issue. Secondly, how or where to free the hw_frames_ctx.

demuxer = libavformat. libavformat sometimes/often opens a decoder to
probe codec parameters. (Which I think is madness, but that's another
issue.)

What absolutely shouldn't happen is that libavformat opens a
hardware-based decoder. What should happen even _less_ is that closing
the decoder somehow leaves hw_frames_ctx set.

I'm against painting bugs just over without knowing the real underlying
issue.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/6] ffmpeg: Always make the qsv device if the option is set

2017-01-22 Thread wm4 
On Sat, 21 Jan 2017 22:16:15 +
Mark Thompson  wrote:

> On 18/01/17 08:01, wm4 wrote:
> > On Tue, 17 Jan 2017 22:31:48 +
> > Mark Thompson  wrote:
> >   
> >> Previously it was only created if the decode hwaccel was requested;
> >> this makes it unconditionally so we can use it without the hwaccel.
> >> ---
> >>  ffmpeg.h |  4 +---
> >>  ffmpeg_opt.c | 13 -
> >>  ffmpeg_qsv.c | 14 ++
> >>  3 files changed, 19 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/ffmpeg.h b/ffmpeg.h
> >> index 75bf50e..7362c2d 100644
> >> --- a/ffmpeg.h
> >> +++ b/ffmpeg.h
> >> @@ -604,9 +604,6 @@ extern const OptionDef options[];
> >>  extern const HWAccel hwaccels[];
> >>  extern int hwaccel_lax_profile_check;
> >>  extern AVBufferRef *hw_device_ctx;
> >> -#if CONFIG_QSV
> >> -extern char *qsv_device;
> >> -#endif
> >>  
> >>  
> >>  void term_init(void);
> >> @@ -641,6 +638,7 @@ int vdpau_init(AVCodecContext *s);
> >>  int dxva2_init(AVCodecContext *s);
> >>  int vda_init(AVCodecContext *s);
> >>  int videotoolbox_init(AVCodecContext *s);
> >> +int qsv_device_init(const char *device);
> >>  int qsv_init(AVCodecContext *s);
> >>  int qsv_transcode_init(OutputStream *ost);
> >>  int vaapi_decode_init(AVCodecContext *avctx);
> >> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> >> index a1c02fc..49397be 100644
> >> --- a/ffmpeg_opt.c
> >> +++ b/ffmpeg_opt.c
> >> @@ -462,6 +462,17 @@ static int opt_vaapi_device(void *optctx, const char 
> >> *opt, const char *arg)
> >>  }
> >>  #endif
> >>  
> >> +#if CONFIG_QSV
> >> +static int opt_qsv_device(void *optctx, const char *opt, const char *arg)
> >> +{
> >> +int err;
> >> +err = qsv_device_init(arg);
> >> +if (err < 0)
> >> +exit_program(1);
> >> +return 0;
> >> +}
> >> +#endif
> >> +
> >>  /**
> >>   * Parse a metadata specifier passed as 'arg' parameter.
> >>   * @param arg  metadata string to parse
> >> @@ -3694,7 +3705,7 @@ const OptionDef options[] = {
> >>  #endif
> >>  
> >>  #if CONFIG_QSV
> >> -{ "qsv_device", HAS_ARG | OPT_STRING | OPT_EXPERT, { _device },
> >> +{ "qsv_device", HAS_ARG | OPT_EXPERT, { .func_arg = opt_qsv_device },
> >>  "set QSV hardware device (DirectX adapter index, DRM path or X11 
> >> display name)", "device"},
> >>  #endif
> >>  
> >> diff --git a/ffmpeg_qsv.c b/ffmpeg_qsv.c
> >> index 86824b6..9356f05 100644
> >> --- a/ffmpeg_qsv.c
> >> +++ b/ffmpeg_qsv.c
> >> @@ -28,8 +28,6 @@
> >>  
> >>  #include "ffmpeg.h"
> >>  
> >> -char *qsv_device = NULL;
> >> -
> >>  static int qsv_get_buffer(AVCodecContext *s, AVFrame *frame, int flags)
> >>  {
> >>  InputStream *ist = s->opaque;
> >> @@ -43,19 +41,19 @@ static void qsv_uninit(AVCodecContext *s)
> >>  av_buffer_unref(>hw_frames_ctx);
> >>  }
> >>  
> >> -static int qsv_device_init(InputStream *ist)
> >> +int qsv_device_init(const char *device)
> >>  {
> >>  int err;
> >>  AVDictionary *dict = NULL;
> >>  
> >> -if (qsv_device) {
> >> -err = av_dict_set(, "child_device", qsv_device, 0);
> >> +if (device) {
> >> +err = av_dict_set(, "child_device", device, 0);
> >>  if (err < 0)
> >>  return err;
> >>  }
> >>  
> >>  err = av_hwdevice_ctx_create(_device_ctx, AV_HWDEVICE_TYPE_QSV,
> >> - ist->hwaccel_device, dict, 0);
> >> + device, dict, 0);
> >>  if (err < 0) {
> >>  av_log(NULL, AV_LOG_ERROR, "Error creating a QSV device\n");
> >>  goto err_out;
> >> @@ -76,7 +74,7 @@ int qsv_init(AVCodecContext *s)
> >>  int ret;
> >>  
> >>  if (!hw_device_ctx) {
> >> -ret = qsv_device_init(ist);
> >> +ret = qsv_device_init(ist->hwaccel_device);
> >>  if (ret < 0)
> >>  return ret;
> >>  }
> >> @@ -148,7 +146,7 @@ int qsv_transcode_init(OutputStream *ost)
> >>  av_log(NULL, AV_LOG_VERBOSE, "Setting up QSV transcoding\n");
> >>  
> >>  if (!hw_device_ctx) {
> >> -err = qsv_device_init(ist);
> >> +err = qsv_device_init(ist->hwaccel_device);
> >>  if (err < 0)
> >>  goto fail;
> >>  }  
> > 
> > Like the vaapi case, this leaks a device context each time the option
> > is used after the first time.  
> 
> Right, I can fix that.  (For VAAPI too.)
> 
> > Also, shouldn't this maybe only set the hwcontext type, and ffmpeg.c
> > should call av_hwdevice_ctx_create() in a common code path later?  
> 
> Is there any case where the ordering matters?
> 
> (It does have to be created unconditionally once you have the option, because 
> it needs to be set for filters to work.  The skipped scale_qsv and subsequent 
> deinterlace_qsv filters can be merged to work with hwupload after this.)

Probably would be a separate change at a much later time anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] possible to create a new ffmpeg-xcam plugin in video filters

2017-01-22 Thread Wind Yuan 

On 1/22/2017 4:28 PM, Steven Liu wrote:

2017-01-22 16:17 GMT+08:00 Wind Yuan :


Hi there,
I'm planning to implement a new video filter xcam-filter in ffmpeg.
It's from libXCam(https://github.com/01org/libxcam/wiki) which is a
project opensourced in 2015 and focusing on image/video quality improvement
and video analysis with HW acceleration, especially on GPU.
ffmpeg xcam-filter may have following features which were already
enabled in libXCam. We have customers who want use ffmpeg HW codec and
libXCam HW filter work together in their cases.
1. Wavelet based bayes shrink Noise Reduciton,
2. 3D Noise Reduction,
3. Wide Dynamic Range,
4. Defog/Dehaze
5. Digital Video Stabilization
and more.


I think it's a good idea.

Thanks.



My questions are
1. Does ffmpeg have interests on the above features?
2. Can ffmpeg accept this new video filter fmpeg-xcam?
3. libXCam is in C++ language, any ffmpeg plugins with C++ implementation
OR have to convert to standard C interface?


Perhaps alway use C is better, make the code style unify

Sure, we can have C interface export.

Thanks,
Wind Yuan

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

Re: [FFmpeg-devel] possible to create a new ffmpeg-xcam plugin in video filters

2017-01-22 Thread Steven Liu 
2017-01-22 16:17 GMT+08:00 Wind Yuan :

> Hi there,
> I'm planning to implement a new video filter xcam-filter in ffmpeg.
> It's from libXCam(https://github.com/01org/libxcam/wiki) which is a
> project opensourced in 2015 and focusing on image/video quality improvement
> and video analysis with HW acceleration, especially on GPU.
> ffmpeg xcam-filter may have following features which were already
> enabled in libXCam. We have customers who want use ffmpeg HW codec and
> libXCam HW filter work together in their cases.
> 1. Wavelet based bayes shrink Noise Reduciton,
> 2. 3D Noise Reduction,
> 3. Wide Dynamic Range,
> 4. Defog/Dehaze
> 5. Digital Video Stabilization
> and more.
>
I think it's a good idea.

>
> My questions are
> 1. Does ffmpeg have interests on the above features?
> 2. Can ffmpeg accept this new video filter fmpeg-xcam?
> 3. libXCam is in C++ language, any ffmpeg plugins with C++ implementation
> OR have to convert to standard C interface?
>
Perhaps alway use C is better, make the code style unify

>
> Thanks,
> Wind Yuan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] possible to create a new ffmpeg-xcam plugin in video filters

2017-01-22 Thread Wind Yuan 

Hi there,
I'm planning to implement a new video filter xcam-filter in ffmpeg. 
It's from libXCam(https://github.com/01org/libxcam/wiki) which is a 
project opensourced in 2015 and focusing on image/video quality 
improvement and video analysis with HW acceleration, especially on GPU.
ffmpeg xcam-filter may have following features which were already 
enabled in libXCam. We have customers who want use ffmpeg HW codec and 
libXCam HW filter work together in their cases.

1. Wavelet based bayes shrink Noise Reduciton,
2. 3D Noise Reduction,
3. Wide Dynamic Range,
4. Defog/Dehaze
5. Digital Video Stabilization
and more.

My questions are
1. Does ffmpeg have interests on the above features?
2. Can ffmpeg accept this new video filter fmpeg-xcam?
3. libXCam is in C++ language, any ffmpeg plugins with C++ 
implementation OR have to convert to standard C interface?


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