On Thu, 13 Aug 2020, Nicolas Sugino wrote:
In listener mode the first fd is not closed when libsrt_close() is called
because it is overwritten by the new accept fd.
Added the listen_fd to the context to properly close it when libsrt_close() is
called.
This fixes trac ticket #8372, right? A
Hi James,
thanks for your feedback, please help review it again.
Changelist for v3:
use av_fifo_* instead of homebrewed fifo operations
obu_probe(), add padding obu to alllow list
read_header(), use "const AVRational* framerate" instead of "AVRational
framerate"
It's defined in Section
In listener mode the first fd is not closed when libsrt_close() is called
because it is overwritten by the new accept fd.
Added the listen_fd to the context to properly close it when libsrt_close() is
called.
Signed-off-by: Nicolas Sugino
---
libavformat/libsrt.c | 8 +++-
1 file changed,
> On Aug 13, 2020, at 11:57 AM, leozhang wrote:
>
> Signed-off-by: leozhang
> ---
> libavutil/video_enc_params.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/video_enc_params.h b/libavutil/video_enc_params.h
> index 43fa443..e3b422d 100644
> --- a/libavuti
The channel layouts accepted by ff_merge_channel_layouts() are of two
types: Ordinary channel layouts and generic channel layouts. These are
layouts that match all layouts with a certain number of channels.
Therefore parsing these channel layouts is not done in one go; instead
first the intersectio
From bbcf114eea30368b6b97a3ef1b0c68cd75fb5a5c Mon Sep 17 00:00:00 2001
From: Alex Pokotilo
Date: Wed, 12 Aug 2020 23:56:46 +1000
Subject: [PATCH] fix memory leak in qsvenc.c
"ff_qsv_enc_close" function called at the end of qsv encoding session and it frees q->async_fifo content content. "bs" ite
On 8/12/2020 9:53 PM, Xu, Guangxin wrote:
>
> Hi James,
> Thanks for the review.
> Comment in line.
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of James
>> Almer
>> Sent: Wednesday, August 12, 2020 9:06 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH
Hi James,
Thanks for the review.
Comment in line.
> -Original Message-
> From: ffmpeg-devel On Behalf Of James
> Almer
> Sent: Wednesday, August 12, 2020 9:06 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V2 2/3] avormat/av1dec: add low-
> overhead bitstream form
---
libavcodec/h264_metadata_bsf.c | 348 ++---
1 file changed, 191 insertions(+), 157 deletions(-)
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index e59b5b8369..d69713cbab 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h2
---
libavcodec/h264_metadata_bsf.c | 91 --
1 file changed, 43 insertions(+), 48 deletions(-)
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index eb1503159b..e59b5b8369 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264
On 12/08/2020 02:55, Andreas Rheinhardt wrote:
First of all: I only looked at the sei_user_data stuff yet.
Mark Thompson:
---
libavcodec/h264_metadata_bsf.c | 443 ++---
1 file changed, 242 insertions(+), 201 deletions(-)
diff --git a/libavcodec/h264_metadata_bsf
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Steve Lhomme
> Sent: Wednesday, August 12, 2020 2:05 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer
> copies are done before submitting them
>
> On 2020-08-11 12:43, Stev
While having the possibility of non-NOPTS values that can suddenly
jump in time due to adjustments to match PCR is not nice for DVB
subtitles, apparently the parser for this format bases its behavior on
whether the packets' timestamps are NOPTS or not. Thus while we can
adjust timestamps, we should
Since this was originally written H.265 has changed to allow arbitrary
values here, but leaves their meaning unspecified.
---
On 12/08/2020 00:03, Andreas Rheinhardt wrote:
> Obviously, the code for reading/writing the mastering display colour
> volume SEI needs to be updated, too.
Yeah. I don't
This is as far as 22.2 follows the same channel order as
WaveFormatExtensible's channel mask (and the AV_CH_* defines).
After LFE2 the side channels would follow, but that offset of
one stops us from utilizing them without further tweaks.
This change was verified by using swresample to downmix to
Alexander Strasser (12020-08-12):
> Stupid question: Why do we transform relative URLs at all?
>
> Isn't it normally supposed to work for HTTP on the server-side too?
>
> Many clients seem to do it. Just curious why...
At the very least, we need to be able to combine:
http://site.com/contents/t
---
On 12/08/2020 00:03, Andreas Rheinhardt wrote:
> ...
Yep, all changed as you suggest.
libavcodec/Makefile | 2 +-
libavcodec/cbs_h265.c | 95 +++
libavcodec/cbs_h265.h | 18
3 files changed, 114 insertions(+), 1 deletion(-)
create mode 10
On Wed, Aug 12, 2020 at 6:40 PM Mohammad Izadi wrote:
> Vittorio,
>
> What is the next step for me?
>
> Thanks,
> Mohammad
>
Hi, I don't have any more comments for the patch, except that it would be
nice if there were some kind of fate testing.
See for example cf1cae58b015427918ecfa507a045aae4cf
On 11/08/2020 21:13, Andreas Rheinhardt wrote:
Mark Thompson:
---
libavcodec/cbs_h264.h | 24
libavcodec/cbs_h2645.c| 1 +
libavcodec/cbs_h264_syntax_template.c | 40 +++
3 files changed, 65 insertions(+)
diff --git
When one merges two AVFilterChannelLayouts structs, there is no need to
allocate a new one. Instead one can reuse one of the two given ones.
If one does this, one also doesn't need to update the references of the
AVFilterChannelLayouts that is reused. Therefore this commit reuses the
structure with
On 2020-08-09 14:56 +0200, Michael Niedermayer wrote:
> On Sun, Aug 09, 2020 at 02:24:34PM +0200, Alexander Strasser wrote:
> >
> >
> > Am 9. August 2020 12:56:53 MESZ schrieb Michael Niedermayer
> > :
> > >On Fri, Aug 07, 2020 at 11:26:58PM +0200, Alexander Strasser wrote:
> > >> Don't pass a pot
HEVC NALs are no longer being skipped based on their nuh_layer_id
value since ad326379c6.
Signed-off-by: James Almer
---
libavcodec/h2645_parse.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 2e03871640..a7cd
No point in trying to parse nonexistent header bits.
Signed-off-by: James Almer
---
Will fix indentation before pushing. But the diff was smaller like this.
libavcodec/h2645_parse.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/h2645_parse.c b/libavc
This will prevent reporting a bogus value in the log message when
the header parsing fails.
Signed-off-by: James Almer
---
libavcodec/h2645_parse.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 5708fe56f9..162272a6de 100644
--- a
Hi all!
On 2020-08-12 14:53 +, Nicolas George wrote:
> ffmpeg | branch: master | Nicolas George | Thu Jul 30
> 00:02:10 2020 +0200| [1201687da268c11459891a80ca1972aeaca8db88] | committer:
> Nicolas George
>
> lavf/url: rewrite ff_make_absolute_url() using ff_url_decompose().
>
> Also add an
Andreas Rheinhardt (12020-08-12):
> My intention was to eventually reuse the whole AVFilterFormats with the
> smaller nb_formats; only the refs need to be reallocated and only the
> refs from the other AVFilterFormats will need to be added and updated
> (the ones from the AVFilterFormats that is re
Preserve the original workings, that does not use frames timestamps
and therefore is very fragile.
Allow to remove needs_fifo.
Signed-off-by: Nicolas George
---
libavfilter/vaf_spectrumsynth.c | 69 -
1 file changed, 34 insertions(+), 35 deletions(-)
Tested wit
Filters can use min_samples/max_samples if the number is constant
or activate and ff_inlink_consume_samples().
Signed-off-by: Nicolas George
---
libavfilter/avfilter.h | 8
libavfilter/fifo.c | 99 ++
2 files changed, 3 insertions(+), 104 deletio
It is not relevant when using activate and framesync.
Signed-off-by: Nicolas George
---
libavfilter/vf_overlay_qsv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavfilter/vf_overlay_qsv.c b/libavfilter/vf_overlay_qsv.c
index 2a4dc5cb58..11f5fc2242 100644
--- a/libavfilter/vf_overlay_q
Signed-off-by: Nicolas George
---
libavfilter/avfilter.h | 3 +--
libavfilter/avfiltergraph.c | 40 -
libavfilter/internal.h | 8
3 files changed, 1 insertion(+), 50 deletions(-)
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
Vittorio,
What is the next step for me?
Thanks,
Mohammad
On Fri, Aug 7, 2020 at 9:51 AM Mohammad Izadi wrote:
> Any more comments? Are you OK to merge?
> Thanks,
> Mohammad
>
>
> On Thu, Jul 30, 2020 at 9:06 AM Vittorio Giovara <
> vittorio.giov...@gmail.com> wrote:
>
>> On Mon, Jul 27, 2020
On Tue, 11 Aug 2020 23:38:21 +0530
Anamitra Ghorui wrote:
> This patch adds support for non animated, animated, non interlaced and
> interlaced FLIF images.
> Hopefully, all previously mentioned mistakes have been resolved.
> However, there are a few things I want to ask:
>
> * The decoder can a
On 2020-08-09 14:54 +0200, Michael Niedermayer wrote:
> On Fri, Aug 07, 2020 at 11:26:17PM +0200, Alexander Strasser wrote:
> > Snow uses the ratecontrol module, but does not expose a way to set
> > the rc_eq expression. The default expression, set in the ratecontrol
> > module, will always be used
On 2020-07-31 09:45 +0800, myp...@gmail.com wrote:
> On Fri, Jul 31, 2020 at 3:47 AM Alexander Strasser wrote:
> >
> > On 2020-07-30 21:18 +0800, myp...@gmail.com wrote:
> > >
> > > After repeated thinking， I can accept this solution, thx
> >
> > Just to avoid confusion. You accept this
> >
> > >
Marton Balint (12020-08-10):
> Add to commit message that this fixes tickets 8813, 8814.
Done.
> You can move these after the use_base_path section but before the empty path
> check which also sets simplify_path.
Done.
> Add TODO that this can be removed after all callers check return value
We
Nicolas George:
> Andreas Rheinhardt (12020-08-11):
>> Do you remember
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/267549.html? If I
>> were allowed to reorder a and b so that a->nb <= b->nb, one would not
>> have to allocate a new list to return at all: One could reuse a and
>> would
tis 2020-08-11 klockan 15:15 +0200 skrev Tomas Härdin:
> tor 2020-08-06 klockan 15:27 +0100 skrev Harry Mallon:
> > I attach a patch to apply the colour metadata that was read in my
> > previous commit during mxf encoding. ffmpeg previously wrote the
> > transfer characteristic only, and not for al
On 8/10/2020 6:34 AM, Xu Guangxin wrote:
> It's defined in Section 5.2, used by netflix.
> see http://download.opencontent.netflix.com/?prefix=AV1/Chimera/
> ---
> configure| 1 +
> libavformat/allformats.c | 1 +
> libavformat/av1dec.c | 266 +++
ons 2020-08-12 klockan 13:43 +0100 skrev Harry Mallon:
> @@ -2492,6 +2504,18 @@ static int mxf_parse_structural_metadata(MXFContext
> *mxf)
> }
> if (descriptor->aspect_ratio.num && descriptor->aspect_ratio.den)
> st->display_aspect_ratio = descriptor->as
Andreas Rheinhardt (12020-08-08):
> I was thinking about this part of the MERGE_FORMATS macro:
>
> for (i = 0; i < a->nb; i++)
> for (j = 0; j < b->nb; j++)
> if (a->fmts[i] == b->fmts[j]) {
> if(k >= FFMIN(a->nb, b->nb)){
>
I'm very sorry for the noise, I just thought of a way that the last patch could
be troublesome. Fixed here.
From 31ce817887ec84907b3aadb5dc1657b01b8d0dbd Mon Sep 17 00:00:00 2001
From: Harry Mallon
Date: Wed, 12 Aug 2020 10:26:23 +0100
Subject: [PATCH v3] avformat/mxfdec: Read video range from
On 2020-08-12 12:32 +0200, Jean-Baptiste Kempf wrote:
> On Wed, 12 Aug 2020, at 00:29, Alexander Strasser wrote:
> > Definitions of non-obvious data should have a short comment
> > explaining their origin.
> >
> > If the data is of mathematical origin, you can document that
> > or u
Yes it definitely could be true, however it's not.
If you rename the file it opens just fine in media player, as well as
ffmpeg has no trouble copying streams out of the data files.
On Wed., Aug. 12, 2020, 8:34 a.m. Ronald S. Bultje,
wrote:
> Hi,
>
> On Tue, Aug 11, 2020 at 4:57 PM Nathanael Ne
Hi,
On Tue, Aug 11, 2020 at 4:57 PM Nathanael Newton wrote:
> This is a video from a genie wireless security camera.
> They claimed it was encrypted, in fact this was a lie, it's just obfuscated
> by being renamed to .data
Both could be true at the same time. It could be both renamed as well a
Rebased the patch on master (it didn't build before) and fixed FATE.
From ac8d7884b036b504d07f38815de1c163c5e1691e Mon Sep 17 00:00:00 2001
From: Harry Mallon
Date: Wed, 12 Aug 2020 10:26:23 +0100
Subject: [PATCH v2] avformat/mxfdec: Read video range from PictureDescriptor
* Capture black_ref,
On 2020-08-11 12:43, Steve Lhomme wrote:
Sorry if you seem to know all the answers already, but I don't and so
I have to
investigate.
Last year, I had literally worked this down to death. I followed every
slightest
hint from countless searches, read through hundreds of discussions,
driven
be
Andreas Rheinhardt (12020-08-11):
> Do you remember
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/267549.html? If I
> were allowed to reorder a and b so that a->nb <= b->nb, one would not
> have to allocate a new list to return at all: One could reuse a and
> would only have to reallocate
On Wed, 12 Aug 2020 at 00:00, Michal Rybarik wrote:
> Hello,
>
> I am using ffmpeg to transcode video in live stream - both input and
> output are MPEG-TS multicasts (single program transport stream). Input
> MPEG-TS contains EIT (EPG) and I want to copy it to the output.
>
> Current ffmpeg treat
Ashutosh Pradhan (12020-08-12):
> Generate algorithmic music using riffs, lindenmayer systems, cellular
> automaton and rythm algorithms.
Please document what use this algorithmic music is: is it nice to listen
to? Or something else?
Regards,
--
Nicolas George
signature.asc
Description: P
Generate algorithmic music using riffs, lindenmayer systems, cellular automaton
and rythm algorithms.
Changelog|1 +
configure|4 +
doc/filters.texi | 141 +
libavfilter/Makefile |1 +
libavfilter/allfilters.c |1 +
libavfilter/as
On Wed, 12 Aug 2020, at 00:29, Alexander Strasser wrote:
> Definitions of non-obvious data should have a short comment
> explaining their origin.
>
> If the data is of mathematical origin, you can document that
> or use code snippets or pseudo-code. If the data was gained
> emp
On Tue, Aug 11, 2020 at 11:54:41AM +0200, Paul B Mahol wrote:
> On 7/29/20, Paul B Mahol wrote:
> > On 7/28/20, Nicolas George wrote:
> >> Paul B Mahol (12020-07-28):
> >>> >> Please add an example that produces high quality output.
> >>> >> Iam asking so the filter can be tested in relation to t
Thanks to Tomas for reviewing these MXF patches. Here is another. FFMPEG
already writes out the three range tags. This just reads them in.
Best,
Harry
From c49f77d1e887d8c84752df11213dcf5afa8f761e Mon Sep 17 00:00:00 2001
From: Harry Mallon
Date: Wed, 12 Aug 2020 10:26:23 +0100
Subject: [PATCH
53 matches
Mail list logo
