mp4muxer hangs for a long time with no disk activity but eventually succeeds

[MastaG]

After upgrading my OS to Fedora 32 the mp4muxer seems to hang a long time when creating profile 7 mp4 muxes.

mp4muxer --dv-profile 7 -i BL.hevc -i EL.hevc -i dolby.ac3 -o movie.mp4

It could be due to the upgrade from GCC 9 to 10, but I don't know.

[MastaG]

Same with clang 10.. it just waits very very very long (over 2 hours) to mux these layers.
Any way to get some debug info on that the thing is doing?

[ShaoWeiguo]

What's the duration of the content?

[ShaoWeiguo]

The purpose of this project is to help Dolby's customers/partners to understand how to implement Dolby's technology in theirs existing system. It's just the example.

[cgorlla]

I am fairly sure this is normal behavior. The periods that show no disk activity are seen on my W10 machine as well. I believe it encodes a portion in memory then writes it.

[ShaoWeiguo]

@cgorlla Sorry, I don't get your point. Could you give more information?

[cgorlla]

I was speaking to @MastaG’s issue—I don't think it's an issue it all. It seems to just be encoding while it's not writing anything to the disk, then it writes the encoded file to the disk. Obviously you would know more than me though!

[MastaG]

Well I'm going to give the precompiled windows binary a shot tomorrow.
I think with version 1.0.1 something broke. Because multiple members reported the same.

We use the tool to remux Blu-ray into mp4 container.
Which is bl + el + AC3 audio (profile 7) but that does not work any longer.
Mp4muxer sits there for hours doing nothing and the resulting file does not play..

Tomorrow I'll also do some more testing using an older revision to see if I can bisect the commit.

[MastaG]

Well I wasn't able to bisect the commit yet.
But version 1.0.1 broke profile 7 muxes.

I've tested the initial 1.0.0 windows 64 bit binary by demuxing the Blu-ray disc of Gemini Man.
I've used the following options:
--dv-profile 7 -i BL.hevc -i EL.hevc -i audio.ac3 --media-lang eng -o Gemini_Man.mp4

Where:
BL.hevc is the 4k HDR10 base layer
EL.hevc is the Dolby Vision enhanced layer
audio.ac3 is the core AC3 5.1 audio extracted from the TrueHD track

Now for this use case it takes long on both versions of mp4muxer, probably because the movie uses a full enhanced layer and it's 60fps instead of 24.

However the resulting file produced with version 1.0.0 plays fine on my TV and triggers DV.
The resulting file produced with 1.0.1 doesn't play at all.

[cgorlla]

@MastaG very interesting. Have you tried yusesope’s tool to make a single layer .hevc from a BL and EL? And then put it through the new MP4Muxer? Curious to see if it works.

[ShaoWeiguo]

Please have a try with @cgorlla suggestion, and it shall work.

[MastaG]

@cgorlla I'll try that out as soon as possible.
So merge both layers together in mode 1 (BL+EL+RPU) and then mux the output with --dv-proile 7?

[ano2020]

Hi there,

same problem here (win 8.1):

1. mp4muxer starts reading the BL HEVC file and the ac3 file and writes out to user tmp, while memory of proc increases
2. then for me something strange happens: regarding to procmon (Sysinternals Tool) the mp4muxer proc does a "read file" operation of itself (path-to\mp4muxer.exe)
3. After that "read file" operation, the memory of the proc decreases and there is no i/o disk activity anymore; the proc then operates at about 25% CPU usage, which normally idicates a hunging proc

Maybe anyone can post a link to the v1.0.0 windows binary to test if it works with that version?

Thanks in advance.
ano2020

[ano2020]

Update to my last post:

mp4muxer v1.0.1 "hungs" for a while, but then continues to work. Was able to create a singe track dual layer mp4 file which plays with DV on my LG C7 TV with plex app or "LG Player" after using yusesope's tool (which creates the singe track dual layer .hevc file for mp4muxer).