Re: [FFmpeg-devel] MPEG-2 FLAGS2_FAST benchmarks

> > Did you remove the branch for FLAGS2_FAST and the large amount of inlined > code when making this measurement? > I used the attached patch to benchmark this: Normal Removed 6616 6553 6640 6514 6684 6498 6588 6505 6613 6493 Mean 6628.2 6512.6 Stdev 36.22430124 23.92279248 This means there i

Re: [FFmpeg-devel] MPEG-2 FLAGS2_FAST benchmarks

In addition here are results when precomputing the quant tables: Precalculated 6439 6424 6407 6436 6437 Mean 6428.6 Stdev 13.42758355 Kieran On Sun, 14 Jun 2020 at 16:05, Kieran Kunhya wrote: > Did you remove the branch for FLAGS2_FAST and the large amount of inlined >> code when ma

Re: [FFmpeg-devel] MPEG-2 FLAGS2_FAST benchmarks

On Sun, 14 Jun 2020 at 17:32, Michael Niedermayer wrote: > On Sun, Jun 14, 2020 at 05:05:35PM +0100, Kieran Kunhya wrote: > > In addition here are results when precomputing the quant tables: > > > > Precalculated > > 6439 > > 6424 > > 6407 > > 6436 &

Re: [FFmpeg-devel] Kicked out Paul from IRC

> The part I was arguing is applying patches which are clearly blocked. > Some developers apparently can do that. And other developers opinions > means nothing much. > The sooner we have a technical committee and code of conduct, the sooner that change can happen. You can't call people Hitler for

Re: [FFmpeg-devel] MPEG-2 FLAGS2_FAST benchmarks

On Sun, 14 Jun 2020 at 18:47, Carl Eugen Hoyos wrote: > Am So., 14. Juni 2020 um 02:33 Uhr schrieb Kieran Kunhya : > > > Logical fallacy. > > Could you please stop this? > > Apart from the personal attack, we have far too many known, reproducible > bugs to spend time

Re: [FFmpeg-devel] MPEG-2 FLAGS2_FAST benchmarks

> > > Also the speed benefits are tiny overall, sub-1%. > > This claim is not supported by the statistics you posted > For the overall decoding of MPEG-2 the VLC/dequant functions take up roughly 30% of decoding time. FAST vs normal is about 2% faster on the VLC/dequant functions, therefore the to

Re: [FFmpeg-devel] MPEG-2 FLAGS2_FAST benchmarks

> > The one-tailed (we are not considering whether "fast" is slower than > "normal") homoscedastic ("equal variance sampled, not paired") student t > test has a p value of 0.009638597, which for a typical p value threshold of > 0.05 would reject the null hypothesis ("they are the same speed") and >

Re: [FFmpeg-devel] query on pixel formats

On Sat, 20 Jun 2020 at 18:59, Gautam Ramakrishnan wrote: > On Thu, Jun 18, 2020 at 3:06 AM Carl Eugen Hoyos > wrote: > > > > Am Mi., 17. Juni 2020 um 23:30 Uhr schrieb Carl Eugen Hoyos > > : > > > > > (A wild guess is that gray8 has to be added to RGB_PIXEL_FORMATS) > > > > If this is the issue,

[FFmpeg-devel] chfd: Add tag names

Some of them were not reverse engineered correctly so I will fix them later. 0001-cfhd-Add-tag-names.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, v

Re: [FFmpeg-devel] [PATCH v2 1/2] libavcodec/pgxdec: Add PGX decoder

On Sun, 28 Jun 2020 at 15:27, Carl Eugen Hoyos wrote: > Am So., 28. Juni 2020 um 16:24 Uhr schrieb Gautam Ramakrishnan > : > > > Oh got it, just need to ignore the text then. > > You *can* > > Carl Eugen > Why are you confusing Gautam like this? If I were new to FFmpeg and working on this I woul

Re: [FFmpeg-devel] [PATCH 1/1] avcodec/h264: Fix poc_lsb in open gop context

On Mon, 2 Sep 2019 at 09:01, Gaullier Nicolas wrote: > >Envoyé : mardi 23 juillet 2019 14:09 > >When no IDR nor mmco_reset is found, prev_poc_lsb is undefined and shall > not be assumed to be zero > >--- > > libavcodec/h264_parse.c | 2 ++ > > libavcodec/h264dec.c| 2 +- > > 2 files changed, 3

