On Fri, 15 Dec 2017 18:11:34 +
Josh de Kock wrote:
> On Fri, 15 Dec 2017 18:08:02 +
> Josh de Kock wrote:
>
> > [...]
>
> Attached again with the correct mime...
>
This looks like it's break with the win32 stdatomic wrapper for all cas
calls.
_
On Fri, 15 Dec 2017 15:02:44 +0800
wbse...@gmail.com wrote:
> From: wang-bin
>
> 1. a cvpixelbuffer backed by iosurface can always be converted to an opengl
> texture, using CGLTexImageIOSurface2D for macOS, and undocumented api
> texImageIOSurface(which is internally used by public api
> CVO
On Fri, 15 Dec 2017 15:05:50 +0800
wbse...@gmail.com wrote:
> From: wang-bin
>
> mmal buffer->data is already in host memory. AFAIK decoders implemented in
> omx must
> be configured to output frames to either memory or something directly used by
> renderer,
> for example mediacodec surface, m
peg sw decoder.
> It's confused, and I think wm4 give a other patch for this case. you can
> refer to
> https://patchwork.ffmpeg.org/patch/6773/
My patch was just static metadata, so this is different.
___
ffmpeg-devel mailing list
ff
On Fri, 15 Dec 2017 03:11:47 +0100
Carl Eugen Hoyos wrote:
> 2017-12-14 14:28 GMT+01:00 wm4 :
>
> >> > This email message is for the sole use of the intended
> >> > recipient(s) and may contain confidential information.
> >>
> >> Please remov
On Thu, 14 Dec 2017 19:54:26 +0100
Jorge Ramirez wrote:
> On 12/14/2017 07:48 PM, wm4 wrote:
> > This is pretty much a requirement for any codec that handles modern
> > codecs like h264, but it was missing. Potentially could lead to issues
> > like missing frames a
AVCodec.caps_internal doesn't hold this field.
---
libavcodec/rkmppdec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/rkmppdec.c b/libavcodec/rkmppdec.c
index fa522ce2ed..c57a6ded38 100644
--- a/libavcodec/rkmppdec.c
+++ b/libavcodec/rkmppdec.c
@@ -588,8 +588,7
This is pretty much a requirement for any codec that handles modern
codecs like h264, but it was missing. Potentially could lead to issues
like missing frames at the end of a stream.
---
Untested.
---
libavcodec/v4l2_m2m_dec.c | 2 +-
libavcodec/v4l2_m2m_enc.c | 2 +-
2 files changed, 2 insertions
On Thu, 14 Dec 2017 16:02:59 +0100
wm4 wrote:
> Explicitly identify decoder/encoder wrappers with a common name. This
> saves API users from guessing by the name suffix. For example, they
> don't have to guess that "h264_qsv" is the h264 QSV implementation, and
> inst
On Thu, 14 Dec 2017 18:06:11 +0100
Matthieu Bouron wrote:
> On Thu, Dec 14, 2017 at 01:02:49PM +0100, wm4 wrote:
> > On Thu, 14 Dec 2017 12:53:38 +0100
> > Matthieu Bouron wrote:
> >
> > > On Thu, Dec 14, 2017 at 12:21:28PM +0100, wm4 wrote:
> > &g
On Thu, 14 Dec 2017 16:01:49 +
Aman Gupta wrote:
> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > index 086beb41fc..c47e5c4045 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -2599,8 +2599,9 @@ AVCodec ff_hevc_videot
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark
On Thu, 14 Dec 2017 16:01:55 +0100
Michael Niedermayer wrote:
> On Thu, Dec 14, 2017 at 02:26:31PM +0100, wm4 wrote:
> > I propose that FFmpeg sets the minimum supported Windows version to
> > Windows Vista (or maybe Windows 7). This would remove Windows XP
> > support.
&
On Thu, 14 Dec 2017 11:22:29 +0100
Carl Eugen Hoyos wrote:
> 2017-12-14 11:12 GMT+01:00 Yogender Gupta :
> > I would like to correct a couple of lines on the following ffmpeg web page.
> >
>
> > https://trac.ffmpeg.org/wiki/HWAccelIntro
>
> A wiki is a wiki.
>
> > Can anyone please guide
I propose that FFmpeg sets the minimum supported Windows version to
Windows Vista (or maybe Windows 7). This would remove Windows XP
support.
The reason is that Windows XP does not provide certain convenient APIs,
in particular locking primitives that map well to pthread. There are
other problems,
On Thu, 14 Dec 2017 12:53:38 +0100
Matthieu Bouron wrote:
> On Thu, Dec 14, 2017 at 12:21:28PM +0100, wm4 wrote:
> > On Thu, 14 Dec 2017 11:09:13 +0100
> > Matthieu Bouron wrote:
> >
> > > ---
> > >
On Thu, 14 Dec 2017 11:09:13 +0100
Matthieu Bouron wrote:
> ---
> libavcodec/mediacodec_wrapper.c | 262
> +++-
> 1 file changed, 70 insertions(+), 192 deletions(-)
>
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index f3
On Wed, 13 Dec 2017 20:56:30 +0100 (CET)
Marton Balint wrote:
> On Wed, 13 Dec 2017, Michael Niedermayer wrote:
>
> > On Wed, Dec 13, 2017 at 11:59:26AM +0100, Paul B Mahol wrote:
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> libavcodec/mjpegdec.c| 18 +-
> >>
On Tue, 12 Dec 2017 18:28:28 -0300
James Almer wrote:
> On 12/12/2017 4:38 AM, wm4 wrote:
> > On Mon, 11 Dec 2017 22:56:24 +0100
> > Michael Niedermayer wrote:
> >
> >> On Mon, Dec 11, 2017 at 11:43:30AM +0100, wm4 wrote:
> >>> On Fri, 8 Dec
On Tue, 12 Dec 2017 22:13:30 +0100
Carl Eugen Hoyos wrote:
> 2017-12-12 22:12 GMT+01:00 Paul B Mahol :
> > On 12/12/17, Carl Eugen Hoyos wrote:
> >> 2017-12-11 11:43 GMT+01:00 wm4 :
> >>
> >>> You've been ignoring this issue, though.
> >&
On Tue, 12 Dec 2017 14:55:59 +0100
Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/avcodec.h | 1 +
> libavcodec/utils.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5db6a81320..df715fd5ee 100644
> --- a/
On Tue, 12 Dec 2017 09:08:51 +0100
Hendrik Leppkes wrote:
> On Tue, Dec 12, 2017 at 9:04 AM, wm4 wrote:
> > On Tue, 12 Dec 2017 08:50:01 +0100
> > Hendrik Leppkes wrote:
> >
> >> On Tue, Dec 12, 2017 at 12:25 AM, Aaron Levinson
> >> wrote:
> >
On Tue, 12 Dec 2017 08:50:01 +0100
Hendrik Leppkes wrote:
> On Tue, Dec 12, 2017 at 12:25 AM, Aaron Levinson
> wrote:
> > On 12/8/2017 2:27 AM, Michael Niedermayer wrote:
> >>
> >> On Fri, Dec 08, 2017 at 09:49:25AM +0100, Hendrik Leppkes wrote:
> >>>
> >>> On Fri, Dec 8, 2017 at 6:09 AM, Ro
On Mon, 11 Dec 2017 22:56:24 +0100
Michael Niedermayer wrote:
> On Mon, Dec 11, 2017 at 11:43:30AM +0100, wm4 wrote:
> > On Fri, 8 Dec 2017 18:51:52 +0100
> > Carl Eugen Hoyos wrote:
> >
> > > 2017-12-08 18:45 GMT+01:00 Tiejun.Peng :
> > > > i agr
On Mon, 11 Dec 2017 22:10:24 +
Mark Thompson wrote:
> On 11/12/17 12:34, Matthieu Bouron wrote:
> >>
> >> New patch attached fixing errors in get_format() by keeping the original
> >> AVCodecHWConfigInternal (ad-hoc) and adding a new one (hw-device) with the
> >> device_type field set to the
On Mon, 27 Nov 2017 20:45:59 -0800
Philip Langdale wrote:
> We have a number of hardware backed implementations in the codebase
> that are done as full decoders instead of HWAccels for various
> reasons. These decoders cannot be discovered today, and clients
> which care end up needing to hardcod
On Mon, 11 Dec 2017 11:36:52 -0300
James Almer wrote:
> On 12/11/2017 11:28 AM, Hendrik Leppkes wrote:
> > On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol wrote:
> >> On 12/11/17, Hendrik Leppkes wrote:
> >>> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol wrote:
> >
> > Fine, but i
On Mon, 11 Dec 2017 15:28:31 +0100
Hendrik Leppkes wrote:
> On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol wrote:
> > On 12/11/17, Hendrik Leppkes wrote:
> >> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol wrote:
>
> Fine, but it's inevitable that the encoder supports the J format
On Mon, 11 Dec 2017 08:32:52 -0500
"Ronald S. Bultje" wrote:
> Hi,
>
> On Sat, Dec 9, 2017 at 10:37 AM, Paul B Mahol wrote:
>
> > @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
> > uint8_t max_lowres; ///< maximum value for lowres
> > supported by the decoder
> >
On Mon, 11 Dec 2017 14:22:43 +0100
Paul B Mahol wrote:
> On 12/11/17, Hendrik Leppkes wrote:
> > On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol wrote:
> >>>
> >>> Fine, but it's inevitable that the encoder supports the J formats still
> >>> for a while.
> >>
> >>
> >> Why are you all dismis
On Mon, 11 Dec 2017 12:07:34 +0100
Paul B Mahol wrote:
> On 12/11/17, wm4 wrote:
> > On Sat, 9 Dec 2017 16:37:53 +0100
> > Paul B Mahol wrote:
> >
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> libavcodec/avcodec.h | 1 +
> >&
On Sat, 9 Dec 2017 16:37:53 +0100
Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/avcodec.h | 1 +
> libavcodec/utils.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5db6a81320..e5de4797c8 100644
> --- a/
On Fri, 8 Dec 2017 18:51:52 +0100
Carl Eugen Hoyos wrote:
> 2017-12-08 18:45 GMT+01:00 Tiejun.Peng :
> > i agree with you. too much experience value in condition of Judgement
> > like this:
> > "else if(max_frames>=4 && max_frames >= p->buf_size/1)".
> > why it is the value ? it is hard
On Fri, 8 Dec 2017 06:52:20 +0100
Michael Niedermayer wrote:
> On Fri, Dec 08, 2017 at 01:09:50AM -0300, James Almer wrote:
> > On 12/8/2017 12:26 AM, wm4 wrote:
> > > On Thu, 7 Dec 2017 23:23:51 +0100
> > > Michael Niedermayer wrote:
> > >
> > &
On Thu, 7 Dec 2017 23:23:51 +0100
Michael Niedermayer wrote:
> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:
> > On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:
> > > On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:
> > > > On Sat, N
On Wed, 6 Dec 2017 17:27:43 +0800
"tiejun.peng" wrote:
> fix #6895: https://trac.ffmpeg.org/ticket/6895
> stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3
>
> Signed-off-by: tiejun.peng
> ---
> libavformat/mp3dec.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/l
On Tue, 5 Dec 2017 22:38:11 +0100
Hendrik Leppkes wrote:
> On Tue, Dec 5, 2017 at 8:23 PM, James Almer wrote:
> > On 12/5/2017 8:12 AM, Hendrik Leppkes wrote:
> >> On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
> >>> After some tests:
> >>> 1) #undef far
> >>> after #include is wrong -- i
On Mon, 4 Dec 2017 20:41:42 +0100
Timo Rothenpieler wrote:
> The external headers can be found at
> https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
> ---
LGTM, although I would have preferred giving the include paths a name
not specific to ffmpeg. But as I understand, the headers contai
On Mon, 4 Dec 2017 00:56:36 +
Mark Thompson wrote:
> On 04/12/17 00:09, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes ticket #6717, files without sei can be produced
> > with remuxing and seeking, even if this is a (separate) bug, such
> > files exist in the wild.
> >
> > Ple
On Mon, 4 Dec 2017 14:09:40 +
Derek Buitenhuis wrote:
> On 12/4/2017 12:45 PM, Carl Eugen Hoyos wrote:
> > Committers have to be subscribed to -cvslog.
>
> "Have to"? I certainly am not, and neither are many. Are you going to
> kick all of them out and revoke their push access? I think not
On Fri, 1 Dec 2017 18:02:52 +0100
Michael Niedermayer wrote:
> On Fri, Dec 01, 2017 at 10:01:42AM +0100, Nicolas George wrote:
> > Paul B Mahol (2017-11-30):
> > > +static int reset_links(AVFilterContext *filter)
> > > +{
> > > +int i, ret;
> > > +
> > > +if (!filter)
> > > +ret
On Thu, 30 Nov 2017 16:27:01 -0800
John Stebbins wrote:
> ---
> fftools/ffplay.c | 21 -
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index 10a917194d..152d220cdb 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffp
On Fri, 1 Dec 2017 10:35:34 +0100
Paul B Mahol wrote:
> On 12/1/17, Nicolas George wrote:
> > Paul B Mahol (2017-11-30):
> >> +static int reset_links(AVFilterContext *filter)
> >> +{
> >> +int i, ret;
> >> +
> >> +if (!filter)
> >> +return 0;
> >> +
> >> +for (i = 0; i < fi
On Thu, 30 Nov 2017 15:44:19 +0100
Hendrik Leppkes wrote:
> On Thu, Nov 30, 2017 at 3:29 PM, Hendrik Leppkes wrote:
> > On Thu, Nov 30, 2017 at 3:17 PM, Michael Niedermayer
> > wrote:
> >> On Thu, Nov 30, 2017 at 11:55:03AM +, Rostislav Pehlivanov wrote:
> >>> On 28 November 2017 at 01:
On Wed, 29 Nov 2017 23:15:44 +0100
Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 4
> libavfilter/vf_stereo3d.c | 35 ---
> 2 files changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/fi
On Thu, 30 Nov 2017 02:41:44 +0100
Carl Eugen Hoyos wrote:
> 2017-11-29 16:30 GMT+01:00 wm4 :
>
> > You won't hear any lies from me.
>
> That's too good to be true;-(
So you admit you're denying the truth because the truth hurts you?
That's pretty h
On Wed, 29 Nov 2017 18:10:49 +
"Mironov, Mikhail" wrote:
> >
> > It also should be made clear that nvidia does not somehow receive preferred
> > treatment over other vendors.
>
> Respectfully, but it does by inaction.
> Thanks,
> Mikhail
Not really. Intel has the best hardware transcodin
On Wed, 29 Nov 2017 17:42:05 +0100
Timo Rothenpieler wrote:
> Am 29.11.2017 um 17:40 schrieb wm4:
> > On Wed, 29 Nov 2017 17:27:01 +0100
> > Hendrik Leppkes wrote:
> >
> >> On Wed, Nov 29, 2017 at 5:24 PM, wm4 wrote:
> >>>
> >>> W
On Wed, 29 Nov 2017 17:27:01 +0100
Hendrik Leppkes wrote:
> On Wed, Nov 29, 2017 at 5:24 PM, wm4 wrote:
> >
> > What really irks me is that nvidia is not giving us any support for
> > supporting their stuff. AFAIK the current headers are the last MIT
> > licensed o
On Wed, 29 Nov 2017 16:24:42 +0100
wm4 wrote:
> webm usually has invisible superframes merged with normal frames.
> (vpxenc muxes them in this form, which is evidence enough that this is
> the standard webm packet format. It's rather unclear whether ffmpeg is
> even allowed t
On Wed, 29 Nov 2017 09:09:14 -0700
Pavel Koshevoy wrote:
> On Tue, Nov 28, 2017 at 12:47 AM, Tobias Rapp wrote:
> > On 27.11.2017 17:14, Pavel Koshevoy wrote:
>
>
>
> >> Personally, I would prefer if the bundled external headers were
> >> installed together with ffmpeg public headers (so nv
We did this for the sake of the decoder. With the vp9 change, it's not
necessary anymore.
---
libavcodec/vp9_parser.c | 127 --
libavformat/hlsplaylist.h | 4 +-
2 files changed, 12 insertions(+), 119 deletions(-)
diff --git a/libavcodec/vp9_parser.
cussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] AMD external header
> >
> > On 11/29/17, Carl Eugen Hoyos wrote:
> > > 2017-11-29 15:58 GMT+01:00 wm4 :
> > >
> > >> Well, don't worry too much. People li
On Wed, 29 Nov 2017 10:23:54 -0500
Compn wrote:
> On Wed, 29 Nov 2017 15:58:29 +0100, wm4 wrote:
>
> > On Tue, 28 Nov 2017 16:09:57 +
> > "Mironov, Mikhail" wrote:
> > >
> > > I wanted to stay out of license issues and this forum is
On Wed, 29 Nov 2017 16:07:36 +0100
Carl Eugen Hoyos wrote:
> 2017-11-29 15:58 GMT+01:00 wm4 :
>
> > Well, don't worry too much. People like him are, as some would say,
> > toxic members of the community. Frequent drama and flame wars happen.
> > (And here's whe
On Wed, 29 Nov 2017 15:13:01 +
"Mironov, Mikhail" wrote:
> >
> > > +{ AV_PIX_FMT_D3D11, AMF_SURFACE_NV12 },
> >
> > Wut, really? It's not a typo? It looks tricky.
> >
> > I assume AMF has D3D11 input, but then it'd still need to exclude P010.
> > I don't think this is ever don
webm usually has invisible superframes merged with normal frames.
(vpxenc muxes them in this form, which is evidence enough that this is
the standard webm packet format. It's rather unclear whether ffmpeg is
even allowed to remux them with split packets.)
The vp9 decoder needs them to be in separa
On Tue, 28 Nov 2017 16:09:57 +
"Mironov, Mikhail" wrote:
> >
> > Pavel Koshevoy (2017-11-27):
> > > That is unnecessarily un-diplomatic and will likely offend the
> > > contributors from nvidia and amd.
> >
> > Well, I find offensive that they benefit from my work yet make extra efforts
On Mon, 27 Nov 2017 02:15:12 +
"Mironov, Mikhail" wrote:
> Hi,
> I would like to summarize thoughts on several threads on this forum related
> to the issue of including AMD/AMF header file into FFmpeg source tree.
> It looks like they reflect some policies formal or informal.
> Mark tried t
On Tue, 28 Nov 2017 00:43:25 +
Mark Thompson wrote:
> ...
>
> Ok; done, plus some trivial testing to make sure it works. If you're happy
> with this and noone else says anything then I'll push it tomorrow.
>
> Relatedly: your name on patches does not match your full name - I've
> preserv
On Mon, 27 Nov 2017 20:46:00 -0800
Philip Langdale wrote:
> If hardware acceleration is implemented through an HWAccel, then it's
> easy to recognise, but some hardware implementations are best suited
> to implementation as full decoders, and these are not easy to identify.
> Clients typically ne
On Tue, 17 Oct 2017 20:23:25 +0200
Thilo Borgmann wrote:
> Am 17.10.17 um 06:49 schrieb wm4:
> > I have realized that your veto is actually not valid:
> > - it's a Libav merge
> > - it has been for months in the Libav repo and you didn't specifically
> >
On Tue, 17 Oct 2017 19:20:50 +0200
Jorge Ramirez-Ortiz wrote:
> A user can close the codec while keeping references to some of the
> capture buffers. When the codec is closed, the structure that keeps
> the contexts, state and the driver file descriptor is freed.
>
> Since access to some of the
Correction: will push as part of cuvid/videotoolbox patches whenever
they're ready.
On Tue, 17 Oct 2017 00:58:58 +0200
Michael Niedermayer wrote:
> > It doesn't - not the user's. We use only the field for internal
> > purposes (as AVFrame users), and we never do anything with the user's
> > valu
Tue, 17 Oct 2017 00:58:58 +0200
Michael Niedermayer wrote:
> On Mon, Oct 16, 2017 at 09:40:26AM +0200, wm4 wrote:
> > On Sat, 14 Oct 2017 23:01:41 +0200
> > Michael Niedermayer wrote:
> >
> > > On Fri, Oct 13, 2017 at 09:19:04PM +0200, wm4 wrote:
> &g
On Mon, 16 Oct 2017 16:24:56 +0100
Rostislav Pehlivanov wrote:
> On 16 October 2017 at 16:14, wm4 wrote:
>
> > On Mon, 16 Oct 2017 16:02:19 +0100
> > Rostislav Pehlivanov wrote:
> >
> > > Signed-off-by: Rostislav Pehlivanov
> &
On Mon, 16 Oct 2017 12:27:17 -0300
James Almer wrote:
> On 10/16/2017 12:02 PM, Rostislav Pehlivanov wrote:
> > Signed-off-by: Rostislav Pehlivanov
> > ---
> > libavutil/frame.c | 16 ++--
> > libavutil/frame.h | 13 +
> > 2 files changed, 19 insertions(+), 10 deletions(
On Mon, 16 Oct 2017 16:02:19 +0100
Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov
> ---
> libavutil/frame.c | 16 ++--
> libavutil/frame.h | 13 +
> 2 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/libavutil/frame.c b/libavutil/fram
On Mon, 16 Oct 2017 20:32:03 +0800
Xiaolei Yu wrote:
> On 10/16/2017 07:36 PM, wm4 wrote:
> > On Mon, 16 Oct 2017 19:28:27 +0800
> > Xiaolei Yu wrote:
> >
> >> On 10/03/2017 09:15 PM, wm4 wrote:
> >>> From: Anton Khirnov
> >>>
>
On Mon, 16 Oct 2017 19:28:27 +0800
Xiaolei Yu wrote:
> On 10/03/2017 09:15 PM, wm4 wrote:
> > From: Anton Khirnov
> >
> > Use the AVFrame.opaque_ref field. The original user's opaque_ref is
> > wrapped in the lavc struct and then unwrapped before the fra
On Sat, 14 Oct 2017 23:01:41 +0200
Michael Niedermayer wrote:
> On Fri, Oct 13, 2017 at 09:19:04PM +0200, wm4 wrote:
> > On Fri, 13 Oct 2017 19:41:28 +0200
> > Michael Niedermayer wrote:
> >
> > > On Fri, Oct 06, 2017 at 01:48:14AM +0200, wm4 wrote:
>
On Fri, 13 Oct 2017 19:41:28 +0200
Michael Niedermayer wrote:
> On Fri, Oct 06, 2017 at 01:48:14AM +0200, wm4 wrote:
> > On Fri, 6 Oct 2017 00:01:30 +0200
> > Michael Niedermayer wrote:
> >
> > > The opaque_ref wraping is a really bad design. Iam not s
On Fri, 13 Oct 2017 20:03:12 +0200
Michael Niedermayer wrote:
> I dont really know and as a maintainer of some of this code, i dont
> really want to have to keep track of how exactly AVFrames can pass
> through the code.
You have to do that anyway.
> And as the one taking care of a lot of secur
From: Anton Khirnov
This will be useful in the CUVID hwaccel. It should also eventually
replace current decoder-specific mechanisms used by various other
hwaccels.
Merges Libav commit 704311b2946d74a80f65906961cd9baaa18683a3.
---
libavcodec/decode.c | 3 +++
libavcodec/decode.h | 6 ++
2 fi
From: Anton Khirnov
This will be useful in the CUVID hwaccel.
Merges Libav commit badf0951f54c1332e77455dc40398f3512540c1b.
---
libavcodec/decode.c | 11 +++
libavcodec/decode.h | 15 +++
2 files changed, 26 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode
From: Anton Khirnov
If the get_buffer() call fails, the frame might have some side data
already set. Make sure it gets freed.
CC: libav-sta...@libav.org
Merges Libav commit de77671438c24ffea93398c8dc885d4dd04477de.
---
libavcodec/decode.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
From: Anton Khirnov
Use the AVFrame.opaque_ref field. The original user's opaque_ref is
wrapped in the lavc struct and then unwrapped before the frame is
returned to the caller.
This new struct will be useful in the following commits.
Merges Libav commit 359a8a3e2d1194b52b6c386f94fd0929567dfb67
In the is_mjpeg case, the user's get_buffer2 callback is not called,
thus completely breaking the API.
---
libavcodec/avrndec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/avrndec.c b/libavcodec/avrndec.c
index c37f99661b..104ff2d904 100644
--- a/libavcodec/avrndec.c
+++ b/libavc
m for performing delayed processing on the
decoded frames
decode: add a per-frame private data for hwaccel use
wm4 (1):
lavc/avrndec: remove AV_CODEC_CAP_DR1, as it's broken
libavcodec/avrndec.c | 1 -
libavcodec/decode.c
On Fri, 13 Oct 2017 16:30:59 +0200
Hendrik Leppkes wrote:
> On Fri, Oct 13, 2017 at 4:14 PM, James Almer wrote:
> > On 10/12/2017 6:30 PM, James Almer wrote:
> >> Should prevent some options from being added to cflags when they
> >> don't exist and the compiler only warns about it.
> >>
> >> S
On Fri, 13 Oct 2017 16:46:31 +0200
Daniel Kučera wrote:
> bump.
LGTM too. The maintainer is relatively inactive, and it's a small fix
that doesn't even require the maintainer's approval, so I pushed the
patch.
___
ffmpeg-devel mailing list
ffmpeg-devel
On Thu, 12 Oct 2017 14:28:01 -0400
"Helmut K. C. Tessarek" wrote:
> I'm rather busy, and creating my compile script is an ongoing process
> which I have been maintaining for the last 6 years.
Probably better not to use bleeding edge git master, then.
On Thu, 12 Oct 2017 16:16:31 +0200
Nicolas George wrote:
> Le quintidi 15 vendémiaire, an CCXXVI, Daniel Kučera a écrit :
> > I'm not sure if you mean this patch is unacceptable but if so, I want
> > to note, that this patch is not the same as I submitted before: this
> > one adds cmdlne option t
On Thu, 12 Oct 2017 01:28:01 +0200
Michael Niedermayer wrote:
> On Tue, Oct 10, 2017 at 10:26:13PM +0200, Thomas Mundt wrote:
> > 2017-10-10 19:36 GMT+02:00 Sasi Inguva :
> >
> > > This is required for FLV files, for which duration_pts comes out to be
> > > zero.
> > >
> > > Signed-off-by: Sas
On Wed, 11 Oct 2017 14:58:22 +0800
Jun Zhao wrote:
>
Most of this seems to be copy&pasted from the vaapi deint filter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Tue, 10 Oct 2017 10:36:58 -0700
Sasi Inguva wrote:
> This is required for FLV files, for which duration_pts comes out to be zero.
>
> Signed-off-by: Sasi Inguva
> ---
> fftools/ffmpeg.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fft
On Tue, 10 Oct 2017 13:25:53 -0300
James Almer wrote:
> On 10/10/2017 1:01 PM, wm4 wrote:
> > On Tue, 10 Oct 2017 12:45:59 -0300
> > James Almer wrote:
> >
> >> On 10/9/2017 8:17 AM, wm4 wrote:
> >>> On Sun, 8 Oct 2017 13:53:13 +0200
> >>
On Tue, 10 Oct 2017 12:45:59 -0300
James Almer wrote:
> On 10/9/2017 8:17 AM, wm4 wrote:
> > On Sun, 8 Oct 2017 13:53:13 +0200
> > Michael Niedermayer wrote:
> >
> >> On Sat, Oct 07, 2017 at 12:06:23AM +0200, wm4 wrote:
> >>> On Fri, 6 Oct 201
On Tue, 10 Oct 2017 03:24:56 +0300
Ivan Kalvachev wrote:
> On 10/9/17, wm4 wrote:
> > On Mon, 9 Oct 2017 03:04:53 +0300
> > Ivan Kalvachev wrote:
> >
> >> The public functions av_alloc_vdpaucontext() and
> >> av_vdpau_alloc_context() are allocatin
On Mon, 9 Oct 2017 12:40:41 +0100
Mark Thompson wrote:
> On 09/10/17 08:49, Jun Zhao wrote:
> > V3: Remove hwaccel_lax_profile_check opt, and add new pre-stream
> > hwaccel_flags option
> >
>
> > From 2b1585fd6e6e68c81761ace0a8503385067086e0 Mon Sep 17 00:00:00 2001
> > From: Jun Zhao
> > Da
On Mon, 9 Oct 2017 03:04:53 +0300
Ivan Kalvachev wrote:
> The public functions av_alloc_vdpaucontext() and
> av_vdpau_alloc_context() are allocating AVVDPAUContext
> structure that is supposed to be placed in avctx->hwaccel_context.
>
> However the rest of libavcodec/vdpau.c uses avctx->hwaccel_
On Sun, 8 Oct 2017 17:16:21 -0300
James Almer wrote:
> Remove the SDL_main define from the global cflags but not from the
> ffplay cflags, and the -mwindows linker option from extralibs instead
> of overriding it with the addition of -mconsole.
>
> Signed-off-by: James Almer
> ---
> configure
On Sun, 8 Oct 2017 21:01:34 +0100
Mark Thompson wrote:
> Incorporating all review comments from last time:
> * Change all CBS users to hold a pointer rather than the whole structure.
> * Rearrange the MPEG-2 framerate stuff so that it doesn't add code and then
> remove it in the series.
> * Add
On Sun, 8 Oct 2017 17:13:24 +0100
Derek Buitenhuis wrote:
> On 10/8/2017 5:11 PM, Mark Thompson wrote:
> > This is just how hardware surfaces are stored in AVFrames - they have their
> > own API-specific handles in the data[] pointers because that's the only
> > place to put them.
> >
> > See
On Sun, 8 Oct 2017 13:53:13 +0200
Michael Niedermayer wrote:
> On Sat, Oct 07, 2017 at 12:06:23AM +0200, wm4 wrote:
> > On Fri, 6 Oct 2017 16:53:17 +0200
> > Michael Niedermayer wrote:
> >
> > > Hi all
> > >
> > > if there are no objec
On Sun, 8 Oct 2017 16:49:58 +0100
Mark Thompson wrote:
> This has been deprecated in libva2 because hardware does not and will not
> support it. Therefore never consider it for decode, and for encode assume
> the user meant constrained baseline profile instead.
> ---
> On 08/10/17 16:44, Derek B
On Fri, 6 Oct 2017 18:02:44 -0300
James Almer wrote:
> On 10/6/2017 5:44 PM, Paul B Mahol wrote:
> > On 10/6/17, Michael Niedermayer wrote:
> >> On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
> >>> Hi,
> >>>
> >>> On Thu, Oct 5, 2017 at 7:52 PM, Michael Niedermayer
> >>>
On Fri, 6 Oct 2017 16:53:17 +0200
Michael Niedermayer wrote:
> Hi all
>
> if there are no objections i will branch release/3.4 in the next days
> and make the 3.4 release a few days after that
>
> If people prefer a specific name, suggest one now, otherwise i will
> pick a random one from past
On Fri, 6 Oct 2017 00:19:33 +0200
Hendrik Leppkes wrote:
> On Thu, Oct 5, 2017 at 10:21 PM, Carl Eugen Hoyos wrote:
> > 2017-10-05 16:32 GMT+02:00 Moritz Barsnick :
> >
> >> Issue: The hls demuxer now inconsistently no longer reports
> >> each opened URL, only the first one. (Reporting of thes
On Fri, 6 Oct 2017 00:01:30 +0200
Michael Niedermayer wrote:
> The opaque_ref wraping is a really bad design. Iam not sure why
> people defend it.
FFmpeg is full of this design. There are plenty of structs with
opaque/priv fields that change meaning depending on the context
(basically how the st
501 - 600 of 3095 matches
Mail list logo
