Re: [FFmpeg-devel] FFmpeg 3.3
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-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(&p, pkt->channel_id | (mode << 6)); > -} else if (pkt->channel_id < 64 + 256) { > -bytestream_put_byte(&p, 0 | (mode << 6)); > -bytestream_put_byte(&p, pkt->channel_id - 64); > -} else { > -bytestream_put_byte(&p, 1 | (mode << 6)); > -bytestream_put_le16(&p, pkt->channel_id - 64); > -} > +ff_rtmp_packet_write_chunk_basic_header(&p, mode, pkt->channel_id); > + > if (mode != RTMP_PS_ONEBYTE) { > bytestream_put_be24(&p, 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, &marker, 1)) < 0) > +p = pkt_hdr; > +ff_rtmp_packet_write_chunk_basic_header(&p, 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-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
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
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.
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(&p, pkt->channel_id | (mode << 6)); -} else if (pkt->channel_id < 64 + 256) { -bytestream_put_byte(&p, 0 | (mode << 6)); -bytestream_put_byte(&p, pkt->channel_id - 64); -} else { -bytestream_put_byte(&p, 1 | (mode << 6)); -bytestream_put_le16(&p, pkt->channel_id - 64); -} +ff_rtmp_packet_write_chunk_basic_header(&p, mode, pkt->channel_id); + if (mode != RTMP_PS_ONEBYTE) { bytestream_put_be24(&p, 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, &marker, 1)) < 0) +p = pkt_hdr; +ff_rtmp_packet_write_chunk_basic_header(&p, 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
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(&st->codec->extradata); > > av_freep(&st->codec->subtitle_header); > > +av_buffer_unref(&st->codec->hw_frames_ctx); > > av_freep(&st->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
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)
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, &ctx->cuparseinfo); +ret = cuvid_test_dummy_decoder(avctx, &ctx->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
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
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, &above_thresh_counter, > >>+&relative_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
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
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
[FFmpeg-devel] Implemented h264 timing SEI info to ffprobe. Review process?
Hi, I'm and old user of ffmpeg but I'm new in this community. So first of all let me congrat you for your work, ffmpeg has been always a great tool for me. I added a new small functionality to ffprobe, now any user can have frame SEI timing info available in ffprobe output (useful to read SMPTE time code). Since this is NOT a patch I don't know which is the best way to submit my changes for review, for now I created this PR against a FFmpeg forked repo: https://github.com/jordicenzano/FFmpeg/pull/1 It woud be great some guidance on that. Jordi Cenzano ___ 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
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
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
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
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
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(&cuinfo, 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, &probed_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, &ctx->cuparseinfo); +ret = cuvid_test_dummy_decoder(avctx, &ctx->cuparseinfo, + probed_chroma_format, + probed_w
Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters
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, &ctx->cuparseinfo); +ret = cuvid_test_dummy_decoder(avctx, &ctx->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] lavc/cuvid: fail early if GPU can't handle video parameters
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). 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
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
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, &above_thresh_counter, +&relative_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
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, &tail, 10); -if (!(*tail == '\0' || *tail == 'c' && *(tail + 1) == '\0') || chlayout <= 0 || chlayout > 63) { +int nb_channels; + +if (av_get_extended_channel_layout(arg, &chlayout, &nb_channels) < 0) { +/* [TEMPORARY 2016-12 -> 2017-12]*/ +nb_channels = strtol(arg, &tail, 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] lavc/cuvid: fail early if GPU can't handle video parameters
> 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. ___ 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
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(&st->codec->extradata); > av_freep(&st->codec->subtitle_header); > +av_buffer_unref(&st->codec->hw_frames_ctx); > av_freep(&st->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 ___ 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
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
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(&cuinfo, 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, >> &probed_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(AV
Re: [FFmpeg-devel] [PATCH] avcodec/alsdec.c: testing MPEG-4 ALS decoder with floating point audio data
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. -Thilo ___ 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
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(&cuinfo, 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, > > &probed_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 >
Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters
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(&cuinfo, 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, > > &probed_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 >
Re: [FFmpeg-devel] [PATCH] lavformat/utils: Fix a memleak that st->codec->hw_frames_ctx
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
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, { &qsv_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(&ist->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(&dict, "child_device", qsv_device, 0); > >> +if (device) { > >> +err = av_dict_set(&dict, "child_device", device, 0); > >> if (err < 0) > >> return err; > >> } > >> > >> err = av_hwdevice_ctx_create(&hw_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 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] possible to create a new ffmpeg-xcam plugin in video filters
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 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
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