A new dovi_tool release would be welcome for use in DGDemux

[videoh]

The --remove-eos option was committed by quietvoid. I have built and tested dovi_tool with it and it works fine. I want to release a new DGDemux with a formal release of dovi_tool supporting --remove-eos, rather than using my own build. So a new release would be greatly appreciated. Thank you!

[quietvoid]

Most likely this weekend.

[videoh]

Thank you!

[videoh]

May I ask what motivated you to add the --remove-eos option? Is there some online discussion/analysis of the issue it is intended to address? Thank you.

[manuelrn]

I am also interested to know more about this. And to know if it is advisable to remove EOS/EOB NALUs or not.

If I'm not mistaken, these NALUs indicate end of sequence and end of bitstream and therefore are only present in the last frame, that is, at the end of the video. I guess they indicate to the player the end of playback, or something like that.

Then I suppose that maybe there could be problems with some seamless branching discs, when some of these discs contain the EOS/EOB NALUs at the end of each frame of each m2ts file instead of only having a single EOS/EOB NALUs at the last m2ts, that is, at the end of the video actually, as it would happen with any other normal disc that is not a seamless branching disc.

So, by having intermediate EOS/EOB NALUs in the middle of the video instead of having only a single one at the end as I guess it should be correct, in case this indicates the end of the playback as I said before (which I don't know, just guessing) maybe it could cause problems with some players that when reading these NALUs try to stop the video playback or something like that and then it could cause in those timestamps artifacts in the image or something similar. Could it be? I don't know, I'm just guessing.

By the way @quietvoid, I remember years ago I told you about this in the MakeMKV forums. I told you that in the seamless branching discs maybe the video could cause problems in case the video had several EOS/EOB NALUs in the middle of the video instead of just a single EOS/EOB NALUs at the end. Which I repeat again that I don't know, it was just an assumption, although I still think the same today.
Here is the message:
https://forum.makemkv.com/forum/viewtopic.php?f=12&t=18602&p=121965#p121965

In case this is finally the case, would it be possible to implement dovi_tool to behave the way I told you in that message years ago?
That is, omit all intermediate EOS/EOB NALUs and keep only the last one. I still think that would be the most coherent and correct thing to do. EOS/EOB NALUs should not exist in intermediate frames, only in the last frame, then I guess the ideal would be that every time dovi_tool finds an EOS/EOB NALUs it checks if it is the end of the video and in case it is not the end of the video then it omits it and in case it is the end of the video then it writes it.

So I suppose that when eliminating these EOS/EOB NALUs, the ideal would be to eliminate only the intermediate ones, and never eliminate the final one.

Greetings and thanks!

[videoh]

Thank you so much Sir! I'll come back with my further findings.

[quietvoid]

With seamless branched discs you end up having EOS/EOB NALUs in the middle of the video, yes.
And it's also motivated by FFmpeg being very strict when parsing as it only allows the RPU to be the last NALU.

So having EOS/EOB after the RPU causes issues.

So I suppose that when eliminating these EOS/EOB NALUs, the ideal would be to eliminate only the intermediate ones, and never eliminate the final one.

It's not worth it because they are not mandatory and you still end up altering the bitstream.

[videoh]

I was able to duplicate the flashing in MPV and then see that it is fixed by the --remove-eos option!

I agree with quietvoid that all the EOS/EOBs should be removed.

So now looking forward to the new release.

[rathann]

Please publish the dolby_vision Rust crate as well when making a release. 3.3.2 is missing from https://crates.io/crates/dolby_vision , by the way.

[quietvoid]

Oh sorry for that, I just published it.

[quietvoid]

A new version has been released.

[rathann]

Thanks, but 3.3.2 is not compatible with bitvec_helpers 4.0.0. I mentioned 3.3.2 only because it was tagged in git but not present on https://crates.io, but we still need a new release (4.0.0?) from current git HEAD.

[quietvoid]

I'm not really convinced there's a good reason to update the version just for dependency updates.
There aren't any functional changes.

[videoh]

Thank you, Sir!