Up until now, a block's relative offset has been reported as the offset
in the log messages output when writing blocks; given that it is
impossible to know the real offset from the beginning of the file at
this point due to the fact that it is not yet known how many bytes will
be used for the conta
Up until now, it was simply presumed that the first packet had a pts of
zero; otherwise the duration of the first chunk was wrong.
Signed-off-by: Andreas Rheinhardt
---
libavformat/webm_chunk.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavformat/webm_chunk.
The last argument of av_strlcpy is supposed to contain the size of the
destination buffer, but it was filled with the size of the source
string, effectively negating its very purpose.
Signed-off-by: Andreas Rheinhardt
---
libavformat/webm_chunk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Andriy Gelman:
> Hello,
>
> I've been working with HEVC + mpegts at low bitrates 10-20kbps.
>
> At these bitrates, mpegts can create a substantial overhead due
> to the 188 byte frame size (i.e. a NAL unit of 200 bytes will get
> rounded up to 376 bytes).
>
> I've tried to get around this by
Jeyapal, Karthick:
>
> On 4/8/19 7:37 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> Karthick J via ffmpeg-devel:
>>> ---
>>> libavformat/dashenc.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git
Aman Gupta:
> On Wed, Apr 10, 2019 at 1:00 AM Hendrik Leppkes wrote:
>
>> On Wed, Apr 10, 2019 at 9:55 AM Aman Gupta wrote:
>>>
>>> On Tue, Apr 9, 2019 at 9:49 PM Hendrik Leppkes
>> wrote:
>>>
On Wed, Apr 10, 2019 at 2:21 AM Aman Gupta wrote:
>
> From: Aman Gupta
>
> Prev
Karthick J via ffmpeg-devel:
> ---
> libavformat/dashenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index f8d71166d4..9dd520787f 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -1750,10 +17
Steve Lhomme:
>> On April 7, 2019 at 11:24 AM Andreas Rheinhardt via ffmpeg-devel
>> wrote:
>>
>>
>> Steve Lhomme:
>>> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>>>> ebml_read_num had a number of flaws:
>>>>
&
Hello,
thanks for taking the time to review this. Much appreciated.
Steve Lhomme:
> Hi,
>
> On 3/27/2019 12:18 PM, Andreas Rheinhardt wrote:
>> This also changed the handling of unknown-sized elements: They are now
>> ended whenever an element not known to be allowed in them is
>> encountered. I
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> By including SimpleBlocks and Blocksgroups twice in the same EbmlSyntax
>> array (with different semantics), one can reduce the duplication of the
>> other values.
>>
>>
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> This commit changes how levels are handled: If the level used for
>> ebml_parse ends directly after an element that has been consumed, then
>> ebml_parse ends the level itself (and any finite-
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> The earlier code set the level to zero upon seeking and after a
>> discontinuity although in both cases parsing (re)starts at a level 1
>> element.
>>
>> Also set the segment'
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> The earlier code had three flaws:
>>
>> 1. The case of an unknown-sized element inside a finite-sized element
>> (which is against the specifications) was not caught.
>>
>>
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> Before this commit, the Matroska muxer would read a block when required
>> to do so, parse the block, create and return the necessary AVPackets
>> and
>> yet keep the blocks (in a
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> ebml_read_num had a number of flaws:
>>
>> 1. The check for read errors/EOF was totally wrong. E.g. an EBML number
>> beginning with the invalid 0x00 would be considered a read er
Steve Lhomme:
> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
>> By default, the data_offset member of the AVFormatInternal of the
>> AVFormatContext associated with the MatroskaDemuxContext has not been
>> initialized explicitly by any Matroska-specific
Hello,
there are currently a few open track issues related to Matroska attached
pics: #2270, #4286, #4591 and #7717. So I thought it worthwhile to take
a look.
The modifications to mux streams with disposition AV_DISPOSITION_ATTACHED_PIC
that contain an attached pic are easy; see the second patch
This commit changes the way video streams with disposition
AV_DISPOSITION_ATTACHED_PIC and that actually contain an attached_pic
are handled: From now on, they will be written as attachment, not as
a Matroska Track.
The restriction to tracks that actually contain an attached_pic is
important. E.g.
This commit enables propagating an AVStream's attached_pic from the
input to the corresponding output stream.
Signed-off-by: Andreas Rheinhardt
---
fftools/ffmpeg.c | 8
1 file changed, 8 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0f157d67d8..4528c466c7 100644
Jun Zhao:
> From: Jun Zhao
>
> Fix memory leak after write trailer for #7827, only store a audio
> packet whose buffer has size greater than zero in cur_audio_pkt.
>
> Thanks to Andreas Rheinhardt for the suggestions.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/matroskaenc.c |3 ++-
>
Audio packets with size zero, but with side-data currently lead to
memleaks, in the Matroska muxer, because they are not properly freed:
They are currently put into an AVPacket in the MatroskaMuxContext to
ensure that the necessary audio is always available for a new cluster,
but are only written
And I think that this memleak in mkv_write_trailer() has a twin in
mkv_write_packet(): Audio frames are not written directly, but rather
put into storage in cur_audio_pkt via av_packet_ref(). But if the
preceding audio packet was a zero size packet (but possibly with
side-data), then the preceding
Hendrik Leppkes:
> On Thu, Apr 4, 2019 at 11:25 AM Jun Zhao wrote:
>>
>> From: Jun Zhao
>>
>> Fix memory leak after write trailer for #7827
>>
>> Signed-off-by: Jun Zhao
>> ---
>> libavformat/matroskaenc.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/libavfo
Hendrik Leppkes:
> On Tue, Apr 2, 2019 at 5:55 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>>
>> Hello,
>>
>> thanks for taking a look at this.
>>
>> Hendrik Leppkes:
>>> On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
>
Hendrik Leppkes:
> On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>> @@ -383,8 +388,8 @@ static void
>> end_ebml_master_crc32_preliminary(AVIOContext *pb, AVIOContext **dyn
>> uint8_t *buf;
>> int size =
Up until now, a block's relative offset has been reported as the offset
in the log messages output when writing blocks; given that it is
impossible to know the real offset from the beginning of the file at
this point due to the fact that it is not yet known how many bytes will
be used for the conta
Hello,
thanks for taking a look at this.
Hendrik Leppkes:
> On Tue, Apr 2, 2019 at 3:36 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>>
>> Up until now, the writing process for level 1 elements (those elements
>> for which CRC-32 elements are written by defau
After the last few commits, the functions for writing master elements
with CRC-32 elements didn't really make use of the ebml_master
structure any more, so remove these parameters from the functions.
The only things that still need to be kept are the positions of the
level 1 elements that are writ
Up until now, a block's relative offset has been reported as the offset
in the log messages output when writing blocks; given that it is
impossible to know the real offset from the beginning of the file at
this point due to the fact that it is not yet known how many bytes will
be used for the conta
Up until now, the length field of most level 1 elements has been written
using eight bytes, although it is known in advance how much space the
content of said elements will take up so that it would be possible to
determine the minimal amount of bytes for the length field. This
commit changes this.
Up until now, the check for whether to write CRC32 elements was always
mkv->write_crc && mkv->mode != MODE_WEBM. This is equivalent to simply
set write_crc to zero in WebM-mode. And this is what this commit does.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 11 ++-
1
Up until now, the writing process for level 1 elements (those elements
for which CRC-32 elements are written by default) was this in case the
output was seekable: Write the EBML ID, write an "unkown length" EBML
number of the desired length, then write the element into a dynamic
buffer, then write
A Matroska EBML ID can only be maximally four bytes long, so make the
variables denoting EBML IDs uint32_t instead of unsigned int to
better reflect this.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 32
1 file changed, 16 insertions(+), 16 d
Fixes intendation, whitespace, a typo and renames a variable
(dyn_bc->cluster_bc) to make its meaning clearer and to bring
it more in line with the naming of similar variables.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 103 +++---
1 file ch
Given that in both the seekable as well as the non-seekable mode dynamic
buffers are used to write level 1 elements and that now no seeks are
used in the seekable case any more, the two modes can be combined; as a
consequence, the non-seekable mode automatically inherits the ability to
write CRC-32
Up until e7ddafd515dc9826915b739d0b977a63c21e96af the Matroska muxer
wrote a secondary seek head referencing all the clusters. When this
was changed, a (now completely wrong) comment remained and the unique
remaining seek head was still called main_seekhead. This has been
changed.
Signed-off-by: A
Since 4e3bdf729a80f868b014ceb02901d87198b545a5 there is no reason any
more to treat the seekable and non-seekable cases separate with regards
to the log message for a new cluster. This effectively reverts
d41aeea8a64bab5d7aacd602f7214f95baad109f.
Also improved the log message: "pts 80dts 0" -> "pt
Up until now the EBML Header length field has been written with eight
bytes, although the EBML Header is always so small that only one byte
is needed for it. This patch saves seven bytes for every Matroska/Webm
file.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c| 5
All places where end_ebml_master_crc32_preliminary are used already
check for whether the output is seekable, so the check in the function
is redundant.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/matroskaenc.c
The upper bounds currently used for determining the size of a CuePoint's
length field can be improved somewhat; as a result, a CuePoint
containing three CueTrackPositions will now only need a size field
with one byte length.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 12 ++
The earlier code included the size of the BlockGroup's length field and
the EBML ID in the calculation of the size for the payload and ignored
the size of the duration's length field. This meant that Blockgroups
corresponding to packets with size 2^(7n) - 17 - n - i, i = 0,..., n - 1,
n = 1,..., 8
At this point, ts already includes the ts_offset so that the relative
time written with the cluster is already given by ts - mkv->cluster_pts.
It is this number that needs to fit into an int16_t.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 2 +-
1 file changed, 1 insertion(
Hello,
this patchset is mostly concerned with reducing the unnecessary overhead
of the Matroska muxer; this overhead mostly comes from not using the
minimal amount of bytes when writing the length field of master
elements. The length fields of most level 1 elements are currently
written on eight b
Carl Eugen Hoyos:
> 2019-03-27 12:18 GMT+01:00, Andreas Rheinhardt:
>
>> I have cced Steve for this (I didn't the first time,
>> because I thought that he (as a maintainer) would
>> also be a subscriber to this list).
>
> Everybody welcomes reviews by Steve but I don't
> think he maintains anythi
This commit replaces copying attached pictures by using references to
the already existing buffers.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matros
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index bd0dfee4db..8243b858da 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
This commit adds a check and a corresponding warning whether there
is data beyond the Matroska segment (only reasonable for finite-sized
segments). If everything looks alright, then parsing is stopped as soon
as EOF is reached (in contrast, the current code would always call
matroska_resync at the
By including SimpleBlocks and Blocksgroups twice in the same EbmlSyntax
array (with different semantics), one can reduce the duplication of the
other values.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff
This is important as unknown-sized elements end upon encountering an
unknown EBML ID.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroska.h| 1 +
libavformat/matroskadec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 86968
The new code does not rely on whether the cluster's position is set or
not to infer whether a cluster needs to be closed or not (instead, the
levels are closed during ebml_parse), so there is no need to reset the
cluster's position at all any more. It will be automatically set to the
correct value
This commit changes how levels are handled: If the level used for
ebml_parse ends directly after an element that has been consumed, then
ebml_parse ends the level itself (and any finite-sized levels that end
there as well) and informs the caller via the return value; if the
current level is unknown
Before this commit, the parsing of clusters mixed EBML levels by
allowing elements from different levels in a EbmlSyntax (namely
matroska_cluster_parsing). This has been changed. The level is now
explicitly used to determine how to parse.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matrosk
The earlier code set the level to zero upon seeking and after a
discontinuity although in both cases parsing (re)starts at a level 1
element.
Also set the segment's length to unkown if an error occured in order not
to drop any valid data that happens to be beyond the designated end of
the segment.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index b98e690f01..6fa324c0cc 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1179,7 +1179,6 @@ static
The earlier code had three flaws:
1. The case of an unknown-sized element inside a finite-sized element
(which is against the specifications) was not caught.
2. The error message wasn't helpful: It compared the length of the child
with the offset of the end of the parent and claimed that the firs
Up until now, the SimpleBlock was treated specially: It basically had
its own EBML category and it was also included in the BlockGroup EBML
syntax (although a SimpleBlock must not exist in a BlockGroup according
to the Matroska specifications). The latter fact also meant that
a MatroskaBlock's buff
ebml_read_num had a number of flaws:
1. The check for read errors/EOF was totally wrong. E.g. an EBML number
beginning with the invalid 0x00 would be considered a read error,
although it is just invalid data.
2. The check for read errors/EOF was done just once, after reading the
first byte of the
When the new incremental parser was introduced, the old parser was
kept, because the new parser was unable to handle the way SSA packets
are put into Matroska. But since 2014 (since
c7d8dbad14ed5fa3c217a4fc1790021d6c0b6416) this is no longer needed, so
that the old parser can be completely removed.
Before this commit, the Matroska muxer would read a block when required
to do so, parse the block, create and return the necessary AVPackets and
yet keep the blocks (in a dynamically allocated list), although they
aren't used at all any more. This has been changed. There is no list any
more and the
By default, the data_offset member of the AVFormatInternal of the
AVFormatContext associated with the MatroskaDemuxContext has not been
initialized explicitly by any Matroska-specific function, so that it was
initialized by default to the offset at the end of matroska_read_header,
i.e. usually to t
Every new element of an EbmlList is zeroed initially in
ebml_parse_elem, so that in particular a SimpleBlock's duration is
initialized to zero. Therefore it is unnecessary to initialize this
field again (for SimpleBlocks) in matroska_parse_cluster_incremental.
Signed-off-by: Andreas Rheinhardt
--
and drop the redundant checks contained in ebml_read_uint and
ebml_read_sint.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index f3bc792728..49f8ff40
It is only necessary to zero the initial allocated memory used to store
the size of laced frames if the block used Xiph lacing. Otherwise no
unintialized data was ever used, so use av_malloc instead of av_mallocz.
Also use the correct type for the allocations.
Signed-off-by: Andreas Rheinhardt
-
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 81e9bb9bff..48b1ba3872 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@
The earlier code relied on the length of clusters always being coded on
eight bytes (as is current Matroska muxer behaviour). But there is no
need to rely on this and this commit changes it.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 13 -
1 file changed, 8 ins
Here is a new version. Some of the already sent patches were slightly
modified: The first patch now removes two unused variables and "Improve
length check" has been rewritten. Furthermore, some new patches not
directly needed in order to fix the garbage error message have been
added:
1. The generi
Mark Thompson:
> On 26/11/2018 13:39, Andreas Rheinhardt wrote:
>> This will enable us to change e.g. the parameter sets of H.2645 in ways
>> that would change the parsing process of future units. An example of
>> this is the h264_redundant_pps bsf.
>
> I thought quite a bit more about how the all
67 matches
Mail list logo
