[FFmpeg-devel] [PATCHv3 2/3] ffplay: convert to new decode API

Signed-off-by: Marton Balint --- ffplay.c | 101 ++- 1 file changed, 54 insertions(+), 47 deletions(-) diff --git a/ffplay.c b/ffplay.c index cf138dc..3d48daa 100644 --- a/ffplay.c +++ b/ffplay.c @@ -187,7 +187,6 @@

[FFmpeg-devel] [PATCHv2] avfilter/vf_framerate: always request input if no output is provided in request_frame

Fixes ticket #6285. Signed-off-by: Marton Balint --- libavfilter/vf_framerate.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c index b4a74f7..0093f78 100644 --- a/libavfilter/vf_framerate.c +++

Re: [FFmpeg-devel] [PATCH 2/2] Add experimental support for Opus in ISO BMFF (MP4)

At 2017-04-05T20:43:21-0300, James Almer wrote: > > +/* OpusSpecificBox size plus magic for Ogg OpusHead header. */ > > +size = atom.size + 16; > > This should be 8. "OpusHead" is not 16 bytes. > > > +avio_read(pb, st->codecpar->extradata + 9, size - 17); > > Same, this should be

[FFmpeg-devel] [PATCH] Observe Set-Cookie headers in HLS streams

Signed-off-by: Micah Galizia --- libavformat/hls.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/libavformat/hls.c b/libavformat/hls.c index bac53a4..ab81863 100644 --- a/libavformat/hls.c +++ b/libavformat/hls.c @@ -630,8 +630,14 @@

[FFmpeg-devel] [PATCH] Observe Set-Cookie headers in HLS streams

Hello, I noticed some Set-Cookie headers are being ignored by the HLS demuxer. Patch attached fixes it. Previously, the cookies wouldn't get updated from the right AVIOContext, or not at all if AVFMT_FLAG_CUSTOM_IO is set -- I'm not really sure why that was done so please let me know if I

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264: Check weight values to be within the specs limits.

Hi, On Thu, Apr 6, 2017 at 8:10 PM, Michael Niedermayer wrote: > On Wed, Mar 22, 2017 at 07:09:23PM +0100, Michael Niedermayer wrote: > > On Wed, Mar 22, 2017 at 09:06:09AM -0400, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Tue, Mar 21, 2017 at 9:59 PM, Michael

[FFmpeg-devel] [PATCH] avcodec/wavpack: Fix invalid shift and integer overflow

Fixes: 940/clusterfuzz-testcase-5200378381467648 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/wavpack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [FFmpeg-devel] [PATCH] avcodec/mjpegdec: Fixes runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'

On Wed, Mar 29, 2017 at 11:47:31AM +0200, wm4 wrote: > On Mon, 27 Mar 2017 00:41:05 +0200 > Michael Niedermayer wrote: > > > On Sun, Mar 26, 2017 at 05:30:05PM -0400, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Sun, Mar 26, 2017 at 3:31 PM, Michael Niedermayer > >

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264: Check weight values to be within the specs limits.

On Wed, Mar 22, 2017 at 07:09:23PM +0100, Michael Niedermayer wrote: > On Wed, Mar 22, 2017 at 09:06:09AM -0400, Ronald S. Bultje wrote: > > Hi, > > > > On Tue, Mar 21, 2017 at 9:59 PM, Michael Niedermayer > > wrote: > > > > > @@ -59,6 +59,9 @@ int

[FFmpeg-devel] [PATCH] avformat/utils: fix estimate_timings_from_pts duration calculation for mpegts files which contain a PMT update

From: Aman Gupta For example: https://s3.amazonaws.com/tmm1/pmt-version-change.ts Before: Duration: 00:00:10.01, start: 1236.288878, bitrate: 16752 kb/s After: Duration: 00:00:19.59, start: 1236.288878, bitrate: 8563 kb/s --- libavformat/utils.c | 21

Re: [FFmpeg-devel] Fix leaked dictionary in mp3dec

The patch didn't show up as properly formatted on https://patchwork.ffmpeg.org/patch/3228/. Re-submitting using no line wrap in the base64 attachment, and copying the contents of the patch for ease of review: >From fced5ab0e09f529397adddcb560d1a08f2df4840 Mon Sep 17 00:00:00 2001 From: Thomas

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: rename a variable.

