Windows - Streaming using matroska muxer: CPU usage increases over time

[MariusSchipper]

Summary of the bug:
When transcoding from raw video to mjpeg encapsulated in matroska on Windows 7 64bit OS, then CPU usage increases over time. After 12 hours, approx. 2-4 times more CPU time is necessary to get the same amount of work done.

How to reproduce:

ffmpeg -f lavfi -i testsrc=size=720x576:rate=50 -pix_fmt yuv420p -vcodec mjpeg -s 360x288 -qscale:v 5 -f matroska - | ffplay -i -

ffmpeg version: Static from 30-06-2015 via Zeranoe.com

[Carl Eugen Hoyos]

Is this only reproducible with matroska output or also with -f mjpeg?
I would assume that the matroska muxer needs resources to store the index and similar at the end of transcoding.

[MariusSchipper]

I will test this overnight and then post the result.

[MariusSchipper]

I ran four tests in total over 12h:

• mjpeg video coder + matroska muxer: CPU usage increases
• mjpeg video coder + mjpeg muxer: CPU usage does NOT increase
• mjpeg video coder + avi muxer: CPU usage does NOT increase
• mpeg1 video coder + mpeg1 muxer: CPU usage does NOT increase

=> Problem is related to matroska usage:

• Isn't the matroska format suitable for streaming?
• What exactly causes the additional work to do?
• Is this a bug or a property of the matroska muxer?

[Carl Eugen Hoyos]

Please test if attached patch improves the issue.

[MariusSchipper]

Thanks for the quick patch, cehoyos!

Unfortunately I do not have the toolchain installed to apply & compile the patch to a windows binary.

Could you carry out the testing instead?

[Carl Eugen Hoyos]

Replying to MariusSchipper:

Thanks for the quick patch, cehoyos!

Unfortunately I do not have the toolchain installed to apply & compile the patch to a windows binary.

Could you carry out the testing instead?

No (I cannot even reproduce your original issue).
I suggest you install current MSYS and try a default compilation.

[Hendrik]

Checks around mkv_add_seekhead_entry are not required, it does not actually write anything itself, similarly mkv_add_cuepoint does not write anything to the file, and the actual writing is protected by a seekable check.

For the OP, try adding a "-live 1" option to the ffmpeg command, and see if it changes anything.

[Carl Eugen Hoyos]

Replying to heleppkes:

Checks around mkv_add_seekhead_entry are not required,

it does not actually write anything itself, similarly mkv_add_cuepoint does not write anything to the file

Of course not.

But it does allocate memory, or do I misunderstand the code?

[Josef Meier]

This command line:

ffmpeg -f lavfi -i testsrc=size=720x576:rate=25 -pix_fmt yuv420p -vcodec mjpeg -s 360x288 -qscale:v 5 -f matroska -live 1 - | ffplay -i - -window_title M-JPEG_Live

(with the option '-live 1') didn't resolve the issue.

The CPU load increased from 1% to 13% over 24 hours. It really seems as if there's a problem with the matroska container.

-f mpeg1video

and

-f mjpeg

work like a charm. The problem with reproducing this effect is in my opinion, that it occurs only after a few hours and it seems as if cpu load increases not linear but exponential after some point in time.

[MariusSchipper]

cehoyos, I finally tested your suggested patch: It works! CPU load does NOT increase anymore!

When will it be applied to the official version?

[Carl Eugen Hoyos]

Patch sent:
​http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/195352

[Carl Eugen Hoyos]

A simplified version of the patch was applied as da46370e94aa9a9225532ac63c5fc7c1259ca837
Thank you for the report and the testing!