Re: [FFmpeg-devel] blended telecine... possible?

On Wed, 4 Sep 2019, 07:34 Kieran O Leary, wrote: > Hi, > > On Wed, 4 Sep 2019, 04:09 Mark Filipak, < > markfilipak.windows+ffm...@gmail.com> wrote: > > > No one has responded. What does that indicate? Lack of interest? Lack of > > knowledge? Lack of time? Shunning of anyone who's not a current >

Re: [FFmpeg-devel] [PATCH v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support

is exponentiated. Patch rejected Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support

> > I agree with your guys. Can I submit a patch to remove AV_PIX_FMT_YUV422P, > it's not belong > to v210 encoder also? It make me misunderstanding it's acceptable to add > other format. > Nope, YUV422P is perfectly fine, it's the correct pixel format, there are no conversions from another pixel

Re: [FFmpeg-devel] Add on-the-fly bitrate adjustment for encoding

On Fri, 11 Oct 2019 at 10:16, Moritz Barsnick wrote: > On Thu, Oct 10, 2019 at 09:24:08 -0700, Adrian Cable wrote: > > This is an addition to ffmpeg.c which enables on-the-fly encoder (e.g. > H.264) bitrate adjustment using ffmpeg interactive mode. For example, > specify “-b:v 299k -bufsize 299k”

Re: [FFmpeg-devel] [PATCH v4 2/2] avcodec/v210dec: add the frame and slice threading support

> > Michael, I have updated the patch to limit thread_count to [1,1, > avctx->height/4], > why height/4, it's borrowed from dxv.c, please give comments whether it's > proper. > For the lack of big speed improvement, make sure you are giving each thread a slice in order. Kieran ___

Re: [FFmpeg-devel] Reimbursement request

On Tue, 29 Oct 2019, 05:02 Paul B Mahol, wrote: > On 10/29/19, Steven Liu wrote: > > Hi, > > I'm requesting the reimbursement of travel expenses for the Google Mentor > > Summit. > > I mentored the Derain project, more details can be found in [1]. > > > > > > Flight (CNY) ¥ 7062.00 > >

[FFmpeg-devel] Fwd: [OpenMedia] CfP: Open Media devront

Dear FFmpeg developers, please see call for papers for FOSDEM 2020. Kieran -- Forwarded message - From: Christophe Massiot Date: Sun, 13 Oct 2019 at 16:34 Subject: [OpenMedia] CfP: Open Media devront To: FOSDEM , Open Media devroom < open-media-devr...@lists.fosdem.org> Hi all,

Re: [FFmpeg-devel] [WIP][RFC][PATCH] avcodec: add BRAW video decoder

> +static av_cold void braw_static_init(void) > +{ > +INIT_VLC_STATIC(&dc_vlc, 13, 16, dc_bits, 1, 1, dc_codes, 2, 2, 8192); > +INIT_VLC_STATIC(&ac_vlc, 18, 194, ac_bits, 1, 1, ac_codes, 4, 4, 262144); > +} > + > +.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE | > +

Re: [FFmpeg-devel] [WIP][RFC][PATCH] avcodec: add BRAW video decoder

> There is thread_once there. And similar is done for imm4. > So do not see what you complain about. I am clearly blind. sorry Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe

Re: [FFmpeg-devel] [PATCH v1] avcodec/mpeg12dec: switch to AVBufferRef buffer for a53 caption

On Sun, 22 Dec 2019 at 13:27, wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavcodec/mpeg12dec.c | 73 > +++--- > 1 file changed, 40 insertions(+), 33 deletions(-) > Does this fix a particular issue? My patch to H.264 fixed a par

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpeg12dec: Fix invalid shift in mpeg2_fast_decode_block_intra()

On Thu, 26 Dec 2019 at 00:27, Michael Niedermayer wrote: > Fixes: left shift of negative value -695 > Fixes: > 19232/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-5702856963522560 > Fixes: > 19555/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-5741218147

Re: [FFmpeg-devel] avcodec/aacenc: Compatibility with Bluetooth A2DP headsets

> > > Thanks. > > Ping? > Have you tried using our LATM mux? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with s

Re: [FFmpeg-devel] [PATCH] Support for Frame Duplication (Doubling/Tripling) by FFMPEG's HEVC Decoder by parsing the picture_struct SEI value(Requirement:http://ffmpeg.org/pipermail/ffmpeg-devel/2019-

On Thu, 9 Jan 2020 at 10:09, Praveen Kumar wrote: > Hi, > > Re-sending the patch after incorporating the review comments over the > previous patch sent yesterday. > Hi, Leave ticks_per_frame alone. I don't see why you are changing it. Kieran ___ ffmp

Re: [FFmpeg-devel] [PATCH 2/9] swscale: Add swscale input support for Y210LE

> > > > Am Do., 16. Jan. 2020 um 07:49 Uhr schrieb Fu, Linjie < > linjie...@intel.com>: > > > > > > > > > -Original Message- > > > > > From: ffmpeg-devel On Behalf Of > > > > > Carl Eugen Hoyos > > > > > Sent: Thursday, January 16, 2020 02:30 > > > > > To: FFmpeg development discussions an

Re: [FFmpeg-devel] [PATCH] ac3enc: drop a global variable

Sent from my mobile device On Wed, 29 Jan 2020, 15:35 Anton Khirnov, wrote: > Log the warning message once per encoder instance instead. > --- > libavcodec/ac3enc.c | 5 ++--- > libavcodec/ac3enc.h | 2 ++ > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/libavcodec/ac3enc.c b

Re: [FFmpeg-devel] [PATCH] Support for Frame Duplication(Doubling/Tripling) by FFmpeg's HEVC Decoder by parsing the picture_struct SEI

On Wed, 29 Jan 2020 at 13:25, Praveen Kumar wrote: > Hi, > > Re-submitting the patch. This patch has the implementation for supporting > frame-duplication (doubling/ tripling) by FFmpeg's HEVC decoder based on > the picture_structure SEI value present in the encoded video. > picture_structure val

Re: [FFmpeg-devel] [PATCH]avfilter: add Intel IPP library based x86 optimized video scaling filter

On Sun, 23 May 2021 at 13:31, Zhislina, Victoria < victoria.zhisl...@intel.com> wrote: > From b01b4130d7301a289b3ad771eaeaf1ca2839045a Mon Sep 17 00:00:00 2001 > From: Zhislina > Date: Mon, 3 May 2021 21:53:54 +0300 > Subject: [PATCH] avfilter: add Intel IPP library based x86 optimized video > s

Re: [FFmpeg-devel] Hardware purchase request

> > I'm thinking of getting a: > LG UltraGear 27GN950-B > Can I ask why you need a ~£1000 monitor? What does it do that others can't? Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpe

Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: remove key frame tagging heuristics

On Mon, 12 Jul 2021 at 20:33, James Almer wrote: > None of these packets contain keyframes, and tagging them as such can > result in > non spec compliant output when remuxing into containers like mp4 and > Matroska, > where bogus samples would be marked as Sync Samples. > > Some tests are updated

Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: remove key frame tagging heuristics

> > Because it isn't something that should be marked as a keyframe as coded > bitstream in any kind of container, like it's the case of mp4 sync samples. > MPEG-TS Random Access Indicator expects keyframes to be signalled like this. With intra-refresh and this code removed, there will be no random

Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: remove key frame tagging heuristics

On Tue, 13 Jul 2021, 02:45 James Almer, wrote: > On 7/12/2021 10:01 PM, Kieran Kunhya wrote: > >> > >> Because it isn't something that should be marked as a keyframe as coded > >> bitstream in any kind of container, like it's the case of mp4 sync >

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/lagarith: Optimize case with singleton probability distribution

> > commit 0ca7a8deeffd33e05ae15a447259b32b6678c727 (HEAD -> master) > Author: Michael Niedermayer > Date: Mon Dec 24 01:14:50 2018 +0100 > > avcodec/lagarith: Optimize case with singleton probability distribution > > Fixes: Timeout > Fixes: > 10554/clusterfuzz-testcase-minimized-ffm

Re: [FFmpeg-devel] [PATCH 1/3] avutil/imgutils: Optimize writing 4 bytes in memset_bytes()

On Tue, 25 Dec 2018 at 22:17 Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 11502/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920 > Before: Executed > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920 > in 11294 ms > After : Exec

Re: [FFmpeg-devel] Transparency of sponsored works (was: avcodec: add photocd decoder)

On Fri, 11 Jan 2019 at 15:31 Nicolas George wrote: > Carl Eugen Hoyos (12019-01-11): > > I believe amount is never published (so far at least afair). > > I think it should. I wonder what other people think. > Are you completely out of your mind? Rega

Re: [FFmpeg-devel] [PATCH] avcodec/rscc: Avoid returning frames that have nearly no undamaged pixels in them

On Thu, 17 Jan 2019 at 00:44 Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 12192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264 > > Before: > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264 > in 15423 ms > After: > clusterfuz

[FFmpeg-devel] [PATCH] vf_showinfo: Fix timecode display

$subj - Indexing is wrong, off by one Kieran 0001-vf_showinfo-Fix-timecode-display.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg4videodec: Clear interlaced_dct for studio profile

ok On Fri, 15 Feb 2019 at 00:58 Michael Niedermayer wrote: > Fixes: Out of array access > Fixes: > 13090/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5408668986638336 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Sig

[FFmpeg-devel] lavd: Remove libndi_newtek

They have not responded to any communications: https://trac.ffmpeg.org/ticket/7589 Kieran 0001-lavd-Remove-libndi_newtek.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-dev

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpeg4videodec: Check idx in mpeg4_decode_studio_block()

On Sun, 10 Mar 2019 at 04:43 Michael Niedermayer wrote: > Fixes: Out of array access > Fixes: > 13500/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5769760178962432 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-

[FFmpeg-devel] [PATCH] News: Removal of libndi

0001-News-Removal-of-libndi.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AVPixelFormat for YUYV 10 bit.

On Mon, 25 Mar 2019 at 13:53 Yufei He wrote: > Hi > > I think there may be one format missing in AVPixelFormat. > > AV_PIX_FMT_YUYV210 > For various reasons v210 and friends are implemented as a codec in FFmpeg. Kieran ___ ffmpeg-devel mailing list ff

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

On Mon, 25 Mar 2019 at 13:02 Yufei He wrote: > Hardware codecs and software codecs are taking different responsibilities. > > Thanks a lot. > > Yufei. > Hi, You should expose the APIs to the hardware, people will buy more of them if they can program the chip to do things as they want. I appreci

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

On Mon, 25 Mar 2019 at 13:56 Kieran Kunhya wrote: > On Mon, 25 Mar 2019 at 13:02 Yufei He wrote: > >> Hardware codecs and software codecs are taking different responsibilities. >> >> Thanks a lot. >> >> Yufei. >> > > Hi, > > You should ex

[FFmpeg-devel] [PATCH] vf_drawtext: Fix memory leak

$subj 0001-vf_drawtext-Fix-memory-leak.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avfilter/interlace: change lowpass_line function

On Tue, 28 Mar 2017 at 14:17 Thomas Mundt wrote: > >>Thomas Mundt schrieb am Di, 21.3.2017: > >>>Thomas Mundt schrieb am Mo, > 13.3.2017: > >> Hi, > >> > >> this patch set > >> 1) changes the lowpass_line function prototype in vf_interlace and > vf_tinterlace as suggested by James Almer. > >> 2

