[FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer
jamrial at gmail.com
Thu Oct 6 17:27:08 EEST 2016
On 10/6/2016 7:29 AM, Michael Niedermayer wrote:
> On Mon, Oct 03, 2016 at 08:36:56PM -0300, James Almer wrote:
>> This patchsets implements the feature requested on ticket #4347.
>> The first three patches are preparation work. The first one isn't
>> strictly related to the implementation, but comes in handy
>> Patches 4 to 11 can be squashed into a single commit before pushing
>> if that's prefered, but for review purposes i split things as one
>> patch per Level 1 element being adapted to write a CRC32 element.
>> Fate tests are updated as needed.
> some questions
> Does this reduce writing speed ? for example when remuxing high
> bitrate data like rawvideo ?
The bulk of the CRC calculation is done once per level 1 element, so it
shouldn't affect remuxing speed in a considerable way. But if preferred,
i could see about adding an option to disable it.
> does this increase latency as in case of streaming ?
> it seemed not from reading the code but iam asking anyway to double
The code mentions the output protocol is not seekable in the case of
streaming. CRC is not calculated and the clusters are written the same
way as before in such scenarios, so it wouldn't make a difference at
> are there any cases where this unreasonably increases memory
> consumption ? (thinking of OOM issues here not a few %)
> probably not but again asking to be sure, you know the code as
> author better ...
Technically, only if the user gives an unreasonable cluster_size_limit
or cluster_time_limit value. But not even then because there are other
checks in the codebase to start new clusters at for example every
keyframe, or when a block's relative timestamp can't be stored as a
signed 2 byte value in the block's header (commit 7923aa0f).
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel