On Mon, 5 Feb 2018 23:49:30 +0700
Muhammad Faiz wrote:
> On Sat, Feb 3, 2018 at 2:44 AM, Josh de Kock wrote:
> > This fixes the fate-fifo-muxer test.
> > ---
> > libavformat/Makefile | 2 +-
> > libavformat/allformats.c | 1 +
> > libavformat/fifo_test.c| 150
> > ++
On Mon, 5 Feb 2018 03:42:48 +0100
Carl Eugen Hoyos wrote:
> 2018-02-04 15:24 GMT+01:00 wm4 :
> > On Thu, 25 Jan 2018 19:00:43 +0100
> > wm4 wrote:
> >
> >> The names inherently clash with the meanings of the HTTP libavformat
> >> protocol options. Re
On Sun, 4 Feb 2018 22:29:10 +0100
Nicolas George wrote:
> Josh de Kock (2018-02-04):
> > If we were to add in APIs which allowed you to register external components
> > again, this idea wouldn't work well as indexes wouldn't necessarily
> > correspond
> > to the component which it previously did
On Thu, 25 Jan 2018 19:00:43 +0100
wm4 wrote:
> The names inherently clash with the meanings of the HTTP libavformat
> protocol options. Rename them after a deprecation period to make them
> compatible with the HTTP ones.
> ---
> I see no better way that wouldn't requ
On Tue, 30 Jan 2018 13:43:25 +0100
wm4 wrote:
> The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
> sequences with 0xFF. This has to be done on every byte of the source
> data, while the current code skipped a byte after a replacement. This
> meant
On Fri, 2 Feb 2018 19:44:18 +
Josh de Kock wrote:
> ---
> fftools/cmdutils.c | 2 +-
> libavcodec/avcodec.h | 6 +-
> libavcodec/bitstream_filter.c | 4 ++--
> libavcodec/bitstream_filters.c | 29 ++---
> 4 files changed, 26 insertions(+
On Sat, 3 Feb 2018 03:29:40 +0100
Michael Niedermayer wrote:
> On Sat, Feb 03, 2018 at 01:36:37AM +0700, Muhammad Faiz wrote:
> > They don't modify AVCodec, no needs to call it at register. They will be
> > wasteful if these codecs are unused. Instead, call static data
> > initialization
> > at
On Fri, 2 Feb 2018 12:59:45 -0800
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> If a subdemuxer has the updated metadata event flag set, the metadata is
> copied
> to the corresponding stream. The flag is cleared on the subdemuxer and the
> appropriate event flag is set on the stream.
On Sat, 3 Feb 2018 01:36:37 +0700
Muhammad Faiz wrote:
> They don't modify AVCodec, no needs to call it at register. They will be
> wasteful if these codecs are unused. Instead, call static data initialization
> at codecs' init.
>
> Benchmark:
> old: 51281340 decicycles in avcodec_register_all,
On Fri, 2 Feb 2018 21:50:00 +0800 (CST)
qw wrote:
> Hi,
>
>
> I use the following command to build ffmpeg:
>
>
> ./configure --cc=/opt/intel/bin/icc --enable-version3 --enable-asm
> --enable-avfilter --disable-static --enable-shared --enable-gpl
> --enable-nonfree --prefix=/usr/local/ --ext
On Thu, 1 Feb 2018 23:50:02 -0800
Richard Shaffer wrote:
> On Thu, Feb 1, 2018 at 10:18 PM, wm4 wrote:
> > On Thu, 1 Feb 2018 18:44:34 -0800
> > rshaf...@tunein.com wrote:
> >
> >> From: Richard Shaffer
> >>
> >> If a subdemuxer has the
On Fri, 2 Feb 2018 00:06:47 -0800
Richard Shaffer wrote:
> On Thu, Feb 1, 2018 at 10:02 PM, wm4 wrote:
> > On Thu, 1 Feb 2018 18:37:45 -0800
> > rshaf...@tunein.com wrote:
> >
> >> From: Richard Shaffer
> >>
> >> While rare, ID3 tags
On Thu, 1 Feb 2018 18:44:34 -0800
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> If a subdemuxer has the updated metadata event flag set, the metadata is
> copied
> to the corresponding stream. The flag is cleared on the subdemuxer and the
> appropriate event flag is set on the stream.
On Thu, 1 Feb 2018 18:37:45 -0800
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> While rare, ID3 tags may be inserted between ADTS frames. This change enables
> parsing them and setting the appropriate metadata updated event flag.
> ---
> I have encountered a streaming provider that I m
On Thu, 1 Feb 2018 07:48:27 +0100
Marcin Woźniak wrote:
> Hello,
> I try to implement an HiSilicon H264 encoder direct input as ffmpeg
> libavdevice source (someking like V4L linux for cameras with H264 source
> driver).
> I successfully recieve H264 packets with NAL units and set correct PTS
On Thu, 1 Feb 2018 02:06:52 +0100
Michael Niedermayer wrote:
> On Wed, Jan 31, 2018 at 12:24:43PM +0100, wm4 wrote:
> > On Wed, 31 Jan 2018 12:11:25 +0100
> > Michael Niedermayer wrote:
> >
> > > On Wed, Jan 31, 2018 at 10:03:58AM +0100, wm4 wrote:
> &
On Wed, 31 Jan 2018 11:52:14 +
Mark Thompson wrote:
> >> On the other side, you get rid of a field in AVFilter and avoid having to
> >> put some pointless boilerplate in a lot of places.
> >
> > The other solution is to initialize next pointer on
> > avfilter_register_all() as before, ad
On Wed, 31 Jan 2018 12:11:25 +0100
Michael Niedermayer wrote:
> On Wed, Jan 31, 2018 at 10:03:58AM +0100, wm4 wrote:
> > On Wed, 31 Jan 2018 09:08:23 +0100
> > Tobias Rapp wrote:
> >
> > > On 30.01.2018 20:37, Michael Niedermayer wrote:
> > > >
On Wed, 31 Jan 2018 11:34:27 +0100
Michael Niedermayer wrote:
> On Tue, Jan 30, 2018 at 01:43:25PM +0100, wm4 wrote:
> > The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
> > sequences with 0xFF. This has to be done on every byte of the source
> &g
On Wed, 31 Jan 2018 09:08:23 +0100
Tobias Rapp wrote:
> On 30.01.2018 20:37, Michael Niedermayer wrote:
> > On Tue, Jan 30, 2018 at 08:27:27PM +0700, Muhammad Faiz wrote:
> >> On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
> >> wrote:
> >>> Its also a step away from supporting plugins.
On Tue, 30 Jan 2018 11:30:43 -0300
James Almer wrote:
> On 1/30/2018 2:45 AM, wm4 wrote:
> > On Tue, 30 Jan 2018 02:24:29 +0100
> > Michael Niedermayer wrote:
> >
> >> On Mon, Jan 29, 2018 at 03:13:54PM -0800, Dale Curtis wrote:
> >>> Otherw
On Tue, 30 Jan 2018 14:09:43 +
Mark Thompson wrote:
> On 30/01/18 07:24, Muhammad Faiz wrote:
> > Move REGISTER_FILTER to FILTER_TABLE in configure.
> > Auto generate filter extern and filter table.
> > Sort filter table, use bsearch on avfilter_get_by_name.
> > Define next pointer at filter
On Tue, 30 Jan 2018 20:16:50 +0700
Muhammad Faiz wrote:
> On Tue, Jan 30, 2018 at 2:58 PM, wm4 wrote:
> > On Tue, 30 Jan 2018 14:24:12 +0700
> > Muhammad Faiz wrote:
> >
> >> Move REGISTER_FILTER to FILTER_TABLE in configure.
> >> Auto generate fi
On Tue, 30 Jan 2018 13:50:37 +0100
Michael Niedermayer wrote:
> On Tue, Jan 30, 2018 at 02:24:12PM +0700, Muhammad Faiz wrote:
> > Move REGISTER_FILTER to FILTER_TABLE in configure.
> > Auto generate filter extern and filter table.
> > Sort filter table, use bsearch on avfilter_get_by_name.
> > D
On Tue, 30 Jan 2018 13:43:25 +0100
wm4 wrote:
> The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
> sequences with 0xFF. This has to be done on every byte of the source
> data, while the current code skipped a byte after a replacement. This
> meant
The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
sequences with 0xFF. This has to be done on every byte of the source
data, while the current code skipped a byte after a replacement. This
meant 0xFF 0x00 0xFF 00 was translated to 0xFF 0xFF 0x00 instead of 0xFF
0xFF. It feels a
On Tue, 30 Jan 2018 11:05:29 +
Ricardo Constantino wrote:
> ---
> src/template_head2 | 23 ---
> 1 file changed, 23 deletions(-)
>
> diff --git a/src/template_head2 b/src/template_head2
> index 71daf07..a0b11ab 100644
> --- a/src/template_head2
> +++ b/src/template_head2
On Tue, 30 Jan 2018 14:24:12 +0700
Muhammad Faiz wrote:
> Move REGISTER_FILTER to FILTER_TABLE in configure.
> Auto generate filter extern and filter table.
> Sort filter table, use bsearch on avfilter_get_by_name.
> Define next pointer at filter extern, no need to initialize
> next pointer at ru
On Tue, 30 Jan 2018 02:24:29 +0100
Michael Niedermayer wrote:
> On Mon, Jan 29, 2018 at 03:13:54PM -0800, Dale Curtis wrote:
> > Otherwise the decoder will throw "Missing header" errors when the
> > packets are sent for decoding.
>
> > mpegaudio_parser.c |7 +++
> > 1 file changed, 7
On Sun, 28 Jan 2018 10:11:20 +0100
Paul B Mahol wrote:
> On 1/28/18, James Almer wrote:
> > On 1/27/2018 10:50 PM, Michael Niedermayer wrote:
> >> Regression since: c6939f65a116b1ffed345d29d8621ee4ffb32235
> >> Found-by: Paul B Mahol
> >> Signed-off-by: Michael Niedermayer
> >> ---
> >> lib
On Sun, 28 Jan 2018 00:01:14 +0100
Karsten Otto wrote:
> read_packet reads content in chunks. Thus seek must be clamped to valid
> chunk positions in the file, which in turn are relative to chapter start
> positions.
>
> So in read_header, scan for chapter headers once by skipping through the
>
On Sat, 27 Jan 2018 18:07:53 +0100 (CET)
Marton Balint wrote:
> On Sat, 27 Jan 2018, wm4 wrote:
>
> >> Docs in avformat.h only says that AV_DISPOSITION_ATTACHED_PIC "usually"
> >> contains one packet.
> >
> > It also implies AVStream.attached
On Fri, 26 Jan 2018 11:11:46 +0800
刘歧 wrote:
> > On 24 Jan 2018, at 15:08, wm4 wrote:
> >
> > AVERROR_EXIT happens when the user's interrupt callback signals that
> > playback should be aborted. In this case, the demuxer shouldn't print a
> > warning, as
On Fri, 26 Jan 2018 23:26:20 -0300
James Almer wrote:
> On 1/26/2018 11:23 PM, wm4 wrote:
> > On Sat, 27 Jan 2018 02:25:49 +0100
> > Michael Niedermayer wrote:
> >
> >> On Fri, Jan 26, 2018 at 12:52:19AM +0100, wm4 wrote:
> >>> On Fri, 26 Jan
On Sat, 27 Jan 2018 02:25:49 +0100
Michael Niedermayer wrote:
> On Fri, Jan 26, 2018 at 12:52:19AM +0100, wm4 wrote:
> > On Fri, 26 Jan 2018 00:21:14 +0100
> > Carl Eugen Hoyos wrote:
> >
> > > 2018-01-26 0:00 GMT+01:00 Hendrik Leppkes :
> > > > On
On Sat, 27 Jan 2018 01:44:04 +0100 (CET)
Marton Balint wrote:
> On Sat, 27 Jan 2018, wm4 wrote:
>
> > The AV_DISPOSITION_ATTACHED_PIC flag is meant only for exporting a
> > static picture (such as embedded cover art) as pseudo video track. The
> > requirement is that t
The AV_DISPOSITION_ATTACHED_PIC flag is meant only for exporting a
static picture (such as embedded cover art) as pseudo video track. The
requirement is that there is exactly 1 packet, and that normal demuxing
does not return it (otherwise avformat_queue_attached_pictures() would
add it a second ti
On Thu, 25 Jan 2018 19:00:43 +0100
wm4 wrote:
> The names inherently clash with the meanings of the HTTP libavformat
> protocol options. Rename them after a deprecation period to make them
> compatible with the HTTP ones.
> ---
> I see no better way that wouldn't requ
On Fri, 26 Jan 2018 00:56:16 +0100
Carl Eugen Hoyos wrote:
> 2018-01-26 0:52 GMT+01:00 wm4 :
> > (and I already wrote that on IRC too, where he lurks as
> > michaelni)
>
> Could one of the native speakers please try to convince
> me that this is not a disparaging te
On Fri, 26 Jan 2018 00:21:14 +0100
Carl Eugen Hoyos wrote:
> 2018-01-26 0:00 GMT+01:00 Hendrik Leppkes :
> > On Thu, Jan 25, 2018 at 11:35 PM, Carl Eugen Hoyos
> > wrote:
> >>> and in particular stop outright harassing me into leaving.
> >>
> >> Yes, I would very much prefer if I could stop
On Thu, 25 Jan 2018 23:08:21 +0100
Carl Eugen Hoyos wrote:
> 2018-01-25 23:04 GMT+01:00 wm4 :
> > On Thu, 25 Jan 2018 22:41:48 +0100
> > Carl Eugen Hoyos wrote:
> >
> >> 2018-01-25 21:54 GMT+01:00 wm4 :
> >>
> >> > Clearly you&#
On Thu, 25 Jan 2018 22:41:48 +0100
Carl Eugen Hoyos wrote:
> 2018-01-25 21:54 GMT+01:00 wm4 :
>
> > Clearly you're trying to bikeshed me here. I'll just ignore this
> > instead of wasting my time on you.
>
> Is there really no hope that you go away for good
On Thu, 25 Jan 2018 21:17:54 +0100
Michael Niedermayer wrote:
> On Thu, Jan 25, 2018 at 08:54:51PM +0100, wm4 wrote:
> > On Thu, 25 Jan 2018 20:46:13 +0100
> > Michael Niedermayer wrote:
> >
> > > On Thu, Jan 25, 2018 at 07:00:43PM +0100, wm4 wrote:
> >
On Thu, 25 Jan 2018 20:46:13 +0100
Michael Niedermayer wrote:
> On Thu, Jan 25, 2018 at 07:00:43PM +0100, wm4 wrote:
> > The names inherently clash with the meanings of the HTTP libavformat
> > protocol options. Rename them after a deprecation period to make them
> > com
On Thu, 25 Jan 2018 15:12:27 -0300
James Almer wrote:
> On 1/25/2018 3:00 PM, wm4 wrote:
> > The names inherently clash with the meanings of the HTTP libavformat
> > protocol options. Rename them after a deprecation period to make them
> > compatible with the HTTP ones.
The names inherently clash with the meanings of the HTTP libavformat
protocol options. Rename them after a deprecation period to make them
compatible with the HTTP ones.
---
I see no better way that wouldn't require more effort than justified.
The incompatible semantics of the "timeout" option whil
On Wed, 24 Jan 2018 23:42:44 -0300
James Almer wrote:
> On 1/24/2018 11:03 PM, Michael Niedermayer wrote:
> > On Wed, Jan 24, 2018 at 12:47:18AM -0300, James Almer wrote:
> >> On 1/24/2018 12:34 AM, Michael Niedermayer wrote:
> >>> Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
>
On Thu, 25 Jan 2018 03:26:51 +0100
Michael Niedermayer wrote:
> On Wed, Jan 24, 2018 at 04:42:38AM +0100, wm4 wrote:
> > On Wed, 24 Jan 2018 04:34:49 +0100
> > Michael Niedermayer wrote:
> >
> > > Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
>
The seek function can just return an error if seeking is unavailable,
but often this is too late. Add a flag that signals that the stream is
unseekable, and use it in HLS.
---
Basically, this is equivalent to being a live stream. In theory, EVENT
playlists can be live streams, but they have full re
AVERROR_EXIT happens when the user's interrupt callback signals that
playback should be aborted. In this case, the demuxer shouldn't print a
warning, as it's expected that all network accesses are stopped.
---
libavformat/hls.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
This makes little sense due to how HLS works, and only causes some
additional annoyances if the HLS read_seek function fails (for example
if it's a live stream). It was most likely unintended.
---
I guess in theory, this might allow skipping forward a bit, but let's be
honest, API users are better
On Wed, 24 Jan 2018 04:34:49 +0100
Michael Niedermayer wrote:
> Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
> Fixes: runtime error: shift exponent 126 is too large for 32-bit type 'int'
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/pro
On Tue, 23 Jan 2018 09:39:53 -0800
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> Enables getting access to ID3 PRIV tags from the command-line or metadata API
> when demuxing. The PRIV owner is stored as the metadata key prepended with
> "id3v2_priv.", and the data is stored as the meta
On Tue, 23 Jan 2018 17:03:26 -0800
Richard Shaffer wrote:
> On Tue, Jan 23, 2018 at 2:32 PM, wm4 wrote:
>
> >
> > I think this test program is pretty nice, though usually we try to get
> > by with running the "ffmpeg" utility to test the libs. Having a
>
On Tue, 23 Jan 2018 09:54:38 -0800
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> Adds basic unit tests for parsing and writing ID3v2 tags.
> ---
> This requires the patch to "add option to parse/store ID3 PRIV tags in
> metadata."
>
> libavformat/Makefile | 3 +-
> libavform
On Mon, 22 Jan 2018 15:48:07 -0800
Richard Shaffer wrote:
> On Mon, Jan 22, 2018 at 3:18 PM, wm4 wrote:
>
> > On Wed, 17 Jan 2018 16:34:39 -0800
> > rshaf...@tunein.com wrote:
> >
> > > From: Richard Shaffer
> > >
> > > Enables getti
On Wed, 17 Jan 2018 16:34:39 -0800
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> Enables getting access to ID3 PRIV tags from the command-line or metadata API
> when demuxing. The PRIV owner is stored as the metadata key prepended with
> "id3v2_priv.", and the data is stored as the meta
On Mon, 22 Jan 2018 09:58:56 +0100
Hendrik Leppkes wrote:
> On Mon, Jan 22, 2018 at 8:55 AM, Jun Zhao wrote:
> > Hi, all:
> >
> > When I read the code about av_init_packet(), I found we use
> > av_init_packet() in most cases like this:
> >
> > av_init_packet(&enc_pkt);
> > enc_pkt.data =
On Sun, 21 Jan 2018 10:24:21 +0700
Muhammad Faiz wrote:
> > I don't trust the atomics use
> > either, I'm don't want to have to debug that ever.
>
> Of course, using atomics is more complicated that using mutex (with
> benefits that it will be faster wh
On Sun, 21 Jan 2018 00:52:18 +
Mark Thompson wrote:
> ---
> struct timeval elements are not big enough in a 32-bit ABI.
>
>
> libavcodec/v4l2_buffers.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> index
On Sun, 21 Jan 2018 03:33:08 +0100
Michael Niedermayer wrote:
> also a memcmp on the data might be worth looking into to avoid re-parsing of
> unchanged PS
> (theres already a memcmp in libavcodec/h264_ps.c)
That sounds like it'd help much more than a buffer pool.
Anyway, did anyone run benchma
On Sat, 20 Jan 2018 18:12:52 -0300
James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/mediacodecdec.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 6c5d3ddd79..b360e7a7f1 100644
> --- a/libavcodec/medi
On Fri, 19 Jan 2018 20:30:59 -0300
James Almer wrote:
> On 1/19/2018 5:06 PM, wm4 wrote:
> > On Fri, 19 Jan 2018 16:51:45 -0300
> > James Almer wrote:
> >
> >> Attempting full frame reconstruction is unnecessary for containers
> >> like Matroska, so ju
On Sat, 20 Jan 2018 11:29:13 +0700
Muhammad Faiz wrote:
> Help avoiding malloc-free cycles when allocating-freeing common
> structures.
>
> Signed-off-by: Muhammad Faiz
> ---
> libavutil/staticpool.h | 117
> +
> 1 file changed, 117 insertions(+
On Sat, 20 Jan 2018 12:52:46 +0700
Muhammad Faiz wrote:
> On Sat, Jan 20, 2018 at 11:49 AM, James Almer wrote:
> > On 1/20/2018 1:29 AM, Muhammad Faiz wrote:
> >> Help avoiding malloc-free cycles when allocating-freeing common
> >> structures.
> >>
> >> Signed-off-by: Muhammad Faiz
> >> ---
>
On Fri, 19 Jan 2018 16:51:45 -0300
James Almer wrote:
> Attempting full frame reconstruction is unnecessary for containers
> like Matroska, so just skip it altogether.
>
> Signed-off-by: James Almer
> ---
> libavcodec/mlp_parser.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/l
On Thu, 18 Jan 2018 16:30:22 +0100
Carl Eugen Hoyos wrote:
> 2018-01-18 16:27 GMT+01:00 Nicolas George :
> > Carl Eugen Hoyos (2018-01-18):
> >> Could you please tell us which cases get broken?
> >
> > I cannot.
>
> Ok.
>
> So we both agree that FFmpeg should get rid of
> Vincent as fast
The intention is to:
1. let API users know whether a HLS stream is live
2. let API users know about the safe seek range
This is supposed to avoid Bad things happening when seeking outside of
range.
There are lots of problems with this patch:
- the API consists of adding yet another set of obscure
On Thu, 18 Jan 2018 15:54:46 +0100
Nicolas George wrote:
> Dave Rice (2018-01-18):
> > Not sure if I understand well the disadvantage of this patch.
>
> When dealing with Unix signals, "not sure if I understand" means
> "don't".
Well, he's asking you why.
If you refuse to explain, I don't th
On Wed, 17 Jan 2018 11:10:26 -0800
Richard Shaffer wrote:
> [...]
> I'm also not sure if an option for compatibility is needed. It's
> > probably fine to prefix the name with something (maybe "id3v2_priv."?),
> > and always export it.
> >
>
> I guess my thought was that users of ffmpeg/ffprobe
On Fri, 12 Jan 2018 13:13:05 -0800
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> Enables getting access to ID3 PRIV tags from the command-line or metadata API
> when demuxing. The PRIV owner is stored as the metadata key, and the data is
> stored as the metadata value. As PRIV tags may
On Tue, 16 Jan 2018 17:47:14 +0100
Steve Lhomme wrote:
> Le 16/01/2018 à 17:42, wm4 a écrit :
> > On Tue, 16 Jan 2018 14:08:37 +0100
> > wm4 wrote:
> >
> >> D3D11 has rather fine grained per texture format capabilities for
> >> different uses that ca
On Tue, 16 Jan 2018 14:08:37 +0100
wm4 wrote:
> D3D11 has rather fine grained per texture format capabilities for
> different uses that can be queried at runtime. Since we don't know at
> the time av_hwdevice_get_hwframe_constraints() is called what the user
> wants to do wit
D3D11 has rather fine grained per texture format capabilities for
different uses that can be queried at runtime. Since we don't know at
the time av_hwdevice_get_hwframe_constraints() is called what the user
wants to do with this, we simply return all formats that have the most
basic support.
---
l
On Thu, 4 Jan 2018 17:02:41 +0100
wm4 wrote:
> It was sort of optional before - if you didn't call it, networking was
> initialized on demand, and an ugly warning was logged. Also, the doxygen
> comments threatened that it would be made strictly required one day.
>
>
On Mon, 15 Jan 2018 11:29:20 -0300
James Almer wrote:
> On 1/15/2018 9:11 AM, wm4 wrote:
> > ---
> > doc/APIchanges | 4
> > libavformat/avformat.h | 2 ++
> > libavformat/utils.c| 8
> > libavformat/version.h | 5 -
> >
---
doc/APIchanges | 4
libavformat/avformat.h | 2 ++
libavformat/utils.c| 8
libavformat/version.h | 5 -
4 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index d66c842521..0184815224 100644
--- a/doc/APIchanges
+++ b/d
On Thu, 4 Jan 2018 17:02:41 +0100
wm4 wrote:
> It was sort of optional before - if you didn't call it, networking was
> initialized on demand, and an ugly warning was logged. Also, the doxygen
> comments threatened that it would be made strictly required one day.
>
>
On Thu, 11 Jan 2018 02:31:14 +0100
wm4 wrote:
> The condition was a bit too long, and most editors will break the line
> and turn it into an unreadable mess. Move out some of the conditions.
>
> This should not change the behavior.
> ---
> libavformat/http.c | 12 +---
On Mon, 15 Jan 2018 11:34:30 +
Mark Thompson wrote:
> On 15/01/18 11:22, wm4 wrote:
> > On Mon, 15 Jan 2018 11:17:39 +
> > Mark Thompson wrote:
> >
> >> On 13/01/18 06:06, wm4 wrote:
> >>> In addition, this does not allow creating frames
On Mon, 15 Jan 2018 11:17:39 +
Mark Thompson wrote:
> On 13/01/18 06:06, wm4 wrote:
> > In addition, this does not allow creating frames contexts with sw_format
> > for which no known transfer formats exist. In theory, we should check
> > whether the chroma format (i
In addition, this does not allow creating frames contexts with sw_format
for which no known transfer formats exist. In theory, we should check
whether the chroma format (i.e. the sw_format) is supported at all by
the vdpau driver, but checking for transfer formats has the same effect.
Note that th
On Sat, 13 Jan 2018 03:47:31 +0100
Carl Eugen Hoyos wrote:
> 2018-01-13 3:19 GMT+01:00 wm4 :
> > On Sat, 13 Jan 2018 02:46:51 +0100
> > Carl Eugen Hoyos wrote:
> >
> >> Hi!
> >>
> >> Seeing 6e80079a it appears that the unstable period is
On Sat, 13 Jan 2018 02:46:51 +0100
Carl Eugen Hoyos wrote:
> Hi!
>
> Seeing 6e80079a it appears that the unstable period is not over yet.
> Vittorio posted a patch that introduces a temporary type to avoid
> breaking API, but that may not be relevant if the api currently
> unstable.
>
> Attache
On Fri, 12 Jan 2018 03:06:29 +0100
Michael Niedermayer wrote:
> On Thu, Jan 11, 2018 at 09:17:06PM +0100, Thilo Borgmann wrote:
> > Am 11.01.18 um 19:45 schrieb Michael Niedermayer:
> > > On Thu, Jan 11, 2018 at 02:43:01PM -0200, Pedro Arthur wrote:
> > >> Hi,
> > >>
> > >> What about a Super
On Thu, 11 Jan 2018 05:34:07 +
"Li, Zhong" wrote:
> > > IIUC, This commit was merged from Libav, checking the commit log of
> > cf7d3846fc865df47bd64f7d4d10bbedf9e3a17b:
> >
> > Yeah, but...
> >
> > > Merge commit '9de9b828ef005dec37052548c195a6b4f18fc701'
> > >
> > > * commit '
On Thu, 11 Jan 2018 02:01:38 +
"Li, Zhong" wrote:
> IIUC, This commit was merged from Libav, checking the commit log of
> cf7d3846fc865df47bd64f7d4d10bbedf9e3a17b:
Yeah, but...
> Merge commit '9de9b828ef005dec37052548c195a6b4f18fc701'
>
> * commit '9de9b828ef005dec37052548c195a6b4
The condition was a bit too long, and most editors will break the line
and turn it into an unreadable mess. Move out some of the conditions.
This should not change the behavior.
---
libavformat/http.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libavformat/htt
On Thu, 11 Jan 2018 09:11:08 +0800
Jun Zhao wrote:
> On 2018/1/11 8:45, wm4 wrote:
> > On Tue, 2 Jan 2018 13:59:12 +0800
> > Jun Zhao wrote:
> >
> >> From e030510864c28d4b17c8d1eb09ab00f274bf5dcc Mon Sep 17 00:00:00 2001
> >> From: Jun Zhao
&g
On Thu, 11 Jan 2018 01:46:56 +0100
Michael Niedermayer wrote:
> On Wed, Jan 10, 2018 at 10:26:58AM +0530, Gyan Doshi wrote:
> >
> >
> > On 1/4/2018 5:25 PM, Gyan Doshi wrote:
> > >
> > >On 12/29/2017 8:38 AM, Michael Niedermayer wrote:
> > >>On Thu, Dec 28, 2017 at 12:50:00PM -0900, Lou Log
On Tue, 2 Jan 2018 13:59:12 +0800
Jun Zhao wrote:
> From e030510864c28d4b17c8d1eb09ab00f274bf5dcc Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Tue, 2 Jan 2018 13:55:29 +0800
> Subject: [PATCH] doc/codecs: Add missing documentation for hwaccel_flags.
>
> document the hwaccel_flags option fo
On Wed, 10 Jan 2018 16:39:16 +0800
Zhong Li wrote:
> It was just useful for deprecated API (avcodec_decode_video2),
> but useless for new decode APIs (avcodec_send_packet/avcodec_receive_frame).
>
> Signed-off-by: Zhong Li
> ---
> doc/examples/qsvdec.c | 1 -
> 1 file changed, 1 deletion(-)
>
On Tue, 9 Jan 2018 09:15:39 +0100
Martin Herkt wrote:
> This reportedly fixes hangs with segmented streams.
> Affects playback via Schannel on Windows in particular.
>
> Can be reproduced with any YouTube live stream.
> ---
> libavformat/avio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 delet
On Tue, 9 Jan 2018 18:06:11 +0100
Jorge Ramirez-Ortiz wrote:
> From: Mark Thompson
>
> Refcount all of the context information. This also fixes a potential
> segmentation fault when accessing freed memory (buffer returned after
> the codec has been closed).
>
> Tested-by: Jorge Ramirez-Ortiz
On Tue, 09 Jan 2018 00:03:15 +
Lukas Rusak wrote:
> I'm not really sure what to do then.
>
> Should I just replace time_base with pkt_timebase instead?
>
> Or
>
> Should I just remove the time base rescaling completely in v4l2_set_pts and
> v4l2_get_pts as it seems to be 1:1 anyways.
The
On Mon, 8 Jan 2018 15:27:38 -0800
Lukas Rusak wrote:
> we check for a valid pts in v4l2_set_pts so we should do the same here
>
> ---
> libavcodec/v4l2_buffers.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
On Mon, 8 Jan 2018 15:27:39 -0800
Lukas Rusak wrote:
> This default time base should be set in order for ffmpeg to rescale the
> timebase in v4l2_get_pts and v4l2_set_pts
>
> ---
> libavcodec/v4l2_m2m_dec.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/v4l2_m2m_dec.c
On Sat, 6 Jan 2018 08:46:26 +
"LongChair ." wrote:
> Here are two updated patches.
>
> I have added the current version check to 1.3.7 and removed the header
> check for control operation.
Pushed the 2 patches.
___
ffmpeg-devel mailing list
ffmpe
On Thu, 4 Jan 2018 17:02:41 +0100
wm4 wrote:
> It was sort of optional before - if you didn't call it, networking was
> initialized on demand, and an ugly warning was logged. Also, the doxygen
> comments threatened that it would be made strictly required one day.
>
>
On Fri, 5 Jan 2018 19:22:00 +
"LongChair ." wrote:
> Yes the newly used control operation seems to have always been there
> anyways, so there shouldn't be much compatibility issues.
I mean the second patch removes a workaround for some old misbehavior,
right? So it should probably be made
301 - 400 of 3095 matches
Mail list logo