Re: [FFmpeg-devel] [RFC] FFmpeg 3.3

> > also what exactly is broken with teh current tree that will be better > in a month and was better 3 weeks ago ? > Is that known ? or is it just "there were lots of chnages, things may > be broken" ? > > all just some randdom comments so myself and also others better > understand what the issue

Re: [FFmpeg-devel] [PATCH v4 1/2] codec: bitpacked: add decoder

On Fri, 31 Mar 2017 at 17:57 Rostislav Pehlivanov wrote: > On 31 March 2017 at 16:36, Damien Riegel < > damien.rie...@savoirfairelinux.com > > wrote: > > > Add a codec capable of decoding some formats of the RFC4175. For now > > it's only capable of handling YCbCr-4:2:2 with 8-bit or 10-bit depth

Re: [FFmpeg-devel] [PATCH] pthread_frame: make accesses to debug field be protected by owner lock.

On Thu, 6 Apr 2017 at 18:48 Ronald S. Bultje wrote: > The av_log() is done outside the lock, but this way the accesses to the > field (reads and writes) are always protected by a mutex. The av_log() > is not run inside the lock context because it may involve user callbacks > and doing that in per

Re: [FFmpeg-devel] [PATCH] avcodec/svq1: zero initialize entries array

On Sun, 9 Apr 2017 at 14:57 James Almer wrote: > Fixes valgrind warnings about "Use of uninitialised value of size 8" > > Signed-off-by: James Almer > --- > This probably just silences a bunch of false possitives. > > libavcodec/svq1dec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions

Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed

