Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: added support for the write_data_type callback

> > This patch makes it possible to do stuff like write a custom in-memory TS > segmenter, which was what I needed it for. > >> Hi >> >> I needed to be able to use the write_data_type callback when reading data >> from the mpegts muxer, to make my application aware of key frames in the >>

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: added support for the write_data_type callback

> > This patch makes it possible to do stuff like write a custom in-memory TS > segmenter, which was what I needed it for. > >> Hi >> >> I needed to be able to use the write_data_type callback when reading data >> from the mpegts muxer, to make my application aware of key frames in the >>

Re: [FFmpeg-devel] [PATCHv3] avcodec/nvenc: Reconfigure resolution on-the-fly

> >>> >>> >>> Can you explain the actual intended use-case for this? >>> >>> The current way to handle resolution changes (or any other stream change of >>> similar magnitude, like a pixel format change) is to flush the existing >>> encoder and then make a new one with the new parameters.

Re: [FFmpeg-devel] [PATCHv2] avcodec/nvenc: Reconfigure resolution on-the-fly

>>> Can you explain the actual intended use-case for this? >>> >>> The current way to handle resolution changes (or any other stream change of >>> similar magnitude, like a pixel format change) is to flush the existing >>> encoder and then make a new one with the new parameters. Even ignoring

Re: [FFmpeg-devel] [PATCHv3] avcodec/nvenc: Reconfigure resolution on-the-fly

>> >> >> Can you explain the actual intended use-case for this? >> >> The current way to handle resolution changes (or any other stream change of >> similar magnitude, like a pixel format change) is to flush the existing >> encoder and then make a new one with the new parameters. Even

Re: [FFmpeg-devel] [PATCHv2] avcodec/nvenc: Reconfigure resolution on-the-fly

