Error: Number of frames of input and RPU file are different! about dovi_tool HOT 12 CLOSED

For example: ffmpeg -map 0:v:0 -c copy -f null - -i BL+FEL+RPU.hevc gives number of frame 161618.

I'm not sure FFmpeg is accurate with this command line.
I have piped from a MakeMKV remux as well as demuxed the video, and the number of frames was always correct.

With your command, the number of frames is increased by 1.
FFmpeg also errored: [NULL @ 0x55660d526a40] missing picture in access unit with size 287

So both piping & demuxing with ffmpeg -i title_t00.mkv -c:v copy video.hevc resulted in frame=189716
While your command results in frame=189717, and is incorrect.

The RPU contains 189716 metadata frames, so that's correct.
And I can do dovi_tool info -i RPU.bin -f 189715, which is fine because the -f parameter starts at 0.
According to the video length, the correct number of frames is also 189716.

I still have to test demuxing into BL+EL and reinjecting, but I'm not really seeing any use case for this.

from dovi_tool.

The issue can be closed now. The problem is really in bad initial demux. Eac3to and MKVExtract break RPU data while demuxing, making it one frame less.
I reripped disc and demuxed with Ffmpeg - everything is ok

from dovi_tool.

Well the only other option is that the RPU has less "metadata" frames, or there's a bug with the HEVC parsing.
Can you reproduce it consistently? Would need a sample of the source at the very least, if encoding can be reproduced.

from dovi_tool.

I also encontered the same problem. I have tested two sources. Both behave similarly. (Use Makemkv latest version to make two layers MKV)
Note: As for source A, I also test a remux mkv from a famous group. The problem also remains.
The following is the procedure.
The command dovi_tool -c -m 2 extract-rpu BL+FEL+RPU.hevc produces the RPU.bin. Further, I check the number of frames with command dovi_tool info -i RPU.bin -f INDEX_OF_FRAME.
I found that the the number of frames from RPU is always one frame less than that of video file.
For example: ffmpeg -map 0:v:0 -c copy -f null - -i BL+FEL+RPU.hevc gives number of frame 161618.
dovi_tool info -i RPU.bin -f 161616 is OK.
dovi_tool info -i RPU.bin -f 161617 will result in panick:

Parsing RPU file...
thread 'main' panicked at 'assertion failed: f < rpus.len()', src\dovi\rpu_info.rs:23:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Although it is possible the source video is unreliable, I just talk about my experience for a reference.

from dovi_tool.

I also encontered the same problem. I have tested two sources. Both behave similarly. (Use Makemkv latest version to make two layers MKV)
Note: As for source A, I also test a remux mkv from a famous group. The problem also remains.
The following is the procedure.
The command dovi_tool -c -m 2 extract-rpu BL+FEL+RPU.hevc produces the RPU.bin. Further, I check the number of frames with command dovi_tool info -i RPU.bin -f INDEX_OF_FRAME.
I found that the the number of frames from RPU is always one frame less than that of video file.
For example: ffmpeg -map 0:v:0 -c copy -f null - -i BL+FEL+RPU.hevc gives number of frame 161618.
dovi_tool info -i RPU.bin -f 161616 is OK.
dovi_tool info -i RPU.bin -f 161617 will result in panick:

Parsing RPU file...
thread 'main' panicked at 'assertion failed: f < rpus.len()', src\dovi\rpu_info.rs:23:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Although it is possible the source video is unreliable, I just talk about my experience for a reference.

I checked my sources again and that is right - extracted RPU is always one frame less than that of video file.
And the problem definitely not in encode. If I extract RPU from source, demux source file to BL and EL-RPU, and then try to insert RPU back into the source BL file - I still get this error. Looks like the problem is in RPU parsing or injecting process.

from dovi_tool.

It's quite likely to be a one off problem, however it feels a little odd that you can use the RPU file with x265, which verifies the number of metadata frames against the frames encoded.
It wouldn't fail but it should be warning.

I'll try to reproduce with a full MakeMKV file, but it would be useful to test with the same title.

from dovi_tool.

It's quite likely to be a one off problem, however it feels a little odd that you can use the RPU file with x265, which verifies the number of metadata frames against the frames encoded.
It wouldn't fail but it should be warning.

I'll try to reproduce with a full MakeMKV file, but it would be useful to test with the same title.

The source file is 50GB big - would be not so easy to upload to some file hosting

from dovi_tool.

@Vortexar I'm not asking for the file itself, just the title. I can buy it myself.

from dovi_tool.

Aquaman (2018)

from dovi_tool.

I did a dovi_tool inject-rpu -i BL.hevc --rpu_in RPU.bin and it worked perfectly fine.

So I can't reproduce the issue here.

from dovi_tool.

For example: ffmpeg -map 0:v:0 -c copy -f null - -i BL+FEL+RPU.hevc gives number of frame 161618.

I'm not sure FFmpeg is accurate with this command line.
I have piped from a MakeMKV remux as well as demuxed the video, and the number of frames was always correct.

With your command, the number of frames is increased by 1.
FFmpeg also errored: [NULL @ 0x55660d526a40] missing picture in access unit with size 287

So both piping & demuxing with ffmpeg -i title_t00.mkv -c:v copy video.hevc resulted in frame=189716
While your command results in frame=189717, and is incorrect.

The RPU contains 189716 metadata frames, so that's correct.
And I can do dovi_tool info -i RPU.bin -f 189715, which is fine because the -f parameter starts at 0.
According to the video length, the correct number of frames is also 189716.

I still have to test demuxing into BL+EL and reinjecting, but I'm not really seeing any use case for this.

THANKS. I found the problem is related to the way I demux the BL+FEL+RPU.mkv. I previously use gMKVExtractGUI. Currently, I will turn to ffmpeg.
BTW, the counting of number of frames is actually correct, but the BL+FEL+RPU.hevc by gMKVExtractGUI seems corrupt so that dovi_tool cannont extract a correct RPU.

from dovi_tool.

I just got around to testing inject-rpu on a very quick Aquaman (2018) encode and it worked fine as well.

from dovi_tool.