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.
ffmpe
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
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 im
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
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
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 CUVI
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 CUVI
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_I
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
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 poi
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
> 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,
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 workar
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 calculat
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
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.
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,
+
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.
Unfortunate
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/lis
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
>
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.
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
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 ti
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 G
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:
> >>
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 d
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. ;-) (Assignm
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
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: 9FF2128B147EF67
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->c
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
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/listin
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 r
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.h
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 >6
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
36 matches
Mail list logo
