On Wed, 23 May 2018 20:25:34 +0100
Rostislav Pehlivanov wrote:
> On 23 May 2018 at 20:01, wm4 wrote:
>
> > On Wed, 23 May 2018 14:29:38 -0400 (EDT)
> > Patrick Keroulas wrote:
> >
> > > - Original Message -
> > > > From: "wm4&
On Wed, 23 May 2018 14:29:38 -0400 (EDT)
Patrick Keroulas wrote:
> - Original Message -
> > From: "wm4"
> > To: ffmpeg-devel@ffmpeg.org
> > Sent: Wednesday, May 23, 2018 12:02:45 PM
> > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags f
On Wed, 23 May 2018 16:46:17 +0100
Rostislav Pehlivanov wrote:
> On 23 May 2018 at 16:18, wm4 wrote:
>
> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> > Patrick Keroulas wrote:
> >
> > > - Original Message -
> > > > From: "Rost
eg-devel] [PATCH v6 1/3] avcodec: add flags for packets
> > with top/bottom field
>
> > On 18 May 2018 at 22:17, wm4 wrote:
>
>
>
> > > But I think a new side data type would be much saner. We could even
> > > just make it something generic, like
On Wed, 23 May 2018 00:21:56 +0200
Hendrik Leppkes wrote:
> On Tue, May 22, 2018 at 10:35 PM, Carl Eugen Hoyos wrote:
> > 2018-05-22 17:40 GMT+02:00, Gagandeep Singh :
> >
> >> +low= s->plane[plane].subband[0];
> >> +high = s->plane[plane].subband[8];
> >> +
On Wed, 23 May 2018 18:29:20 +0800
Jun Zhao wrote:
> Signed-off-by: Jun Zhao
> ---
> libavutil/hwcontext_vaapi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 5bdb02f..7b3cbea 100644
> --- a/libavutil/hwcontext_vaa
On Fri, 18 May 2018 21:59:13 +0100
Rostislav Pehlivanov wrote:
> On 18 May 2018 at 21:03, wm4 wrote:
>
> > On Fri, 18 May 2018 20:09:02 +0100
> > Rostislav Pehlivanov wrote:
> >
> > > On 18 May 2018 at 20:05, Patrick Keroulas <
> > >
t; > To: "FFmpeg development discussions and patches" <
> > ffmpeg-devel@ffmpeg.org>
> > > Sent: Tuesday, May 15, 2018 4:46:02 PM
> > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> > packets with top/bottom field
> >
&g
On Fri, 18 May 2018 11:54:52 -0700
Richard Shaffer wrote:
> On Fri, May 18, 2018 at 2:54 AM, wm4 wrote:
>
> > On Thu, 17 May 2018 20:49:42 -0700
> > rshaf...@tunein.com wrote:
> >
> > > From: Richard Shaffer
> > >
> > > The HLS demuxer will
On Thu, 17 May 2018 17:21:42 -0700
Aman Gupta wrote:
> On Thu, May 17, 2018 at 5:04 PM, Aman Gupta wrote:
>
> > From: Aman Gupta
> >
> > Some filtered mpegts streams may erroneously include PMTs for programs
> > that are not advertised in the PAT. This confuses ffmpeg and most
> > players beca
On Thu, 17 May 2018 20:49:42 -0700
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> The HLS demuxer will process any ID3 tags at the beginning of a segment in
> order to obtain timestamp data. However, when this data was parsed on a second
> or subsequent segment, the updated metadata woul
On Thu, 17 May 2018 18:13:34 -0700
Aman Gupta wrote:
> On Thu, May 17, 2018 at 3:49 PM, Aman Gupta wrote:
>
> > From: Aman Gupta
> >
> > This can be used to detect changes to the streams in an AVProgram
> >
>
> Forgot to add: I have seen two related patches in the wild that attempt to
> sol
On Thu, 17 May 2018 05:50:55 +0100
Rostislav Pehlivanov wrote:
> On 17 May 2018 at 05:46, Zhao Zhili wrote:
>
> > ---
> > libavutil/error.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavutil/error.h b/libavutil/error.h
> > index 71df4da..8a35fef 100644
> > --- a/libavut
On Thu, 17 May 2018 00:41:10 +0200
Carl Eugen Hoyos wrote:
> 2018-05-16 11:47 GMT+02:00, Steinar H. Gunderson
> :
> > On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:
> >> Yes, I am referring to usage of the libavutil headers in C. If the macro
> >> is
> >> only hidden for C++ and
On Wed, 16 May 2018 11:45:58 -0700
Aman Gupta wrote:
> On Wed, May 16, 2018 at 11:14 AM, wm4 wrote:
>
> > On Wed, 16 May 2018 10:17:58 -0700
> > Aman Gupta wrote:
> >
> > > From: Aman Gupta
> > >
> > > HLS streams can contain discont
On Wed, 16 May 2018 10:17:58 -0700
Aman Gupta wrote:
> From: Aman Gupta
>
> HLS streams can contain discontinuities. Mark the format as such.
>
> This triggers various discontinuity fixes in lavf/utils.c and fftools
>
> Signed-off-by: Aman Gupta
> ---
> libavformat/hls.c | 2 +-
> 1 file ch
On Wed, 16 May 2018 15:19:44 +0800
Haihao Xiang wrote:
> Signed-off-by: Haihao Xiang
> ---
> libavcodec/hevcdec.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index c8877626d2..13d868bb4f 100644
> --- a/libavcodec/hevcdec.c
> +++ b
On Wed, 16 May 2018 11:47:36 +0200
"Steinar H. Gunderson" wrote:
> On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:
> > Yes, I am referring to usage of the libavutil headers in C. If the macro is
> > only hidden for C++ and available in C, that would be OK for me. But if the
> > stati
On Wed, 16 May 2018 17:58:46 +0800
Zhao Zhili wrote:
> On 2018年05月16日 17:47, Steinar H. Gunderson wrote:
> > On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:
> >> Yes, I am referring to usage of the libavutil headers in C. If the macro is
> >> only hidden for C++ and available in C,
On Wed, 16 May 2018 10:13:44 +0200
Hendrik Leppkes wrote:
> On Wed, May 16, 2018 at 2:39 AM, Peter Bennett wrote:
> > From: Peter Bennett
> >
> > libavformat.v has url_open, url_close and url_write. These
> > should be ffurl_ in each case.
> > ---
> > libavformat/libavformat.v | 6 +++---
> >
On Wed, 16 May 2018 15:44:36 +0100
Derek Buitenhuis wrote:
> On Wed, May 16, 2018 at 3:25 PM, James Almer wrote:
> > I think the issue is not the lack of clear enforcement rules, but a lack
> > of a proactive enforcer, be it a person or a body. The CoC has done
> > nothing but give people someth
On Tue, 15 May 2018 17:15:05 +0100
Rostislav Pehlivanov wrote:
> On 15 May 2018 at 15:55, wm4 wrote:
>
> > On Mon, 14 May 2018 18:26:35 -0400
> > Patrick Keroulas wrote:
> >
> > > Signed-off-by: Patrick Keroulas
> > > ---
> > > doc/APIch
On Mon, 14 May 2018 18:26:35 -0400
Patrick Keroulas wrote:
> Signed-off-by: Patrick Keroulas
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 8
> libavcodec/version.h | 4 ++--
> 3 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/API
On Mon, 14 May 2018 17:50:25 +0100
Derek Buitenhuis wrote:
> Hello all.
>
> This is a little rambling / stream of thought, but take it as you will,
> and perhaps some discussion or change comes of it. Or, more likely, personal
> attacks, flames, and no change. Or 1 few will reply and then the th
On Fri, 11 May 2018 11:38:52 +0100
Mark Thompson wrote:
> On 11/05/18 08:52, Haihao Xiang wrote:
> > Currently an extra copy of mfx include headers from
> > {MSDK_INSTALL_PREFIX}/include
> > to {MSDK_INSTALL_PREFIX}/include/mfx is required when using pkg-config for
> > libmfx detection. This fix
On Fri, 11 May 2018 01:49:58 +0200
James Darnley wrote:
> ...
Security in ffmpeg sure is weird. On one hand we get all kinds of crazy
stuff that's supposed to mitigate... something (like whitelists), on
the other hand we get this.
> I haven't tried to stand in the way of other bad changes to ff
On Fri, 11 May 2018 00:53:16 +0100
Rostislav Pehlivanov wrote:
> On 11 May 2018 at 00:44, wm4 wrote:
>
> > On Fri, 11 May 2018 00:41:20 +0100
> > Derek Buitenhuis wrote:
> >
> > > On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote:
> > > >
On Fri, 11 May 2018 00:41:20 +0100
Derek Buitenhuis wrote:
> On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote:
> > I do not have time to explain security basics.
> > Get a decent book and read it from a start to an end.
>
> Speaking frankly for a second: Why do people put up with this sor
On Fri, 11 May 2018 00:21:37 +0100
Rostislav Pehlivanov wrote:
> On 10 May 2018 at 23:27, Paul B Mahol wrote:
>
> > On 5/11/18, wm4 wrote:
> > > On Thu, 10 May 2018 16:44:59 +0100
> > > Derek Buitenhuis wrote:
> > >
> > >> These d
On Thu, 10 May 2018 16:44:59 +0100
Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exact
On Thu, 10 May 2018 01:24:42 +0200
Jorge Ramirez-Ortiz wrote:
> On 05/09/2018 04:11 PM, Mark Thompson wrote:
> > On 09/05/18 08:57, Jorge Ramirez-Ortiz wrote:
> >> On 05/09/2018 01:33 AM, Mark Thompson wrote:
> >>> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> >>> index
On Tue, 8 May 2018 17:48:21 +0200
Timo Rothenpieler wrote:
> Am 08.05.2018 um 17:26 schrieb wm4:
> > On Tue, 8 May 2018 15:31:29 +0200
> > Timo Rothenpieler wrote:
> >
> >> ---
> >> configure | 6 --
> >> doc
On Tue, 8 May 2018 17:43:49 +0200
Timo Rothenpieler wrote:
> >> -frame->buf[0] = av_buffer_pool_get(ctx->pool);
> >> +if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
> >> +frame->buf[0] = av_buffer_create(NULL, 0, NULL, NULL, 0);
> >> +else
> >> +frame->buf[0] = av_buf
On Tue, 8 May 2018 15:31:29 +0200
Timo Rothenpieler wrote:
> ---
> configure | 6 --
> doc/APIchanges | 3 ++-
> libavutil/hwcontext_cuda.c | 3 +++
> libavutil/hwcontext_cuda.h | 1 +
> libavutil/version.h| 2 +-
> 5 files changed, 11 insertions(+), 4 d
On Mon, 7 May 2018 23:46:48 +0200
Timo Rothenpieler wrote:
> Frames can be mapped from nvdec/cuvid, not needing any actual memory
> allocation, but all other features of the hw_frames_ctx.
> Hence the dummy-mode, which does not allocate any (notable amounts of)
> memory but otherwise behaves the
On Tue, 8 May 2018 15:31:28 +0200
Timo Rothenpieler wrote:
> Replaces the data pointers with the mapped cuvid ones.
> Adds buffer_refs to the frame to ensure the needed contexts stay alive
> and the cuvid idx stays allocated.
> Adds another buffer_ref to unmap the frame when it's unreferenced it
On Sun, 6 May 2018 17:19:44 +0300
Jan Ekström wrote:
> Yet another case of forgotten 0 =! EOF translation. The libbluray
> documentation specifically mentions that a read of 0 is EOF.
>
> Reported by Fyr on IRC.
> ---
> libavformat/bluray.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
On Sat, 5 May 2018 22:47:37 +0200
Michael Niedermayer wrote:
> Fixes: out of array read
> Fixes:
> 6546/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FIC_fuzzer-6317064647081984
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Sig
On Sat, 5 May 2018 21:10:06 +0200
Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 6292/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP3_fuzzer-4871218218926080
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
On Sat, 5 May 2018 02:35:52 +0200
Carl Eugen Hoyos wrote:
> 2018-05-04 15:00 GMT+02:00, wm4 :
> > On Sat, 28 Apr 2018 19:24:21 +0200
> > wm4 wrote:
> >
> >> If the API user doesn't set avg_frame_rate, matroskaenc will write the
> >> current timeba
On Fri, 4 May 2018 21:51:38 -0300
James Almer wrote:
> On 5/4/2018 9:19 PM, Michael Niedermayer wrote:
> > On Fri, May 04, 2018 at 02:02:02PM -0300, James Almer wrote:
> >> On 5/4/2018 1:51 PM, wm4 wrote:
> >>> On Fri, 4 May 2018 13:30:38 -0300
> >>>
On Fri, 4 May 2018 13:30:38 -0300
James Almer wrote:
> On 5/4/2018 12:58 PM, wm4 wrote:
> > On Sat, 28 Apr 2018 19:05:29 +0200
> > wm4 wrote:
> >
> >> This can "demux" .vpy files.
> >>
> >> Some minor code copied from other LGPL parts
On Sat, 28 Apr 2018 19:05:29 +0200
wm4 wrote:
> This can "demux" .vpy files.
>
> Some minor code copied from other LGPL parts of FFmpeg.
>
> I did not found a good way to test a few of the more obscure features,
> like VFR nodes, compat pixel formats, or no
On Fri, 4 May 2018 08:56:18 -0400
Compn wrote:
> On Fri, 4 May 2018 14:36:03 +0200, wm4 wrote:
>
> > FourCC are already split up for avi and mov. Apparently it got
> > sabotaged at some point.
>
> i think mkv re-uses riff list from avi on purpose, as it was meant a
On Sun, 29 Apr 2018 14:23:17 +0200
Clément Bœsch wrote:
> On Sat, Apr 28, 2018 at 08:37:06PM +0200, wm4 wrote:
> > This code will print a warning if any user agent is set - even if the
> > API user used the proper non-deprecated "user_agent" option.
> >
> &
On Sat, 28 Apr 2018 19:24:21 +0200
wm4 wrote:
> If the API user doesn't set avg_frame_rate, matroskaenc will write the
> current timebase as "default duration" for the video track. This makes
> no sense, because the "default duration" implies the framerate of
On Fri, 4 May 2018 08:19:27 -0400
Compn wrote:
> On Thu, 3 May 2018 17:26:38 -0300, James Almer
> wrote:
> > Create a new table with all non standard codecids from ff_codec_bmp_tags
> > and use it exclusively in avidec, then remove them from
> > ff_codec_bmp_tags, adapting other de/muxers if nee
On Fri, 4 May 2018 17:31:52 +0800
Steven Liu wrote:
> > On 4 May 2018, at 17:20, Jan Ekström wrote:
> >
> > WHAT!?
> >
> > This LGTM was for the bit mask *only*
> >
> > ALL OTHER POINTS STAND
>
> Don’t worry , all LGTM too, this could fix the resend sequence header
> timestamp problem, al
On Thu, 3 May 2018 12:11:56 +0300
Andrey Turkin wrote:
> cuvid decoder has one advantage over nvdec: it has a hardware deinterlacer
> support. BTW not sure if this patch takes that into account. So cuvid is
> the only way to get GPU-deinterlaced frames until someone makes CUDA-based
> deinterlace
On Wed, 2 May 2018 19:37:27 +0100
Rostislav Pehlivanov wrote:
> On 2 May 2018 at 19:16, wm4 wrote:
>
> > On Wed, 2 May 2018 19:14:21 +0100
> > Rostislav Pehlivanov wrote:
> >
> > > On 2 May 2018 at 19:04, Marton Balint wrote:
> > >
> > &
On Wed, 2 May 2018 19:14:21 +0100
Rostislav Pehlivanov wrote:
> On 2 May 2018 at 19:04, Marton Balint wrote:
>
> >
> >
> > On Tue, 1 May 2018, Rostislav Pehlivanov wrote:
> >
> > On 1 May 2018 at 23:22, Paul B Mahol wrote:
> >>
> >> On 5/2/18, Michael Niedermayer wrote:
> >>> > Hi
> >>> >
On Wed, 2 May 2018 17:49:05 +0100
Rostislav Pehlivanov wrote:
> On 2 May 2018 at 17:39, wm4 wrote:
>
> > On Wed, 2 May 2018 13:44:48 +0200
> > Nicolas George wrote:
> >
> > > Vittorio Giovara (2018-05-01):
> > > > Well no, let's step back
On Wed, 2 May 2018 13:44:48 +0200
Nicolas George wrote:
> Vittorio Giovara (2018-05-01):
> > Well no, let's step back a little.
> >
> > First of all there is no stigma about adding fields to AVCodecContext,
> > in fact, the more, the merrier, right?
> >
> > Secondly, there _is_ concern about ad
On Tue, 1 May 2018 16:46:37 -0400
Vittorio Giovara wrote:
> --
>
> On 5/1/2018 4:39 PM, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol
> > ---
> > libavcodec/avcodec.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index fb
On Tue, 1 May 2018 22:44:07 +0200
Michael Niedermayer wrote:
> Regression since: af1761f7
> Fixes: Division by 0
> Fixes: ffmpeg_crash_1
>
> Found-by: Thuan Pham, Marcel Böhme, Andrew Santosa and Alexandru Razvan
> Caciulescu with AFLSmart
> Signed-off-by: Michael Niedermayer
> ---
> fftools
On Tue, 1 May 2018 17:48:32 +0200
Paul B Mahol wrote:
> This one actually works with hd1080 y4m files when seeking backwards.
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/yuv4mpegdec.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/yuv4mpe
On Tue, 1 May 2018 15:17:53 +0200
Paul B Mahol wrote:
> On 5/1/18, wm4 wrote:
> > On Tue, 1 May 2018 11:47:04 +0200
> > Paul B Mahol wrote:
> >
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> libavformat/yuv4mpegdec.c| 23
On Tue, 1 May 2018 11:47:04 +0200
Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/yuv4mpegdec.c| 23
> tests/ref/seek/lavf-yuv4mpeg | 52
>
> 2 files changed, 28 insertions(+), 47 deletions(-)
>
> dif
On Sat, 28 Apr 2018 23:21:27 -0300
James Almer wrote:
> Signed-off-by: James Almer
> ---
> fftools/ffmpeg.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index d3054092ba..9b3e9d121e 100644
> --- a/fftools/ffmpeg.c
> +
On Sat, 28 Apr 2018 21:18:47 +0200
Carl Eugen Hoyos wrote:
> 2018-04-28 20:05 GMT+02:00, wm4 :
> > On Sat, 28 Apr 2018 19:52:38 +0200
> > Carl Eugen Hoyos wrote:
> >
> >> 2018-04-28 19:24 GMT+02:00, wm4 :
> >> > If the API user doesn't
On Sat, 28 Apr 2018 15:28:13 -0300
James Almer wrote:
> On 4/28/2018 2:05 PM, wm4 wrote:
> > This can "demux" .vpy files.
> >
> > +pkt->data = pkt->buf->data;
> > +pkt->size = pkt->buf->size;
> > +pkt
This code will print a warning if any user agent is set - even if the
API user used the proper non-deprecated "user_agent" option.
This change should not even break anything, because even if the user
sets the deprecated "user-agent" option, http.c copies it to the
"user_agent" option anyway.
---
On Sat, 28 Apr 2018 19:52:38 +0200
Carl Eugen Hoyos wrote:
> 2018-04-28 19:24 GMT+02:00, wm4 :
> > If the API user doesn't set avg_frame_rate, matroskaenc will write the
> > current timebase as "default duration" for the video track. This makes
> > no
If the API user doesn't set avg_frame_rate, matroskaenc will write the
current timebase as "default duration" for the video track. This makes
no sense, because the "default duration" implies the framerate of the
video. Since the timebase is forced to 1/1000, this will make the
resulting file claim
This can "demux" .vpy files.
Some minor code copied from other LGPL parts of FFmpeg.
I did not found a good way to test a few of the more obscure features,
like VFR nodes, compat pixel formats, or nodes with dynamic size/format
changes. These can be easily implemented on demand.
---
configure
On Sat, 28 Apr 2018 11:58:27 -0300
James Almer wrote:
> On 4/28/2018 8:51 AM, wm4 wrote:
> > On Sat, 28 Apr 2018 11:08:01 +0800
> > Steven Liu wrote:
> >
> >>> On 28 Apr 2018, at 03:37, wm4 wrote:
> >>>
> >
> >
On Fri, 27 Apr 2018 22:27:47 -0300
James Almer wrote:
> On 4/27/2018 4:37 PM, wm4 wrote:
> > From: wm4
> >
> > require_pkg_config libvapoursynth "vapoursynth-script >= 42" VSScript.h
> > vsscript_init || die "ERROR: vapoursynth or vsscript
On Sat, 28 Apr 2018 11:08:01 +0800
Steven Liu wrote:
> > On 28 Apr 2018, at 03:37, wm4 wrote:
> >
> > +
> > +if (strncmp(pd->name, "xyz", 3) == 0)
> > +continue;
>
> liuqideMacBook-Pro:xxx liuqi$ ../tools/patcheck
&g
From: wm4
This can "demux" .vpy files.
Some minor code copied from other LGPL parts of FFmpeg.
Possibly support VS compat pixel formats.
TODO:
- check whether VS can change format midstream
- test vfr mode, return proper timestamps when using it
- drop "lib" pr
On Thu, 26 Apr 2018 14:41:55 +0200
Daniel Oberhoff wrote:
> > On 26. Apr 2018, at 14:40, wm4 wrote:
> >
> > On Thu, 26 Apr 2018 14:12:14 +0200
> > Hendrik Leppkes mailto:h.lepp...@gmail.com>> wrote:
> >
> >> On Thu, Apr 26, 2018 at 2:02 PM, Dani
On Fri, 20 Apr 2018 16:21:13 -0400
Mark Wachsler wrote:
> The -benchmark and -benchmark_all options now show user, system, and real
> time,
> instead of just user time.
> ---
> fftools/ffmpeg.c | 50 ++--
> 1 file changed, 36 insertions(+), 14 deletio
On Thu, 26 Apr 2018 08:59:03 -0800
Lou Logan wrote:
> On Thu, Apr 26, 2018, at 4:40 AM, wm4 wrote:
> >
> > To be fair, I'd prefer the github issue tracker over TRAC any day.
>
> At least it isn't Bugzilla. What are some of the problems with trac? Is there
&g
On Thu, 26 Apr 2018 14:51:09 +0200
Daniel Oberhoff wrote:
> > On 26. Apr 2018, at 14:49, Nicolas George wrote:
> >
> > Daniel Oberhoff (2018-04-26):
> >> ---
> >> include/ffnvcodec/dynlink_loader.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > I may be missing something
On Thu, 26 Apr 2018 14:12:14 +0200
Hendrik Leppkes wrote:
> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
> wrote:
> >
> >> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff
> >> :
> >>
> >>
> >>> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff
> >>> :
> >>>
> >>>
> Am 26.04.2018 um
On Thu, 26 Apr 2018 14:19:51 +0200
Nicolas George wrote:
> Josh de Kock (2018-04-26):
> > >>Generally, adding more things to public API is a bad move
>
> > What I mean by this is making private fields public is generally a bad move.
> > They were initially made private for a reason, and if you
On Thu, 26 Apr 2018 13:39:56 +0200
Carl Eugen Hoyos wrote:
> 2018-04-26 13:34 GMT+02:00, Paul B Mahol :
> > On 4/26/18, Carl Eugen Hoyos wrote:
> >> 2018-04-26 13:17 GMT+02:00, Josh de Kock :
> >>> On 2017/06/26 15:09, Paul B Mahol wrote:
> Rationale:
> - Slower then other encode
On Thu, 26 Apr 2018 13:34:12 +0200
Paul B Mahol wrote:
> On 4/26/18, Carl Eugen Hoyos wrote:
> > 2018-04-26 13:17 GMT+02:00, Josh de Kock :
> >> On 2017/06/26 15:09, Paul B Mahol wrote:
> >>> Rationale:
> >>> - Slower then other encoder
> >>> - Less configurable
> >>> - Does not support alph
On Thu, 26 Apr 2018 13:15:52 +0200
Daniel Oberhoff wrote:
> Hello,
>
> I was wondering if there is any chance to move development to github? I.e.
> not just mirror, but as primary development repo, with issues and pull
> requests? Would make collaboration a *lot* easier (think of submitting a
On Thu, 26 Apr 2018 12:47:58 +0200
Nicolas George wrote:
> Josh de Kock (2018-04-26):
> >It's also not impossible, nor irrational to be removing code which
> > doesn't fit or could be written better if an alternative is provided, the
> > need was never there or removal can otherwise be ju
On Tue, 24 Apr 2018 23:46:09 +0200
Nicolas George wrote:
> Stephan Holljes (2018-04-24):
> > The consensus seems to be that there are more disadvantages in using
> > the http server of libavformat than there are advantages.
>
> I completely disagree. There is no point in having the HTTP server
On Wed, 25 Apr 2018 09:55:10 +0200
Steve Lhomme wrote:
> Le 24/04/2018 à 08:28, Hendrik Leppkes a écrit :
> > On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme wrote:
> >> If we don't do that get_format might not be called for a while and the
> >> proper
> >> SAR not used.
> >>
> >> See the sampl
On Tue, 24 Apr 2018 20:23:43 +0200 (CEST)
Marton Balint wrote:
> On Tue, 24 Apr 2018, Michael Niedermayer wrote:
>
> > On Tue, Apr 24, 2018 at 02:10:53AM +0200, Michael Niedermayer wrote:
> >> On Mon, Apr 23, 2018 at 04:50:54AM +0200, Marton Balint wrote:
> >>>
> >>>
> >>> On Mon, 23 Apr 201
On Tue, 24 Apr 2018 08:28:35 +0200
Hendrik Leppkes wrote:
> On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme wrote:
> > If we don't do that get_format might not be called for a while and the
> > proper
> > SAR not used.
> >
> > See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19
On Mon, 23 Apr 2018 21:09:09 +0200
Thomas Volkert wrote:
> On 23.04.2018 14:08, Rostislav Pehlivanov wrote:
> > On 23 April 2018 at 10:27, Thomas Volkert wrote:
> >
> >> On 22.04.2018 20:03, Carl Eugen Hoyos wrote:
> >>> 2018-04-22 20:00 GMT+02:00, Nicolas George :
> Carl Eugen Hoyos
On Mon, 23 Apr 2018 20:25:40 +0200 (CEST)
Marton Balint wrote:
> On Sun, 22 Apr 2018, wm4 wrote:
>
> > On Sun, 22 Apr 2018 13:24:11 +0200 (CEST)
> > Marton Balint wrote:
> >
> >> On Fri, 20 Apr 2018, wm4 wrote:
> >>
> >> > On Thu,
On Sun, 22 Apr 2018 16:38:08 +0200
Clément Bœsch wrote:
> ---
> TODO: APIChanges + lavu minor bump (not done yet because it will
> conflict with the threadmessage patch)
> ---
> libavutil/opt.c | 6 ++
> libavutil/opt.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/libavutil/op
On Sun, 22 Apr 2018 13:24:11 +0200 (CEST)
Marton Balint wrote:
> On Fri, 20 Apr 2018, wm4 wrote:
>
> > On Thu, 19 Apr 2018 23:25:03 +0200
> > Marton Balint wrote:
> >
> >> Signed-off-by: Marton Balint
> >> ---
> >> doc/APIchanges
On Sun, 22 Apr 2018 13:44:19 +0200 (CEST)
Marton Balint wrote:
> On Fri, 20 Apr 2018, Michael Niedermayer wrote:
>
> > On Thu, Apr 19, 2018 at 09:32:19PM +0200, Marton Balint wrote:
> >> A pixel format which has a palette also has alpha, without this patch the
> >> format negotiation might hav
On Sun, 22 Apr 2018 08:41:18 +0800
Liu Steven wrote:
> > 在 2018年4月22日,上午5:23,wm4 写道:
> >
> > On Sat, 21 Apr 2018 22:55:33 +0200
> > Carl Eugen Hoyos wrote:
> >
> >> 2018-04-19 4:45 GMT+02:00, Steven Liu :
> >>>
> >>>
>
On Sat, 21 Apr 2018 17:56:27 -0400
"Helmut K. C. Tessarek" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
> On 2018-04-21 17:23, wm4 wrote:
> > Just by the way, some have lamented that they think of it as
> > "doxing" when you
On Sat, 21 Apr 2018 23:30:35 +0200
Carl Eugen Hoyos wrote:
> 2018-04-21 23:23 GMT+02:00, wm4 :
>
> >> No (independently of what I think of Vincent's character and tone).
> >
> > Agreed, independently of what I think of you.
> >
> > Just by the way,
On Sat, 21 Apr 2018 22:55:33 +0200
Carl Eugen Hoyos wrote:
> 2018-04-19 4:45 GMT+02:00, Steven Liu :
> >
> >
> >> On 19 Apr 2018, at 03:20, wm4 wrote:
> >>
> >> On Wed, 18 Apr 2018 16:10:26 -0300
> >> James Almer wrote:
> >>
>
On Sat, 21 Apr 2018 15:54:40 +0800
Jun Zhao wrote:
> When use new decode APIs(avcodec_send_packet/avcodec_receive_frame),
> don't need to setting the deprecated field refcounted_frames.
>
> Signed-off-by: Jun Zhao
> ---
> doc/examples/hw_decode.c | 1 -
> 1 file changed, 1 deletion(-)
>
> dif
On Fri, 20 Apr 2018 03:43:30 -0500
Rodger Combs wrote:
> If there was a way to indicate this to consumers, or expose an option to turn
> this off, I'd say it should have that... but there's no good infrastructure
> to do that in an hwaccel, so whatever.
> One nit; otherwise LGTM.
>
I guess it
On Thu, 19 Apr 2018 23:25:03 +0200
Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> doc/APIchanges| 3 +++
> libavutil/pixdesc.c | 3 +--
> libavutil/pixdesc.h | 8 ++--
> libavutil/tests/pixdesc.c | 4
> libavutil/version.h | 2 +-
> 5 files ch
On Thu, 19 Apr 2018 12:55:00 -0700
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> This refactors get_cookies to simplify some code paths, specifically for
> skipping logic in the while loop or exiting it. It also simplifies the logic
> for appending additional values to *cookies by repla
On Thu, 19 Apr 2018 21:44:36 +0200
Hendrik Leppkes wrote:
> ex
>
> On Thu, Apr 19, 2018 at 9:39 PM, wm4 wrote:
> > On Thu, 19 Apr 2018 21:32:20 +0200
> > Marton Balint wrote:
> >
> >> Signed-off-by: Marton Balint
> >> ---
> >> doc/A
On Tue, 17 Apr 2018 16:37:13 -0700
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> This refactors get_cookies to simplify some code paths, specifically for
> skipping logic in the while loop or exiting it. It also simplifies the logic
> for appending additional values to *cookies by repla
On Thu, 19 Apr 2018 21:32:20 +0200
Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> doc/APIchanges | 3 +++
> libavutil/pixdesc.h | 11 +++
> libavutil/version.h | 2 +-
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchange
On Thu, 19 Apr 2018 17:01:56 +0200
Nicolas George wrote:
> James Almer (2018-04-19):
> > It would have not been backwards compatible in such scenario to load at
> > runtime an hypotetical 3.4.x lavf library with that change in an
> > application that was built against 3.3.x or older. Regardless o
1 - 100 of 3095 matches
Mail list logo