Minimum video length with MKV muxer?

[CryGuy]

Hi,

with the mkv muxer, is there a minimum video length? I've stumbled on a situation where the length was 991 ms and the resulting video file was unusuable (<1 KB). I've uploaded the source file:

https://mega.nz/#!n8pQ1SyC!P5VYPqB_x73uPTwK1DYOYWM2cOmFvhpjhnBIRgdXaPQ

Steps to reproduce:

• Open the source file
• Select from the start to 0.991 s.
• Select mkv muxer
• Select x264 encoder (settings if it matters: medium, film, high, auto, crf=22).
• Transcode

The resulting video file is not usuable. If you switch to MP4 muxer, it works well. Is this a mkv limitation or an ADM issue? Or maybe my lack of skills?

EDIT: Sorry, forgot: Tested with version 2.7.4 release and latest build (190819).

Thanks

[eumagga0x2a]

Is there any practical use for saving such a short sequence? Due to encoder delay, especially with B-frames / High profile enabled, x264 needs to have seen quite a lot of pictures to output at least one compressed frame. Select the Baseline profile if you need to reduce encoder delay to a minimum.

I could not identify any meaningful difference between one and the same bundled libavformat library outputting to MKV or MP4 once x264 was able to output at least one frame, it might be a border case though.

[CryGuy]

You're right, it's exceptionally short. Explanation: I've split the source video into four (logical) parts. First, I encode part 1, then I encode the same part with 10x slow motion (by setting frequency from 30 to 3, then resampling at 30 fps). I do the same with the other parts. It's for showing an animal in slowmo. One of the four parts is indeed only 991 ms short, but the slowmo will be 9,91 s then. So this is intended.

[eumagga0x2a]

Unless the source is a high-speed-burst-recording from a smartphone, resampling a usual 30fps video won't look good. Apart from that, why do you re-encode intermediate steps? Just stack any number of changeFps and resampleFps filters in one go.

[CryGuy]

Slowmo looks as good as intended. I single-stepped through the frames, and that's how I wanted it to look like in the final video. It was for a private purpose for someone that doesn't know how to single-step frames. It was not thought to be published. Sorry, I don't have another source. The result is perfect. It was just that question.
I didn't write I re-encode intermediate steps. I've mentioned the two filters required for that purpose. They are applied in the same transcoding run.

[eumagga0x2a]

Good, then using the baseline profile is the way to go for now.

[eumagga0x2a]

Should be fixed by [x264] Do not give up if we cannot get the next picture before receiving the first compressed image, wait for the queue of buffered frames to become empty, thank you for raising the topic.

[CryGuy]

Good, then using the baseline profile is the way to go for now.

I will do so

Should be fixed by [x264] Do not give up if we cannot get the next picture before receiving the first compressed image, wait for the queue of buffered frames to become empty, thank you for raising the topic.

This is great

Dankeschön!

[CryGuy]

...Just curious: Why is there a difference between the container formats if it's an encoding issue?

[eumagga0x2a]

There should not be any and there was none in my testing (I didn't use your sample, however). Maybe some inadvertent slip during testing like switching from x264 to copy mode?

[CryGuy]

It is reproducable without changing the encoder, but only by switching the muxer.
Now that I do provide a sample, you don't use it.

[eumagga0x2a]

Well, now I disabled locally the patches fixing the issue and followed exactly the steps to reproduce using your sample – no change, in both cases zero frames are stored, no matter MKV or MP4.

With the fix(es) restored, 30 frames are output.

[CryGuy]

Now I do not understand this at all! The problem was there as described. I double-check before posting. Now that you were saying you can't reproduce it, I've tried it again - and I can't reproduce it too. I don't get it. I swear, it was like I said! With MKV, there was no progress bar when transcoding, and the file size was 1 KB. I've only switched to MP4, then there was a progress bar - only for few seconds for this short piece of video, but it was there - and the resulting file was 1,6 MB. It must have been this way, because I've then remuxed this mp4 file to mkv using ffmpeg. When I was narrowing down the problem, the only thing I did was switching forth and back between mp4 and mkv, that's why I was blaming the muxer for it. Hence the title of this thread.

Well, with one thing I was wrong: I've used the "very slow" profile instead of medium, but as I've just checked now again, this is not the decisive point, too.

This just made me angry because I really verified it. I must be missing something.... I'll comeback as soon as I find out what makes the difference. Currently, I'm clueless.

Thanks

[eumagga0x2a]

A fresh MinGW 64 bits nightly has been uploaded (190901) --> https://avidemux.org/nightly/win64/

Re-encoding very short clips using x264 should work there.

Regarding the mystery of x264 managing to output something where it failed to do so right before that, it might have been helpful to have the admlog.txt from that session (at least it would be possible to verify that it was really x264 and not copy, e.g.). If it was really x264, then there must be some massive memory mismanagement (using big swaths of uninitialized memory) somewhere.

[CryGuy]

Unfortunatelly, I don't have the admlog.txt log anymore as I did it last Wednesday.
I had to trancode (not copy) because the markers were not at key frames and I was resampling to 30 fps.

I thought, maybe I've cancelled a previous transcoding run, so that something might not have been cleaned up correctly and it influences the next run. However, I've reproduced this situation too, but to no avail.

Earlier, I started from scratch and did the whole video processing again like I did four days ago. Still, I can't reproduce the problem. I don't get it.

Maybe one day when I'm lying in my bed and don't think about it, I'll have the idea...

Thanks again for the fix.