This allows the use of muxers like matroska, which attempt to seek even
when an AVIOContext doesn't set `seekable`, without concern for a rouge
seek leading the muxer to overwrite the wrong data in a later segment.
---
doc/muxers.texi | 17
libavformat/segment.c | 276
Signed-off-by: Nablet Developer
---
libavcodec/qsvenc_h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index c1f6003..f5b01bb 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@
On Tue, Oct 4, 2016 at 12:11 PM, Josh de Kock wrote:
> Putting SCTE35 support in another library like Upipe was suggested as well.
This is something that I don't understand. Should FFmpeg just ignore
the existance of this very important standard in the professional
video
On 01/10/2016 18:27, Carlos Fernandez Sanz wrote:
- Addresses new comments such as like idx value checking and filename checking
Carlos Fernandez (4):
Adding SCTE-35 CUI codec
SCTE-35 extraction from mpegts
SCTE-35 support in hlsenc
Correct Indentation
libavcodec/avcodec.h| 2 +
This fixes downconverting framerates to multiples.
For example, prior to this patch, converting 900 frames at 60 fps
to 30 fps would output 451 frames instead of the correct 450.
Signed-off-by: Derek Buitenhuis
---
DISCLAIMER: I don't know libavfilter very well, and
On 03/10/2016 00:05, Michael Niedermayer wrote:
On Sun, Oct 02, 2016 at 11:16:49PM +0100, Josh de Kock wrote:
On 02/10/2016 22:47, Michael Niedermayer wrote:
On Sun, Oct 02, 2016 at 01:51:41AM +0100, Josh de Kock wrote:
Explicitly state that FATE should pass, and code should work
for all
On 03/10/2016 15:40, Josh de Kock wrote:
On 02/10/2016 19:46, Adriano Pallavicino wrote:
LGTM. Will apply both patches squashed in a day if there are no further
comments.
Applied.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Mon, 3 Oct 2016, Carlos Fernandez Sanz wrote:
From: Carlos Fernandez
Signed-off-by: Carlos Fernandez
---
libavcodec/avcodec.h| 2 ++
libavcodec/codec_desc.c | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavcodec/avcodec.h
On Mon, 3 Oct 2016, Carlos Fernandez Sanz wrote:
On Sat, Oct 1, 2016 at 10:50 AM, Marton Balint wrote:
Empty line.
Thanks, corrected in V13.
If all OK, can this patchset be merged?
I guess patch 1 and 2 are OK now. However, I am not sure the third
(hls) patch got a
On Tue, Oct 04, 2016 at 06:33:48PM +0200, wm4 wrote:
> Some API users (in particular ffmpeg.c) check the best effort timestamp
> only.
> ---
> Using guess_correct_pts() - not sure what I was thinking.
> ---
> libavcodec/utils.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
LGTM
On Tue, Oct 04, 2016 at 10:13:41PM +0100, Derek Buitenhuis wrote:
> On 10/4/2016 9:58 PM, Michael Niedermayer wrote:
> > breaks fate
> > and the change to fate looks wrong, the last frame is lost
> > make fate-filter-fps
> > TESTfilter-fps
> > --- ./tests/ref/fate/filter-fps 2016-10-04
On 10/4/2016 10:21 PM, Michael Niedermayer wrote:
>> This "break" may actually be more correct output, but I am not familiar
>> enough
>> with lavfi or vf_fps to say. Removing the last frame in case where it should
>> have
>> been removed was the entire point of this patch.
>
> the change to
On Tue, Oct 04, 2016 at 04:21:29PM -0400, Derek Buitenhuis wrote:
> This fixes downconverting framerates to multiples.
>
> For example, prior to this patch, converting 900 frames at 60 fps
> to 30 fps would output 451 frames instead of the correct 450.
>
> Signed-off-by: Derek Buitenhuis
Fixes regression as of ee72b6d1
Signed-off-by: Josh de Kock
---
The irony of this patch is terrible, but oh well. Maybe we're missing a
'everyone makes mistakes' policy.
doc/developer.texi | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git
On 10/4/2016 9:58 PM, Michael Niedermayer wrote:
> breaks fate
> and the change to fate looks wrong, the last frame is lost
> make fate-filter-fps
> TESTfilter-fps
> --- ./tests/ref/fate/filter-fps 2016-10-04 14:46:19.642736770 +0200
> +++ tests/data/fate/filter-fps 2016-10-04
On Tue, Oct 04, 2016 at 11:10:00PM +0100, Josh de Kock wrote:
> Fixes regression as of ee72b6d1
>
> Signed-off-by: Josh de Kock
> ---
> The irony of this patch is terrible, but oh well. Maybe we're missing a
> 'everyone makes mistakes' policy.
>
> doc/developer.texi | 18
On Tue, Oct 4, 2016 at 8:41 AM, Hendrik Leppkes wrote:
> On Tue, Oct 4, 2016 at 4:05 AM, Michael Niedermayer
> wrote:
>> On Sat, Oct 01, 2016 at 04:15:45PM +0200, Hendrik Leppkes wrote:
>>> Decoders have previously not used AVFrame.pts, and with the
Please don't top post on the mailing list.
On Tue, Oct 4, 2016 at 8:20 AM, Min wrote:
> Hi, I'm using ffmpeg dxva2 implementation (ffmpeg_dxva2.c) to render mp4
> video to a DX texture.
>
> The crash happens when closing my application, when I call to
> av_frame_free() to the
On Tue, Oct 04, 2016 at 12:22:38AM +0530, Umair Khan wrote:
> Hi,
>
> Patch attached.
>
> It fixes the fate tests.
> However, there's a slight bug in the encoder in handling the last frame.
> I'll definitely fix it later.
> I hope the patch can be merged in this state.
[...]
> +/**
> + *
On Tue, Oct 04, 2016 at 08:41:42AM +0200, Hendrik Leppkes wrote:
> On Tue, Oct 4, 2016 at 4:05 AM, Michael Niedermayer
> wrote:
> > On Sat, Oct 01, 2016 at 04:15:45PM +0200, Hendrik Leppkes wrote:
> >> Decoders have previously not used AVFrame.pts, and with the upcoming
>
On Tue, Oct 04, 2016 at 01:52:02PM +0200, Hendrik Leppkes wrote:
> On Tue, Oct 4, 2016 at 1:44 PM, Hendrik Leppkes wrote:
> > On Tue, Oct 4, 2016 at 1:23 PM, Michael Niedermayer
> > wrote:
> >> On Tue, Oct 04, 2016 at 08:41:42AM +0200, Hendrik Leppkes
On Tue, Oct 04, 2016 at 10:30:24AM +0200, Hendrik Leppkes wrote:
> On Tue, Oct 4, 2016 at 8:41 AM, Hendrik Leppkes wrote:
> > On Tue, Oct 4, 2016 at 4:05 AM, Michael Niedermayer
> > wrote:
> >> On Sat, Oct 01, 2016 at 04:15:45PM +0200, Hendrik Leppkes
On Tue, Oct 4, 2016 at 1:55 PM, Michael Niedermayer
wrote:
> On Tue, Oct 04, 2016 at 10:30:24AM +0200, Hendrik Leppkes wrote:
>> On Tue, Oct 4, 2016 at 8:41 AM, Hendrik Leppkes wrote:
>> > On Tue, Oct 4, 2016 at 4:05 AM, Michael Niedermayer
>> >
On Tue, Oct 4, 2016 at 1:23 PM, Michael Niedermayer
wrote:
> On Tue, Oct 04, 2016 at 08:41:42AM +0200, Hendrik Leppkes wrote:
>> On Tue, Oct 4, 2016 at 4:05 AM, Michael Niedermayer
>> wrote:
>> > On Sat, Oct 01, 2016 at 04:15:45PM +0200, Hendrik
Hi!
Sorry if I miss something but with this patch, the hardening_check
script succeeds here both for x86_32 and x86_64 (static and shared).
Please comment, Carl Eugen
From 3c5df95a022e9148f753dd2a850570080740c602 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 4
On Tue, Oct 4, 2016 at 1:44 PM, Hendrik Leppkes wrote:
> On Tue, Oct 4, 2016 at 1:23 PM, Michael Niedermayer
> wrote:
>> On Tue, Oct 04, 2016 at 08:41:42AM +0200, Hendrik Leppkes wrote:
>>> On Tue, Oct 4, 2016 at 4:05 AM, Michael Niedermayer
>>>
On Mon, 3 Oct 2016 17:45:08 -0700
Jon Toohill wrote:
> Muxers can check AVCodecParameters.initial_padding for the
> encoder+decoder delay, and read the AV_PKT_DATA_SKIP_SAMPLES
> side data from the last packet for the encoder padding.
>
> This change also
On Tue, 4 Oct 2016 14:15:03 +0200
Michael Niedermayer wrote:
> On Tue, Oct 04, 2016 at 01:52:02PM +0200, Hendrik Leppkes wrote:
> > On Tue, Oct 4, 2016 at 1:44 PM, Hendrik Leppkes
> > wrote:
> > > On Tue, Oct 4, 2016 at 1:23 PM, Michael
On Tue, 4 Oct 2016 16:35:02 +0200
Hendrik Leppkes wrote:
> On Tue, Oct 4, 2016 at 4:32 PM, wm4 wrote:
> > On Tue, 4 Oct 2016 14:15:03 +0200
> > Michael Niedermayer wrote:
> >
> >> On Tue, Oct 04, 2016 at 01:52:02PM +0200,
The slice index expected by D3D11VA is the one from the texture not from the
array or texture/slices.
In VLC the slices we provide the decoder don't start from 0 and thus pictures
appear in bogus order. With possible crashes and corruptions when using an
invalid index.
---
libavcodec/dxva2.c | 9
On Tue, Oct 4, 2016 at 4:32 PM, wm4 wrote:
> On Tue, 4 Oct 2016 14:15:03 +0200
> Michael Niedermayer wrote:
>
>> On Tue, Oct 04, 2016 at 01:52:02PM +0200, Hendrik Leppkes wrote:
>> > On Tue, Oct 4, 2016 at 1:44 PM, Hendrik Leppkes
On 10/3/2016 1:21 PM, James Almer wrote:
> On 10/3/2016 12:27 PM, Dave Rice wrote:
>> Hi,
>>
>>> On Oct 2, 2016, at 7:14 PM, James Almer wrote:
>>>
>>> On 9/27/2016 3:03 PM, James Almer wrote:
It's listed as supported in both
On Mon, Oct 03, 2016 at 08:36:57PM -0300, James Almer wrote:
> The durations are never written in that situation.
>
> Signed-off-by: James Almer
> ---
> libavformat/matroskaenc.c| 2 +-
> tests/fate/matroska.mak | 2 +-
> tests/fate/wavpack.mak | 4 ++--
>
On 10/4/2016 9:00 PM, Michael Niedermayer wrote:
> On Mon, Oct 03, 2016 at 08:36:57PM -0300, James Almer wrote:
>> The durations are never written in that situation.
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/matroskaenc.c| 2 +-
>> tests/fate/matroska.mak
On 10/4/2016 11:47 AM, Steve Lhomme wrote:
> The slice index expected by D3D11VA is the one from the texture not from the
> array or texture/slices.
>
> In VLC the slices we provide the decoder don't start from 0 and thus pictures
> appear in bogus order. With possible crashes and corruptions
On 10/4/2016 11:35 AM, Hendrik Leppkes wrote:
> On Tue, Oct 4, 2016 at 4:32 PM, wm4 wrote:
>> On Tue, 4 Oct 2016 14:15:03 +0200
>> Michael Niedermayer wrote:
>>
>>> On Tue, Oct 04, 2016 at 01:52:02PM +0200, Hendrik Leppkes wrote:
On Tue, Oct 4,
3 parts:
- Supports multiple chapter streams
- Exports regular text chapter streams as opaque data. This prevents consumers
from showing chapters as if they were regular subtitle streams.
- Exports video chapter streams as thumbnails, and provides the first one as
an attached_pic.
---
Reviewed-By: Michael Niedermayer
---
libavformat/mov.c | 156 +++---
1 file changed, 78 insertions(+), 78 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d0f1316..c9fef8a 100644
--- a/libavformat/mov.c
On 10/4/2016 7:20 PM, Michael Niedermayer wrote:
> On Tue, Oct 04, 2016 at 11:10:00PM +0100, Josh de Kock wrote:
>> Fixes regression as of ee72b6d1
>>
>> Signed-off-by: Josh de Kock
>> ---
>> The irony of this patch is terrible, but oh well. Maybe we're missing a
>> 'everyone
Reviewed-By: Michael Niedermayer
---
ffprobe.c | 1 +
libavformat/avformat.h | 12 +---
tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
On Tue, Oct 04, 2016 at 09:23:37PM -0300, James Almer wrote:
> On 10/4/2016 9:00 PM, Michael Niedermayer wrote:
> > On Mon, Oct 03, 2016 at 08:36:57PM -0300, James Almer wrote:
> >> The durations are never written in that situation.
> >>
> >> Signed-off-by: James Almer
> >> ---
On Tue, Oct 04, 2016 at 12:24:00PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Sorry if I miss something but with this patch, the hardening_check
> script succeeds here both for x86_32 and x86_64 (static and shared).
>
> Please comment, Carl Eugen
only case i found that breaks is with
On Mon, Oct 03, 2016 at 05:45:08PM -0700, Jon Toohill wrote:
> Muxers can check AVCodecParameters.initial_padding for the
> encoder+decoder delay, and read the AV_PKT_DATA_SKIP_SAMPLES
> side data from the last packet for the encoder padding.
>
> This change also fixes the first_discard_sample
On Sun, Oct 02, 2016 at 06:56:48PM +0200, wm4 wrote:
> Some API users (in particular ffmpeg.c) check the best effort timestamp
> only.
> ---
> Still undecided if this is the right approach.
> ---
> libavcodec/utils.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
On 10/4/2016 12:52 PM, Hendrik Leppkes wrote:
> On Tue, Oct 4, 2016 at 2:45 AM, Jon Toohill
> wrote:
>> Muxers can check AVCodecParameters.initial_padding for the
>> encoder+decoder delay, and read the AV_PKT_DATA_SKIP_SAMPLES
>> side data from the last packet
Some API users (in particular ffmpeg.c) check the best effort timestamp
only.
---
Using guess_correct_pts() - not sure what I was thinking.
---
libavcodec/utils.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index
On Tue, Oct 4, 2016 at 4:05 AM, Michael Niedermayer
wrote:
> On Sat, Oct 01, 2016 at 04:15:45PM +0200, Hendrik Leppkes wrote:
>> Decoders have previously not used AVFrame.pts, and with the upcoming
>> deprecation of pkt_pts (in favor of pts), this would lead to an
On Mon, Oct 03, 2016 at 11:49:39PM -0500, Rodger Combs wrote:
> ---
> ffprobe.c | 13 +
> tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
> tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
>
Hi, I'm using ffmpeg dxva2 implementation (ffmpeg_dxva2.c) to render mp4
video to a DX texture.
The crash happens when closing my application, when I call to
av_frame_free() to the last frame I've created to decompress video. The
hwcontext references go to 0 and internal structs start to free its
49 matches
Mail list logo