This should make it easier to spot such cases.
---
fftools/ffmpeg.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 63c8771a01..70e7274d87 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3281,6 +3281,20 @@ static int
Additionally, reap the first rewards by being able to set the
color related encoding values based on the passed AVFrame.
---
fftools/ffmpeg.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index
Adds a wrapper function, which handles any errors depending on how
fatal a failure would be.
---
fftools/ffmpeg.c | 51
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 84306818a2..cb7644de6a
data manually.
With this patch set, since ffmpeg.c takes color related options as dictionary
keys, the AVFrame values will only be utilized if the user has not set the
option for a given stream. Thus, this use case still works.
Jan Ekström (4):
ffmpeg: deduplicate init_output_stream usage logic
On Sat, Jul 25, 2020 at 12:09 AM Mohammad Izadi
wrote:
>
> On Fri, Jul 24, 2020 at 9:30 AM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
> > Mohammad Izadi:
> > > From: Mohammad Izadi
> > >
> > > HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs
> > to be
On Tue, Sep 15, 2020 at 10:54 AM Michael Niedermayer
wrote:
>
> On Sun, Sep 13, 2020 at 01:26:22PM +0300, Jan Ekström wrote:
> > Additionally, reap the first rewards by being able to set the
> > color related encoding values based on the passed AVFrame.
> >
> > Th
On Tue, Sep 15, 2020 at 1:06 PM Jan Ekström wrote:
>
> On Tue, Sep 15, 2020 at 10:54 AM Michael Niedermayer
> wrote:
> >
> > On Sun, Sep 13, 2020 at 01:26:22PM +0300, Jan Ekström wrote:
> > > Additionally, reap the first rewards by being able to set the
> > &
On Tue, Sep 15, 2020 at 5:28 PM Jan Ekström wrote:
>
>
> Further looking into this, it seems to come from filtering (?) (diff attached)
>
> decoded AVFrame: 128x128, pix_fmt: rgba, range: pc
> while...
> AVFrame to be encoded: 128x128, pix_fmt: bgra, range: tv
>
> Jan
On Tue, Sep 15, 2020 at 7:39 PM James Almer wrote:
>
> On 9/15/2020 1:21 PM, Jan Ekström wrote:
> > On Tue, Sep 15, 2020 at 5:28 PM Jan Ekström wrote:
> >>
> >>
> >> Further looking into this, it seems to come from filtering (?) (diff
> >> attac
This value - while it looks like the actual range of the content -
is nothing but the internal value of swscale.
Thus, if we have RGB content, force the value to 1. Swscale will
ignore it, but at least the value of the output AVFrame will now
properly be "full range" instead of "limited range",
On Tue, Sep 15, 2020 at 9:12 PM Jan Ekström wrote:
>
> On Tue, Sep 15, 2020 at 7:39 PM James Almer wrote:
> >
> > On 9/15/2020 1:21 PM, Jan Ekström wrote:
> > > On Tue, Sep 15, 2020 at 5:28 PM Jan Ekström wrote:
> > >>
> > >>
> > >
On Wed, Sep 16, 2020 at 12:24 AM Michael Niedermayer
wrote:
>
> On Mon, Sep 14, 2020 at 12:33:14AM +0300, Jan Ekström wrote:
> > - For video, this means a single initialization point in do_video_out.
> > - For audio we unfortunately need to do it in two places just
> >
On Mon, Sep 14, 2020 at 12:31 AM Jan Ekström wrote:
>
Diff between v1 and v2 follows:
- Forgotten to be removed debug logs removed.
- Still log debug_ts even in case of nullptr AVFrame or AV_NOPTS_VALUE.
Decided against separating the logging because this way it's a
self-contained pack
On Mon, Sep 14, 2020 at 12:33 AM Jan Ekström wrote:
>
> - For video, this means a single initialization point in do_video_out.
> - For audio we unfortunately need to do it in two places just
> before the buffer sink is utilized (if av_buffersink_get_samples
> would still work a
- For video, this means a single initialization point in do_video_out.
- For audio we unfortunately need to do it in two places just
before the buffer sink is utilized (if av_buffersink_get_samples
would still work according to its specification after a call to
avfilter_graph_request_oldest
Adds a wrapper function, which handles any errors depending on how
fatal a failure would be.
---
fftools/ffmpeg.c | 51
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 84306818a2..cb7644de6a
for a given stream. Thus, this use case still works.
Jan Ekström (4):
ffmpeg: deduplicate init_output_stream usage logic
ffmpeg: move AVFrame time base adjustment into a function
ffmpeg: move A/V non-streamcopy initialization to a later point
ffmpeg: pass decoded or filtered AVFrame to output stream
This will have to be called later for video down the line.
---
fftools/ffmpeg.c | 77
1 file changed, 52 insertions(+), 25 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index cb7644de6a..7e6c0a962b 100644
--- a/fftools/ffmpeg.c
+++
Additionally, reap the first rewards by being able to set the
color related encoding values based on the passed AVFrame.
The only tests that seem to have changed their results with this
change seem to be the MXF tests. There, the muxer writes the
limited/full range flag to the output container if
- For video, this means a single initialization point in do_video_out.
- For audio we unfortunately need to do it in two places just
before the buffer sink is utilized (if av_buffersink_get_samples
would still work according to its specification after a call to
avfilter_graph_request_oldest
This will have to be called later for video down the line.
---
fftools/ffmpeg.c | 69 ++--
1 file changed, 44 insertions(+), 25 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index cb7644de6a..54802a8ec3 100644
--- a/fftools/ffmpeg.c
+++
On Thu, Sep 3, 2020 at 8:29 PM Jan Ekström wrote:
>
> Currently the API is internally limited to unsigned integers, so if we
> limit the file size as well as the amount to read to UINT_MAX - 1, we
> do not require additional limiting to be performed on the values.
>
> Th
This enables people to override the sanity check without compiling
a new binary.
---
libavformat/dashdec.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index c5a5ff607b..4080b9b650 100644
---
This is absurdly large, but unfortunately a ~2 hour Youtube
live stream archive can still be around 3.2 megabytes when
requested as MPEG-DASH.
---
libavformat/dashdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index
On Tue, Sep 1, 2020 at 8:45 PM Jan Ekström wrote:
>
> This enables people to override the sanity check without compiling
> a new binary.
> ---
> libavformat/dashdec.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat
This enables people to override the sanity check without compiling
a new binary.
---
libavformat/dashdec.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index c5a5ff607b..bea9616f4a 100644
---
On Tue, Sep 1, 2020 at 5:22 PM Harry Mallon wrote:
>
>
>
>
> > On 12 Aug 2020, at 21:58, Vittorio Giovara
> > wrote:
> >
> > 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
On Tue, Sep 1, 2020 at 9:19 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > This enables people to override the sanity check without compiling
> > a new binary.
> > ---
> > libavformat/dashdec.c | 13 ++---
> > 1 file changed, 10 insertions(+
On Tue, Sep 1, 2020 at 9:31 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > This enables people to override the sanity check without compiling
> > a new binary.
> > ---
> > libavformat/dashdec.c | 17 ++---
> > 1 file changed, 14 insertions(+
On Tue, Sep 1, 2020 at 9:56 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > On Tue, Sep 1, 2020 at 9:31 PM Andreas Rheinhardt
> > wrote:
> >>
> >> Jan Ekström:
> >>> This enables people to override the sanity check without compiling
> >&
On Sun, Sep 13, 2020 at 7:14 PM Michael Niedermayer
wrote:
>
> On Sun, Sep 13, 2020 at 01:26:20PM +0300, Jan Ekström wrote:
> > This will have to be called later for video down the line.
> > ---
> > fftools/ffmpeg.c | 77
Fixes vf_scale outputting RGB AVFrames with limited range in
case either input or output specifically sets the range.
Keeps the external interfaces the same, but allows us to retrieve
and set nonzero value for RGB. Additionally defines the default
value of the AVOption as -1 so we can
On Wed, Oct 7, 2020 at 8:34 PM Michael Niedermayer
wrote:
>
> On Wed, Oct 07, 2020 at 02:03:16AM +0300, Jan Ekström wrote:
> > This makes isAnyRGB return true for AV_PIX_FMT_PAL8 which is currently
> > the only pixel format with this flag.
> >
> > This lets us h
On Fri, Oct 2, 2020 at 12:33 PM Martin Storsjö wrote:
>
> On Mon, 28 Sep 2020, Jan Ekström wrote:
>
> > The generated text streams for chapters lack an AVStream since they
> > are but an internal concept within movenc.
> >
> > Fixes #8190
> > ---
> &
On Wed, Oct 7, 2020 at 9:27 PM Jan Ekström wrote:
>
> Fixes vf_scale outputting RGB AVFrames with limited range in
> case either input or output specifically sets the range.
>
> Keeps the external interfaces the same, but allows us to retrieve
> and set nonzero value for RGB. Ad
On Tue, Oct 13, 2020 at 12:07 AM Dave Evans wrote:
>
> This patch fixes the total failure to parse cues when style and region
> definition blocks are contained in the input file, and ensures those blocks
> are written to the output when copying.
>
Thank you for taking time to add a FATE test,
- For video, this means a single initialization point in do_video_out.
- For audio we unfortunately need to do it in two places just
before the buffer sink is utilized (if av_buffersink_get_samples
would still work according to its specification after a call to
avfilter_graph_request_oldest
We now have the possibility of getting AVFrames here, and we should
not touch the muxer's codecpar after writing the header.
---
fftools/ffmpeg.c | 27 ++-
.../fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
This will have to be called later for video down the line.
---
fftools/ffmpeg.c | 72 +++-
1 file changed, 47 insertions(+), 25 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index cb7644de6a..0d8ed26912 100644
--- a/fftools/ffmpeg.c
+++
be utilized if the user has not set the
option for a given stream. Thus, this use case still works.
Jan Ekström (6):
ffmpeg: deduplicate init_output_stream usage logic
ffmpeg: move AVFrame time base adjustment into a function
ffmpeg: move A/V non-streamcopy initialization to a later point
This way the old max queue size limit based behavior for streams
where each individual packet is large is kept, while for smaller
streams more packets can be buffered (current default is at 50
megabytes per stream).
For some explanation, by default ffmpeg copies packets from before
the appointed
Adds a wrapper function, which handles any errors depending on how
fatal a failure would be.
---
fftools/ffmpeg.c | 51
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 84306818a2..cb7644de6a
Additionally, reap the first rewards by being able to set the
color related encoding values based on the passed AVFrame.
The only tests that seem to have changed their results with this
change seem to be the MXF tests. There, the muxer writes the
limited/full range flag to the output container if
On Fri, Oct 16, 2020, 22:47 Michael Niedermayer
wrote:
> On Fri, Oct 16, 2020 at 04:16:46PM +0300, Jan Ekström wrote:
> > - For video, this means a single initialization point in do_video_out.
> > - For audio we unfortunately need to do it in two places just
> > b
On Fri, Oct 16, 2020 at 11:03 PM Michael Niedermayer
wrote:
>
> On Fri, Oct 16, 2020 at 04:16:44PM +0300, Jan Ekström wrote:
> > Adds a wrapper function, which handles any errors depending on how
> > fatal a failure would be.
> > ---
&g
Fixes vf_scale outputting RGB AVFrames with limited range flagged
in case either input or output specifically sets the range.
This is the reverse of the logic utilized for RGB and PAL8 content
in sws_setColorspaceDetails.
---
libswscale/utils.c | 4 ++--
1 file changed, 2 insertions(+), 2
---
libswscale/utils.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 9ca378bd3b..832c9f873c 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -864,6 +864,11 @@ static void fill_xyztables(struct SwsContext *c)
On Fri, Oct 9, 2020 at 10:02 PM Michael Niedermayer
wrote:
>
> On Wed, Oct 07, 2020 at 09:27:20PM +0300, Jan Ekström wrote:
> > Fixes vf_scale outputting RGB AVFrames with limited range in
> > case either input or output specifically sets the range.
> >
> > Keeps th
On Sun, Oct 11, 2020 at 12:28 AM Michael Niedermayer
wrote:
>
> On Sat, Oct 10, 2020 at 03:20:28AM +0300, Jan Ekström wrote:
> > ---
> > libswscale/utils.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/libswscale/ut
Fixes vf_scale outputting RGB AVFrames with limited range in
case either input or output specifically sets the range.
Keeps the external interfaces the same, but allows us to retrieve
and set nonzero value for RGB. Additionally defines the default
value of the AVOption as -1 so we can
This makes isAnyRGB return true for AV_PIX_FMT_PAL8 which is currently
the only pixel format with this flag.
This lets us have a single query for formats where we need to force
range as only full range content is supported.
---
libswscale/swscale_internal.h| 2 +-
On Wed, Oct 7, 2020 at 2:03 AM Jan Ekström wrote:
>
> Fixes vf_scale outputting RGB AVFrames with limited range in
> case either input or output specifically sets the range.
>
> Keeps the external interfaces the same, but allows us to retrieve
> and set nonzero value for RGB. Ad
On Sat, Oct 17, 2020 at 3:32 AM Jan Ekström wrote:
>
> On Fri, Oct 16, 2020, 22:47 Michael Niedermayer
> wrote:
>>
>> On Fri, Oct 16, 2020 at 04:16:46PM +0300, Jan Ekström wrote:
>> > - For video, this means a single initialization point in do_video_out.
>>
not your enemy.
Jan
> On 8/16/20, Michael Niedermayer wrote:
> > On Sat, Aug 01, 2020 at 02:07:30PM +0300, Jan Ekström wrote:
> >> ---
> >> libavcodec/aacdec_template.c | 89 +++-
> >> 1 file changed, 78 insertions(+)
On Sun, Aug 16, 2020 at 2:15 AM Michael Niedermayer
wrote:
>
> On Sat, Aug 01, 2020 at 02:07:30PM +0300, Jan Ekström wrote:
> > ---
> > libavcodec/aacdec_template.c | 89 +++-
> > 1 file changed, 78 insertions(+), 11 deletions(-)
> &g
On Tue, Aug 18, 2020 at 12:45 PM Jan Ekström wrote:
>
> On Tue, Aug 18, 2020 at 12:17 PM Paul B Mahol wrote:
> >
> > I think there is open bug report about SEGV regarding this commit on trac.
> >
> > Please revert or fix ASAP!
> >
>
> Thank you for lett
On Fri, Aug 14, 2020 at 8:36 PM Michael Niedermayer
wrote:
>
> On Thu, Aug 13, 2020 at 01:26:58AM +0300, Jan Ekström wrote:
> > This is as far as 22.2 follows the same channel order as
> > WaveFormatExtensible's channel mask (and the AV_CH_* defines).
> >
> > Afte
This was quite useful to verify that 22.2 got properly handled,
among other things.
---
libavcodec/aacdec_template.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 1e112ccf76..4662bbe41a 100644
---
On Thu, Aug 13, 2020 at 12:52 PM Jan Ekström wrote:
>
> On Thu, Aug 13, 2020 at 10:34 AM Marton Balint wrote:
> >
> >
> >
> > On Thu, 13 Aug 2020, Jan Ekström wrote:
> >
> > > While having the possibility of non-NOPTS values that can suddenly
>
This way the layout set at various points can be checked instead
of only having the layout at the end.
---
libavcodec/aacdec_template.c | 53 ++--
1 file changed, 32 insertions(+), 21 deletions(-)
diff --git a/libavcodec/aacdec_template.c
This way we can check that we have exactly the required things for 22.2.
Fixes #8845
---
libavcodec/aacdec_template.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index
reorder.
This one, if found non-interesting, can just be ignored. I decided to
post it as it was part of my verification.
Jan Ekström (3):
avcodec/aacdec_template: keep tabs on layout in sniff_channel_order
avcodec/aacdec_template: add more checks to make sure only 22.2 gets
to 22.2
avcodec
On Fri, Aug 28, 2020 at 11:01 PM Xiaohan Wang (王消寒) wrote:
>
> Resend with @chromium.org account. Sorry for the noise.
I think something like this could be the underlying issue that got hit
when the 22.2 check was too lax and set incorrect parameters earlier
in the parsing process? What this
On Tue, Aug 18, 2020 at 7:45 PM Paul B Mahol wrote:
>
> On 8/18/20, Jan Ekström wrote:
> > On Tue, Aug 18, 2020 at 12:45 PM Jan Ekström wrote:
> >>
> >> On Tue, Aug 18, 2020 at 12:17 PM Paul B Mahol wrote:
> >> >
> >> > I think the
This way the layout set at various points can be checked instead
of only having the layout at the end.
---
libavcodec/aacdec_template.c | 56 ++--
1 file changed, 35 insertions(+), 21 deletions(-)
diff --git a/libavcodec/aacdec_template.c
This was quite useful to verify that 22.2 got properly handled,
among other things.
---
libavcodec/aacdec_template.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 63604d39fd..b9b9ae5324 100644
---
be ignored. I decided to
post it as it was part of my verification.
Jan Ekström (3):
avcodec/aacdec_template: keep tabs on layout in sniff_channel_order
avcodec/aacdec_template: add more checks to make sure only 22.2 gets
to 22.2
avcodec/aacdec_template: log the element order before/after
On Tue, Aug 18, 2020 at 10:25 PM Jan Ekström wrote:
>
> This way we can check that we have exactly the required things for 22.2.
>
> Fixes #8845
> ---
> libavcodec/aacdec_template.c | 40 ++--
> 1 file changed, 38 insertions(+), 2 deleti
This way we can check that we have exactly the required things for 22.2.
Fixes #8845
---
libavcodec/aacdec_template.c | 47 ++--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index
On Sat, Aug 22, 2020 at 2:21 PM Michael Niedermayer
wrote:
>
> On Sat, Aug 22, 2020 at 12:58:00AM +0300, Jan Ekström wrote:
> > This was quite useful to verify that 22.2 got properly handled,
> > among other things.
> > ---
> > libavcodec/aacdec_template.c | 26 +++
On Sat, Aug 22, 2020 at 2:17 PM Michael Niedermayer
wrote:
>
> On Sat, Aug 22, 2020 at 12:57:59AM +0300, Jan Ekström wrote:
> > This way we can check that we have exactly the required things for 22.2.
> >
> > Fixes #8845
> > ---
> >
On Sat, Aug 22, 2020 at 4:44 PM Michael Niedermayer
wrote:
>
> On Sat, Aug 22, 2020 at 02:36:09PM +0300, Jan Ekström wrote:
> > On Sat, Aug 22, 2020 at 2:17 PM Michael Niedermayer
> > wrote:
> > >
> > > On Sat, Aug 22, 2020 at 12:57:59AM +0300, Jan Ekström
On Sat, Aug 22, 2020 at 11:39 PM Jan Ekström wrote:
>
> Validates the set channel layout as well as verifies that the received
> layout to the function matches the reference layout, so that it matches
> the implemented re-ordering logic.
>
> Fixes #8845
> ---
> libavcode
Validates the set channel layout as well as verifies that the received
layout to the function matches the reference layout, so that it matches
the implemented re-ordering logic.
Fixes #8845
---
libavcodec/aacdec_template.c | 21 +++--
1 file changed, 19 insertions(+), 2
On Sat, Aug 22, 2020 at 11:42 PM Carl Eugen Hoyos wrote:
>
> Am Sa., 22. Aug. 2020 um 22:40 Uhr schrieb Jan Ekström :
> >
> > Validates the set channel layout as well as verifies that the received
> > layout to the function matches the reference layout, so that it matche
On Tue, Aug 18, 2020 at 10:25 PM Jan Ekström wrote:
>
> The first two commits fix both of the fuzzing samples I have on hand.
> One being from #8845, and another provided privately by Michael. Changes have
> been tested both with clang 10's ASAN as well as standard valgrind.
>
F
On Tue, Aug 18, 2020 at 10:25 PM Jan Ekström wrote:
>
> This way the layout set at various points can be checked instead
> of only having the layout at the end.
> ---
> libavcodec/aacdec_template.c | 53 ++--
> 1 file changed, 32 insertion
On Mon, Aug 24, 2020 at 11:04 PM Paul B Mahol wrote:
>
> On 8/22/20, Carl Eugen Hoyos wrote:
> > Am Sa., 22. Aug. 2020 um 23:15 Uhr schrieb Jan Ekström :
> >>
> >> On Sat, Aug 22, 2020 at 11:42 PM Carl Eugen Hoyos
> >> wrote:
> >> >
> >&
On Sat, Aug 15, 2020 at 12:29 PM Jan Ekström wrote:
>
> On Fri, Aug 14, 2020 at 8:36 PM Michael Niedermayer
> wrote:
> >
> > On Thu, Aug 13, 2020 at 01:26:58AM +0300, Jan Ekström wrote:
> > > This is as far as 22.2 follows the same channel order as
> > &
On Fri, Aug 14, 2020 at 8:36 PM Michael Niedermayer
wrote:
>
> On Thu, Aug 13, 2020 at 01:26:58AM +0300, Jan Ekström wrote:
> > This is as far as 22.2 follows the same channel order as
> > WaveFormatExtensible's channel mask (and the AV_CH_* defines).
> >
> > Afte
On Sun, Sep 20, 2020 at 5:54 PM Andreas Rheinhardt
wrote:
>
> Otherwise the result of such tests will not accurately reflect the
> current state.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> tests/fate-run.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Tue, Sep 22, 2020 at 12:42 PM Martin Storsjö wrote:
>
> On Mon, 21 Sep 2020, Jan Ekström wrote:
>
> > This is utilized by various media ingests to figure out the bit
> > rate of the content you are pushing towards it, so write it by
> > default for video, audio and
On Wed, Sep 23, 2020 at 6:49 PM Vittorio Giovara
wrote:
>
> On Sun, Sep 20, 2020 at 8:48 PM Jan Ekström wrote:
>
> > On Sun, Sep 20, 2020 at 9:34 PM Vittorio Giovara
> > wrote:
> > >
> > > On Sun, Sep 20, 2020 at 7:12 PM Jan Ekström wrote:
> > &g
On Tue, Sep 22, 2020 at 12:58 PM Jan Ekström wrote:
>
> On Tue, Sep 22, 2020 at 12:42 PM Martin Storsjö wrote:
> >
> > On Mon, 21 Sep 2020, Jan Ekström wrote:
> >
> > > This is utilized by various media ingests to figure out the bit
> > > rate of the co
If the average bit rate cannot be calculated, such as in the case
of streamed fragmented mp4, utilize various available parameters
in priority order.
Tests are updated where the esds or btrt or ISML manifest boxes'
output changes.
---
libavformat/movenc.c | 17 +
The newly calculated average bit rate value is pretty much what is
being done here.
---
libavformat/movenc.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 860e331b19..20768cd45f 100644
---
This is utilized by various media ingests to figure out the bit
rate of the content you are pushing towards it, so write it by
default for video, audio and subtitle tracks. It is only mentioned
for timed metadata sample descriptions in QTFF, so limit it only to
ISOBMFF (MODE_MP4).
Updates the
(ISOBMFF) for now.
Unifies the MPEG-4 bit rate value calculation, and attempts to utilize
it wherever applicable.
Jan Ekström (5):
avformat/movenc: split MPEG-4 bit rate value calculation
avformat/movenc: utilize bit rate helper function in ISML writing
avformat/movenc: implement writing
This can now be re-utilized in other places.
---
libavformat/movenc.c | 44 ++--
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 12471c7d68..5888d10770 100644
--- a/libavformat/movenc.c
+++
This way we have a single location in movenc which utilizes the
CPB properties.
---
libavformat/movenc.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 5888d10770..a4ec4d05c9 100644
--- a/libavformat/movenc.c
+++
On Mon, Sep 21, 2020 at 1:12 PM Martin Storsjö wrote:
>
> On Sun, 20 Sep 2020, Jan Ekström wrote:
>
> > This is utilized by various media ingests to figure out the bit
> > rate of the content you are pushing towards it, so write it by
> > default for video, audio and
On Thu, Sep 17, 2020 at 11:31 PM Michael Niedermayer
wrote:
>
> On Wed, Sep 16, 2020 at 11:18:48PM +0300, Jan Ekström wrote:
> > This value - while it looks like the actual range of the content -
> > is nothing but the internal value of swscale.
> >
> > Thus,
As it was brought up that the current documentation leaves things
as specific to YCbCr only, ICtCp and RGB are now mentioned.
Additionally, the specifications on which these definitions of
narrow and full range are defined are mentioned.
This way, the documentation of AVColorRange should now
On Sat, Sep 19, 2020 at 12:47 AM James Almer wrote:
>
> On 9/18/2020 6:05 PM, Jan Ekström wrote:
> > As it was brought up that the current documentation leaves things
> > as specific to YCbCr only, ICtCp and RGB are now mentioned.
> > Additionally, the specifications on
As it was brought up that the current documentation leaves things
as specific to YCbCr only, ICtCp and RGB are now mentioned.
Additionally, the specifications on which these definitions of
narrow and full range are defined are mentioned.
This way, the documentation of AVColorRange should now
On Mon, Sep 28, 2020 at 6:14 PM Andreas Rheinhardt
wrote:
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/movenc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 63adae5e0a..a90bbfa458 100644
> --- a/libavformat/movenc.c
Missed due to lack of FATE tests, but chapters are a movenc track
w/o an AVStream. We also expect the codecpar in the track, which we are
utilizing without checks. Thus, cause an early exit if it is missing
as well.
Fixes #8190
---
libavformat/movenc.c | 6 ++
1 file changed, 6 insertions(+)
On Mon, Sep 28, 2020 at 11:57 PM Jan Ekström wrote:
>
> The generated text streams for chapters lack an AVStream since they
> are but an internal concept within movenc.
>
> Fixes #8190
Yes, I have now twice missed the fact that it is #8910 and not #8190.
But fret not, I have not
The generated text streams for chapters lack an AVStream since they
are but an internal concept within movenc.
Fixes #8190
---
libavformat/movenc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 20768cd45f..c1ff922e88
On Wed, Sep 16, 2020 at 2:16 PM Timo Rothenpieler wrote:
>
> ---
> src/download | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/download b/src/download
> index 706d402..0f090b8 100644
> --- a/src/download
> +++ b/src/download
> @@ -79,6 +79,9 @@
> Windows EXE Files
>
301 - 400 of 1160 matches
Mail list logo