> > Well, this instance is exactly a case like that. If the alignment > requirements are not documented, then an application can do things in a > way similar to take_samples() right now, and result in a crash. And > there is no blaming the application, it followed the documentation. > > The bug is

Re: [FFmpeg-devel] [PATCH] hevc_sei: add support for User Data Unregistered SEI messages

> > > +if (strlen(user_data + 16) > 0) > +av_log(logctx, AV_LOG_DEBUG, "user data:\"%s\"\n", user_data + > 16); > Eugh, no, no, no. Some encoders put random junk in here and my terminal goes crazy. The h264 stuff is bad as well but libav people were so insistent this stuff was printed.

[FFmpeg-devel] libavcodec/h264_sei: Don't log random user data.

From d43c0366d4ba128772dc7909152f4e9635f269cb Mon Sep 17 00:00:00 2001 From: Kieran Kunhya Date: Fri, 5 May 2017 14:29:59 -0700 Subject: [PATCH] libavcodec/h264_sei: Don't log random user data. This prevents terminal junk. --- libavcodec/h264_sei.c | 3 --- 1 file changed, 3 deletions(-)

Re: [FFmpeg-devel] FFMpeg GPL license Violations by Android apps

Hi, Out of interest, how did you automate this process? Is it as simple as looking for the FFmpeg configure string? Regards, Kieran Kunhya On Mon, 15 May 2017 at 16:36 riya khanna wrote: > Typo: We have inspected *1.6 million free* Google Playstore Android apps > > On Mon, May 15, 2