On Thu, Apr 06, 2017 at 08:56:19PM +0200, Nicolas George wrote: > Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : > > If i fix it i would break your patchset if i apply it before and ill > > forget to do it later ... > > Do not worry about that, I will rebase and fix the conflicts

Re: [FFmpeg-devel] [PATCH] pthread_frame: don't return stale error codes after flush

On Thu, 2017-04-06 at 18:18 +0200, wm4 wrote: > > >  p->got_frame = 0; > > >  av_frame_unref(p->frame); > > > +p->result = 0; Shouldn't p->result be similarly reset together with p->got_frame also in ff_thread_decode_frame()? A similar problem seems possible: - a normal

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: rename a variable.

Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : > If i fix it i would break your patchset if i apply it before and ill > forget to do it later ... Do not worry about that, I will rebase and fix the conflicts if necessary. On the other hand, I would very much like to avoid wasting

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: rename a variable.

On Thu, Apr 06, 2017 at 07:35:04PM +0200, Nicolas George wrote: > Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : > > A comment explaining this (if you agree that the issue is real and not > > some mistake of understanding something on my side) > > would be a good idea. > > could

Re: [FFmpeg-devel] [PATCH] pthread_frame: make accesses to debug field be protected by owner lock.

On Thu, 6 Apr 2017 at 18:48 Ronald S. Bultje wrote: > The av_log() is done outside the lock, but this way the accesses to the > field (reads and writes) are always protected by a mutex. The av_log() > is not run inside the lock context because it may involve user callbacks >

[FFmpeg-devel] [PATCH] pthread_frame: make accesses to debug field be protected by owner lock.

The av_log() is done outside the lock, but this way the accesses to the field (reads and writes) are always protected by a mutex. The av_log() is not run inside the lock context because it may involve user callbacks and doing that in performance-sensitive code is probably not a good idea. This

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: rename a variable.

Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : > A comment explaining this (if you agree that the issue is real and not > some mistake of understanding something on my side) > would be a good idea. > could be confusing otherwise and lead to misunderstandings I am sorry, I have no

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: rename a variable.

On Thu, Apr 06, 2017 at 07:03:25PM +0200, Nicolas George wrote: > Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : > > Its a while ago i worked with this and the code changed since then > > so maybe iam wrong but > > > > pkt->duration is the duration of the frame encoded in that

Re: [FFmpeg-devel] [PATCH 4/4] ffmpeg: send EOF pts to filters.

On Thu, Apr 06, 2017 at 10:44:51AM +0200, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > ffmpeg.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > > With this change, filters have a timestamp when EOF is reached, available in >

Re: [FFmpeg-devel] [PATCH] flvdec: option for dropping negative CTS frames Initial frames with negative pts can produce video/audio desynchronization when a decoder is not prepared to handle negative

On Thu, 6 Apr 2017 14:18:20 -0300 Felipe Astroza wrote: > 2017-04-06 2:00 GMT-03:00 wm4 : > > > On Wed, 5 Apr 2017 17:15:26 -0300 > > Felipe Astroza wrote: > > > > > 2017-04-05 15:35 GMT-03:00 wm4 : > > > >

Re: [FFmpeg-devel] [PATCH] flvdec: option for dropping negative CTS frames Initial frames with negative pts can produce video/audio desynchronization when a decoder is not prepared to handle negative

2017-04-06 2:00 GMT-03:00 wm4 : > On Wed, 5 Apr 2017 17:15:26 -0300 > Felipe Astroza wrote: > > > 2017-04-05 15:35 GMT-03:00 wm4 : > > > > > On Wed, 5 Apr 2017 14:29:30 -0300 > > > fel...@astroza.cl wrote: > > > > > > > From:

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: rename a variable.

Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : > Its a while ago i worked with this and the code changed since then > so maybe iam wrong but > > pkt->duration is the duration of the frame encoded in that packet > that is not neccesarily the time between its dts and the next dts >

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: rename a variable.

On Thu, Apr 06, 2017 at 06:15:56PM +0200, Nicolas George wrote: > Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : > > what is duration_dts ? > > It is the duration that is needed to update the DTS variables. The next > patch, as you can see, introduces duration_pts for the same

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/h264: add avx 8-bit h264_idct_dc_add

