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, translate the value to 1 which is what
at least this filter expects for RGB. Swscale will ignore this value
when set.
Additionally, after calling
On Sun, Sep 20, 2020 at 3:34 PM Carl Eugen Hoyos wrote:
>
>
>
>
>
> > Am 20.09.2020 um 13:52 schrieb Bernd Kuhls :
> >
> > Fixes static builds with toolchains needing "-lm" for math functions.
>
> Please don’t.
>
Please reword this in another way if your meaning is to note that
you'd like the
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 1962f2..31e1ac1589 100644
--- a/libavformat/movenc.c
+++
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
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 0f14e255e9..35d028e6de 100644
---
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 +
Various media ingest servers read the incoming stream's advertised bit
rate from this box.
As it is only defined for timed metadata tracks in QTFF, limit it to
just MODE_MP4 (ISOBMFF) for now.
Unifies the MPEG-4 bit rate value calculation, and attempts to utilize
it everywhere matching.
Jan
This can now be re-utilized in other places.
---
libavformat/movenc.c | 39 +--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 12471c7d68..1962f2 100644
--- a/libavformat/movenc.c
+++
On Thu, Sep 10, 2020 at 3:00 AM James Almer wrote:
>
> On 9/9/2020 7:54 PM, Michael Niedermayer wrote:
> > On Thu, Sep 03, 2020 at 03:55:04PM -0300, James Almer wrote:
> >> Actually write it in yuv4_write_header() instead of with the first
> >> packet.
> >>
> >> Signed-off-by: James Almer
> >>
On Sun, Sep 20, 2020 at 5:50 PM Michael Niedermayer
wrote:
>
> On Sat, Sep 19, 2020 at 02:42:01PM +0300, 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.
> > Addition
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 Sun, Sep 20, 2020 at 9:34 PM Vittorio Giovara
wrote:
>
> On Sun, Sep 20, 2020 at 7:12 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,
On Sun, Sep 20, 2020 at 6:03 PM Michael Niedermayer
wrote:
>
> On Sun, Sep 20, 2020 at 01:36:56PM +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, if
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 Wed, Sep 16, 2020 at 1:20 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_v
On Wed, Sep 16, 2020 at 11:38 PM Michael Niedermayer
wrote:
>
> On Wed, Sep 16, 2020 at 12:16:43AM +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,
- 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
be utilized if the user has not set the
option for a given stream. Thus, this use case still works.
Jan Ekström (5):
ffmpeg: add a data size threshold for muxing queue size
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
On Tue, Oct 27, 2020 at 10:38 PM Bohan Li
wrote:
>
> Add the option to use -enable-keyframe-filtering with libaom-av1
> codec. The option controls the encoder behavior on performing
> temporal filtering on keyframes.
>
Hi,
Looking at the amount of options etc which you want to expose to
FFmpeg
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
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 3af189e7f2..498e5f08a6 100644
--- a/fftools/ffmpeg.c
+++
We now have the possibility of getting AVFrames here, and we should
not touch the muxer's codecpar after writing the header.
Results of FATE tests change as the MXF and Matroska muxers actually
write down the field/frame coding type of a stream in their
respective headers. Before this change,
On Wed, Oct 21, 2020 at 10:14 AM Jan Ekström wrote:
>
> On Fri, Oct 16, 2020, 16:16 Jan Ekström wrote:
>>
>> This patch set started with a very simple wish to not have to set color
>> related values manually each time when utilizing ffmpeg.c.
>>
>> As o
On Tue, Oct 27, 2020 at 8:30 PM Jan Ekström wrote:
>
> This patch set started with a very simple wish to not have to set color
> related values manually each time when utilizing ffmpeg.c.
>
> As of the fourth iteration, the following changes were done since the third:
> 1. The d
On Wed, Oct 14, 2020 at 2:54 AM Mohammad Izadi
wrote:
>
> From: Mohammad Izadi
>
> HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
> decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
> data packet to be used or passed through.
>
> The
On Tue, Oct 27, 2020 at 1:03 PM Anton Khirnov wrote:
>
> Quoting Jan Ekström (2020-10-16 15:16:47)
> > 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
On Tue, Oct 27, 2020, 13:13 Anton Khirnov wrote:
>
> Quoting Jan Ekström (2020-10-16 15:16:48)
> > 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
On Mon, Aug 3, 2020 at 10:34 AM Carl Eugen Hoyos wrote:
>
>
>
> > Am 02.08.2020 um 23:16 schrieb Jan Ekström :
> >
> >> On Sat, Aug 1, 2020 at 4:29 PM Carl Eugen Hoyos wrote:
> >>
> >>> Am Sa., 1. Aug. 2020 um 14:47 Uhr schrieb Jan Ekström :
>
On Sat, Aug 1, 2020 at 9:52 PM Michael Niedermayer
wrote:
>
> On Sat, Aug 01, 2020 at 02:07:26PM +0300, Jan Ekström wrote:
> > Only this sub-set of channels actually follows the bit mask order
> > in the official 22.2 channel mapping. Additionally, the 5.1 channels
> >
On Sat, Aug 1, 2020 at 4:29 PM Carl Eugen Hoyos wrote:
>
> Am Sa., 1. Aug. 2020 um 14:47 Uhr schrieb Jan Ekström :
> >
> > On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen Hoyos wrote:
> > >
> > > Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan Ekström :
> > >
Utilizes the newly added 22.2 channel layout for channel_layout 13.
---
libavcodec/aacdectab.h | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacdectab.h b/libavcodec/aacdectab.h
index baf51a74bf..c54a3eb943 100644
---
Additionally, add comments regarding their definitions. Based on
ARIB STD-B32, which bases on 14496-3:2009 and 14496-3:2009/AMD4.
---
libavcodec/mpeg4audio.c | 17 +++--
libavcodec/mpeg4audio.h | 2 +-
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git
These bits are utilized by channel layouts such as 22.2. If those
are dropped, the returned channel layout is no longer a match
against the AV_CH_LAYOUT define when returned from this function.
---
libswresample/rematrix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Requires some extraneous top side and bottom front channels to be
defined.
According to STD-B59v2, the defined channel layout is:
- FL
- FR
- FC
- LFE1
- BL
- BR
- FLc
- FRc
- BC
- LFE2
- SiL
- SiR
- TpFL
- TpFR
- TpFC
- TpC
- TpBL
- TpBR
- TpSiL
- TpSiR
- TpBC
- BtFC
- BtFL
- BtFR
---
5 }
tag 15 = { pos: (null) (140), syn_elem: CPE, elem_id: 7 }
Jan Ekström (7):
avutil/channel_layout: add 22.2 layout
swresample/matrix: switch internal clean_layout function to not drop
high bits
swresample/rematrix: treat 22.2 as 5.1 (back) when mixing
avcodec/mpeg4audio:
---
libavcodec/aacdec_template.c | 89 +++-
1 file changed, 78 insertions(+), 11 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 21db12fdab..8c5048cc13 100644
--- a/libavcodec/aacdec_template.c
+++
Only this sub-set of channels actually follows the bit mask order
in the official 22.2 channel mapping. Additionally, the 5.1 channels
are there for backwards compatibility with the previous system.
This enables the utilization of 22.2 content until a proper down/up
matrix is added into
On Sat, Aug 1, 2020 at 2:51 PM Carl Eugen Hoyos wrote:
>
> Am Di., 16. Juni 2020 um 23:11 Uhr schrieb Jan Ekström :
> >
> > Requires some extraneous top side and bottom front channels to be
> > defined.
> >
> > According to STD-B59v2, the defined channel l
On Sat, Aug 1, 2020 at 4:42 PM James Almer wrote:
>
> On 8/1/2020 9:17 AM, Jan Ekström wrote:
> > On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen Hoyos wrote:
> >>
> >> Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan Ekström :
> >>
> >>> Additionally, t
We now have the capability to do this.
---
libavcodec/aacdec_template.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index a473e1bad7..21db12fdab 100644
--- a/libavcodec/aacdec_template.c
+++
On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen Hoyos wrote:
>
> Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan Ekström :
>
> > Additionally, the spec only mentions stereo/5.1 for direct mapping, so
> > I've kept to 5.1 since we have the capability for that one.
>
> And
On Sat, Aug 1, 2020 at 2:07 PM Jan Ekström wrote:
>
> The decoding parts of this patch set have not changed from v2.
> I have now added changes so that 22.2 gets properly handled as
> 5.1 (for which it has backwards compatibility) until it gets a
> proper remix matrix defined in
On Tue, Jul 28, 2020 at 3:30 PM Takio Yamaoka wrote:
>
> An initial value of `AVCodecContext::chromaoffset` is zero,
> then it causes to block `-chromaoffset` setting as result.
> In addition, even though a negative number of `chromaoffset`
> is meaningful, `X264Context::chroma_offset` is
On Sat, Aug 1, 2020 at 4:29 PM Carl Eugen Hoyos wrote:
>
> Am Sa., 1. Aug. 2020 um 14:47 Uhr schrieb Jan Ekström :
> >
> > On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen Hoyos wrote:
> > >
> > > Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan Ekström :
> > >
On Sat, Aug 1, 2020 at 4:44 PM Jan Ekström wrote:
>
> > > At this point I would not like to attempt to figure out how to skip
> > > channel coding units in the AAC decoder
> >
> > Just throw them away?
> >
>
> Very easy to say in words, but I
On Sat, Aug 1, 2020 at 2:46 PM Paul B Mahol wrote:
>
> On 6/16/20, Jan Ekström wrote:
> > Requires some extraneous top side and bottom front channels to be
> > defined.
> >
> > According to STD-B59v2, the defined channel layout is:
> > - FL
> >
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
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
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
> > jump in time due to adjustments to match PCR is not nice for DVB
> > subtitles, appa
On Thu, Aug 6, 2020 at 3:16 AM Takio Yamaoka wrote:
>
> 2020年8月6日(木) 7:24 Jan Ekström :
> >
> > Sorry, decided to take a look at the logic but didn't have the time to
> > actually test it locally.
>
> Thank you for replying. It sounds good for me.
>
> > I
On Wed, Aug 5, 2020 at 4:27 AM Takio Yamaoka wrote:
>
> Thank you for the review!
> It is my first time to send a patch. So I was relieved to hear that.
>
> Is it OK to wait to merge?
>
> Best Regards,
> Takio
>
Sorry, decided to take a look at the logic but didn't have the time to
actually test
Utilizes the newly added 22.2 channel layout for channel_layout 13.
---
libavcodec/aacdectab.h | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacdectab.h b/libavcodec/aacdectab.h
index baf51a74bf..c54a3eb943 100644
---
, but at least
7/24 seem to be correct looking at the decoded WAV output in Audacity
(front left/right, center, top and bottom front left/right seem to be
correct based on the sample linked in #8714).
Fixes #8714
Jan Ekström (5):
avutil/channel_layout: add 22.2 layout
avcodec/mpeg4audio: add
Requires some extraneous top side and bottom front channels to be
defined.
According to STD-B59v2, the defined channel layout is:
- FL
- FR
- FC
- LFE1
- BL
- BR
- FLc
- FRc
- BC
- LFE2
- SiL
- SiR
- TpFL
- TpFR
- TpFC
- TpC
- TpBL
- TpBR
- TpSiL
- TpSiR
- TpBC
- BtFC
- BtFL
- BtFR
---
Additionally, add comments regarding their definitions. Based on
ARIB STD-B32, which bases on 14496-3:2009 and 14496-3:2009/AMD4.
---
libavcodec/mpeg4audio.c | 17 +++--
libavcodec/mpeg4audio.h | 2 +-
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git
---
libavcodec/aacdec_template.c | 53 +++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 0590e77d75..0be0ad6566 100644
--- a/libavcodec/aacdec_template.c
+++
We now have the capability to do this.
---
libavcodec/aacdec_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index a473e1bad7..0590e77d75 100644
--- a/libavcodec/aacdec_template.c
+++
---
libavcodec/aacdec_template.c | 89 +++-
1 file changed, 78 insertions(+), 11 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 21db12fdab..8c5048cc13 100644
--- a/libavcodec/aacdec_template.c
+++
We now have the capability to do this.
---
libavcodec/aacdec_template.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index a473e1bad7..21db12fdab 100644
--- a/libavcodec/aacdec_template.c
+++
Additionally, add comments regarding their definitions. Based on
ARIB STD-B32, which bases on 14496-3:2009 and 14496-3:2009/AMD4.
---
libavcodec/mpeg4audio.c | 17 +++--
libavcodec/mpeg4audio.h | 2 +-
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git
Utilizes the newly added 22.2 channel layout for channel_layout 13.
---
libavcodec/aacdectab.h | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacdectab.h b/libavcodec/aacdectab.h
index baf51a74bf..c54a3eb943 100644
---
the correct channels for 5.1 and stereo
downmix (checked with ffmpeg.c by utilizing `-channel_layout` 5.1 and stereo),
although the default downmix logic seems to lower the volume somewhat.
Fixes #8714
Jan Ekström (5):
avutil/channel_layout: add 22.2 layout
avcodec/mpeg4audio: add newer
Requires some extraneous top side and bottom front channels to be
defined.
According to STD-B59v2, the defined channel layout is:
- FL
- FR
- FC
- LFE1
- BL
- BR
- FLc
- FRc
- BC
- LFE2
- SiL
- SiR
- TpFL
- TpFR
- TpFC
- TpC
- TpBL
- TpBR
- TpSiL
- TpSiR
- TpBC
- BtFC
- BtFL
- BtFR
---
= { pos: (null) (140), syn_elem: CPE, elem_id: 7 }
> >
> > swresample seems to give out the correct channels for 5.1 and stereo
> > downmix (checked with ffmpeg.c by utilizing `-channel_layout` 5.1 and
> > stereo),
> > although the default downmix logic seems
On Wed, Jul 29, 2020 at 2:39 PM Jan Ekström wrote:
>
> swresample seems to give out the correct channels for 5.1 and stereo
> downmix (checked with ffmpeg.c by utilizing `-channel_layout` 5.1 and stereo),
> although the default downmix logic seems to lower the volume somewhat.
&g
From: Jan Ekström
Signed-off-by: Jan Ekström
---
fftools/ffprobe.c | 29 -
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 3453aa09ff..b1fccad65e 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
On Mon, Dec 7, 2020 at 12:08 PM Jan Ekström wrote:
>
> The primary parts of this are patches 1,4,5. 2 and 3 were just noticed when
> poking at the recovery timestamp logic, where the stream-time comparison logic
> seemed somewhat weird (such as comparing the pts to last_reco
From: Jan Ekström
Enables encoding of other subtitle formats into TTML and writing
them out as such documents.
Signed-off-by: Jan Ekström
---
Changelog | 1 +
doc/general_contents.texi | 1 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1
On Tue, Dec 8, 2020 at 2:54 PM Jan Ekström wrote:
>
> From: Jan Ekström
>
> This way the timestamp adjustments do not have to be manually
> undone in case of failure and need to recover/retry.
>
> Fixes an issue where the timestamp adjustment would be re-done over
> and
AVStream called s to st as it indeed was confusing.
- Switched to utilizing avio_w8 when writing a single byte in the muxer.
Jan
Jan Ekström (2):
ffprobe: switch to av_bprint_escape for XML escaping
{avcodec,avformat}: add TTML encoder and muxer
Stefano Sabatini (1):
avutil/{avstring,bprint
From: Stefano Sabatini
---
libavutil/avstring.h | 1 +
libavutil/bprint.c | 14 ++
tools/ffescape.c | 1 +
3 files changed, 16 insertions(+)
diff --git a/libavutil/avstring.h b/libavutil/avstring.h
index ee225585b3..79bb920a70 100644
--- a/libavutil/avstring.h
+++
On Mon, Jan 11, 2021 at 10:53 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > On Tue, Dec 8, 2020 at 2:54 PM Jan Ekström wrote:
> >>
> >> From: Jan Ekström
> >>
> >> This way the timestamp adjustments do not have to be manually
> >
On Mon, Nov 23, 2020 at 10:11 PM James Almer wrote:
>
> On 11/23/2020 4:10 PM, Jan Ekström wrote:
> > Until now an API user with a non-libavformat MP4 or Matroska demuxer
> > would have had to manually filter the extradata to skip the first four
> > bytes when passin
On Sun, Dec 6, 2020 at 5:43 PM James Almer wrote:
>
> Signed-off-by: James Almer
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On Sun, Dec 6, 2020 at 5:44 PM James Almer wrote:
>
> Create a local one instead from a byte buffer input argument.
>
> Signed-off-by: James Almer
The actual change mentioned in the commit message is LGTM, and the
updated sanity checks seem good (since now the alternatives at that
point are
On Mon, Dec 7, 2020 at 1:23 AM Jan Ekström wrote:
>
> On Sun, Dec 6, 2020 at 5:44 PM James Almer wrote:
> >
> > Create a local one instead from a byte buffer input argument.
> >
> > Signed-off-by: James Almer
>
> The actual change mentioned in the commi
ding whether a codec tag is
acceptable in cases of meta-muxers such as fifo.
Jan
Bernard Boulay (1):
avformat/fifo: always wait recovery_wait_time between recoveries
Jan Ekström (4):
avformat/fifo: fix handling of stream-time non-NOPTS recovery
avformat/fifo: cause immediate stream-time r
On Mon, Dec 7, 2020 at 12:14 PM Nicolas George wrote:
>
> Jan Ekström (12020-12-07):
> > From: Jan Ekström
> >
> > As this is a meta muxer and the same flag is set with the fifo
> > meta muxer, there is really no reason not to have this set here
> > as well
From: Jan Ekström
This way discontinuities backwards could also get handled (albeit
they generally tend to be incorrect to begin with on this layer of
avformat).
Signed-off-by: Jan Ekström
---
libavformat/fifo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat
ion.
4. Do not limit sleeping in recovery based on recovery_nr being
nonzero ("not the first time of attempted recovery").
Signed-off-by: Jan Ekström
---
libavformat/fifo.c | 54 +-
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git
From: Jan Ekström
As this is a meta muxer and the same flag is set with the fifo
meta muxer, there is really no reason not to have this set here
as well.
Signed-off-by: Jan Ekström
---
libavformat/tee.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/tee.c b
From: Jan Ekström
Otherwise each new attempt will leave its connection open.
Signed-off-by: Jan Ekström
---
libavformat/fifo.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 9fc524adbdf..bc363e458cd 100644
From: Jan Ekström
The API client has no visibility into the values provided by the
underlying muxer, so we either do this always, or when an option
is presented.
In this case, we do it unconditionally, as this is probably more
useful.
Signed-off-by: Jan Ekström
---
libavformat/fifo.c | 12
From: Jan Ekström
Until now the proper diff between last_recovery_ts and packet's pts
was only done when last_recovery_ts was AV_NOPTS_VALUE. This is
kind of an oxymoron as the result of comparing that difference to
AV_NOPTS_VALUE most likely always be relatively large.
Thus, move the immediate
On Mon, Dec 7, 2020 at 3:56 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > From: Jan Ekström
> >
> > Enables encoding of other subtitle formats into TTML and writing
> > them out as such documents.
> >
> > Signed-off-by: Jan Ekström
> > ---
On Mon, Dec 7, 2020 at 4:03 PM Andreas Rheinhardt
wrote:
> >
> > You are not copying the terminating NUL; and you also don't account for
> > it in the above check. Is this intended?
> >
>
> The srt encoder does it like you, the ass encoder is careful only to
> output a NUL terminated string (with
From: Jan Ekström
This way the timestamp adjustments do not have to be manually
undone in case of failure and need to recover/retry.
Fixes an issue where the timestamp adjustment would be re-done over
and over again when recovery by muxing the same AVPacket again is
attempted. Would become
AV1CodecConfigurationRecord
in ff_isom_write_av1c, which is called from the MP4 and Matroska
writers.
5. Finally, both MP4 and Matroska demuxers are changed to expose the
full AV1CodecConfigurationRecord as extradata.
Jan Ekström (5):
avcodec/cbs_av1: add support for standard MP4/Matroska extradata
Libavcodec can now handle the AV1CodecConfigurationRecord structure
as-is when passed as extradata, so the standard behavior of
read-box-into-extradata should suffice, just like with AVC and HEVC.
---
libavformat/mov.c | 30 +-
1 file changed, 1 insertion(+), 29
Libavcodec can now handle the standard AV1CodecConfigurationRecord
extradata as-is.
---
libavformat/matroskadec.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 44db2c8358..da0fadd47a 100644
--- a/libavformat/matroskadec.c
+++
From: Mark Thompson
This is useful in decoders and parsers, matching the way that bitstream
filters read extradata from AVCodecParameters.
---
libavcodec/cbs.c | 77
libavcodec/cbs.h | 11 +++
2 files changed, 50 insertions(+), 38
---
libavformat/av1.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavformat/av1.c b/libavformat/av1.c
index 0cbffb1fd8..5512c4e0f7 100644
--- a/libavformat/av1.c
+++ b/libavformat/av1.c
@@ -375,6 +375,20 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t
*buf, int
This way API clients can just pass the AV1CodecConfigurationRecord
as extradata as-is without further filtering.
---
libavcodec/cbs_av1.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index
This lets us re-utilize the extradata-related checks in the CBS
to add support for passing the AV1CodecConfigurationRecord
as extradata as-is without further filtering.
---
libavcodec/av1_parser.c | 2 +-
libavcodec/av1dec.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff
On Wed, Dec 9, 2020 at 4:34 PM Sun Zhenliang wrote:
>
> 1) 3GPP TS 26.244 V16.1.0 (2020-09) and ISO/IEC 14496-15: "Information
> technology – Coding of audio-visual objects – Part 15: Carriage of NAL unit
> structured video in the ISO base media file format" states HEVC's sample
> entry in
From: Jan Ekström
Enables encoding of other subtitle formats into TTML and writing
them out as such documents.
Signed-off-by: Jan Ekström
---
Changelog | 1 +
doc/general_contents.texi | 1 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1
I've intentionally kept this initial version simple (no styling etc) to focus
on the basics. As this goes through review, additional features can be added
(I had initial PoC for styling implemented some time around previous VDD), and
there is another patch set in my queue which would then add
From: Stefano Sabatini
---
libavutil/avstring.h | 1 +
libavutil/bprint.c | 14 ++
tools/ffescape.c | 1 +
3 files changed, 16 insertions(+)
diff --git a/libavutil/avstring.h b/libavutil/avstring.h
index ee225585b3..79bb920a70 100644
--- a/libavutil/avstring.h
+++
From: Jan Ekström
Signed-off-by: Jan Ekström
---
fftools/ffprobe.c | 29 -
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 86bd23d36d..a127a3f9bb 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
401 - 500 of 1160 matches
Mail list logo
