It's been a wrapper for a simple av_bsf_free() call since c96904f525.
Signed-off-by: James Almer
---
libavcodec/decode.c | 7 +--
libavcodec/decode.h | 2 --
libavcodec/utils.c | 4 ++--
3 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/libavcodec/decode.c
On Tue, May 19, 2020 at 7:10 PM Andreas Rheinhardt
wrote:
>
> ff_id3v2_free_extra_meta() takes a ID3V2ExtraMeta ** so that it can
> already reset the pointer.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/hls.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
May 19, 2020, 20:50 by s...@jkqxz.net:
> On 13/05/2020 16:53, Lynne wrote:
>
>> This, along with the next patch, are the last missing pieces to being
>> interoperable with libplacebo.
>> There is no danger of users running into this API break because there are
>> none,
>> and API was completely
On Tue, May 19, 2020 at 2:33 AM Marton Balint wrote:
>
>
>
> On Mon, 18 May 2020, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2020-05-16 15:52:22)
> >> Hi,
> >>
> >> As you may know, a recent patchset enabled AVCodecContext->profile
> >> constants to reside in encoders.
> >>
> >> In order
May 19, 2020, 20:57 by s...@jkqxz.net:
> On 13/05/2020 16:53, Lynne wrote:
>
>> With this, the puzze of making libplacebo, ffmpeg and any other Vulkan
>> API users interoperable is complete.
>> Users of both libraries can initialize one another's contexts without having
>> to create a new one.
May 19, 2020, 19:02 by c...@passwd.hu:
>
>
> On Tue, 19 May 2020, Lynne wrote:
>
>> May 19, 2020, 09:23 by e...@fastwebnet.it:
>>
>>> Hi Marton,
>>>
>>> Thanks very much for the feedback; below answers to your points - let me
>>> know further feedback if any.
>>>
And sorry, I cannot say how
On Tue, May 19, 2020 at 09:06:59PM +0200, Marton Balint wrote:
> pos47_full is not updated for every packet, and for unseekable inputs the
> resync logic might simply skip some 0x47 sync bytes. In order to detect these
> let's check for modulo instead of exact value.
Before modifying and
On 5/19/2020 6:40 PM, Derek Buitenhuis wrote:
> On 19/05/2020 22:03, James Almer wrote:
>> When pic->reordered_opaque is 0 (default value) x265pic.userData will
>> remain NULL. This in turn means x265pic_out.userData will also be NULL
>> and avctx->reordered_opaque will be set to 0, so it's
On Tue, May 19, 2020 at 11:19:03AM -0300, James Almer wrote:
> On 5/19/2020 11:12 AM, Michael Niedermayer wrote:
> > On Mon, May 18, 2020 at 11:45:21AM +0200, Anton Khirnov wrote:
> >> ---
> >> libavformat/Makefile | 1 +
> >> tests/Makefile| 1 +
> >>
On 5/19/2020 5:53 PM, Hendrik Leppkes wrote:
> On Tue, May 19, 2020 at 10:45 PM Derek Buitenhuis
> wrote:
>>
>> On 19/05/2020 19:55, James Almer wrote:
>>> +if (pic->reordered_opaque) {
>>
>> If this is meant to be PTS, won't this break on PTS==0?
>>
>
> Well, it won't break anything,
On Tue, May 19, 2020 at 10:45 PM Derek Buitenhuis
wrote:
>
> On 19/05/2020 19:55, James Almer wrote:
> > +if (pic->reordered_opaque) {
>
> If this is meant to be PTS, won't this break on PTS==0?
>
Well, it won't break anything, since if its not set on the frame,
it'll be set to zero
On 19/05/2020 22:03, James Almer wrote:
> When pic->reordered_opaque is 0 (default value) x265pic.userData will
> remain NULL. This in turn means x265pic_out.userData will also be NULL
> and avctx->reordered_opaque will be set to 0, so it's functionally the
> expected behavior.
> This is done to
On Tue, 19 May 2020, James Almer wrote:
On 5/19/2020 5:57 PM, Martin Storsjö wrote:
Some encoders don't provide split out extradata directly on init (or
at all). In particular, the MediaFoundation encoder wrapper doesn't
always (depending on the actual encoder device) - this is the case for
On 5/19/2020 5:57 PM, Martin Storsjö wrote:
> Some encoders don't provide split out extradata directly on init (or
> at all). In particular, the MediaFoundation encoder wrapper doesn't
> always (depending on the actual encoder device) - this is the case for
> Qualcomm's HEVC encoder on SD835, and
Some encoders don't provide split out extradata directly on init (or
at all). In particular, the MediaFoundation encoder wrapper doesn't
always (depending on the actual encoder device) - this is the case for
Qualcomm's HEVC encoder on SD835, and also on some QSV H264 encoders).
This only works
On Tue, 19 May 2020, Lynne wrote:
May 19, 2020, 11:25 by e...@fastwebnet.it:
I wouldn't be surprised if the xlib code has some PTS issues and schedules
downloading a frame late.
I'm far from being an expert, but I would be surprised if that had issues
considering it's the main Linux
On 5/19/2020 5:18 PM, Derek Buitenhuis wrote:
> On 19/05/2020 19:55, James Almer wrote:
>> +if (pic->reordered_opaque) {
>
> If this is meant to be PTS, won't this break on PTS==0?
>
> - Derek
When pic->reordered_opaque is 0 (default value) x265pic.userData will
remain NULL. This in
On 19/05/2020 19:55, James Almer wrote:
> +if (pic->reordered_opaque) {
If this is meant to be PTS, won't this break on PTS==0?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
On 13/05/2020 16:53, Lynne wrote:
> This, along with the next patch, are the last missing pieces to being
> interoperable with libplacebo.
> There is no danger of users running into this API break because there are
> none,
> and API was completely backwards-incompatibly changed just 2 days ago.
On 13/05/2020 16:53, Lynne wrote:
> With this, the puzze of making libplacebo, ffmpeg and any other Vulkan
> API users interoperable is complete.
> Users of both libraries can initialize one another's contexts without having
> to create a new one.
> > From 28264793295b0d7861527f40fa7c7041a3b34907
On Mon, 18 May 2020, Aman Gupta wrote:
On Fri, May 15, 2020 at 12:04 AM Martin Storsjö wrote:
On Tue, 12 May 2020, Martin Storsjö wrote:
> From: wm4
>
> This contains encoder wrappers for H264, HEVC, AAC, AC3 and MP3.
>
> This is based on top of an original patch by wm4
> . The original
Marton Balint (12020-05-19):
> As Nicolas mentioned, kmsgrab practically requires root. Also, I tried it on
> Intel half a year ago on Ubuntu 18.04, and it simply does not work
> correctly. There were crashes, there were random failures with cryptic error
> messages, usually at the beginning of
pos47_full is not updated for every packet, and for unseekable inputs the
resync logic might simply skip some 0x47 sync bytes. In order to detect these
let's check for modulo instead of exact value.
Also skip unrecognized sync byte distances instead of considering them as a
failure of detection.
Signed-off-by: James Almer
---
libavcodec/libx265.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 573ecc8cb0..821175c1b6 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -504,6 +504,16 @@
2020.05.19. 17:27 keltezéssel, Zhong Li írta:
Tomas Härdin 于2020年5月19日周二 下午10:25写道：
fre 2020-05-15 klockan 10:14 +0800 skrev Tao Zhang:
Marton Balint 于2020年5月15日周五 上午2:33写道：
On Thu, 14 May 2020, Tao Zhang wrote:
Hi,
FFmpeg supports multiple outputs created out of the same input in the
On Sun, 17 May 2020, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/mpegts.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 0833d62..4bca339 100644
--- a/libavformat/mpegts.c
+++
On Tue, 19 May 2020, lance.lmw...@gmail.com wrote:
On Sun, May 17, 2020 at 02:41:18PM +0200, Marton Balint wrote:
On Sun, 17 May 2020, lance.lmw...@gmail.com wrote:
> On Sat, May 16, 2020 at 07:36:45PM +0200, Marton Balint wrote:
> >
> >
> > On Sat, 16 May 2020, lance.lmw...@gmail.com
May 19, 2020, 13:09 by geo...@nsup.org:
> Nicolas George (12020-05-19):
>
>> The doc says:
>>
>> Requires either DRM master or CAP_SYS_ADMIN to run.
>>
>> Does it work for a normal user on a desktop distribution freshly
>> installed, without configuration?
>>
>> (I should test, but all my boxes
On Tue, 19 May 2020, Lynne wrote:
May 19, 2020, 09:23 by e...@fastwebnet.it:
Hi Marton,
Thanks very much for the feedback; below answers to your points - let me know
further feedback if any.
And sorry, I cannot say how useful this would be, maybe now is the time
for people to speak up
May 19, 2020, 11:25 by e...@fastwebnet.it:
> Hi Lynne,
>
> Thanks for the feedback.
> Some more discussion points below.
>
>> There already is a zero-overhead capture on linux - kmsgrab. It works on AMD
>> and Intel.
>>
>
> Does it work on Nvidia too? Does it have smooth capture?
> Does it work
lance.lmw...@gmail.com (12020-05-19):
> Thanks for sharing the background, now the document isn't very clear how to
> use the option, after checking, nobody use it, so I think it's better to
> claim it as bool. I can take a look how to convert graph to dot format if
> nobody
> will support it.
Tomas Härdin 于2020年5月19日周二 下午10:25写道：
>
> fre 2020-05-15 klockan 10:14 +0800 skrev Tao Zhang:
> > Marton Balint 于2020年5月15日周五 上午2:33写道：
> > >
> > >
> > > On Thu, 14 May 2020, Tao Zhang wrote:
> > >
> > > > Hi,
> > > > FFmpeg supports multiple outputs created out of the same input in the
> > > >
On Tue, May 19, 2020 at 05:02:42PM +0200, Nicolas George wrote:
> Nicolas George (12020-05-19):
> > Originally, the second parameter to avfilter_graph_dump() was supposed
> > to be dump options. None was ever added, and I later came to realize
> > that using a string for that was more of the same
May 19, 2020, 11:40 by geo...@nsup.org:
> This is me NAKing your NAK.
>
You're not allowed to remove NAKs of other developers.
Feel free to disagree of course.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Nicolas George (12020-05-19):
> Originally, the second parameter to avfilter_graph_dump() was supposed
> to be dump options. None was ever added, and I later came to realize
> that using a string for that was more of the same bad idea.
>
> I have no objection to making this bit obsolete, but
lance.lmw...@gmail.com (12020-05-19):
> From: Limin Wang
>
> dumpgraph option currently uses string types, but actually only requires bool
> type
Originally, the second parameter to avfilter_graph_dump() was supposed
to be dump options. None was ever added, and I later came to realize
that
From: Limin Wang
dumpgraph option currently uses string types, but actually only requires bool
type
Signed-off-by: Limin Wang
---
doc/indevs.texi | 2 +-
libavdevice/lavfi.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index
From: Limin Wang
It's useful for debugging filter graph purposes, now only lavfi can do that.
Reviewed-by: Carl Eugen Hoyos
Signed-off-by: Limin Wang
---
doc/ffmpeg.texi | 4
fftools/ffmpeg.h| 1 +
fftools/ffmpeg_filter.c | 7 +++
fftools/ffmpeg_opt.c| 3 +++
4
Lynne (12020-05-19):
> You underestimate how many library users use OpenGL.
Oh, I just noticed two seconds after sending: There is a big reasoning
mistake here.
I do not underestimate how many library users use OpenGL.
You overestimate how many library users use OpenGL and allow users to
use
Lynne (12020-05-19):
> New versions of libdrm can allow it to work without root. It needs
> modifications.
When these versions have landed in Debian Stable, we will see. In the
meantime, it is useful now.
> You underestimate how many library users use OpenGL.
> My NAK still stands, whether you
fre 2020-05-15 klockan 10:14 +0800 skrev Tao Zhang:
> Marton Balint 于2020年5月15日周五 上午2:33写道：
> >
> >
> > On Thu, 14 May 2020, Tao Zhang wrote:
> >
> > > Hi,
> > > FFmpeg supports multiple outputs created out of the same input in the
> > > same process like
> > > ffmpeg -i input -filter_complex
On 5/19/2020 11:12 AM, Michael Niedermayer wrote:
> On Mon, May 18, 2020 at 11:45:21AM +0200, Anton Khirnov wrote:
>> ---
>> libavformat/Makefile | 1 +
>> tests/Makefile| 1 +
>> tests/fate-run.sh | 7 +
>> tests/fate/h264.mak | 6 +-
>>
On Mon, May 18, 2020 at 11:45:21AM +0200, Anton Khirnov wrote:
> ---
> libavformat/Makefile | 1 +
> tests/Makefile| 1 +
> tests/fate-run.sh | 7 +
> tests/fate/h264.mak | 6 +-
> tests/fate/vpx.mak| 5 +
>
Michael Niedermayer wrote:
>Its quite a while since 4.2.2 so i intend to make 4.2.3 soon
>if you want something backported, backport it now
Good news, thank you!
Out of curiosity, are you also preparing the 4.3 major release?
Best regards, Reto
___
Manolis: drawtext's text expansion section [0] does not mention the special
variable %{frame_num} has 0 paddable. When I tested locally (on master), it is
not 0 padded.
Running through different scenario, I recommend the expanded file path to not
contain 0 padded frame number:- if automatic
May 19, 2020, 09:23 by e...@fastwebnet.it:
> Hi Marton,
>
> Thanks very much for the feedback; below answers to your points - let me know
> further feedback if any.
>
>> And sorry, I cannot say how useful this would be, maybe now is the time
>> for people to speak up if somebody is particularly
Nicolas George (12020-05-19):
> The doc says:
>
> Requires either DRM master or CAP_SYS_ADMIN to run.
>
> Does it work for a normal user on a desktop distribution freshly
> installed, without configuration?
>
> (I should test, but all my boxes are very far from the default
>
On Sat, 09 May 2020 14:00:04 +
"Zane van Iperen" wrote:
>
> single: Single-track
> track{0,1}: Dual-track
> trunc-t1: Truncated track 1
> trunc-t2-track{0,1}: Fully-truncated track 2
> trunc-t2a-track{0,1}: Partially-truncated track 2
> trunc-h2:
Lynne (12020-05-19):
> You're not allowed to remove NAKs of other developers.
Says who? “NAK”s have no value anyway.
> Feel free to disagree of course.
Feel free to provide the technical information useful to make the
discussion go forward:
# Does it work for a normal user on a desktop
Out of curiosity if I was proposing/using the native NVidia proprietary
library for screen capture (linked at runtime dynamically), would that
be more acceptable in terms of conflicts (I wouldn't like it because it
wouldn't support AMD/Intel based hardware)?
Are the headers for those
Up until now, the ID3v2ExtraMeta structure (which is used when parsing
ID3v2 tags containing attached pictures, chapters etc.) contained a
pointer to separately allocated data that depended on the type of the
tag. Yet the difference of the sizes of the largest and the smallest of
these structures
If the write_id3v2 option is set, the aiff muxer would write id3v2 tags
if there is global metadata or if there are attached pics to write.
Chapters are ignored in this check that precedes writing id3v2 tags.
Yet 47ac344970f1d6ef149c4b8a883b68cdb15112c2 added support for writing
chapters as id3v2
ff_id3v2_free_extra_meta() takes a ID3V2ExtraMeta ** so that it can
already reset the pointer.
Signed-off-by: Andreas Rheinhardt
---
libavformat/hls.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 89386ea1b7..3e35d157ad 100644
---
ff_id3v2_parse_apic/chapters/priv/priv_dict all had a parameter
extra_meta of type ID3v2ExtraMeta ** as if the functions wanted to make
*extra_meta point to something else. But they don't, so just use an
ID3v2ExtraMeta *.
Signed-off-by: Andreas Rheinhardt
---
libavformat/aacdec.c | 2 +-
A buffer whose size is not a multiple of four has been initialized using
consecutive writes of 32bits. This results in a stack-buffer-overflow
reported by ASAN in the checkasm-sw_scale FATE-test.
Signed-off-by: Andreas Rheinhardt
---
Instead of using FFALIGN one could also just remove the "- 1"
On Sat, 16 May 2020 11:53:27 +
"Zane van Iperen" wrote:
>
> Add support for encoding adpcm_ima_ssi and muxing to kvag.
>
Ping.
Zane
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
On Sun, May 17, 2020 at 02:41:18PM +0200, Marton Balint wrote:
>
>
> On Sun, 17 May 2020, lance.lmw...@gmail.com wrote:
>
> > On Sat, May 16, 2020 at 07:36:45PM +0200, Marton Balint wrote:
> > >
> > >
> > > On Sat, 16 May 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > On Sat, May 16, 2020
Lynne (12020-05-19):
> There already is a zero-overhead capture on linux - kmsgrab. It works
> on AMD and Intel.
The doc says:
Requires either DRM master or CAP_SYS_ADMIN to run.
Does it work for a normal user on a desktop distribution freshly
installed, without configuration?
(I
Hi Lynne,
Thanks for the feedback.
Some more discussion points below.
> There already is a zero-overhead capture on linux - kmsgrab. It works
on AMD and Intel.
Does it work on Nvidia too? Does it have smooth capture?
Does it work for 3d applications?
>> Wouldn't a hwaccel frame imply no
Hi David,
Not a full review, but a minor point that popped in mind.
It is common to pad serially numbered files with 0. E.g. if you have <1000
files, the 9th file will be named file009.txt.
Is this case handled by the expansion? Or is it assumed that the text file
numbers are not zero-padded?
Some flac muxers write truncated metadata picture size if the picture
data do not fit in 24 bits. Detect this by truncting the size found inside
the picture block and if it matches the block size use it and read rest
of picture data.
This workaround is only for flac files and not ogg files with
于2020年5月19日周二 上午2:56写道：
>
> From: Artem Galin
>
> Example: --init_hw_device d3d11va:,vendor=0x8086
>
> qsv_device option is still works and has higher priority over vendor
> option.
Would be nice if you can document it in ffmpeg.texi.
> Signed-off-by: Artem Galin ---
>
Hi Marton,
Thanks very much for the feedback; below answers to your points - let me
know further feedback if any.
> And sorry, I cannot say how useful this would be, maybe now is the time
> for people to speak up if somebody is particularly against adding this
> for any reason.
I haven't
于2020年5月19日周二 上午4:31写道：
>
> From: Artem Galin
>
> Adding DX11 relevant device type checks and adjusting callbacks with
> proper MediaSDK pair type support.
>
> Extending structure for proper MediaSDK pair type support.
>
> Signed-off-by: Artem Galin
> ---
> libavcodec/qsv.c | 53
于2020年5月19日周二 上午3:26写道：
>
> From: Artem Galin
>
> Signed-off-by: Artem Galin
> ---
> fftools/ffmpeg_opt.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 60bb437ea7..83f1b53e9d 100644
> --- a/fftools/ffmpeg_opt.c
it looks fine to me.
On 5/19/20, Mark Reid wrote:
> On Sun, May 10, 2020 at 12:40 AM Paul B Mahol wrote:
>
>> On 5/10/20, Mark Reid wrote:
>> > On Sat., May 9, 2020, 11:59 p.m. Paul B Mahol,
>> > wrote:
>> >
>> >> Do we support these float formats in swscale?
>> >> If not, than patch is IMHO
66 matches
Mail list logo