> On 12 Mar 2019, at 23:40, Mark Thompson wrote: > >> On 08/03/2019 07:44, Oliver Collyer wrote: >> From c704e3535f866d9f89535b9df59db9ca9811bcf9 Mon Sep 17 00:00:00 2001 >> From: Oliver Collyer >> Date: Fri, 8 Mar 2019 07:42:41 + >> Subject: [P

Re: [FFmpeg-devel] [PATCH 1/1] avcodec/aacenc: Validate and log bitrate changes made during encoding

> On 12 Mar 2019, at 21:57, Rostislav Pehlivanov wrote: > >> On Sat, 9 Mar 2019 at 12:56, Oliver Collyer wrote: >> >> Although accenc appears able to cope with dynamic bitrate changes, this >> patch makes sure that any such changes are validated in the same ma

[FFmpeg-devel] [PATCH 1/1] avcodec/aacenc: Validate and log bitrate changes made during encoding

Although accenc appears able to cope with dynamic bitrate changes, this patch makes sure that any such changes are validated in the same manner as the initial bitrate and also adds logging of such changes in verbose mode. 0001-avcodec-aacenc-Validate-and-log-bitrate-changes-made.patch

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: added support for the write_data_type callback

[Apols for sending this again, but I realised the subject didn't describe the change, which was unhelpful) This patch makes it possible to do stuff like write a custom in-memory TS segmenter, which was what I needed it for. > Hi > > I needed to be able to use the write_data_type callback when

Re: [FFmpeg-devel] [PATCHv2] avcodec/nvenc: Reconfigure resolution on-the-fly

>>> To use this feature you would need to: >>> >>> 1. Specify max_width and max_height before opening the encoder >> >> Can't they be set to a maximum number to be as flexible as possible? >> > > It would allocate the output surfaces to this size if we took that approach > and I don’t think

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Reconfigure resolution on-the-fly

> On 7 Mar 2019, at 23:57, Carl Eugen Hoyos wrote: > > 2019-03-06 15:57 GMT+01:00, Oliver Collyer : >> Hi >> >> I needed the dynamic resolution changing feature of NVENC to be accessible >> through the ffmpeg libraries for a hobby project, so I added support

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc:

> Hi > > I needed to be able to use the write_data_type callback when reading data > from the mpegts muxer, to make my application aware of key frames in the data > so I added support. I used the matroska implementation as a reference. > > If this is accepted, I will format this as a proper

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Reconfigure resolution on-the-fly

> >>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h >>> index 0ce22ec4fa..7087f82ce1 100644 >>> --- a/libavcodec/avcodec.h >>> +++ b/libavcodec/avcodec.h >>> @@ -3357,6 +3357,12 @@ typedef struct AVCodecContext { >>> * - encoding: unused >>> */ >>>int

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Reconfigure resolution on-the-fly

>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h >> index 0ce22ec4fa..7087f82ce1 100644 >> --- a/libavcodec/avcodec.h >> +++ b/libavcodec/avcodec.h >> @@ -3357,6 +3357,12 @@ typedef struct AVCodecContext { >> * - encoding: unused >> */ >> int discard_damaged_percentage; >>

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Reconfigure resolution on-the-fly

>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h >> index 0ce22ec4fa..7087f82ce1 100644 >> --- a/libavcodec/avcodec.h >> +++ b/libavcodec/avcodec.h >> @@ -3357,6 +3357,12 @@ typedef struct AVCodecContext { >> * - encoding: unused >> */ >> int discard_damaged_percentage; >>

[FFmpeg-devel] [PATCH] avformat/mpegtsenc:

Hi I needed to be able to use the write_data_type callback when reading data from the mpegts muxer, to make my application aware of key frames in the data so I added support. I used the matroska implementation as a reference. If this is accepted, I will format this as a proper patch after

[FFmpeg-devel] [PATCH] avcodec/nvenc: Reconfigure resolution on-the-fly

Hi I needed the dynamic resolution changing feature of NVENC to be accessible through the ffmpeg libraries for a hobby project, so I added support and here is a patch. I will format this as a proper patch after any changes necessary following feedback. To use this feature you would need to:

[FFmpeg-devel] NVENC: Possible issue with recent b_frame_mode support?

Hello With latest ffmpeg-master code on Windows, when I enable the new nvenc encoder option "b_ref_mode" with "middle", and 4 b-frames, I find that calls to avcodec_receive_packet are returning invalid dts/pts combinations. To be more precise dts is frequently greater than pts by 1. This then

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

Version created using git format-patch. 0001-Fixed-some-minor-memory-leaks.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

19 4:59 AM, Oliver Collyer wrote: >> >> >>> On 2 Jan 2019, at 17:52, Oliver Collyer wrote: >>> >>> >>> >>>> On 2 Jan 2019, at 11:30, Oliver Collyer wrote: >>>> >>>> >>>> >>>>> O

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

> On 2 Jan 2019, at 17:52, Oliver Collyer wrote: > > > >> On 2 Jan 2019, at 11:30, Oliver Collyer wrote: >> >> >> >>> On 1 Jan 2019, at 23:58, James Almer wrote: >>> >>> On 1/1/2019 5:01 PM, Oliver Collyer wrot

Re: [FFmpeg-devel] Memory leaks using x265 encoder

> On 2 Jan 2019, at 19:18, Steinar H. Gunderson > wrote: > > On Wed, Jan 02, 2019 at 04:34:28PM +0100, Nicolas George wrote: >> This is not a leak, it is short-sightedness by leak detectors. > > Most modern leak detectors distinguish between memory that's still reachable > (usually not a

Re: [FFmpeg-devel] Memory leaks using x265 encoder

> On 2 Jan 2019, at 18:38, Nicolas George wrote: > > Oliver Collyer (2019-01-02): >> Can you clarify what you mean by "static variables are unacceptable". >> They're all over the place in ffmpeg (random example >> https://github.com/FFmpeg/FFmpeg/blob/a0a

Re: [FFmpeg-devel] Memory leaks using x265 encoder

>>> +static int open_enc_count = 0; >>> +static pthread_mutex_t open_enc_count_lock = PTHREAD_MUTEX_INITIALIZER; >> >> Static variables are unacceptable. And indeed, these are wrong: you are >> counting several instances, possibly of different APIs, but with a >> single counter. >> > > Yes, I

Re: [FFmpeg-devel] Memory leaks using x265 encoder

> On 2 Jan 2019, at 18:05, Nicolas George wrote: > > Oliver Collyer (2019-01-02): >> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c > > Please use git format-patch to prepare your patches. Also please try to > convince your MUA to use text/plain for pa

Re: [FFmpeg-devel] Memory leaks using x265 encoder

> On 2 Jan 2019, at 16:03, Oliver Collyer wrote: > > > >> On 2 Jan 2019, at 12:58, Oliver Collyer wrote: >> >> Hello >> >> So this time I'm reporting some potential memory leaks in the x265 encoder. >> There are a few hundred following

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

> On 2 Jan 2019, at 11:30, Oliver Collyer wrote: > > > >> On 1 Jan 2019, at 23:58, James Almer wrote: >> >> On 1/1/2019 5:01 PM, Oliver Collyer wrote: >>> -- Block 26224 at 0x74240F70: 151 bytes -- >>> Leak Hash: 0x35

Re: [FFmpeg-devel] Memory leaks using x265 encoder

> On 2 Jan 2019, at 12:58, Oliver Collyer wrote: > > Hello > > So this time I'm reporting some potential memory leaks in the x265 encoder. > There are a few hundred following a short encode session, but all seem to > have the same call stack as below but varying alloca

[FFmpeg-devel] Memory leaks using x265 encoder

Hello So this time I'm reporting some potential memory leaks in the x265 encoder. There are a few hundred following a short encode session, but all seem to have the same call stack as below but varying allocation sizes. I am calling avcodec_open2() to open the encoder and then

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

> On 1 Jan 2019, at 23:58, James Almer wrote: > > On 1/1/2019 5:01 PM, Oliver Collyer wrote: >> -- Block 26224 at 0x74240F70: 151 bytes -- >> Leak Hash: 0x357CD5AF, Count: 1, Total 151 bytes >> Call Stack (TID 55752): >>ucrtb

[FFmpeg-devel] Possible memory leaks in dshow capture

Greetings I'm reporting some possible memory leaks in the dshow format code. As far as I can tell I'm freeing everything I should; the leaks come via allocations made during av_format_open_input and I can confirm that in my code I calling av_format_close_input when I'm done, as per the

Re: [FFmpeg-devel] Patches related to bug 4988

So I’ve spent some more time investigating this issue. It actually affects the two USB capture devices I have, the Magewell XI100DUSB-HDMI and the Inogeni DVI2USB. Each of them suffers similar (but not identical) problems with corrupted buffers at the start of the capture. One workaround is

Re: [FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

> Just one note; encoding from YUV420P to P010LE is still slow. It will be > nice a similar patch is done for YUV420P 8bits to P010LE 10 bits > convertion. (For reason: > http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf) > Ali I’m curious as whether you have managed to save

Re: [FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

> On 2 Sep 2016, at 12:12, Timo Rothenpieler wrote: > >> Just sticking my head above the parapet, but shouldn’t things like... >> >>> +for (x = 0; x < c->srcW / 2; x++) { >>> +dstUV[x*2 ] = src[1][x] << 6; >>> +dstUV[x*2+1] =

Re: [FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

Just sticking my head above the parapet, but shouldn’t things like... > +for (x = 0; x < c->srcW / 2; x++) { > +dstUV[x*2 ] = src[1][x] << 6; > +dstUV[x*2+1] = src[2][x] << 6; > +} …be more efficiently written as... uint16_t* tdstUV =

Re: [FFmpeg-devel] Performance of P010LE/BE pixel convertion

> I’m not sure it’ll make much difference - you may recall my original > patch had code in nvenc.c that took a YUV420P input and converted it > to P010 as it fed the frames into the encoder. Out of curiosity I did > some quick testing of this versus the code that has since been added > in swscale

Re: [FFmpeg-devel] Performance of P010LE/BE pixel convertion

> On 1 Sep 2016, at 14:59, Timo Rothenpieler wrote: > > Am 01.09.2016 um 13:44 schrieb Ronald S. Bultje: >> Hi Timo, >> >> On Thu, Sep 1, 2016 at 7:34 AM, Timo Rothenpieler >> wrote: >> Hi, On Thu, Sep 1, 2016 at 7:00 AM, Ali

Re: [FFmpeg-devel] Performance of P010LE/BE pixel convertion

> On 1 Sep 2016, at 14:44, Ronald S. Bultje wrote: > > Hi Timo, > > On Thu, Sep 1, 2016 at 7:34 AM, Timo Rothenpieler > wrote: > >>> Hi, >>> >>> On Thu, Sep 1, 2016 at 7:00 AM, Ali KIZIL wrote: >>> Hi Oliver, I

Re: [FFmpeg-devel] Performance of P010LE/BE pixel convertion

Hi Ali > On 1 Sep 2016, at 14:00, Ali KIZIL wrote: > > Hi Oliver, > > I just setup my DDR3 RAM speed to 2133 Mhz on i7 4960x server. It dosnt > make a much difference. FPS is still waiving 41-44 fps for UHD P010LE HEVC > Main 10 encoding. > > Also, rawvideo P010LE

Re: [FFmpeg-devel] Performance of P010LE/BE pixel convertion

What CPU are you using? It's presumably going to vary wildly from one CPU to another? > On 1 Sep 2016, at 08:52, Ali KIZIL wrote: > > Hi all, > > I tested P010LE pixel convertion from YUV420P in NVENC Main 10 HEVC UHD 50 > fps encoding on Nvidia Pascal Titan X GPU: > >

[FFmpeg-devel] Patches related to bug 4988

Hi In relation to this bug report from 10 months ago: https://trac.ffmpeg.org/ticket/4988 I’ve been having similar problems capturing video using v4l2 and the Magewell XI100DUSB-HDMI capture device. I’ve attached some logs to the bug report to illustrate

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Include nvEncodeAPI v7 SDK header

>> And I think there are some deprecated comments in nvenc.c: >> - references to only H.264 (HEVC was already added) >> - references to version 5 as "current SDK revision" > There are no references to version 5 of the SDK that I can see in nvenc.c following my patch. There was one next to where

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

Aug 2016, at 14:49, Timo Rothenpieler <t...@rothenpieler.org> wrote: > > On 8/25/2016 7:56 PM, Oliver Collyer wrote: >> Hi Timo >> >> Thankyou for the clarification. >> >> Attached are what should be the final versions of these patches then, with >>

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

-NVENC-added-support-for-rate-control-lookahead.patch Description: Binary data > On 25 Aug 2016, at 13:48, Timo Rothenpieler <t...@rothenpieler.org> wrote: > > Am 24.08.2016 um 12:30 schrieb Oliver Collyer: >> Ok thanks, Timo. >> >> So I’ve split this in

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

> On 24 Aug 2016, at 20:57, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > Hi! > > 2016-08-24 10:00 GMT+02:00 Oliver Collyer <ovcoll...@mac.com>: >> I’m not sure what would happen - currently the nvenc.c code enforces >> 10-bit encoding when it gets a

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

m 24.08.2016 um 10:21 schrieb Oliver Collyer: >>> In any case, please split the rate control patch from the 10bit patch. >>> >> >> Just double-checking this - both changes require a bump of the minimum NVENC >> version to 7. Do you still want them as

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

> In any case, please split the rate control patch from the 10bit patch. > Just double-checking this - both changes require a bump of the minimum NVENC version to 7. Do you still want them as separate patches or does this tie them together? If they are to be separate patches then obviously one

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

> On 24 Aug 2016, at 10:50, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > Hi! > > 2016-08-24 9:41 GMT+02:00 Oliver Collyer <ovcoll...@mac.com>: >> >>> On 23 Aug 2016, at 21:21, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>> >>

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

> On 23 Aug 2016, at 21:21, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > Hi! > > 2016-08-23 19:10 GMT+02:00 Oliver Collyer <ovcoll...@mac.com>: >> +AV_PIX_FMT_YUV420P10LE, > > I know this is theoretical but the Nvidia header seems to indicate &g

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

> On 24 Aug 2016, at 08:31, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > Hi! > > 2016-08-23 22:22 GMT+02:00 Oliver Collyer <ovcoll...@mac.com>: >>> On 23 Aug 2016, at 21:21, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>> 2016-08-2

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

Hi Carl Thanks for looking at my patch. > On 23 Aug 2016, at 21:21, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > Hi! > > 2016-08-23 19:10 GMT+02:00 Oliver Collyer <ovcoll...@mac.com>: >> +AV_PIX_FMT_YUV420P10LE, > > I know this is theoretical

[FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

Hi all Attached is a patch for the above. 10-bit HEVC encoding is a new feature of the latest Pascal Nvidia GPUs, released in the past few months; I’ve added support for the yuv420p10le and yuv444p10le pixel formats. Rate control lookahead is available on pre-Pascal models too but is

[FFmpeg-devel] [PATCH] Fixed issues preventing ffserver write_index and files_size from being set correctly which was breaking ffserver streaming.

Hi all My first patch/appearance in these parts so please go easy on me if I’ve done anything wrong! I discovered that ffserver streaming was broken (it seems like it has been since 20th November) and I opened a ticket for this (https://trac.ffmpeg.org/ticket/5250