Re: [FFmpeg-devel] question on mosiac video issues -shortest

On Tue, 23 May 2017 at 10:26 Moritz Barsnick wrote: > On Sun, May 21, 2017 at 23:36:07 +, Kyle Douglas wrote: > > When using the param -shortest appears to have no impact on my ffmpeg > > command using multiple inputs as source. One is a looping slate video > that > > stops and it seems to st

Re: [FFmpeg-devel] [PATCH] Add A53 Closed Captions to MPEG header if they are available.

> > The cc_count is only 5 bits, which mean that only 31 3-byte "closed caption > constructs" will fit in a "block".Testing this with 1080i60 material, I > found that 2 or 3 blocks was often necessary to hold all of the CC data. > > I tried ignoring that limit of 31 "constructs" per block, and

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpegvideo: Use intra_scantable in dct_unquantize_h263_intra_c()

On Tue, 20 Jun 2017, 00:38 Michael Niedermayer, wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/mpegvideo.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c > index 63a30b93ce..e29558b3a2 100644 > --- a/libav

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

> > The idea would be that there would only be one uint8_t buffer and the > 2000 entries from te pool would point into that. > So as a larger NAL shifts through the 2000 the pointers would get > distributed differently but the size would not grow > Any variable size buffer the H2645NAL needs would

Re: [FFmpeg-devel] [PATCH] web/template_head2: Remove net neutrality script

On Thu, 2 Nov 2017 at 21:12 Lou Logan wrote: > I would prefer it if the site did not involve politics. > > I implemented a client side solution using an ad blocker, so consider > this patch dropped. > I agree, the popup is annoying. I would like to save the bees, whales, environment, 25p freddo

[FFmpeg-devel] PATCH] h2645: Allocate a single buffer per packet. Drastically reduces memory usage on pathological streams.

This patch fixes very high memory usage on pathological streams. 0001-h2645-Allocate-a-single-buffer-per-packet.-Drastical.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-dev

Re: [FFmpeg-devel] libavcodec/h264_sei: Don't log random user data.

On Sat, 6 May 2017 at 17:51 James Almer wrote: > The proper change here would be to look at the uuid and print only those > known to store printable strings, and of course after making sure they > are in fact printable. > As of now, that means x264's uuid only. > The UUID can be corrupt as well.

Re: [FFmpeg-devel] libavcodec/h264_sei: Don't log random user data.