On 4/6/2017 1:01 PM, James Darnley wrote: > On 2017-04-05 06:05, James Almer wrote: >> On 4/4/2017 10:53 PM, James Darnley wrote: >>> Haswell: >>> - 1.02x faster (405±0.7 vs. 397±0.8 decicycles) compared with mmxext >>> >>> Skylake-U: >>> - 1.06x faster (498±1.8 vs. 470±1.3 decicycles) compared

Re: [FFmpeg-devel] [PATCH] pthread_frame: don't return stale error codes after flush

On Thu, 6 Apr 2017 11:38:55 -0400 "Ronald S. Bultje" wrote: > Hi, > > On Thu, Apr 6, 2017 at 11:36 AM, wm4 wrote: > > > Consider the following sequence of events: > > > > - open a codec without AV_CODEC_CAP_DELAY > > - decode call fails with an error

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: rename a variable.

Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : > what is duration_dts ? It is the duration that is needed to update the DTS variables. The next patch, as you can see, introduces duration_pts for the same task for the PTS variables. The current code incorrectly used the same

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: rename a variable.

On Thu, Apr 06, 2017 at 10:44:48AM +0200, Nicolas George wrote: > Makes the reason of the "FIXME" comment more obvious. > Avoid name conflicts for the next commit. > > Signed-off-by: Nicolas George > --- > ffmpeg.c | 12 ++-- > 1 file changed, 6 insertions(+), 6

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/h264: add avx 8-bit h264_idct_add

On 4/6/2017 12:34 PM, James Darnley wrote: > On 2017-04-05 05:44, James Almer wrote: >> On 4/4/2017 10:53 PM, James Darnley wrote: >>> Haswell: >>> - 1.11x faster (522±0.4 vs. 469±1.8 decicycles) compared with mmxext >>> >>> Skylake-U: >>> - 1.21x faster (671±5.5 vs. 555±1.4 decicycles) compared

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/h264: add avx 8-bit h264_idct_dc_add

On 2017-04-05 06:05, James Almer wrote: > On 4/4/2017 10:53 PM, James Darnley wrote: >> Haswell: >> - 1.02x faster (405±0.7 vs. 397±0.8 decicycles) compared with mmxext >> >> Skylake-U: >> - 1.06x faster (498±1.8 vs. 470±1.3 decicycles) compared with mmxext >> --- >>

