Black video after converting Safe movie

[zer0ish]

After you advised me the other project was abandoned and you were working on this new one, I got it setup in Unraid, just made a custom template.
But it looks like I'm having the same issue with my test movie as the other one.

This is what the Inspect tells me.

I assume this means it's good to go for conversion, but once it's done converting, the audio is there, but no video.
It's as if it stripped the video out and just left audio when played in VLC.

I tested using VLC this time since doing a library scan on Emby/Jellyfin takes longer.

Here are the metrics once it completes:

[cryptochrome]

Hey @zer0ish

That's a bit of an odd one. What I can tell you right from the start: No video was stripped. The conversion screenshot shows this. The tool actually counts and compares the frames of the video tracks between original and converted file during the final verification. If they don't match, you wouldn't get a "Verifying... Success!" message. That means, the video is there and intact.

Let's try and dig in:

First, can you give me some details about the system you use to play the converted file? And also, have you tried something other than VLC?

Next, let's use ffmpeg to decode a few frames of both the original and the converted files to see if it throws any errors. Run these commands (replace path and filenames accordingly):

ffmpeg -v error -ss 00:10:00 -i "/path/to/original.mkv.bak.dovi_convert" -map 0:v:0 -frames:v 300 -f null -

ffmpeg -v error -ss 00:10:00 -i "/path/to/converted.mkv" -map 0:v:0 -frames:v 300 -f null -

This will decode 300 frames from 10 minutes into the video. See if that throws any errors, and if it does, please post here. If you want to make double-sure, run the same commands again, but replace the 00:10:00 part with something like 00:45:00 (this will decode 300 frames at a different timestamp than before).

Lastly, let's grab metadata from both files to see if something is off. Run these two commands and attach the resulting JSON files here:

mkvmerge -J "/path/to/original.mkv.bak.dovi_convert" > original.json
mkvmerge -J "/path/to/converted.mkv" > converted.json

Let me know if you have any questions.

Cheers!

[zer0ish]

While I'm at work, I tested using VLC on a VM.
The VM is running Windows 11.

I also tested using Emby, had to wait for it to scan the library but it did the same thing, black video.

I'm converting it again so I can have it for testing.
I'll reply to the other questions once I have the Original and the Converted one side by side to test with.

It took 34 minutes last time, so I should have a follow up reply in about 45 minutes depending how long those commands take to run.

[zer0ish]

hmm took 74 minutes due to Unraid mover doing it's thing.

I'll have to wait until I get home to finish the testing and answer your questions.
I'm moving everything to an SSD share to make things a bit faster for testing.
Downloading both version to the VM as-well. Should be ready to test once I get home assuming everything is done copying over.

Latest result of the conversion.

To be continued...

[cryptochrome]

No rush. It's getting late here, so I am wrapping up for today.

[zer0ish]

Not sure those commands did anything, nothing in the folder or in the command line:

Here are the commands I did for the .json:

Here are the .json files for each:
original.json
converted.json

[cryptochrome]

Oh wow,

you uncovered a really cool bug. But it's such an edge-case that no one else ever reported it.

First things first:

The two ffmpeg commands you ran showed no errors, that's why there is no output. That's actually what we wanted to see. Good!

Where it gets interesting is with the two JSON files:

Your source file (the original) is not a normal, untouched MakeMKV remux. Something, or someone, transcoded the audio from TrueHD Atmos to stereo AAC, while retaining the old track name. That AAC encoding introduced an audio delay of about 21 ms and FFmpeg also wrote the video track with a 21 ms start offset

This is where the bug in dovi_convert comes in.

The original reports:

minimum_timestamp: 21000000
duration: 7814570000000

Those timestamp values are nanoseconds, so the video starts 21 ms after zero.

dovi_convert takes minimum_timestamp and simply passes it - unchanged - to mkvmerge (the tool used to build the new remux). The problem: mkvmerge expects milliseconds, not nanoseconds.

So when the remux is built, instead of starting the video 21,000,000 nanoseconds (or 21 ms) after 0, it starts 21,000,000 milliseconds later, or 5 hours and 50 minutes.

Your VLC player is probably showing you a runtime of approx. 8 hours. If it does, try seeking beyond the 5 hr 50 min. mark - Pretty sure you'll see the video there.

I will fix this with the next release. It's fairly easy, I just need to convert and normalize nanoseconds to milliseconds in the corresponding muxing step.

Out of curiosity: Did you create this remux yourself? Never seen something like this before. Are all your videos muxed this way?

[zer0ish]

As for the did I remux it?

Yes, when I get 4k movies they used to force transcoding on Emby and Jellyfin or just throw errors in their players.
The error was always about aac 5.1 and even if I tried EAC-3 same issue. Now I just remux into 2 channel stereo and all the 4k movies that aren't DV Profile 7 work perfectly. This is why I'm wanting to get these DV profile 7's on my system into DV 8.

This is all automated in tdarr.

Might not make sense, but it's been working, direct playing 4K on all my various devices in home and out of home is the goal.

I can certainly live with my LG C5 TV showing HDR instead of Dolby Vision on some of the 4K content. If the movie still looks great and it can't be converted, it's not a big deal.

Glad I found a real bug that might or might not be my fault 🤣

EDIT: Yup, 8hours and the video is there at around the time you said lol.

[cryptochrome]

Thanks for confirming. I'll get this fixed so you can use it on all your special remuxes :) I'll update this thread when it's done. Might not get to it before the weekend, though.

[zer0ish]

All good, no rush.

Thanks.