On Sat, 4 Nov 2017 at 18:28 Michael Niedermayer wrote: > > The UUID can be corrupt as well. > > We shouldn't be printing random data from the bitstream to the users > > terminal. > > i agree > Ok, I will push unless someone objects. Kieran ___ ffmpeg-

[FFmpeg-devel] [RFC] Removing mpeg4video from mpegvideo

d to write a new idct or use an existing (e.g ProRes) if applicable - DPCM mode (a bit like h264's mode) In particular I think this will break lowres. Is this ok or will the patch be blocked? Regards, Kieran Kunhya ___ ffmpeg-devel mailing li

Re: [FFmpeg-devel] [RFC] Removing mpeg4video from mpegvideo

On Sat, 4 Nov 2017 at 22:33 Carl Eugen Hoyos wrote: > 2017-11-04 21:27 GMT+01:00 Kieran Kunhya : > > > I need to remove MPEG-4 support from mpegvideo in order > > to upstream the following code: > > https://github.com/kierank/ffmpeg-sstp > > Decoding of the yuv42

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

On Thu, 16 Nov 2017 at 18:21 Ronald S. Bultje wrote: > We are re-hashing old arguments here. I'm not really interested in that. > > My review comment is and remains: please remove the log msg. Otherwise, the > patch is perfectly fine. > I agree with Ronald's argument. I don't care about this par

[FFmpeg-devel] [PATCH 1/2] libavcodec: Move ff_print_debug_info2 to mpegutils.c.

$subj 0001-libavcodec-Move-ff_print_debug_info2-to-mpegutils.c.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] h264dec: Remove mpegvideo dependency, it's not needed any more

$subj 0002-h264dec-Remove-mpegvideo-dependency-it-s-not-needed-.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tools/target_dec_fuzzer: Limit error concealment to max_pixels

> > On Mon, 20 Nov 2017 at 17:26 Michael Niedermayer > wrote: > Error concealment is time consuming, limiting it in a pixel dependant way > allows > the decoder to be fuzzed with more frames quicker > How is this a reasonable fix considering you have submitted numerous patches to fix "long-runnin

[FFmpeg-devel] [RFC][PATCH] simple_idct: Template functions to support an input bitdepth parameter

For MPEG-4 Simple Studio Profile, I need to be able to support int32_t input coeffcients to the IDCT functions. I have attempted to implement this with the attached patch. Any comments would be appreciated, I'm pretty sure it is not optimal as-is. Regards, Kieran Kunhya 0001-simple

Re: [FFmpeg-devel] [PATCH] h264: Make Truncating SPS/PPS message debug.

ping On Wed, 30 Aug 2017 at 14:44 Kieran Kunhya wrote: > Padded SPS/PPS is perfectly legal. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check ld/cbd/crd

This happens on legal files as per my "SPS/PPS truncation" patch which scares them into thinking the file is broken. The same goes with spamming logs when there is some data corruption with warnings which are very obscure. Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/scpr: optimize shift loop.

On Fri, 8 Sep 2017 at 22:29 Michael Niedermayer wrote: > Speeds code up from 50sec to 15sec > > Fixes Timeout > Fixes: 3242/clusterfuzz-testcase-5811951672229888 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by >

Re: [FFmpeg-devel] [PATCH v4 2/2] rtp: rfc4175: add handler for YCbCr-4:2:2

> > Hi, > > I am surprised to see no mention on this work in changelog [1]. > > I would put: "partial support of SMPTE 2110-20 (RFC4175)". > > Thanks, > > Eloi > > [1]: https://github.com/FFmpeg/FFmpeg/blob/master/Changelog As an open source project we cannot cite unpublished documents. Kieran _

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

On Tue, 24 Oct 2017 at 00:56 Carl Eugen Hoyos wrote: > 2017-10-24 1:43 GMT+02:00 Niki Bowe : > > On Thu, Oct 19, 2017 at 3:39 PM, Carl Eugen Hoyos > > wrote: > > >> Does the patch have a measurable speed impact? > >> > > Is there a standard set of benchmarks I can run? > > > > For typical videos

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

On Tue, 31 Oct 2017 at 01:42 Kieran Kunhya wrote: > On Tue, 24 Oct 2017 at 00:56 Carl Eugen Hoyos wrote: > >> 2017-10-24 1:43 GMT+02:00 Niki Bowe : >> > On Thu, Oct 19, 2017 at 3:39 PM, Carl Eugen Hoyos >> > wrote: >> >> >> Does the patch have

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

