From: Kaustubh Raste
Remove loops and unroll as block sizes are known.
Signed-off-by: Kaustubh Raste
---
libavcodec/mips/h264qpel_msa.c | 400
1 file changed, 240 insertions(+), 160 deletions(-)
diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec
The doc for image2 muxer makes mention of only the 'update' option but
the muxer contains a 'updatefirst' option as well that effects the same
behaviour. Obviously, the latter isn't a shorthand for the former.
Should 'updatefirst' be removed, or documented?
Regards,
Gyan
__
From: Kaustubh Raste
Replace generic with block size specific function.
Load the specific destination bytes instead of MSA load and pack.
Signed-off-by: Kaustubh Raste
---
libavcodec/mips/h264chroma_msa.c | 627 +-
1 file changed, 275 insertions(+), 352 del
From: Kaustubh Raste
Use immediate unsigned saturation for clip to max saving one vector register.
Signed-off-by: Kaustubh Raste
---
libavcodec/mips/hevc_mc_biw_msa.c | 706 ++-
libavutil/mips/generic_macros_msa.h | 35 ++
2 files changed, 489 insertions(+)
> 在 2017年10月24日，下午2:00，Dixit, Vishwanath 写道：
>
>> On 10/22/17, 1:28 PM, "Liu Steven" wrote:
>> Two patches should be ok, add FATE cases please :)
> I am not familiar with FATE and I could not find any sample hlsenc FATE cases
> in ffmpeg workspace. Could you please help me with this? If some b
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Liu Steven
> Sent: Tuesday, October 24, 2017 3:28 PM
> To: and patches development discussions FFmpeg
>
> Cc: Liu Steven
> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls
The Bayer matrix 8x8 used in DITHER_COPY macro is table dithers[5].
Remaining dithers[] matrixes are generated from this matrix by
downshift or upshift.
This patch fixes dithers[6] and dithers[7] matrixes -- they were
too dark.
Signed-off-by: Mateusz Brzostek
---
libswscale/swscale_unscaled.c |
This patch uses dithering in DITHER_COPY macro only if
it was not used option '-sws_dither none'.
With option '-sws_dither none' it uses downshift.
For human eye dithering is OK, for video codecs not necessarily.
If user don't want to use dithering, we should respect that.
Signed-off-by: Mateusz
Fix tsan warnings.
Signed-off-by: Muhammad Faiz
---
libavutil/crc.c | 49 +
1 file changed, 29 insertions(+), 20 deletions(-)
diff --git a/libavutil/crc.c b/libavutil/crc.c
index 495732b163..d44550c9c0 100644
--- a/libavutil/crc.c
+++ b/libavutil/
On Tue, Oct 24, 2017 at 8:36 AM, James Almer wrote:
> On 10/23/2017 10:24 PM, Michael Niedermayer wrote:
>> On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote:
>>> On 24/10/17 00:52, Michael Niedermayer wrote:
Hi
On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wro
According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field
should contain the absolute position to the maximum audio sample value,
but the current implementation writes the relative peak frame index
instead.
Fix the issue by writing the "unknown" value (-1) for now until the
feature is imp
>The patch contains trailing whitespace and tabs, both cannot be committed to
>the FFmpeg repository.
>You can use tools/patcheck to find the issues.
Cleaned up the spaces/tabs and added braces around else statemens.
> +mxf_write_local_tag(pb, 4, 0x3308);
> +if (st->codec->pix_fmt == AV
24.10.2017 13:35, developm...@axeltechnology.com пише:
The patch contains trailing whitespace and tabs, both cannot be committed to
the FFmpeg repository.
You can use tools/patcheck to find the issues.
Cleaned up the spaces/tabs and added braces around else statemens.
similar patchset was pr
On Mon, Oct 23, 2017 at 10:36:21PM -0300, James Almer wrote:
> On 10/23/2017 10:24 PM, Michael Niedermayer wrote:
> > On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote:
> >> On 24/10/17 00:52, Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark
Hi all,
I did some work around parsing HEVC headers, and while looking at ffmpeg's
implementation, I noticed
a few bugs and a few style issues. I'm not submitting a patch, since my
familiarity with the decoder is
very limited, but hopefully the maintainers will go over the list below and
change
LGTM
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
kaustubh.ra...@imgtec.com
Sent: Tuesday, October 24, 2017 12:42 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi weighted hv mc
LGTM
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
kaustubh.ra...@imgtec.com
Sent: Tuesday, October 24, 2017 12:41 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc chroma copy and avg
LGTM
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
kaustubh.ra...@imgtec.com
Sent: Tuesday, October 24, 2017 12:39 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc put mc 11, 31, 13 an
Le decadi 30 vendémiaire, an CCXXVI, Thilo Borgmann a écrit :
> Black/white shirts were preferred by the people wearing them during
> CLT for the past few years.
> We had a bright-green/white before that. Dark-green/white might also
> look good. The question of colors is of course all open. However
Le primidi 1er brumaire, an CCXXVI, Ronald S. Bultje a écrit :
> But this is the whole problem. We're stuck in a stalemate between nothing
> and nobody. As with ffserver, we'll keep postponing this forever more until
> the stalemate is broken.
>
> What incentive is there for anyone to write a repl
> 2017-10-21 18:29 GMT+02:00 Nicolas George :
> > Yes, exactly. This limitation was the reason I did not bother handling
> > longer lines. I would like to understand how it makes a difference.
The answer is: the filename field in AVFormatContext is not used to open
the file, only the argument to a
- On Apr 5, 2017, at 6:11 PM, Rostislav Pehlivanov
wrote:
> On 31 March 2017 at 16:36, Damien Riegel > wrote:
> > This adds partial support for the RFC 4175 (raw video over RTP). The
> > only supported formats are the YCbCr-4:2:2 8 bit because it's natively
> > supported by FFmpeg with pi
Hello,
Simply to tell you that I no longer support my/this thread, especially
because as Tobias said it is for an “aesthetic reason”.
wm4 has mentioned “EBML elements”, there is no such element in the
specifications (if I am not wrong):
https://www.matroska.org/technical/specs/tagging/index
Support for transparencies in animated gifs requires modifying both
libavcodec/gif.c and libavformat/gif.c because both the graphics
control extension (handled by libavformat/gif.c) and the raw frame data
(handled by libavcodec/gif.c) must be changed. This is because
transparencies in GIF can be us
On Mon, Oct 23, 2017 at 7:17 PM, Bjorn Roche wrote:
> On Sat, Oct 21, 2017 at 4:00 PM, Clément Bœsch wrote:
>
>> On Sat, Oct 21, 2017 at 09:47:47PM +0200, Carl Eugen Hoyos wrote:
>> > 2017-10-21 21:43 GMT+02:00 Clément Bœsch :
>> > > On Sat, Oct 21, 2017 at 09:37:06PM +0200, Carl Eugen Hoyos wro
Hi,
On Sun, Sep 4, 2016 at 2:34 PM, Thomas Volkert wrote:
> Hi,
>
> Some guys at the VDD asked for FFmpeg T-shirts.
> I'd like to do a new T-shirt order. The shirts could be given to
> multimedia devs who stop at one of our next booths.
>
> My idea is to order 25 shirts:
>
> 1*S
> 5*M
> 10*L
> 7
Le duodi 2 brumaire, an CCXXVI, James Almer a écrit :
> https://trac.ffmpeg.org/ticket/6767
I do not see in this ticket anything that allows to reproduce the issue
without a huge amount of foreign code.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
On Tue, Oct 24, 2017 at 8:57 PM, Nicolas George wrote:
> Le duodi 2 brumaire, an CCXXVI, James Almer a écrit :
>> https://trac.ffmpeg.org/ticket/6767
>
> I do not see in this ticket anything that allows to reproduce the issue
> without a huge amount of foreign code.
>
> Regards,
Hi,
The base ide
On 10/24/2017 11:04 AM, Kyle Swanson wrote:
Hi,
On Sun, Sep 4, 2016 at 2:34 PM, Thomas Volkert wrote:
Hi,
Some guys at the VDD asked for FFmpeg T-shirts.
I'd like to do a new T-shirt order. The shirts could be given to
multimedia devs who stop at one of our next booths.
My idea is to order
On Tue, Oct 24, 2017 at 9:18 PM, Jan Ekstrom wrote:
> This is a public API change, and I'm not sure if we were planning on
> this. I am not against the fact that zero is no longer implictly EOF,
> but this might have been worth a bit more notice as this does indeed
> break quite a few API clients
Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit :
> The base idea was grasped rather quickly though, which seems to be
> that all API clients utilizing their own IO seem to now require an
> update to their code to return AVERROR_EOF if EOF was hit instead of
> being able to return the number of
On Tue, Oct 24, 2017 at 10:17 PM, Nicolas George wrote:
> Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit :
> I do not consider this a public API change because 0 was never
> documented as a valid return value for a read_packet callback, while
> AVERROR_EOF has been around for a long time.
>
On 10/24/2017 4:37 PM, Jan Ekstrom wrote:
> On Tue, Oct 24, 2017 at 10:17 PM, Nicolas George wrote:
>> Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit :
>> I do not consider this a public API change because 0 was never
>> documented as a valid return value for a read_packet callback, while
>>
Le tridi 3 brumaire, an CCXXVI, Jan Ekstrom a écrit :
> You might be very true, but funny enough I just checked the AVIO
> example doc/examples/avio_reading.c, and the read function there does
> not seem to utilize AVERROR_EOF either :) .
The examples are not exempt from mistakes.
> Just for your
On Tue, Oct 24, 2017 at 10:43 PM, James Almer wrote:
> Maybe first ask what the workaround Nicolas mentioned is about?
This was not meant to push anything on anyone. Just wanted to let him
know what had been come up with elsewhere.
> And preferably don't quote me on this subject. This is not my
On Tue, Oct 24, 2017 at 02:04:28AM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Trying to encode 256-colour subtitles to dvbsub currently fails in the
> "region" section, a hunk of Joolz' patch was not committed six years
> ago.
> Attached patch has two hunks: The forgotten hunk from the original
> pa
2017-10-24 12:35 GMT+02:00 :
> >From 2a657145a9b6bc2c1beb450100fe2d4d80ee Mon Sep 17 00:00:00 2001
> From: "Axel Technology"
> Date: Mon, 23 Oct 2017 18:02:58 +0200
> Subject: [PATCH] Sony XDCAM Fix
>
> Signed-off-by: Axel Technology
> ---
> libavformat/mxfenc.c | 112
> +++
Technically _tzcnt* intrinsics are only available when the BMI
instruction set is present. However the instruction encoding
degrades to "rep bsf" on older processors.
Clang for Windows debatably restricts the _tzcnt* instrinics behind
the __BMI__ architecture define, so check for its presence or
e
2017-10-24 18:40 GMT+02:00 Bjorn Roche :
> This patch assumes paletteuse has already been patched to support
> transparency. (e.g. lavfi/paletteuse: fix to support transparency)
Which should - imo - be unrelated to this patch and indeed, transcoding
a pal8 apng (produced with your paletteuse patc
2017-10-24 18:40 GMT+02:00 Bjorn Roche :
[...]
The patch adds two warnings here on compilation of gif.c,
they should be fixed at some point:
libavcodec/gif.c:164:5: warning: ISO C90 forbids mixed declarations
and code [-Wdeclaration-after-statement]
uint8_t *frame_disposal = av_packet_new_s
2017-10-24 22:11 GMT+02:00 Michael Niedermayer :
> On Tue, Oct 24, 2017 at 02:04:28AM +0200, Carl Eugen Hoyos wrote:
>> Subject: [PATCH] lavc/dvbsub: Allow 256 colour encoding.
>>
>> Fixes ticket #6769.
>
> probably ok
Patch applied.
Thank you, Carl Eugen
Hi!
Attached patch allows sending pcm_s24be over rtp, defined in rfc 3190.
Please comment, Carl Eugen
From 488a5065dac2ab04d03694b9086fd329421840cc Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 24 Oct 2017 23:03:02 +0200
Subject: [PATCH] lavf/rtpenc: Add support for 24 bit pcm encod
On Tue, Mar 28, 2017 at 12:35:29AM +, Felicia Lim wrote:
> Hi all,
>
> Here is another patch to decode Opus ambisonics files using channel mapping
> 2 [1], this time in libopusdec.c.
>
> Please let me know if there are any concerns.
>
> Thanks,
> Felicia
>
> [1]
> *https://trac.tools.ietf.
Le 14/09/2017 à 6:48 PM, pkv.stream a écrit :
Thanks for your comments Moritz.
Corrected patch in attachment.
Regards
Le 14/09/2017 à 5:46 PM, Moritz Barsnick a écrit :
On Fri, Sep 08, 2017 at 01:46:38 +0200, pkv.stream wrote:
- avpriv_request_sample(fc, "Opus in MPEG-TS - channel_config_code >
On Tue, Oct 24, 2017 at 4:24 PM, Carl Eugen Hoyos
wrote:
> 2017-10-24 18:40 GMT+02:00 Bjorn Roche :
>
> > This patch assumes paletteuse has already been patched to support
> > transparency. (e.g. lavfi/paletteuse: fix to support transparency)
>
> Which should - imo - be unrelated to this patch an
On Mon, Oct 23, 2017 at 04:18:28PM -0700, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva
> ---
> libavformat/mov.c | 15 +++-
> tests/fate/mov.mak | 4 ++
> tests/ref/fate/mov-invalid-elst-entry-count | 57
> +
>
On Mon, Oct 23, 2017 at 03:18:12PM +0800, Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> tests/fate/video.mak| 3 +++
> tests/ref/fate/mpeg2-ticket6677 | 12
> 2 files changed, 15 insertions(+)
> create mode 100644 tests/ref/fate/mpeg2-ticket6677
will apply
thanks
>
> 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
_
2017-10-23 14:40 GMT+02:00 James Almer :
> On 10/23/2017 5:09 AM, Carl Eugen Hoyos wrote:
>> 2017-10-23 5:22 GMT+02:00 James Almer :
>>> On 10/21/2017 9:31 PM, Carl Eugen Hoyos wrote:
Hi!
Attached patch silences the many warnings shown when decoding streams
with DolbyVision cont
On 24/10/17 07:02, Jun Zhao wrote:
> From 24b8e1c70fd4bf4eb76404fd9e2020fe3bbd90cb Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Tue, 24 Oct 2017 13:25:21 +0800
> Subject: [PATCH V2] lavc/vaapi_encode_h264: correct VUI
> max_dec_frame_buffering setting.
>
> vseq.max_num_ref_frames not init b
On 24/10/17 23:14, Carl Eugen Hoyos wrote:
> 2017-10-25 0:09 GMT+02:00 Mark Thompson :
>> ffmpeg | branch: master | Mark Thompson | Tue Oct 24
>> 22:56:48 2017 +0100| [5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22] | committer:
>> Mark Thompson
>>
>> cbs_mpeg2: Fix type for marker_bit reading
>>
>>>
From a6a79bda55868f7faee0f183a45191d3251fb5f1 Mon Sep 17 00:00:00 2001
From: Fredrik Hubinette
Date: Tue, 7 Feb 2017 12:19:38 -0800
Subject: [PATCH] Fix minor ffmpeg memory leak in id3v2 parsing.
Reviewed-on: https://chromium-review.googlesource.com/439405
Reviewed-by: Dale Curtis
---
libavform
2017-10-25 0:29 GMT+02:00 Mark Thompson :
> On 24/10/17 23:14, Carl Eugen Hoyos wrote:
>> 2017-10-25 0:09 GMT+02:00 Mark Thompson :
>>> ffmpeg | branch: master | Mark Thompson | Tue Oct 24
>>> 22:56:48 2017 +0100| [5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22] |
>>> committer: Mark Thompson
>>>
>>>
On 10/24/2017 7:33 PM, Fredrik Hubinette wrote:
> From a6a79bda55868f7faee0f183a45191d3251fb5f1 Mon Sep 17 00:00:00 2001
> From: Fredrik Hubinette
> Date: Tue, 7 Feb 2017 12:19:38 -0800
> Subject: [PATCH] Fix minor ffmpeg memory leak in id3v2 parsing.
>
> Reviewed-on: https://chromium-review.goog
On 24/10/17 23:34, Carl Eugen Hoyos wrote:
> 2017-10-25 0:29 GMT+02:00 Mark Thompson :
>> On 24/10/17 23:14, Carl Eugen Hoyos wrote:
>>> 2017-10-25 0:09 GMT+02:00 Mark Thompson :
ffmpeg | branch: master | Mark Thompson | Tue Oct 24
22:56:48 2017 +0100| [5b2c71bb94d7cab23ee81b5c29388f5fa
On Tue, Oct 24, 2017 at 19:38:58 -0300, James Almer wrote:
> > Subject: [PATCH] Fix minor ffmpeg memory leak in id3v2 parsing.
> >
> > Reviewed-on: https://chromium-review.googlesource.com/439405
> > Reviewed-by: Dale Curtis
[...]
> This doesn't seem to apply to git head, or even the recently cut
With pre-2.0 Intel drivers in CBR mode, if an explicit SEI message with
the old (now deprecated) type is not included, the driver generates and
inserts some timing SEI which is almost certainly invlaid. Before
7a4fac5e91789b73e07bd4ad20493cfde028df76 we always inserted our own SEI
so this would no
On 25/10/17 00:32, Mark Thompson wrote:
> With pre-2.0 Intel drivers in CBR mode, if an explicit SEI message with
> the old (now deprecated) type is not included, the driver generates and
> inserts some timing SEI which is almost certainly invlaid. Before
> 7a4fac5e91789b73e07bd4ad20493cfde028df76
On Tue, Oct 24, 2017 at 04:15:01PM +0200, Nicolas George wrote:
> Le primidi 1er brumaire, an CCXXVI, Ronald S. Bultje a écrit :
> > But this is the whole problem. We're stuck in a stalemate between nothing
> > and nobody. As with ffserver, we'll keep postponing this forever more until
> > the stal
On Tue, Oct 24, 2017 at 12:40:22PM -0400, Bjorn Roche wrote:
> Support for transparencies in animated gifs requires modifying both
> libavcodec/gif.c and libavformat/gif.c because both the graphics
> control extension (handled by libavformat/gif.c) and the raw frame data
> (handled by libavcodec/gi
On Thu, Sep 14, 2017 at 06:48:33PM +0200, pkv.stream wrote:
> Thanks for your comments Moritz.
> Corrected patch in attachment.
> Regards
>
> Le 14/09/2017 à 5:46 PM, Moritz Barsnick a écrit :
> >On Fri, Sep 08, 2017 at 01:46:38 +0200, pkv.stream wrote:
> >>-avpriv_request_samp
Michael,
what do you think of this patch?
I tried to reflect what the xvid decoder does for those N_VOP frame and in
case it is not packed.
On Tue, Oct 24, 2017 at 6:42 PM, Thierry Foucu wrote:
> Changed the return value when no VOD were encoded in Mpeg4 bistream.
> And if we do have already
Changed the return value when no VOD were encoded in Mpeg4 bistream.
And if we do have already a decoded frames and we are not in xvid_packed
mode, output the existing decoded frame instead of nothing.
---
libavcodec/h263dec.c | 9 -
libavcodec/mpeg4videodec.c | 2 +-
libavcodec/mpeg
Michael,
the following patch seems to work. I restricted the change to N_VOP (from xvid)
frame.
I tried to match it with what the xvidcore decoder does for such packets.
What do you think?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://
On 10/24/2017 6:50 PM, Michael Niedermayer wrote:
> On Mon, Oct 23, 2017 at 03:18:12PM +0800, Zhong Li wrote:
>> Signed-off-by: Zhong Li
>> ---
>> tests/fate/video.mak| 3 +++
>> tests/ref/fate/mpeg2-ticket6677 | 12
>> 2 files changed, 15 insertions(+)
>> create mode 1
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Wednesday, October 25, 2017 10:09 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] fate: add a test for mpeg2 issue of
> ticket #6677
>
> On 10/24/201
One of the users had recently complained about encoding problems with HEVC
encoding with WP (Weighted Prediction). This is a driver issue that has been
identified, and shows up when using HEVC + WP + (PictureTimingSEI messages and
or buffering period SEI messages).
Recently the PictureTiming SE
Signed-off-by: Zhong Li
---
tests/fate/video.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index 51678078a3..c7f2dcea9e 100644
--- a/tests/fate/video.mak
+++ b/tests/fate/video.mak
@@ -258,7 +258,7 @@ FATE_VIDEO-$(call DEMDEC,
68 matches
Mail list logo
