Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

2020-03-09 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> On Fri, Feb 28, 2020 at 6:10 AM Andreas Rheinhardt <
>> andreas.rheinha...@gmail.com> wrote:
>>
>>> On Tue, Feb 25, 2020 at 2:24 PM Andreas Rheinhardt <
>>> andreas.rheinha...@gmail.com> wrote:
>>>
 Andreas Rheinhardt:
> Andreas Rheinhardt:
>> Andreas Rheinhardt:
>>> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
>>> beginning referencing the main level 1 elements (i.e. not the Clusters)
>>> and one at the end, referencing the Clusters. This second SeekHead was
>>> useless and has therefore been removed. Yet the SeekHead-related
>>> functions and structures are still geared towards this usecase: They
>>> are built around an allocated array of variable size that gets
>>> reallocated every time an element is added to it although the maximum
>>> number of Seek entries is a small compile-time constant, so that one 
>>> should
>>> rather include the array in the SeekHead structure itself; and said
>>> structure should be contained in the MatroskaMuxContext instead of being
>>> allocated separately.
>>>
>>> The earlier code reserved space for a SeekHead with 10 entries, although
>>> we currently write at most 6. Reducing said number implied that every
>>> Matroska/Webm file will be 84 bytes smaller and required to adapt
>>> several FATE tests; furthermore, the reserved amount overestimated the
>>> amount needed for for the SeekHead's length field and how many bytes
>>> need to be reserved to write a EBML Void element, bringing the total
>>> reduction to 89 bytes.
>>>
>>> Signed-off-by: Andreas Rheinhardt 
>>> ---
>>
>> Ping.
>>
>> - Andreas
>>
> Ping (the actual patch (which has been omitted for brevity) is here:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/256997.html).
>
> - Andreas
>
 Another ping.

 - Andreas

>>>
>>> Ping.
>>>
>>> - Andreas
>>>
>>
>> Ping.
>>
>> - Andreas
>>
> Ping.
> 
> - Andreas
> 
Ping.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

2020-03-05 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> On Fri, Feb 28, 2020 at 6:10 AM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
> 
>> On Tue, Feb 25, 2020 at 2:24 PM Andreas Rheinhardt <
>> andreas.rheinha...@gmail.com> wrote:
>>
>>> Andreas Rheinhardt:
 Andreas Rheinhardt:
