Failure in step 2 (Muxing)

[juzun31]

Hi, I'm currently trying out the tool to convert my 4k Bluray Remuxes to DV Profile 8.1 so the DV information is playable on Apple TV.
The first step (Converting) is successful after around 15min, but then at step 2 (Muxing) it immediately fails. The debug log shows the following message:

"Track 0: Mkvmerge found data in this video track that cannot be parsed. The error message was:
Operation not supported"

The original file seems to be fine and plays without any issues. The last message before the failure line is the following:

"Track 0: Information about the aspect ratio was extracted from the video bitstream. The display dimensions were set to 3840/2160."

Is this any indication what the problem could be? Unfortunately, the log file doesn't say anything more.

Does anyone have an idea or was facing a similar problem?

[cryptochrome]

Hey @juzun31, it sounds like mkvmerge has trouble parsing some data in the converted p81 video stream. Unfortunately, the error messages mkvmerge produces are vague. "Operation not supported" could mean different things.

Can you give me some more information about your system?

Are you running the container version? Or did you install directly on your system? What OS? Where are the files located (NAS or local HD)? Does this happen with all your files or just one/some? Also, please provide the exact dovi_convert command you used.

If you are not using the container version, please make sure that all the dependencies like dovi_tool, mkvmerge etc. are up to date.

Last but not least, the full debug log of dovi_convert could help. Please attach it (you can remove/replace filenames if you have privacy concerns).

Cheers

[juzun31]

Hi @cryptochrome, thanks for your thoughts.

The first two commands unfortunately don't show any output.

This is the memory and swap information:

               gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:       13Gi       4,5Gi       4,9Gi       575Mi       4,9Gi       8,9Gi
Auslager:      2,0Gi        33Mi       2,0Gi

NAME      TYPE SIZE  USED PRIO
/swapfile file   2G 33,3M   -2

dovi_tool is version 2.3.3
mkvmerge is version v100.0 ('Do Hot Girls Like Chords') 64-bit

I will take a look into the docker version to run it on my NAS directly this afternoon. It totally makes sense regarding the bottleneck, and my NAS should be powerful enough.

[cryptochrome]

Ok, I think we can pretty much rule out memory and version issues.

Let's see if you run into the same problem using the Docker version. If you do, we need to take a closer look at your source files. It's possible there is something in them that is tripping up mkvmerge.

Before you do that, though, we have one last thing we can try:

Use dovi_convert's --safe flag for conversion. It will use a different method to stream data from ffmpeg into dovi_tool. It is designed to handle some rare Blueray discs that use "seamless branching". Since I don't know which movies you are trying to convert, it's worth a shot:

dovi_convert convert movie.mkv --safe

Please note that this will be slower than the normal conversion, so it's best to run this with a local file, not over NAS.

[juzun31]

Let's see if you run into the same problem using the Docker version.

So I just set up the Docker version on my NAS and converted this file successfully in around 15min total, so I think it has to be some problem on my local Linux machine. I will use the Docker version on NAS from now on, especially since I don't have to stream the information over smb to my local machine first.

Nevertheless, I did a try locally with --safe, but this time it even failed at Step 2/4 with "Safe Mode Failed" after 30 seconds.
dovi_convert_debug.log

Debug log says that there is not enough space, but I don't think that's right. The original file is around 25GB, and I have around 50GB of free space.

[cryptochrome]

Glad to hear it works with the Docker container. Explore some of its setup options like temp storage on SSD for faster operations (full docs at docs.doviconvert.com)

As for disk space: Not sure why I didn't think of that earlier, but if you really only have 50 GB free space, that explains a lot. The original file is kept during conversion, and a new remux is created with roughly the same file size, plus some larger temp files. It would also explain why the log file got truncated.

So that was the most likely culprit. With --safe enabled, you hit that limit earlier, because instead of piping the movie data into dovi_tool, it stores it on disk, first.

Pretty sure if you tried again locally with a larger disk, it wouldn't crap out.

Either way, glad you got it working now. Happy converting :)

[juzun31]

That makes sense then. I just assumed the space is enough :D

Will definitely look into the temp storage on SSD, but so far I'm very happy with the converting, it completely does what I expected.

Thanks for your quick help here and for the tool!

[cryptochrome]

You're welcome! :)

[juzun31]

Don‘t want to open a new discussion so I hope it‘s fine here @cryptochrome .

I used the tool for some files and worked fine for the most part. But there are some episodes of Game of Thrones for example where some selected scenes don‘t seem to have color or brightness information. The picture is very grey tinted.
But that‘s only for a few seconds/scenes. Like 10 to 20 seconds per episode.

What can cause this? Is there any way to fix this?

[cryptochrome]

@juzun31 are these Bluray remuxes? If so, are the originals with a dovi FEL or MEL? What does dovi_convert scan|inspect say in terms of verdict?

Without knowing more, I'd say there may be a FEL that does have corrections that get lost when the FEL is stripped. AFAIK, some GOT episodes are particularly challenging in some very dark scenes. A dovi FEL can have corrections for such scenes.