Re: [FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect

On Thu, Apr 06, 2017 at 02:09:46PM +0100, Matthias Troffaes wrote: > Many thanks for your feedback, Michael and Nicolas. > > On Wed, Apr 5, 2017 at 7:02 PM, Michael Niedermayer > wrote: > > fails on qemu mips > > Thank you for flagging this failure. I'm currently trying

[FFmpeg-devel] [PATCH] h264: don't re-call ff_h264_direct_ref_list_init() w/ frame-mt.

I'm hoping that this will address the remaining tsan fate-h264 issues: WARNING: ThreadSanitizer: data race (pid=24478) Read of size 8 at 0x7dbc0001c828 by main thread (mutexes: write M3243): #0 ff_h264_ref_picture src/libavcodec/h264_picture.c:107 (ffmpeg+0x013b78d8) [..] Previous

Re: [FFmpeg-devel] [PATCH 3/3] avformat/dump : Display Content Light Level metadata

Thanks ! On Thu, Apr 6, 2017 at 4:45 PM, James Almer wrote: > On 4/2/2017 5:08 AM, Steve Lhomme wrote: >> -- >> update the previous patch: >> - use MaxCLL/MaxFALL which are not rational numbers anymore >> --- >> libavformat/dump.c | 11 +++ >> 1 file changed, 11

Re: [FFmpeg-devel] [PATCH] pthread_frame: don't return stale error codes after flush

Hi, On Thu, Apr 6, 2017 at 11:36 AM, wm4 wrote: > Consider the following sequence of events: > > - open a codec without AV_CODEC_CAP_DELAY > - decode call fails with an error > - ff_thread_flush() is called > - drain packet is sent > > Then the last step would make

[FFmpeg-devel] [PATCH] pthread_frame: don't return stale error codes after flush

Consider the following sequence of events: - open a codec without AV_CODEC_CAP_DELAY - decode call fails with an error - ff_thread_flush() is called - drain packet is sent Then the last step would make ff_thread_decode_frame() return an error, because p->result can still be set to an error

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/h264: add avx 8-bit h264_idct_add

On 2017-04-05 05:44, James Almer wrote: > On 4/4/2017 10:53 PM, James Darnley wrote: >> Haswell: >> - 1.11x faster (522±0.4 vs. 469±1.8 decicycles) compared with mmxext >> >> Skylake-U: >> - 1.21x faster (671±5.5 vs. 555±1.4 decicycles) compared with mmxext > > Again, you should add an SSE2

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/h264: change some labels to be macro-local

Hi, On Thu, Apr 6, 2017 at 10:22 AM, James Darnley wrote: > On 2017-04-05 13:41, Ronald S. Bultje wrote: > > Hi, > > > > On Tue, Apr 4, 2017 at 9:53 PM, James Darnley wrote: > > > >> The labels get stripped leading to (slightly) nicer disassembly from > >>

[FFmpeg-devel] [PATCH v2] avformat/hlsenc: add hls encrypt options

refer to: https://git.libav.org/?p=libav.git;a=commitdiff;h=0a4b9d0ccd10b3c39105f99bd320f696f69a75a2 add hls encrypt options looks like libav's libavformat/hlsenc.c Signed-off-by: Steven Liu --- doc/muxers.texi | 16 +++ libavformat/hlsenc.c | 122

Re: [FFmpeg-devel] [PATCH 3/3] avformat/dump : Display Content Light Level metadata

On 4/2/2017 5:08 AM, Steve Lhomme wrote: > -- > update the previous patch: > - use MaxCLL/MaxFALL which are not rational numbers anymore > --- > libavformat/dump.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/libavformat/dump.c b/libavformat/dump.c > index

Re: [FFmpeg-devel] [PATCH 2/3] lavc: Add Content Light Level side metadata found in HEVC

On 4/3/2017 4:29 AM, Steve Lhomme wrote: > These data are necessary when transmitting HDR over HDMI. > > -- > update the previous patch: > - rename CEA 861.3 to CTA-861.3 > - update with MaxCLL/MaxFALL changes in avutil > update the previous patch: > - rebased and updated version bump > --- >

Re: [FFmpeg-devel] [libav-devel] ff_thread_get_format and metadata

On Thu, Apr 6, 2017 at 1:08 PM, Hendrik Leppkes wrote: > On Thu, Apr 6, 2017 at 11:35 AM, Steve Lhomme wrote: >> On Thu, Apr 6, 2017 at 11:08 AM, Hendrik Leppkes wrote: >>> On Thu, Apr 6, 2017 at 11:01 AM, Steve Lhomme

Re: [FFmpeg-devel] [PATCH 1/3] lavu: add support for Content Light Level side metadata

On 4/3/2017 4:29 AM, Steve Lhomme wrote: > As found in HEVC. > > I put the code in mastering_display_metadata as they usually go together in > Blu-Ray UHD sources. > > -- > update the previous patch: > - rename CEA 861.3 to CTA-861.3 > - use MaxCLL and MaxFALL names that are more commonly found

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add hls encrypt options

2017-04-06 22:07 GMT+08:00 Moritz Barsnick : > On Thu, Apr 06, 2017 at 15:47:58 +0200, Moritz Barsnick wrote: > > On Wed, Apr 05, 2017 at 22:04:01 +0800, Steven Liu wrote: > > > +{"hls_enc", "AES128 encryption support", > OFFSET(encrypt), AV_OPT_TYPE_INT,{.i64 =

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add hls encrypt options

2017-04-06 22:07 GMT+08:00 Moritz Barsnick : > On Thu, Apr 06, 2017 at 15:47:58 +0200, Moritz Barsnick wrote: > > On Wed, Apr 05, 2017 at 22:04:01 +0800, Steven Liu wrote: > > > +{"hls_enc", "AES128 encryption support", > OFFSET(encrypt), AV_OPT_TYPE_INT,{.i64 =

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/h264: change some labels to be macro-local

On 2017-04-05 13:41, Ronald S. Bultje wrote: > Hi, > > On Tue, Apr 4, 2017 at 9:53 PM, James Darnley wrote: > >> The labels get stripped leading to (slightly) nicer disassembly from >> objdump. >> > [..] > >> -jz .cycle%1end >> +jz %%skip > > > Can you preserve the

Re: [FFmpeg-devel] [PATCH] Build fix for MIPS

Hi, On Wed, Apr 5, 2017 at 4:53 PM, Ronald S. Bultje wrote: > Hi, > > On Wed, Apr 5, 2017 at 8:38 AM, Shivraj Patil > wrote: > >> Hi, >> >> >> >> Updated the patch as per comments. >> >> As hevcpred_init_mips.c needs definition of HAVE_MSA and

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add hls encrypt options

On Thu, Apr 06, 2017 at 15:47:58 +0200, Moritz Barsnick wrote: > On Wed, Apr 05, 2017 at 22:04:01 +0800, Steven Liu wrote: > > +{"hls_enc", "AES128 encryption support", > > OFFSET(encrypt), AV_OPT_TYPE_INT,{.i64 = 0}, 0, 1, E}, Furthermore, this looks like a

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add hls encrypt options

On Wed, Apr 05, 2017 at 22:04:01 +0800, Steven Liu wrote: > +{"hls_enc", "AES128 encryption support", > OFFSET(encrypt), AV_OPT_TYPE_INT,{.i64 = 0}, 0, 1, E}, > +{"hls_enc_key", "use the specified hex-coded 16byte key to encrypt the > segments",

Re: [FFmpeg-devel] [PATCH] avfilter/vf_framerate: always request input if no output is provided in request_frame

On Wed, Apr 05, 2017 at 02:03:00 +0200, Marton Balint wrote: > -static int process_work_frame(AVFilterContext *ctx, int stop) > +static int process_work_frame(AVFilterContext *ctx, int filter_frame) Just from a level of confusion, I don't find it smart to name a variable (albeit a local one) the

Re: [FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect

Many thanks for your feedback, Michael and Nicolas. On Wed, Apr 5, 2017 at 7:02 PM, Michael Niedermayer wrote: > fails on qemu mips Thank you for flagging this failure. I'm currently trying to reproduce the problem. May I ask what toolchain you typically use to compile

Re: [FFmpeg-devel] [libav-devel] ff_thread_get_format and metadata

On Thu, Apr 6, 2017 at 11:35 AM, Steve Lhomme wrote: > On Thu, Apr 6, 2017 at 11:08 AM, Hendrik Leppkes wrote: >> On Thu, Apr 6, 2017 at 11:01 AM, Steve Lhomme wrote: >>> Hi, >>> >>> As I am progressing in proper HDR10 support in VLC, I

Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: remove the stats metadata added by mkvmerge.

On Thu, 6 Apr 2017 12:27:43 +0200 Nicolas George wrote: > They are probably not valid for the resulting file. > They look like this: > BPS : 40665 > BPS-eng : 40665 > DURATION: 00:00:20.0 > DURATION-eng:

[FFmpeg-devel] [PATCH] ffmpeg_opt: remove the stats metadata added by mkvmerge.

They are probably not valid for the resulting file. They look like this: BPS : 40665 BPS-eng : 40665 DURATION: 00:00:20.0 DURATION-eng: 00:00:20.0 NUMBER_OF_FRAMES: 10 NUMBER_OF_FRAMES-eng: 10 NUMBER_OF_BYTES

Re: [FFmpeg-devel] [libav-devel] ff_thread_get_format and metadata

On Thu, Apr 6, 2017 at 11:38 AM, wm4 wrote: > On Thu, 6 Apr 2017 11:08:24 +0200 > Hendrik Leppkes wrote: > >> On Thu, Apr 6, 2017 at 11:01 AM, Steve Lhomme wrote: >> > Hi, >> > >> > As I am progressing in proper HDR10 support in VLC,

Re: [FFmpeg-devel] [libav-devel] ff_thread_get_format and metadata

On Thu, 6 Apr 2017 11:08:24 +0200 Hendrik Leppkes wrote: > On Thu, Apr 6, 2017 at 11:01 AM, Steve Lhomme wrote: > > Hi, > > > > As I am progressing in proper HDR10 support in VLC, I am facing an > > issue. The mastering (and lighting pending patch)

Re: [FFmpeg-devel] [libav-devel] ff_thread_get_format and metadata

On Thu, Apr 6, 2017 at 11:08 AM, Hendrik Leppkes wrote: > On Thu, Apr 6, 2017 at 11:01 AM, Steve Lhomme wrote: >> Hi, >> >> As I am progressing in proper HDR10 support in VLC, I am facing an >> issue. The mastering (and lighting pending patch) metadata are

Re: [FFmpeg-devel] [libav-devel] ff_thread_get_format and metadata

On Thu, Apr 6, 2017 at 11:01 AM, Steve Lhomme wrote: > Hi, > > As I am progressing in proper HDR10 support in VLC, I am facing an > issue. The mastering (and lighting pending patch) metadata are set on > the AVFrame but not available to the ff_get_format() receiver. > > That

[FFmpeg-devel] ff_thread_get_format and metadata

Hi, As I am progressing in proper HDR10 support in VLC, I am facing an issue. The mastering (and lighting pending patch) metadata are set on the AVFrame but not available to the ff_get_format() receiver. That means when we configure our vout and decoder we don't know if it's going to have HDR

Re: [FFmpeg-devel] [PATCH 2/4] ffmpeg: use reordered duration for stream PTS.

On Thu, 6 Apr 2017 11:04:48 +0200 Nicolas George wrote: > Le septidi 17 germinal, an CCXXV, Hendrik Leppkes a écrit : > > pkt_duration is often missing or incorrect. > > I have FATE-tested the resulting code and it exhibits no regression. FATE doesn't test most of the

Re: [FFmpeg-devel] [PATCH 2/4] ffmpeg: use reordered duration for stream PTS.

Le septidi 17 germinal, an CCXXV, Hendrik Leppkes a écrit : > pkt_duration is often missing or incorrect. I have FATE-tested the resulting code and it exhibits no regression. > At the very last falling back to the old logic if its unset seems > sensible. I do not think so. The old logic was

Re: [FFmpeg-devel] [PATCH 3/4] lavfi/buffersrc: add av_buffersrc_close().

On Thu, 6 Apr 2017 10:44:50 +0200 Nicolas George wrote: > TODO APIChanges and minor bump. > > Signed-off-by: Nicolas George > --- > libavfilter/buffersrc.c | 22 -- > libavfilter/buffersrc.h | 8 > 2 files changed, 20

Re: [FFmpeg-devel] [PATCH 2/4] ffmpeg: use reordered duration for stream PTS.

On Thu, Apr 6, 2017 at 10:44 AM, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > ffmpeg.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > > Unchanged. Necessary for the next patches. > > > diff --git a/ffmpeg.c b/ffmpeg.c >

[FFmpeg-devel] Patch: filter af_amix inputs

Dear All, While needing automatically to mix several hundred audio files, I noticed that the libavfilter module af_amix.c (audio filter 'amix') is hard-coded to limit inputs to 32. Of course, I believe this to be sensible as no doubt you do, too. However, because the code appears to be written

[FFmpeg-devel] [PATCH 4/4] ffmpeg: send EOF pts to filters.

Signed-off-by: Nicolas George --- ffmpeg.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) With this change, filters have a timestamp when EOF is reached, available in link->current_pts. For example, vf_fps could make use of it to fix the duration of the last

[FFmpeg-devel] [PATCH 3/4] lavfi/buffersrc: add av_buffersrc_close().

TODO APIChanges and minor bump. Signed-off-by: Nicolas George --- libavfilter/buffersrc.c | 22 -- libavfilter/buffersrc.h | 8 2 files changed, 20 insertions(+), 10 deletions(-) diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c index

[FFmpeg-devel] [PATCH 2/4] ffmpeg: use reordered duration for stream PTS.

Signed-off-by: Nicolas George --- ffmpeg.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) Unchanged. Necessary for the next patches. diff --git a/ffmpeg.c b/ffmpeg.c index 4db8ea82ac..41f1f076ca 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -2357,7 +2357,7 @@ static

[FFmpeg-devel] [PATCH 1/4] ffmpeg: rename a variable.

Makes the reason of the "FIXME" comment more obvious. Avoid name conflicts for the next commit. Signed-off-by: Nicolas George --- ffmpeg.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) Unchanged. diff --git a/ffmpeg.c b/ffmpeg.c index

Re: [FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect

Le sextidi 16 germinal, an CCXXV, Matthias C. M. Troffaes a écrit : > +#define DEFINE_BLEND(NAME, TYPE, DECL, EXPR) > \ > +static void blend_##NAME##_##TYPE(AVFilterContext *ctx, AVFrame *in, int > plane)\ > +{

Re: [FFmpeg-devel] [PATCH] avfilter/vf_framerate: always request input if no output is provided in request_frame

Le sextidi 16 germinal, an CCXXV, Marton Balint a écrit : > Fixes ticket #6285. > > Signed-off-by: Marton Balint > --- > libavfilter/vf_framerate.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) It respects the scheduling requirements, and the logic seems sound