V2 : - Change the last_idr_frame filed location based on Mark code review.
- Modify the commit message to actually explain the problem.
From a1bf2b021effd36f8297b331855a282d775f2a44 Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Fri, 11 Nov 2016 14:53:49 +0800
Subject: [PATCH v2] lavc/vaapi_en
2016-11-04 23:02 GMT+08:00 Michael Niedermayer :
> On Fri, Nov 04, 2016 at 07:54:48PM +0800, Steven Liu wrote:
> > when parsing keyframe index metadata, list the message by trace log
> >
> > Signed-off-by: Steven Liu
> > ---
> > libavformat/flvdec.c |2 ++
> > 1 files changed, 2 insertions(+
On Mon, Nov 14, 2016 at 01:59:06AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patches are a requirement to fix two tickets.
>
> Please review, Carl Eugen
patches LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed
Yes, this change is intended.
Previously, the mov_read_uuid always read the uuid-xmp byte by byte even if,
c->export_xmp == false, it’s no need to export xmp data by default.
It’s OK for a small size uuid-xmp atom. But for a large size of that atom,
which is, for example, exported by non-linear
On Tue, Sep 06, 2016 at 07:11:17AM +0300, Dmitry Kalinkin wrote:
> __MAC_10_11 can be present in updated revision of an older SDK so it
> can't reliably detect availability of kAudioFormatEnhancedAC3 constant.
>
> Fixes: b4daa2c40f ('lavc/audiotoolboxdec: add eac3 decoder')
> Cc: Rodger Combs
> S
Hi!
Attached patches are a requirement to fix two tickets.
Please review, Carl Eugen
From 64541da83bf85110a8cab5805a8425e632f560ee Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 14 Nov 2016 01:43:40 +0100
Subject: [PATCH 1/2] lavu/pixfmt: Add GRAY10
Based on 7471352f by Luca Barbato
On 2016/11/11 16:29, Hendrik Leppkes wrote:
> On Fri, Nov 11, 2016 at 9:09 AM, Jun Zhao wrote:
>>
>
> Do you have a sample file for this case? AFAIK all vc1 files I ever
> saw worked with the DXVA2 hwaccel before, just want to make sure they
> are not getting broken.
>
> - Hendrik
We used the f
On 2016/11/11 20:34, Timo Rothenpieler wrote:
> This patch seems incomplete.
> Did you forget to add the vaapi_vp8.c file before commiting?
>
Yes, I forget to add the vaapi_vp8.c. And because Mark will merge the vaapi_vp8
hwaccel and other vaapi infrastructure from Libav, so I will don't update
On 2016/11/12 21:57, Mark Thompson wrote:
> On 11/11/16 07:57, Jun Zhao wrote:
>> From 4635e7e4a0ea24f77e71ffc9a9074e75c61bfe44 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao
>> Date: Fri, 11 Nov 2016 15:51:01 +0800
>> Subject: [PATCH] lavc/vaapi: Add VP8 decode hwaccel
>>
>> Add VP8 decode hwaccel
On Fri, Nov 11, 2016 at 01:27:12AM +0100, Simon Thelen wrote:
> Signed-off-by: Simon Thelen
> ---
> doc/ffmpeg.texi | 34 ++
> 1 file changed, 34 insertions(+)
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During
On 2016/11/12 22:00, Mark Thompson wrote:
> On 11/11/16 02:24, Jun Zhao wrote:
>> From 5db0b2cd0930ed88d853114f13b69a80a44d9c4c Mon Sep 17 00:00:00 2001
>> From: Jun Zhao
>> Date: Fri, 11 Nov 2016 10:04:53 +0800
>> Subject: [PATCH] lavc/vaapi_encode_h265: fix the hevc vaapi encoder output
>> sh
On 11/13/2016 7:54 PM, Nicolas George wrote:
> Le tridi 23 brumaire, an CCXXV, James Almer a écrit :
>> AVSomethingInternal *internal;
>
>> No technical advantages i can think of compared to your method, but it's
>> thoroughly tested, clean, and above all ubiquitous. See for example
>> AVFilte
On Mon, Nov 14, 2016 at 12:21 AM, Carl Eugen Hoyos wrote:
> 2016-11-14 0:11 GMT+01:00 Hendrik Leppkes :
That has proven to be problematic before, between merges
adding fields at the wrong offset by accident,
>>>
>>> IIRC, you are mistaken, we only had that kind of issue about
>>> public
2016-11-11 14:56 GMT+01:00 Kieran O Leary :
> Hi Carl,
>
>
> On Fri, Nov 11, 2016 at 1:31 PM, Michael Niedermayer > wrote:
>
>> On Thu, Nov 10, 2016 at 11:08:23PM +0100, Carl Eugen Hoyos wrote:
>> > Hi!
>> >
>> > Not sure how useful this is but we also support gprp12.
>> >
>> > Please comment, Carl
2016-11-11 14:31 GMT+01:00 Michael Niedermayer :
> On Thu, Nov 10, 2016 at 11:08:23PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Not sure how useful this is but we also support gprp12.
>>
>> Please comment, Carl Eugen
>
>> dpx.c | 12
>> 1 file changed, 8 insertions(+), 4 deletions
On Sun, Nov 13, 2016 at 08:55:01PM +0100, Andreas Cadhalpun wrote:
> This is similar to commit 9ac61e73d0843ec4b83f4e3d47eded73234e406e.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavutil/softfloat.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM
thx
[...]
--
Michael Gn
2016-11-14 0:11 GMT+01:00 Hendrik Leppkes :
>>> That has proven to be problematic before, between merges
>>> adding fields at the wrong offset by accident,
>>
>> IIRC, you are mistaken, we only had that kind of issue about
>> public fields.
>
> No, this happened in 3.1 with "private" fields in publ
Le quartidi 24 brumaire, an CCXXV, Hendrik Leppkes a écrit :
> I disagree with that, this is generic utility code, not a tight
> algorithm loop, where absolute efficiency is not necessarily required,
> and disregarding code simplicity amd consistency will just harm in the
> long-run.
We can discus
On Sun, Nov 13, 2016 at 11:54 PM, Nicolas George wrote:
>> As i said, what I'm mostly looking for is consistency across the codebase
>> and to reduce ifdeffery.
>
> For consistency, I would prefer removing the indirections where they
> already are and replace them with invisible fields.
>
> And I
2016-11-11 12:15 GMT+01:00 wm4 :
> On Fri, 11 Nov 2016 10:19:08 +0100
> Carl Eugen Hoyos wrote:
>
>> 2016-11-11 9:03 GMT+01:00 Hendrik Leppkes :
>> > On Fri, Nov 11, 2016 at 6:34 AM, Yogender Gupta wrote:
>> >> The included patch should fix.
>> >>
>> >
>> > ffmpeg.c is in the middle of some chan
Le tridi 23 brumaire, an CCXXV, James Almer a écrit :
> AVSomethingInternal *internal;
> No technical advantages i can think of compared to your method, but it's
> thoroughly tested, clean, and above all ubiquitous. See for example
> AVFilterInternal and AVCodecInternal.
It has technical DISa
On 11/13/2016 6:57 PM, Nicolas George wrote:
> Le tridi 23 brumaire, an CCXXV, James Almer a écrit :
>> I don't really like this method. This kind of ifdeffery is very
>> uncommon and feels dirty. Just look at avutil/common.h to see how bad
>> a public header can get this way.
>> I'd prefer if we c
Signed-off-by: Andreas Cadhalpun
---
libavcodec/libschroedingerdec.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/libavcodec/libschroedingerdec.c b/libavcodec/libschroedingerdec.c
index 1e392b3..83c790c 100644
--- a/libavcodec/libschroedingerdec.
They are not valid and can cause problems/crashes for API users.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/libschroedingerdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libschroedingerdec.c b/libavcodec/libschroedingerdec.c
index c9930c7..1e392b3 10064
Le tridi 23 brumaire, an CCXXV, James Almer a écrit :
> I don't really like this method. This kind of ifdeffery is very
> uncommon and feels dirty. Just look at avutil/common.h to see how bad
> a public header can get this way.
> I'd prefer if we can stick with the usual internal opaque structs
> i
On 11/13/2016 7:10 AM, Nicolas George wrote:
> A lot of changes happen at the same time:
>
> - Add private_fields.h to devine private fields in AVFilterLink.
> It allows to have the private fields directly in structured types
> without needing an indirection for an opaque structure nor the
>
On 9/19/2016 6:17 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 2 ++
> libavcodec/allcodecs.c | 2 ++
> libavcodec/avcodec.h| 2 ++
> libavcodec/codec_desc.c | 14 ++
> libavcodec/pcm.c| 34 ++
>
It causes division by zero crashes.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/aacsbr_fixed.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/aacsbr_fixed.c b/libavcodec/aacsbr_fixed.c
index b26314a..d2a7027 100644
--- a/libavcodec/aacsbr_fixed.c
+++ b/libavcodec/aacsbr_f
On Mon, Sep 19, 2016 at 11:17:20PM +0200, Paul B Mahol wrote:
> Fixes #5602 and #5603.
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/wavdec.c | 13 +
> 1 file changed, 13 insertions(+)
LGTM
please add a fate test if possible
thx
[...]
--
Michael GnuPG fingerprint: 9FF2
On Mon, Sep 19, 2016 at 11:17:19PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 2 ++
> libavcodec/allcodecs.c | 2 ++
> libavcodec/avcodec.h| 2 ++
> libavcodec/codec_desc.c | 14 ++
> libavcodec/pcm.c| 34
This is similar to commit 9ac61e73d0843ec4b83f4e3d47eded73234e406e.
Signed-off-by: Andreas Cadhalpun
---
libavutil/softfloat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/softfloat.h b/libavutil/softfloat.h
index a3b2238..48d0d59 100644
--- a/libavutil/softfloat
avc->channels can be 0.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/libopusdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
index acc62f1..505ed57 100644
--- a/libavcodec/libopusdec.c
+++ b/libavcodec/libopusdec.c
@@
On 13.11.2016 18:48, Paul B Mahol wrote:
> On 11/13/16, Andreas Cadhalpun wrote:
>> This prevents a division by zero in read_packet.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/filmstripdec.c | 7 +++
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>
> lgtm
Pushed.
On 11/13/16, Andreas Cadhalpun wrote:
> This prevents a division by zero in read_packet.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/filmstripdec.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
lgtm
___
ffmpeg-devel mai
This prevents a division by zero in read_packet.
Signed-off-by: Andreas Cadhalpun
---
libavformat/filmstripdec.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavformat/filmstripdec.c b/libavformat/filmstripdec.c
index 414e276..0aeb594 100644
--- a/libavformat/film
On Sun, Nov 13, 2016 at 10:18:18AM +0100, Michael Niedermayer wrote:
> On Sat, Nov 12, 2016 at 10:05:22PM -0500, Vittorio Giovara wrote:
> [...]
> > So I really do not see a use case for using int64 here.
>
> then you can use int32, less than int32 is too little if for example
> you wnat the preci
On Sun, Nov 13, 2016 at 4:46 PM, Yogender Gupta wrote:
>> I created a simpler patch that avoids modifying the external signature
>> of the function, and it still fixes it for me. Can you test and
>> confirm? Then we can apply this.
>
>
>> Just tested this patch, and I can confirm that at least a c
> I created a simpler patch that avoids modifying the external signature
> of the function, and it still fixes it for me. Can you test and
> confirm? Then we can apply this.
> Just tested this patch, and I can confirm that at least a cuvid hwaccel
> transcode works again.
I also verified the
> I created a simpler patch that avoids modifying the external signature
> of the function, and it still fixes it for me. Can you test and
> confirm? Then we can apply this.
Just tested this patch, and I can confirm that at least a cuvid hwaccel
transcode works again.
On 13.11.2016 03:22, Ronald S. Bultje wrote:
> Hi Andreas,
>
> On Nov 12, 2016 5:52 PM, "Andreas Cadhalpun"
> mailto:andreas.cadhal...@googlemail.com>>
> wrote:
>>
>> The handling of the other block sizes was disabled for 'SCALED == 0' in
>> commit dc96c0f9fc96bf4167633befc074394062793322, so th
On Fri, Nov 11, 2016 at 12:47 PM, Yogender Gupta wrote:
>>>These are merges. Unless you volunteer to do the merges yourself (and
>>>properly please) you'll have to live with this.
>
> So were there merges that got left and broke the functionality. When do we
> get these merges in ? Please let me
On Fri, Oct 21, 2016 at 6:32 PM, Derek Buitenhuis
wrote:
> The design one fist: This approach is fundamentally wrong. Edit lists are
> meant to be applied at presentation level, not packet level. The current
> implementation will cause problems in a number of cases:
>
> * Audio packets. Especi
On 11/12/16, Sasi Inguva wrote:
> The above file has an edit list with duration zero .
>
> *
> Even quick time player doesn't play the video.
>
> Enabling the old code to populate skip_samples by looking at first edit
> list duration, when -ignore_editlist is true is a good fallback. I'll send
>
On Sun, Nov 13, 2016 at 1:31 AM, Timo Rothenpieler
wrote:
> Seems like I never tested on any 32bit platform.
>
Applied, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sun, Nov 13, 2016 at 9:48 AM, Carlos Fernandez Sanz
wrote:
> One of the reasons apparently for not merging the SCTE-35 patch;
> better never include that in ffmpeg and have the professional use and
> pay for other products even though an implementation that doesn't
> break anything at that has
Le duodi 22 brumaire, an CCXXV, Ing. Radomír Polách a écrit :
> I am not sure either, but I think it is better this way, because you can
> easily use it to pass result from a search script:
> ./ffmpeg -i $(./findmypaint.sh) ...
> Search script is a simple script which finds for you screen, focus wi
On Thu, Jun 02, 2016 at 04:28:13PM +0200, Vlad Tarca wrote:
> Pro-MPEG Code of Practice #3 release 2 forward error correction for
> rtp_mpegts streams
>
> Signed-off-by: Vlad Tarca
> ---
> Changelog | 1 +
> doc/general.texi| 1 +
> doc/protocols.texi | 35
>
A lot of changes happen at the same time:
- Add private_fields.h to devine private fields in AVFilterLink.
It allows to have the private fields directly in structured types
without needing an indirection for an opaque structure nor the
structure definition in public headers.
- Add a framequ
Signed-off-by: Nicolas George
---
libavfilter/Makefile | 1 +
libavfilter/framequeue.c | 123 +
libavfilter/framequeue.h | 173 +++
3 files changed, 297 insertions(+)
create mode 100644 libavfilter/framequeue.c
cr
On Sat, Nov 12, 2016 at 2:02 AM, Hendrik Leppkes wrote:
> Fixes building with --disable-everything --enable-shared --enable-dxva2
>
> The hwcontext DXVA2 implementation in avutil needs this library now, instead
> of just the ffmpeg program.
> ---
> configure | 3 ++-
> 1 file changed, 2 insertion
On Sat, Nov 12, 2016 at 10:05:22PM -0500, Vittorio Giovara wrote:
[...]
> So I really do not see a use case for using int64 here.
then you can use int32, less than int32 is too little if for example
you wnat the precission to be sufficient to know where a tele lens
points with pixel precission and
On 9/19/16, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 2 ++
> libavcodec/allcodecs.c | 2 ++
> libavcodec/avcodec.h| 2 ++
> libavcodec/codec_desc.c | 14 ++
> libavcodec/pcm.c| 34 ++
> libavco
52 matches
Mail list logo
