After some more testing suggested by compn:
- Checking the timestamps of the packets (both dts and pts) -> the
patch doesn't change them
- Checking mp4->mkv conversion: before/after produces the same binary
file, except for some padding bytes in the header
- Checking a MOV with many streams: teste
AVBufferPool is actually super lazy. It does not allocate N buffers at
initialization. So for images, in all three cases (per-stream,
per-media, and no pool), the behaviour is the same : 1 av_malloc per
stream.
To be sure, I ran more tests:
On image1.heic (48-streams), as reported by massif with `
On 11/24/2024 8:52 PM, compn wrote:
On Sun, 24 Nov 2024 18:14:03 +0100
Arnaud Masserann wrote:
Good question. I just benchmarked all the .mov files in the samples repo.
On average, there is a 1.3x speedup. A few files are slower, but 75%
of the files have at least a 1.11x speedup, and 25% of t
On Sun, 24 Nov 2024 18:14:03 +0100
Arnaud Masserann wrote:
> Good question. I just benchmarked all the .mov files in the samples repo.
> On average, there is a 1.3x speedup. A few files are slower, but 75%
> of the files have at least a 1.11x speedup, and 25% of the files have
> at least 1.49x.
>
Hi,
On Sun, Nov 24, 2024 at 12:25 PM Arnaud Masserann
wrote:
> There is no 32-stream limit.
> Each AVBufferPool needs to be initialized with a fixed allocation
> size. So, the 32 pools are for 1^1 bit allocations, 1^2 bit
> allocations, ...2^32 bit allocations. See mov_pool_get in the patch.
>
>
On 11/24/2024 2:31 PM, James Almer wrote:
On 11/22/2024 2:46 PM, Arnaud Masserann wrote:
Most demuxers allocate a new buffer for each packet.
For MOV, this can be problematic, because of some high-bitrate
codecs like ProRes/HAPQ/NotchLC.
Use pools of buffer instead.
For some test media, demuxi
On 11/22/2024 2:46 PM, Arnaud Masserann wrote:
Most demuxers allocate a new buffer for each packet.
For MOV, this can be problematic, because of some high-bitrate
codecs like ProRes/HAPQ/NotchLC.
Use pools of buffer instead.
For some test media, demuxing goes from 20ms/frame to 11ms/frame,
clos
There is no 32-stream limit.
Each AVBufferPool needs to be initialized with a fixed allocation
size. So, the 32 pools are for 1^1 bit allocations, 1^2 bit
allocations, ...2^32 bit allocations. See mov_pool_get in the patch.
This is why moving pools[32] to MOVContext could be ok: audio packets
woul
Good question. I just benchmarked all the .mov files in the samples repo.
On average, there is a 1.3x speedup. A few files are slower, but 75%
of the files have at least a 1.11x speedup, and 25% of the files have
at least 1.49x.
Outliers include openquicktime/aletrek-tga-8bit.mov (0.8x, so slower)
Hi Arnaud,
On Fri, Nov 22, 2024 at 1:08 PM Arnaud Masserann
wrote:
> - Should the pools be per-stream (in MOVStreamContext) or per file (in
> MOVContext) ?
>
I'm assuming the per-stream is because their bitrates (and packet sizes)
will typically be substantially different. For example, video wi
On Fri, 22 Nov 2024 18:46:19 +0100
Arnaud Masserann wrote:
> Most demuxers allocate a new buffer for each packet.
> For MOV, this can be problematic, because of some high-bitrate
> codecs like ProRes/HAPQ/NotchLC.
>
> Use pools of buffer instead.
>
> For some test media, demuxing goes from 20ms
A few questions:
- Should the pools be per-stream (in MOVStreamContext) or per file (in
MOVContext) ?
- I added an av_get_pooled_packet(AVBufferPool*) function in the
avformat API. This might be undesirable. Possible alternatives:
- Adding a av_get_pooled_packet(AVBufferPool*[32]) function
inst
Most demuxers allocate a new buffer for each packet.
For MOV, this can be problematic, because of some high-bitrate
codecs like ProRes/HAPQ/NotchLC.
Use pools of buffer instead.
For some test media, demuxing goes from 20ms/frame to 11ms/frame,
close to the perf of ReadFile (10ms/frame), making it
13 matches
Mail list logo