On Tue, 31 Oct 2017 at 02:26 Michael Niedermayer wrote: > On Thu, Oct 19, 2017 at 11:46:47AM -0700, Nikolas Bowe wrote: > > Found via fuzzing. > > /tmp/poc is a 1 MB mpegts file generated via fuzzing, where 1 packet has > many NALUs > > Before this change: > > $ /usr/bin/time -f "\t%M Max Resid

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

> > This reduces memory consumption to linear from qudratic but i think > it still can be made to allocate very large amounts of memory. > That is with many small NAL units MAX_MBPAIR_SIZE would be allocated > for each.in worst case. > So this does fix the qudratic issue but not the OOM issue. > Us

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

> > Am I missing something here? > > P.S. I see Kieran mailed the same thing as I wrote this. > Further to Derek's excellent explanation, I think the best way is to go back to the old "in-place" NAL parsing code for H264. I will prepare a patch to do this. Kieran _

Re: [FFmpeg-devel] [PATCH] Fix quadratic memory use in ff_h2645_extract_rbsp() when multiple NALUs exist in packet.

On Tue, 31 Oct 2017 at 22:36 Niki Bowe wrote: > I was going to prepare a patch, but it sounds like Kieran is going to. > Thank you Kieran. Let me know if there's anything you want me to do, or if > you would prefer me to do it for the experience. > > As for the NAL memory pool, I think I see what

Re: [FFmpeg-devel] [PATCH 1/4] V14 - Adding SCTE-35 CUI codec

On Fri, 21 Oct 2016, 20:05 Marton Balint, wrote: > > On Thu, 20 Oct 2016, Michael Niedermayer wrote: > > > On Tue, Oct 18, 2016 at 05:36:27PM -0700, Carlos Fernandez Sanz wrote: > >> From: Carlos Fernandez > >> > >> Signed-off-by: Carlos Fernandez > >> --- > >> libavcodec/avcodec.h| 1 + >

Re: [FFmpeg-devel] [PATCH 1/4] V14 - Adding SCTE-35 CUI codec

On Sat, 22 Oct 2016, 06:13 Rostislav Pehlivanov, wrote: > On 22 October 2016 at 01:17, Kieran Kunhya wrote: > > > On Fri, 21 Oct 2016, 20:05 Marton Balint, wrote: > > > > > > > > On Thu, 20 Oct 2016, Michael Niedermayer wrote: > > > > > &

[FFmpeg-devel] Fwd: [devroom-managers] Open Media devroom FOSDEM 2017 - Call For Participation

Hi all, Following a successful Open Media room at FOSDEM 2015 and 2016, we are organizing another Open Media room at FOSDEM 2017, and we are looking for propositions of talks and panels. FOSDEM is one of the largest (5,000+ hackers!) gatherings of Free Software contributors in the world and happen

Re: [FFmpeg-devel] TR-03 implementation

hings (event loop, non-blocking io, control of thread placement, latency control etc) If you do try to attempt this you'll find that capture might work, certainly playback will not work. Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] TR-03 implementation

> > The only thing which may fit would the UYVY 10bit format. But good luck > getting the conversions adapted to libswscale. I certainly won't help you > other than discourage you from doing it considering it is absolutely > useless since absolutely nothing else uses that format and also it would >

Re: [FFmpeg-devel] TR-03 implementation

> > sure, ffmpeg has support for many pixel formats and adding more > pixfmts is not a problem. > > my best answer would be to look at commits which add other pixel > formats and just follow how they were added to libswscale. make some > fate tests, and it should be done. > > hopefully you have tes

Re: [FFmpeg-devel] [RFC]lavc/ffv1dec: Scale msb-packed output to full 16bit

> > It was lossless before and is lossless after the patch but it > output the 16bit format that you don't like and of which you > claim it breaks with find_best_pix_fmt() - I still believe this > should be trivial to fix. > > Currently white is gray, the patch tries to fix this. > erm...in what w

Re: [FFmpeg-devel] [RFC]lavc/ffv1dec: Scale msb-packed output to full 16bit

