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,
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
> -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
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
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://
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,
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
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
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 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 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
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 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
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 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
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
>>>
>>>
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
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
>>
>>>
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
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
>
> 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
_
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
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 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
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, 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.
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
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
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 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
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 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
> +++
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
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
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 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
>>
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.
>
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 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
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 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
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
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
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
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
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
- 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
> 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
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
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
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
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
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
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
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
>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
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
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
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/
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
> -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
> 在 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
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(+)
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
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
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
68 matches
Mail list logo