> Andreas Rheinhardt:
>> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
>> beginning referencing the main level 1 elements (i.e. not the Clusters)
>> and one at the end, referencing the Clusters. This second SeekHead was
>> useless and has therefore been removed. Yet the SeekHead-related
>> functions and structures are still geared towards this usecase: They
>> are built around an allocated array of variable size that gets
>> reallocated every time an element is added to it although the maximum
>> number of Seek entries is a small compile-time constant, so that one 
>> should
>> rather include the array in the SeekHead structure itself; and said
>> structure should be contained in the MatroskaMuxContext instead of being
>> allocated separately.
>>
>> The earlier code reserved space for a SeekHead with 10 entries, although
>> we currently write at most 6. Reducing said number implied that every
>> Matroska/Webm file will be 84 bytes smaller and required to adapt
>> several FATE tests; furthermore, the reserved amount overestimated the
>> amount needed for for the SeekHead's length field and how many bytes
>> need to be reserved to write a EBML Void element, bringing the total
>> reduction to 89 bytes.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>
> Ping.
>
> - Andreas
>
 Ping (the actual patch (which has been omitted for brevity) is here:
 https://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/256997.html).

 - Andreas

>>> Another ping.
>>>
>>> - Andreas
>>>
>>
>> Ping.
>>
>> - Andreas
>>
> 
> Ping.
> 
> - Andreas
> 
Ping.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

2020-03-02 Thread Andreas Rheinhardt
On Fri, Feb 28, 2020 at 6:10 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> On Tue, Feb 25, 2020 at 2:24 PM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> Andreas Rheinhardt:
>> > Andreas Rheinhardt:
>> >> Andreas Rheinhardt:
>> >>> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
>> >>> beginning referencing the main level 1 elements (i.e. not the
>> Clusters)
>> >>> and one at the end, referencing the Clusters. This second SeekHead was
>> >>> useless and has therefore been removed. Yet the SeekHead-related
>> >>> functions and structures are still geared towards this usecase: They
>> >>> are built around an allocated array of variable size that gets
>> >>> reallocated every time an element is added to it although the maximum
>> >>> number of Seek entries is a small compile-time constant, so that one
>> should
>> >>> rather include the array in the SeekHead structure itself; and said
>> >>> structure should be contained in the MatroskaMuxContext instead of
>> being
>> >>> allocated separately.
>> >>>
>> >>> The earlier code reserved space for a SeekHead with 10 entries,
>> although
>> >>> we currently write at most 6. Reducing said number implied that every
>> >>> Matroska/Webm file will be 84 bytes smaller and required to adapt
>> >>> several FATE tests; furthermore, the reserved amount overestimated the
>> >>> amount needed for for the SeekHead's length field and how many bytes
>> >>> need to be reserved to write a EBML Void element, bringing the total
>> >>> reduction to 89 bytes.
>> >>>
>> >>> Signed-off-by: Andreas Rheinhardt 
>> >>> ---
>> >>
>> >> Ping.
>> >>
>> >> - Andreas
>> >>
>> > Ping (the actual patch (which has been omitted for brevity) is here:
>> > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/256997.html).
>> >
>> > - Andreas
>> >
>> Another ping.
>>
>> - Andreas
>>
>
> Ping.
>
> - Andreas
>

Ping.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

2020-02-27 Thread Andreas Rheinhardt
On Tue, Feb 25, 2020 at 2:24 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> Andreas Rheinhardt:
> > Andreas Rheinhardt:
> >> Andreas Rheinhardt:
> >>> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
> >>> beginning referencing the main level 1 elements (i.e. not the Clusters)
> >>> and one at the end, referencing the Clusters. This second SeekHead was
> >>> useless and has therefore been removed. Yet the SeekHead-related
> >>> functions and structures are still geared towards this usecase: They
> >>> are built around an allocated array of variable size that gets
> >>> reallocated every time an element is added to it although the maximum
> >>> number of Seek entries is a small compile-time constant, so that one
> should
> >>> rather include the array in the SeekHead structure itself; and said
> >>> structure should be contained in the MatroskaMuxContext instead of
> being
> >>> allocated separately.
> >>>
> >>> The earlier code reserved space for a SeekHead with 10 entries,
> although
> >>> we currently write at most 6. Reducing said number implied that every
> >>> Matroska/Webm file will be 84 bytes smaller and required to adapt
> >>> several FATE tests; furthermore, the reserved amount overestimated the
> >>> amount needed for for the SeekHead's length field and how many bytes
> >>> need to be reserved to write a EBML Void element, bringing the total
> >>> reduction to 89 bytes.
> >>>
> >>> Signed-off-by: Andreas Rheinhardt 
> >>> ---
> >>
> >> Ping.
> >>
> >> - Andreas
> >>
> > Ping (the actual patch (which has been omitted for brevity) is here:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/256997.html).
> >
> > - Andreas
> >
> Another ping.
>
> - Andreas
>

Ping.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

2020-02-25 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> Andreas Rheinhardt:
>>> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
>>> beginning referencing the main level 1 elements (i.e. not the Clusters)
>>> and one at the end, referencing the Clusters. This second SeekHead was
>>> useless and has therefore been removed. Yet the SeekHead-related
>>> functions and structures are still geared towards this usecase: They
>>> are built around an allocated array of variable size that gets
>>> reallocated every time an element is added to it although the maximum
>>> number of Seek entries is a small compile-time constant, so that one should
>>> rather include the array in the SeekHead structure itself; and said
>>> structure should be contained in the MatroskaMuxContext instead of being
>>> allocated separately.
>>>
>>> The earlier code reserved space for a SeekHead with 10 entries, although
>>> we currently write at most 6. Reducing said number implied that every
>>> Matroska/Webm file will be 84 bytes smaller and required to adapt
>>> several FATE tests; furthermore, the reserved amount overestimated the
>>> amount needed for for the SeekHead's length field and how many bytes
>>> need to be reserved to write a EBML Void element, bringing the total
>>> reduction to 89 bytes.
>>>
>>> Signed-off-by: Andreas Rheinhardt 
>>> ---
>>
>> Ping.
>>
>> - Andreas
>>
> Ping (the actual patch (which has been omitted for brevity) is here:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/256997.html).
> 
> - Andreas
> 
Another ping.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

2020-02-22 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
>> beginning referencing the main level 1 elements (i.e. not the Clusters)
>> and one at the end, referencing the Clusters. This second SeekHead was
>> useless and has therefore been removed. Yet the SeekHead-related
>> functions and structures are still geared towards this usecase: They
>> are built around an allocated array of variable size that gets
>> reallocated every time an element is added to it although the maximum
>> number of Seek entries is a small compile-time constant, so that one should
>> rather include the array in the SeekHead structure itself; and said
>> structure should be contained in the MatroskaMuxContext instead of being
>> allocated separately.
>>
>> The earlier code reserved space for a SeekHead with 10 entries, although
>> we currently write at most 6. Reducing said number implied that every
>> Matroska/Webm file will be 84 bytes smaller and required to adapt
>> several FATE tests; furthermore, the reserved amount overestimated the
>> amount needed for for the SeekHead's length field and how many bytes
>> need to be reserved to write a EBML Void element, bringing the total
>> reduction to 89 bytes.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
> 
> Ping.
> 
> - Andreas
> 
Ping (the actual patch (which has been omitted for brevity) is here:
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/256997.html).

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

2020-02-19 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
>> beginning referencing the main level 1 elements (i.e. not the Clusters)
>> and one at the end, referencing the Clusters. This second SeekHead was
>> useless and has therefore been removed. Yet the SeekHead-related
>> functions and structures are still geared towards this usecase: They
>> are built around an allocated array of variable size that gets
>> reallocated every time an element is added to it although the maximum
>> number of Seek entries is a small compile-time constant, so that one should
>> rather include the array in the SeekHead structure itself; and said
>> structure should be contained in the MatroskaMuxContext instead of being
>> allocated separately.
>>
>> The earlier code reserved space for a SeekHead with 10 entries, although
>> we currently write at most 6. Reducing said number implied that every
>> Matroska/Webm file will be 84 bytes smaller and required to adapt
>> several FATE tests; furthermore, the reserved amount overestimated the
>> amount needed for for the SeekHead's length field and how many bytes
>> need to be reserved to write a EBML Void element, bringing the total
>> reduction to 89 bytes.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
> 
> Ping.
> 
> - Andreas
> 
Ping.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

2020-02-16 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
> beginning referencing the main level 1 elements (i.e. not the Clusters)
> and one at the end, referencing the Clusters. This second SeekHead was
> useless and has therefore been removed. Yet the SeekHead-related
> functions and structures are still geared towards this usecase: They
> are built around an allocated array of variable size that gets
> reallocated every time an element is added to it although the maximum
> number of Seek entries is a small compile-time constant, so that one should
> rather include the array in the SeekHead structure itself; and said
> structure should be contained in the MatroskaMuxContext instead of being
> allocated separately.
> 
> The earlier code reserved space for a SeekHead with 10 entries, although
> we currently write at most 6. Reducing said number implied that every
> Matroska/Webm file will be 84 bytes smaller and required to adapt
> several FATE tests; furthermore, the reserved amount overestimated the
> amount needed for for the SeekHead's length field and how many bytes
> need to be reserved to write a EBML Void element, bringing the total
> reduction to 89 bytes.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---

Ping.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

2020-02-10 Thread Andreas Rheinhardt
Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
beginning referencing the main level 1 elements (i.e. not the Clusters)
and one at the end, referencing the Clusters. This second SeekHead was
useless and has therefore been removed. Yet the SeekHead-related
functions and structures are still geared towards this usecase: They
are built around an allocated array of variable size that gets
reallocated every time an element is added to it although the maximum
number of Seek entries is a small compile-time constant, so that one should
rather include the array in the SeekHead structure itself; and said
structure should be contained in the MatroskaMuxContext instead of being
allocated separately.

The earlier code reserved space for a SeekHead with 10 entries, although
we currently write at most 6. Reducing said number implied that every
Matroska/Webm file will be 84 bytes smaller and required to adapt
several FATE tests; furthermore, the reserved amount overestimated the
amount needed for for the SeekHead's length field and how many bytes
need to be reserved to write a EBML Void element, bringing the total
reduction to 89 bytes.

Signed-off-by: Andreas Rheinhardt 
---
Resending (and pinging) this because the lavf-fate-av1.mkv-FATE-test
(which didn't exist at the time the first version has been sent) also
needs to be updated. The rest of the patchset is already compatible with
the new test.

 libavformat/matroskaenc.c| 119 ---
 tests/fate/matroska.mak  |   2 +-
 tests/fate/wavpack.mak   |   4 +-
 tests/ref/fate/aac-autobsf-adtstoasc |   4 +-
 tests/ref/fate/binsub-mksenc |   2 +-
 tests/ref/fate/rgb24-mkv |   4 +-
 tests/ref/lavf-fate/av1.mkv  |   4 +-
 tests/ref/lavf/mka   |   4 +-
 tests/ref/lavf/mkv   |   4 +-
 tests/ref/lavf/mkv_attachment|   4 +-
 tests/ref/seek/lavf-mkv  |  44 +-
 11 files changed, 73 insertions(+), 122 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 42f21eae8b..99ea3c6bf1 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -57,6 +57,10 @@
 #include "libavcodec/mpeg4audio.h"
 #include "libavcodec/internal.h"
 
+/* Level 1 elements we create a SeekHead entry for:
+ * Info, Tracks, Chapters, Attachments, Tags and Cues */
+#define MAX_SEEKHEAD_ENTRIES 6
+
 typedef struct ebml_master {
 int64_t pos;///< absolute offset in the containing 
AVIOContext where the master's elements start
 int sizebytes;  ///< how many bytes were reserved for 
the size
@@ -69,11 +73,9 @@ typedef struct mkv_seekhead_entry {
 
 typedef struct mkv_seekhead {
 int64_t filepos;
-int64_t segment_offset; ///< the file offset to the 
beginning of the segment
-int reserved_size;  ///< -1 if appending to file
-int max_entries;
-mkv_seekhead_entry  *entries;
+mkv_seekhead_entry  entries[MAX_SEEKHEAD_ENTRIES];
 int num_entries;
+int reserved_size;
 } mkv_seekhead;
 
 typedef struct mkv_cuepoint {
@@ -136,7 +138,7 @@ typedef struct MatroskaMuxContext {
 int64_t cluster_pts;
 int64_t duration_offset;
 int64_t duration;
-mkv_seekhead*seekhead;
+mkv_seekheadseekhead;
 mkv_cues*cues;
 mkv_track   *tracks;
 mkv_attachments *attachments;
@@ -396,10 +398,6 @@ static void mkv_deinit(AVFormatContext *s)
 ffio_free_dyn_buf(&mkv->tracks_bc);
 ffio_free_dyn_buf(&mkv->tags_bc);
 
-if (mkv->seekhead) {
-av_freep(&mkv->seekhead->entries);
-av_freep(&mkv->seekhead);
-}
 if (mkv->cues) {
 av_freep(&mkv->cues->entries);
 av_freep(&mkv->cues);
@@ -412,61 +410,33 @@ static void mkv_deinit(AVFormatContext *s)
 }
 
 /**
- * Initialize a mkv_seekhead element to be ready to index level 1 Matroska
- * elements. If a maximum number of elements is specified, enough space
- * will be reserved at the current file location to write a seek head of
- * that size.
- *
- * @param segment_offset The absolute offset to the position in the file
- *   where the segment begins.
- * @param numelements The maximum number of elements that will be indexed
- *by this seek head, 0 if unlimited.
+ * Initialize the SeekHead element to be ready to index level 1 Matroska
+ * elements. Enough space to write MAX_SEEKHEAD_ENTRIES SeekHead entries
+ * will be reserved at the current file location.
  */
-static mkv_seekhead *mkv_start_seekhead(AVIOContext *pb, int64_t 
segment_offset,
-int numelements)
+static void mkv_start_seekhead(MatroskaMuxContext *mkv, AVIOContext *pb)
 {
-mkv_seekhead *new_seekhead = av_mallocz(sizeof(mkv_seekhead));
-