On Thu, 17 Nov 2016 at 18:05 Kieran Kunhya wrote: > On Wed, 16 Nov 2016 at 23:49 Kieran Kunhya wrote: > > It was lossless before and is lossless after the patch but it > output the 16bit format that you don't like and of which you > claim it breaks with find_best_pix_fmt

Re: [FFmpeg-devel] [RFC]lavc/ffv1dec: Scale msb-packed output to full 16bit

On Wed, 16 Nov 2016 at 23:49 Kieran Kunhya wrote: > It was lossless before and is lossless after the patch but it > output the 16bit format that you don't like and of which you > claim it breaks with find_best_pix_fmt() - I still believe this > should be trivial to fix. >

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

I object to this patch for the reasons Rostislav outlined.. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/examples: add fuzz target for individual ffmpeg APIs for in-process fuzzing with libFuzzer, AFL, and similar fuzzing engines.

On Fri, 4 Nov 2016 at 21:41 Michael Niedermayer wrote: > On Fri, Oct 28, 2016 at 11:02:21PM +0200, Michael Niedermayer wrote: > > From: Thomas Garnier > > > > Signed-off-by: Michael Niedermayer > > --- > > doc/examples/decoder_targeted.c | 183 > > > 1

Re: [FFmpeg-devel] Outreachy 2016

On Mon, 8 Feb 2016, 15:34 Michael Niedermayer wrote: > > Hi all > > This is a reminder that the deadline to register FFmpeg with outreachy > is tomorrow, the 9th february > see: https://www.gnome.org/outreachy/ > "Free and open source software organizations and supporting companies are invited to

[FFmpeg-devel] [PATCH v2] Add GBRAP12 pixel format

--- libavcodec/utils.c| 2 ++ libavutil/pixdesc.c | 28 libavutil/pixfmt.h| 4 libavutil/version.h | 2 +- libswscale/input.c| 4 libswscale/swscale_unscaled.c | 3 +++ libswscale/utils.c

[FFmpeg-devel] [PATCH] avcodec/cfhd: Add support for 12-bit RGBA.

Plays all known samples --- libavcodec/cfhd.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c index 2436aae..0773ffa 100644 --- a/libavcodec/cfhd.c +++ b/libavcodec/cfhd.c @@ -152,14 +152,15 @@ static void free_buffers

[FFmpeg-devel] FFmpeg in Outreachy Round 12

up: https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-05 Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] New task ideas for GSoC and Outreachy

that a student needs to work on for two months FULL-TIME so it can't just be fixing the odd thing here and there. Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: Check the number of tag/value pairs

On Thu, 11 Feb 2016 at 21:12 Michael Niedermayer wrote: > Fixes potentially long loop > Fixes: CID1351382/11 > > Signed-off-by: Michael Niedermayer > --- > libavcodec/cfhd.c |5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c > index 2436aae..5

[FFmpeg-devel] [PATCH] avcodec/cfhd: Fix errors with valid files.

--- libavcodec/cfhd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c index 0773ffa..6dc22ca 100644 --- a/libavcodec/cfhd.c +++ b/libavcodec/cfhd.c @@ -313,7 +313,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, int *go

[FFmpeg-devel] [PATCH v2] cfhd: reallocate internal buffers on format change.

--- libavcodec/cfhd.c | 18 -- libavcodec/cfhd.h | 2 ++ 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c index 5c15d9b..46d766a 100644 --- a/libavcodec/cfhd.c +++ b/libavcodec/cfhd.c @@ -156,6 +156,7 @@ static int alloc_buffers

Re: [FFmpeg-devel] FFmpeg in Outreachy Round 12

I should be on the twitter chat (@kierank_) on the Monday. Kieran From: Marina Zhurakhinskaya To: Michael Niedermayer Cc: FFmpeg development discussions and patches ; outreachy-admins ; o...@ffmpeg.org Sent: Friday, 26 February 2016, 14:05 Subject: Re: [FFmpeg-devel] FFmpeg in Outreach

[FFmpeg-devel] [PATCH] avcodec/cfhd: Fixes cfhd_odd.mov which has a resolution of 496x241

In this case container width/height is better however. Thanks to koda for the sample --- libavcodec/cfhd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c index e37bef0..98f16d3 100644 --- a/libavcodec/cfhd.c +++ b/libavcodec/cfhd.c @@ -467,6 +467,9 @@

<    1   2   3   4   5   6   7   8   9   10   >