N1KT1
£1500 total I would estimate.
I am happy to host these (as with the M1s) but as these are NUCs anyone can
buy and host them easily.
Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-
at 22:20, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Dec 4, 2022 at 1:08 PM Kieran Kunhya wrote:
> >
> >> Hello,
> >>
> >> As discussed at the developer meeting it would be good to have an
> AVX-512
> >> (ICL) FATE machine and also a
Hello,
I have not received a reply from "fate-ad...@ffmpeg.org" and would like to
know which individuals are behind this email address?
Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailma
On Sat, 10 Dec 2022 at 18:12, Carl Eugen Hoyos wrote:
> Am Fr., 9. Dez. 2022 um 18:07 Uhr schrieb Michael Niedermayer
> :
> >
> > On Thu, Dec 08, 2022 at 09:40:12PM +0000, Kieran Kunhya wrote:
> > > I intend to buy this RAM:
> > >
> https://www.amazon.
$subj
0001-libavutil-Remove-TOMI-CPU.patch
Description: Binary data
___
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
On Sat, 17 Dec 2022 at 23:44, Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Is this code broken or stand in the way of progress?
>
> - Andreas
>
I believe this CPU only exists on paper.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@
On Sun, 18 Dec 2022 at 10:41, Stefano Sabatini wrote:
> On Sat, Dec 17, 2022 at 9:46 PM Michael Niedermayer
> wrote:
> >
> > On Sat, Dec 17, 2022 at 07:57:06PM +0000, Kieran Kunhya wrote:
> > > On Sat, 10 Dec 2022 at 18:12, Carl Eugen Hoyos
> wrote:
> > >
On Tue, 8 Dec 2020 at 14:03, Josh Dekker wrote:
> Kieran offered to host one Mac Mini, though I'm unsure what his capacity
> for
> hosting is.
>
I can host as many devices as you see fit and give access to appropriate
people.
I've done this in the past when avx2 was a new feature set.
Kieran
__
On Tue, 8 Dec 2020 at 14:10, Kieran Kunhya wrote:
> On Tue, 8 Dec 2020 at 14:03, Josh Dekker wrote:
>
>> Kieran offered to host one Mac Mini, though I'm unsure what his capacity
>> for
>> hosting is.
>>
>
> I can host as many devices as you see fi
>
> I want to replace it with an event loop. That means that instead of reading
> on a protocol context, we would register a callback for when data is
> available, and then let the loop run.
>
This would be a good idea in general and bring FFmpeg into the early 21st
century.
As I understand it the
On Sat, 2 Jan 2021 at 16:52, Nicolas George wrote:
> If we want FFmpeg to have good protocols as well as good codecs, it
> needs to have the infrastructure to make them possible. And for
> protocols, the infrastructure is mostly two things: crypto protocols and
> en event loop.
>
In my opinion w
Apple Site.
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".
>
> I can host these in the UK 24/7 and provide access and label them as
> belonging to the project and not me.
>
To clarify these will be hosted in a proper datacentre, with proper
connectivity, cooling etc.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-
On Sun, 3 Jan 2021 at 21:53, Josh Dekker wrote:
> On 2021/01/03 20:18, Michael Niedermayer wrote:
> > On Sun, Jan 03, 2021 at 06:32:11PM +0100, Kieran Kunhya wrote:
> >> Hello,
> >>
> >> As it's 2021 I would like to propose FFmpeg purchase one or more (
>
> > I will buy these if nobody objects by the end of the week.
>
> Totally in favor, also I'd like us to have two machines running.
>
> Thanks for hosting!
>
> -Thilo
>
Hi,
Just to confirm, I have bought the two Mac Minis.
They should be delivered and racked up in early February (lockdown may
d
ill accept
CrowdSupply) and there is a long lead-time for it:
https://www.mouser.co.uk/ProductDetail/SiFive/HF105-000?qs=zW32dvEIR3vHEV%2FPYYkdMA==
Also, I'll have to claim for a case and M.2 SSD.
I am happy to host this like with the Apple M1.
Regards
On 3 November 2014 14:35, Michael Niedermayer wrote:
> On Mon, Nov 03, 2014 at 09:35:16AM +0100, Thomas Volkert wrote:
>> From: Thomas Volkert
>>
>> ---
>> Changelog| 1 +
>> configure| 3 +++
>> libavformat/allformats.c | 1 +
>> libavformat/udp.c| 55
>From 196dd0d9eb40ca18e3bba993f5198bd1bde536ce Mon Sep 17 00:00:00 2001
From: Kieran Kunhya
Date: Sat, 8 Nov 2014 20:34:25 -0600
Subject: [PATCH] swscale: Enable yuv2planeX_8 assembly that had been disabled
for some reason
---
libswscale/x86/swscale.c |2 +-
1 file changed, 1 insert
---
libswscale/x86/swscale.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index 8ce87b3..c9f3b1a 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -430,7 +430,7 @@ switch(c->dstBpc){ \
case 16:
filter/x86/vf_interlace.asm
new file mode 100644
index 000..40b10fc
--- /dev/null
+++ b/libavfilter/x86/vf_interlace.asm
@@ -0,0 +1,80 @@
+;*
+;* x86-optimized functions for interlace filter
+;*
+;* Copyright (C) 2014 Ki
> Can't pavgw be used here?
I don't think so?
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
erlace.o
YASM-OBJS-$(CONFIG_VOLUME_FILTER)+= x86/af_volume.o
YASM-OBJS-$(CONFIG_YADIF_FILTER) += x86/vf_yadif.o
diff --git a/libavfilter/x86/vf_interlace.asm b/libavfilter/x86/vf_interlace.asm
new file mode 100644
index 000..8c2e9b0
--- /dev/null
+++ b/libavfilter/x8
---
libavcodec/v210dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
index ae03952..978dffe 100644
--- a/libavcodec/v210dec.c
+++ b/libavcodec/v210dec.c
@@ -117,7 +117,7 @@ static int decode_frame(AVCodecContext *avctx, void *data
On 22 November 2014 at 19:32, Reimar Döffinger wrote:
> On Sat, Nov 22, 2014 at 07:11:57PM +0000, Kieran Kunhya wrote:
>> ---
>> libavcodec/v210dec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/v210dec.c b/libavcodec/v2
---
libavcodec/v210enc.c| 78 ++---
libavcodec/v210enc.h| 31
libavcodec/x86/Makefile | 2 ++
3 files changed, 88 insertions(+), 23 deletions(-)
create mode 100644 libavcodec/v210enc.h
diff --git a/libavcodec/v210enc.c b/l
vc1dsp.o
YASM-OBJS-$(CONFIG_VORBIS_DECODER) += x86/vorbisdsp.o
YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm
new file mode 100644
index 000..ca3edf4
--- /dev/null
+++ b/libavcodec/x86/v210enc.asm
@@ -0,0 +1,76 @@
+;
> You may be able to use mova below as well, but I don't know if AVFrame->data
> and AVPacket->data
> are aligned here.
> It's probably worth a try.
Won't work because 12 bytes at a time are processed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
---
libavcodec/v210enc.c | 151 +++---
libavcodec/v210enc.h | 4 +-
libavcodec/x86/v210enc.asm| 104 -
libavcodec/x86/v210enc_init.c | 13 +++-
libavutil/x86/x86util.asm | 5 ++
5 files changed, 218 inse
---
libavfilter/x86/vf_interlace.asm |2 --
1 file changed, 2 deletions(-)
diff --git a/libavfilter/x86/vf_interlace.asm b/libavfilter/x86/vf_interlace.asm
index b8d8616..85811da 100644
--- a/libavfilter/x86/vf_interlace.asm
+++ b/libavfilter/x86/vf_interlace.asm
@@ -42,8 +42,6 @@ cglobal low
---
libavcodec/v210enc.c | 151 +++---
libavcodec/v210enc.h | 4 +-
libavcodec/x86/v210enc.asm| 102 +++-
libavcodec/x86/v210enc_init.c | 13 +++-
libavutil/x86/x86util.asm | 5 ++
5 files changed, 217 inser
+145,7 @@ YASM-OBJS-$(CONFIG_RV40_DECODER) += x86/rv34dsp.o
\
YASM-OBJS-$(CONFIG_SVQ1_ENCODER) += x86/svq1enc.o
YASM-OBJS-$(CONFIG_TRUEHD_DECODER) += x86/mlpdsp.o
YASM-OBJS-$(CONFIG_TTA_DECODER)+= x86/ttadsp.o
+YASM-OBJS-$(CONFIG_V210_ENCODER) += x86/
> v210_enc_chroma_shuf1_8: db 0,-1,1,-1,2,-1,3,-1,8,-1,9,-1,10,-1,11,-1
> -v210_enc_chroma_shuf2_8: db 4,-1,5,-1,6,-1,7,-1,12,-1,13,-1,14,-1,15,-1
> +v210_enc_chroma_shuf2_8: db 3,-1,4,-1,5,-1,7,-1,11,-1,12,-1,13,-1,15,-1
>
> v210_enc_chroma_mult_8: dw 4,16,64,0,64,4,16,0
Thanks
Th
+145,7 @@ YASM-OBJS-$(CONFIG_RV40_DECODER) += x86/rv34dsp.o
\
YASM-OBJS-$(CONFIG_SVQ1_ENCODER) += x86/svq1enc.o
YASM-OBJS-$(CONFIG_TRUEHD_DECODER) += x86/mlpdsp.o
YASM-OBJS-$(CONFIG_TTA_DECODER)+= x86/ttadsp.o
+YASM-OBJS-$(CONFIG_V210_ENCODER) += x86/
On 30 November 2014 at 12:39, Aleksey Vasenev wrote:
> We keep only half source frames.
> Source: time_base 1/10 and ptss 0 1 2 3 4 5 6 7 8 9
> Before change: time_base 1/5 and ptss 0 1 2 3 4
> After change: time_base 1/10 and ptss 0 2 4 6 8
> You can see that before and after equal. No problem wi
On 1 December 2014 at 20:04, Michael Niedermayer wrote:
> Inspired by discussion with kierank
> Signed-off-by: Michael Niedermayer
Can you explain what this patch does and how it affects all the
different options in tinterlace?
Kieran
___
ffmpeg-devel
On 1 December 2014 at 20:26, Michael Niedermayer wrote:
> On Mon, Dec 01, 2014 at 08:17:18PM +0000, Kieran Kunhya wrote:
>> On 1 December 2014 at 20:04, Michael Niedermayer wrote:
>> > Inspired by discussion with kierank
>> > Signed-off-by: Michael Niedermayer
>
> This effectively limits interlacing to two framerates. What about pure
> 30i? What about some future (or past) framerate we didn't think of?
> Listing all possible framerate combinations is simply not
> maintainable.
Erm, let's not propagate more crazy interlaced framerates.
> If you reeall
Sent from my mobile device
On 1 Dec 2014 21:55, "Michael Niedermayer" wrote:
>
> On Mon, Dec 01, 2014 at 08:54:16PM +, Vittorio Giovara wrote:
> > On Mon, Dec 1, 2014 at 8:04 PM, Michael Niedermayer
wrote:
> > > Inspired by discussion with kierank
> > > Signed-off-by: Michael Niedermayer
> >
> Furthermore, I do not see any ASS styling in the decoder, that would be a
> good test case.
Captions shouldn't be ASS styled - they should be styled as per the
specification (see VLC).
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http:
On 22 December 2014 at 01:43, Dtison.net wrote:
> Hello
>
> Would there be any interest in additional work on parallelization of the
> library?
>
> It is mentioned the Changelog and in multithreading.txt.
What part of FFmpeg are you interested in Parallelising?
Kieran
___
Hi,
Does the CODEC_CAP_FRAME_THREADS API support frame threaded encoding?
Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I think this is right but would be useful to get it checked. Visually the
output looks ok
---
libavfilter/vf_scale.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 64b88c2..83a0666 100644
--- a/libavfi
Fixed wrong chroma line use
---
libavfilter/vf_scale.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 64b88c2..9189103 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -373,6 +373,13 @@ static
>
>> +
>> av_opt_set_int(*s, "src_h_chr_pos", scale->in_h_chr_pos, 0);
>> av_opt_set_int(*s, "src_v_chr_pos", scale->in_v_chr_pos, 0);
>> av_opt_set_int(*s, "dst_h_chr_pos", scale->out_h_chr_pos, 0);
>> @@ -520,8 +527,8 @@ static int filter_frame(AVFilterLink
Merry Christmas!
---
libavfilter/vf_scale.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 64b88c2..f77884c 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -373,6 +373,17 @@ static int config_props(AVFilte
---
libswscale/utils.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index ab494ed..601e7bf 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1960,6 +1960,8 @@ struct SwsContext *sws_getCachedContext(struct SwsContext
*contex
> no, there where some comments on IRC but IIRC they where along the
> lines of future improvments not objections/blocking
Has any work been done on whether this implementation matches the
reference vectors as I mentioned on IRC?
Kieran
___
ffmpeg-devel
On 14 January 2015 at 09:41, Anshul wrote:
> Hi
>
> I have enabled demuxing and muxing path for datat stream
How do you guarantee accuracy of the SCTE-35 stream without a timestamp?
Note that ffmpeg isn't able to understand timestamps here because it
should be using an interpolated PCR.
Kieran
_
On 17 January 2015 at 18:14, Nicolas George wrote:
> Le septidi 27 nivôse, an CCXXIII, Philip Langdale a écrit :
>> On Fri, 16 Jan 2015 22:17:56 +0100
>> Nicolas George wrote:
>> Ok. I did this test and it produces correct results - SAR 133:221 which
>> yields the correct final aspect ratio,
>
>
> FFmpeg is correct, there is absolutely no doubt about it: This "active"
> pixels nonsense is only relevant for certain very specific media, definitely
> not when encoding testsrc and decoding the result to showinfo. Demuxers or
> high-level tools may know when they are dealing with that kind of c
On 17 January 2015 at 20:01, Philip Langdale wrote:
> There is a long sad story behind all this, but it's somewhat ambiguous as to
> whether DVD content should be treated as 720 pixels wide or 704 pixels, with
> 16 pixels cut off. If you decide is should be 704 pixels wide, you need to
> adjust th
On 17 January 2015 at 20:42, Nicolas George wrote:
> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>> BT601 makes this very clear. The active picture is 702 pixels.
>
> There are two fundamental flaws with your reasoning:
>
> First, BT601 only applies to a some
On 17 January 2015 at 23:00, Nicolas George wrote:
> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>> I don't make the standards and frankly whether you dislike them is
>> your problem but they exist and need to work correctly.
>> Instead you wish to break
On 17 January 2015 at 23:38, Nicolas George wrote:
> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>> The behaviour of the Nvidia code I believe is correct.
>> As far as I understand it corrects SAR for 720-width content to comply
>> with BT601.
>
>
On 17 January 2015 at 23:46, Kieran Kunhya wrote:
> On 17 January 2015 at 23:38, Nicolas George wrote:
>> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>>> The behaviour of the Nvidia code I believe is correct.
>>> As far as I understand it corrects SAR
On 18 January 2015 at 09:40, Nicolas George wrote:
> Le nonidi 29 nivôse, an CCXXIII, Hendrik Leppkes a écrit :
>> nvenc should behave the same as libx264, or any other video encoder, if
>> this patch makes it do that, then it should be applied.
>>
>> If bt601 needs special handling not yet presen
On 18 January 2015 at 12:22, Michael Niedermayer wrote:
> On Sun, Jan 18, 2015 at 02:52:59AM +0100, Hendrik Leppkes wrote:
>> On Sun, Jan 18, 2015 at 1:02 AM, Nicolas George wrote:
>>
>> > L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>> > > Oo
On 18 January 2015 at 13:57, Michael Niedermayer wrote:
> I hope this should reduce the confusion about display aspect ratios in the
> overscan case
Stop trying to look for a mathematical relationship when there isn't one...
___
ffmpeg-devel mailing li
On 18 January 2015 at 13:55, Michael Niedermayer wrote:
> On Sun, Jan 18, 2015 at 01:28:36PM +0000, Kieran Kunhya wrote:
>> On 18 January 2015 at 12:22, Michael Niedermayer wrote:
>> > On Sun, Jan 18, 2015 at 02:52:59AM +0100, Hendrik Leppkes wrote:
>> >> On Sun, Ja
> iam not trying to look for anything, iam just trying to fix bugs
> and as is ffmpeg displays the wrong DAR in the printout for the
> overscan case (i belive this is a big part of the misuderstandings),
> you would get bt601 with some crazy nonsense DAR
> values instead of 16:9 and 4:3, this patch
> the active area is stored in mpeg1/2 and should be used, its in the
> pan scan variables IIRC, that way there is a very close to correct
> mathematical relation between SAR, DAR and the active area in the
> BT601 case
> There should be no problem here with complying to BT601 and the
> video codin
On 18 January 2015 at 19:44, Georg Lippitsch wrote:
> Examples:
>
> Capture video clip at 720p50 with 32bit audio:
> ffmpeg -bm_audiodepth 32 -f decklink -i 'UltraStudio Mini Recorder@14'
> -acodec copy -vcodec copy output.avi
>
> Capture video clip at 576i50 with 8 audio channels:
> ffmpeg -bm_c
> Taking the Sample/pixel aspect ratio (SAR) calculated above and feeding
> that back into calculating a display aspect ratio *for the whole frame*
> leads to a value that is not 16:9 (or 4:3), and it appears to be this
> figure which is then reported as the DAR, rather than that of the active
> pi
> +for(p=0; p<3; p++) {
> +int h = f->height;
> +int w = f->width;
> +if (p) {
> +w >>= h_chroma_shift;
> +h >>= v_chroma_shift;
> +}
> +
> yes, its overall 3 lines shorter as well
> ive locally changed it to this:
Thanks, much easier to understand.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> this context, that means that they make the following, questionable,
> assumptions:
erm
> 1) If the input dimensions are 720x480 or 720x576, assume the content has
> an active area of 704x480 or 704x576.
702x576
Kieran
___
ffmpeg-devel mailing list
On 29 January 2015 at 09:20, Paul B Mahol wrote:
> On 1/29/15, Michael Niedermayer wrote:
>> On Wed, Jan 28, 2015 at 03:13:27PM +, Paul B Mahol wrote:
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> Bit-exact with mp=softpulldown except first frame which is uninitialized
>>> data in mp filter.
>
On 29 January 2015 at 09:57, Kieran Kunhya wrote:
> On 29 January 2015 at 09:20, Paul B Mahol wrote:
>> On 1/29/15, Michael Niedermayer wrote:
>>> On Wed, Jan 28, 2015 at 03:13:27PM +, Paul B Mahol wrote:
>>>> Signed-off-by: Paul B Mahol
>>>> ---
On 4 June 2015 at 15:57, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/s302m.c | 34 ++
> 1 file changed, 34 insertions(+)
This should be made optional - there are legitimate reasons such as
decoding 302m to wav that this wo
> Thanks for this analysis. I've pushed the patch now.
>
> By the way, afl [1] is really a great tool for finding such problems.
> I can only recommend everyone to try it out yourself.
Not to push this off-topic but can you let me know how you use afl
with ffmpeg - I could never get it to work whe
> Suppose you're writing a video player with browsing capabilities for network
> protocols (like Kodi/XBMC). Now you can have file rename/delete
> functionality in it.
Suppose you are writing a video player and need to change the screen resolution.
Can we have that feature in libavutil too?
Kiera
From 6c0c94f8581d9e76301b03f9f416972fc0265fb6 Mon Sep 17 00:00:00 2001
From: Kieran Kunhya
Date: Sun, 21 Jun 2015 23:59:12 +0100
Subject: [PATCH] avcodec: Add support for per-frame AFD output in h264
---
libavcodec/h264.c | 11 +++
libavcodec/h264.h | 3 +++
libavcodec
From: Kieran Kunhya
---
libavcodec/h264.c | 10 ++
libavcodec/h264.h | 3 +++
libavcodec/h264_sei.c | 6 ++
3 files changed, 19 insertions(+)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 9be317c..1cbd4cb 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
---
libavcodec/h264.c | 10 ++
libavcodec/h264.h | 2 ++
libavcodec/h264_sei.c | 32 +++-
3 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 1cbd4cb..d971c7b 100644
--- a/libavcodec/h264.c
+++ b/li
Fix missing line
---
libavcodec/h264.c | 11 +++
libavcodec/h264.h | 2 ++
libavcodec/h264_sei.c | 32 +++-
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 1cbd4cb..1569ec8 100644
--- a/libavco
> So I have a more conceptual question, maybe Kieran can help answer this
> also. Why are these tests called api-$codec tests? I don't see anything
> flac/h264 specific in these tests so far, and they could basically be
> reused for any video (h264) or audio (flac) test (for audio: as long as
> the
---
libavcodec/h264.c | 11 +++
libavcodec/h264.h | 2 ++
libavcodec/h264_sei.c | 35 ++-
3 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 1cbd4cb..1569ec8 100644
--- a/libavcodec/h264.c
+++
How much equipment or server resources do you need.
I should be able to host this.
Kieran
On 3 July 2015 at 18:53, Michael Niedermayer wrote:
> Hi all
>
> It is POSSIBLE that we need to move to different servers/hosting.
> We have been informed that the free hosting and servers we use
> currentl
---
libavcodec/h264.c | 9 +
libavcodec/h264.h | 2 ++
libavcodec/h264_sei.c | 39 +--
3 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index baedcf4..f62ad6a 100644
--- a/libavcodec/h264.c
+
OVH has poor quality connectivity by the way - this could lead to
performance issues in some countries.
Why can't you use the server videolan offered?
Kieran
On 14 July 2015 at 21:32, Michael Niedermayer wrote:
> Hi all
>
> libnova (see CC:) has offered us a
> OVH (France) 64gb ram xeon server w
> I like kieranks' offer. although i dont know the service hours or
> timeframe of hosting.
So the machine sits in our datacentre next to my office, has a 100meg
connection. Plenty more spare machines here ffmpeg could use but
they're all a bit old.
Kieran
On 17 July 2015 at 22:00, Michael Niedermayer wrote:
> On Fri, Jul 17, 2015 at 04:16:53PM +0200, Michael Niedermayer wrote:
>> On Fri, Jul 17, 2015 at 03:30:26PM +0200, Jean-Baptiste Kempf wrote:
>> > On 15 Jul, Michael Niedermayer wrote :
>> > > longer awnser,
>> > > videolan IIUC would be willin
Hello,
Please note there will be a trac outage owing to the rerouting of fibre as
part of the London Underground extension.
Regards,
Kieran Kunhya
-- Forwarded message -
Hello,
There is going to be a loss of service at some point during the time frame
stated below whilst
On 9 Oct 2015 10:13 pm, "Paul B Mahol" wrote:
>
> diff --git a/libavcodec/x86/audiodsp.asm b/libavcodec/x86/audiodsp.asm
> index 3ffb27f..246e945 100644
> --- a/libavcodec/x86/audiodsp.asm
> +++ b/libavcodec/x86/audiodsp.asm
> @@ -41,7 +41,14 @@ cglobal scalarproduct_int16, 3,3,3, v1, v2, order
>
Please note this is tonight - Don't say you weren't told!
Kieran
On 9 October 2015 at 07:37, Kieran Kunhya wrote:
> Hello,
>
> Please note there will be a trac outage owing to the rerouting of fibre as
> part of the London Underground extension.
>
&
Yeah...sometimes it's best to just let the past lie there. I'd rather
see it gone completely to be honest .
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 23 October 2015 at 00:19, Lou Logan wrote:
> Signed-off-by: Lou Logan
> ---
>
> I'm tired of looking at it, being reminded of such things, and it has
> served its purpose long ago.
>
> ---
> src/legal | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/src/legal b/src/legal
>
From a1314d5c9774d555718bbc0a8612144c890bbc59 Mon Sep 17 00:00:00 2001
From: Kieran Kunhya
Date: Mon, 26 Oct 2015 22:26:35 +
Subject: [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays
Fixes crashes on fuzzed files
---
libavcodec/opusdec.c |2 +-
1 file chang
On 26 October 2015 at 22:48, Hendrik Leppkes wrote:
> On Mon, Oct 26, 2015 at 11:29 PM, Kieran Kunhya wrote:
>> From a1314d5c9774d555718bbc0a8612144c890bbc59 Mon Sep 17 00:00:00 2001
>> From: Kieran Kunhya
>> Date: Mon, 26 Oct 2015 22:26:35 +
>> Subject:
> Please review carefully, thanks!
Both patches look ok.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 8 November 2015 at 00:30, Timothy Gu wrote:
> Allows one to do:
>
> ffmpeg -s 1920x1080 -i blah.v210 ...
> ffmpeg -s 1920x1080 -f v210x -i blah.yuv10 ...
>
> Fixes #1869.
Looks good - I wonder if it can be merged with rawvideo though.
Kieran
__
On 11 Nov 2015 7:08 p.m., "Pavel Meshkov" wrote:
>
> Trying to reattach patch
>
> 11.11.2015 22:01, Pavel Meshkov пишет:
>>
>> We added UDP output constant bitrate functionality.
>> Please review patch.
>>
>> P.S.: It's first patch we send. Please notify me if something made wrong.
This an awful
On 11 November 2015 at 22:41, Kieran Kunhya wrote:
>
> On 11 Nov 2015 7:08 p.m., "Pavel Meshkov" wrote:
>>
>> Trying to reattach patch
>>
>> 11.11.2015 22:01, Pavel Meshkov пишет:
>>>
>>> We added UDP output constant bitrate functionalit
> i suggest you read the mpeg specs, they detail when things should be
> sent down to each byte IIRC
> also IIRC its not that complicated, more like timestamp + bytepos/rate
Only for strict CBR streams which FFmpeg cannot know a priori. That's
why the only correct way is to index the stream as it'
On 18 November 2015 at 19:28, Zach Swena wrote:
> Are you referring to this seperate applciation?
>
> https://github.com/mmalecki/multicat/blob/master/trunk/README
>
> While using that makes sense for Pavel's application, why should FFmpeg
> produce a problematic UDP stream in the first place? Fo
> Of course if the user copies a video stream that isn't complaint there will
> be problems if the decoder requires that. The issue here is two fold.
> First, the current udp transmission model can cause problems with
> networking equipment because of it's bursty nature. Second, FFmpeg can
> make
> Why is there a udp stream output option then? Are you trying to say that
> this isn't a bug because FFmpeg isn't supposed to be able to stream? I am
> using FFmpeg mpeg2video as the encoder and multiplexing with mpegts. The
> data FFmpeg produces is fine, it just doesn't send it quite right.
On 19 November 2015 at 12:00, Pavel Meshkov wrote:
> FYI, our awful hack looks like almost working except sometimes effective
> bitrate lost for 1-2 seconds, then spike and then returns to normal (it can
> be once after 15 minutes or after more than 4 hours before this issue).
>
> Also there is a
On 19 November 2015 at 16:15, Zach Swena wrote:
>> How have you confirmed MPEG-TS compliance?
>
> While not completely definitive, I looked at it with a transport stream
> analyser and tested it at our TV station. At the TV station stream the
> file from our server through a remultiplexer that as
Start templating functions for move to support 10-bit
Parts of this patch were written by Rostislav Pehlivanov
---
libavcodec/dirac.c | 10 +-
libavcodec/dirac.h | 3 +-
libavcodec/diracdec.c | 229 ++--
libavformat/oggparsedirac.c
401 - 500 of 998 matches
Mail list logo
