Comments (12)
The address is a memory address of the buffer when parsing, it is not data.
I just tried your process and I end up with identical RPU files when comparing an edited (duplicate) RPU and the extracted RPU from an injected video with mismatched length.
So you're only supposed to look at the checksum of the files to see if they're bit identical.
from dovi_tool.
The address is a memory address of the buffer when parsing, it is not data.
Okay, but even if it's not data, it should also be kept intact, right?
Or is it correct that the 'addr' data is altered?
I just tried your process and I end up with identical RPU files when comparing an edited (duplicate) RPU and the extracted RPU from an injected video with mismatched length.
So you're only supposed to look at the checksum of the files to see if they're bit identical.
Is it completely identical?
That is, does the 'addr' data also stay original without being altered?
from dovi_tool.
No, the addr is runtime dependent when buffers are allocated in memory. It's a pointer, so it will always change.
Like I said it's not data.
It is fine if addr
changes, the important is that the files themselves are the same.
from dovi_tool.
No, the addr is runtime dependent when buffers are allocated in memory. It's a pointer, so it will always change.
But I have done a lot of tests, and 'addr' has never changed, everything is always kept completely intact.
If I extract an RPU multiple times, all the resulting RPUs are identical.
If I inject an RPU into a HEVC file, then I extract the RPU from the injected HEVC and it is completely identical to the original RPU (including 'addr').
If I edit an RPU to add one more frame at the end, all the frames contained in the new edited RPU (except the new last frame, as it does not exist in the original RPU) are completely identical to the original RPU (including 'addr').
And if I inject the edited RPU into a HEVC file, I extract the RPU from the injected HEVC and it still remains completely identical (including 'addr') to the edited RPU (which is also identical to the original RPU, except the new last frame evidently).
In short, absolutely always, whatever I do, even if I edit the RPU, inject and extract it again, everything always remains intact (including 'addr').
But if instead of previously manually editing the RPU, I let the new dovi_tool v0.4.0 do it automatically, all the 'addr' of all the RPU frames are altered.
Couldn't the automatic process just duplicate the last frame without modifying all the others frames?
In the same way that it is done manually with the editor
argument.
Thanks again!
from dovi_tool.
The addr is determined when parsing the RPU, not writing it. There's nothing to be done about it and it has nothing to do with the automatic padding when injecting.
The only reasonable way to fix it would be to stop displaying it when using info
, and instead just show remaining bits.
from dovi_tool.
So 'addr' is not written inside the RPU?
Is it just an information displayed by the info
argument?
So what changes inside the RPU must be something else, and that causes the info
argument to show altered 'addr'.
Since as I commented previously, the RPUs are altered. That is, the checksum of RPUs does not match, the bin files have different MD5s.
And I thought that this was caused by the 'addr', since it was the only thing that was shown differently by the info
argument... But then it must be something else inside the bin file.
Doesn't this happen to you?
Do you need I share my bin files?
from dovi_tool.
addr
is not written in the file.
When I tested I made sure to only duplicate the last metadata only, then the RPUs were identical.
I can compare the RPUs for you if you want..
from dovi_tool.
- Original RPU.bin
The original RPU file. - Manually edited RPU.bin
The "Original RPU.bin" file edited manually to duplicate the last frame.
For this I used:
{
"duplicate": [
{
"source": 157868,
"offset": 157868,
"length": 1
}
]
}
- Automatically edited RPU.bin
The "Original RPU.bin" file automatically edited by the new dovi_tool v0.4.0 during the injection process.
It should be identical to "Manually edited RPU.bin", but it is not. Something changes.
Thanks again!
from dovi_tool.
I have more information.
I have removed the last frame from the "Automatically edited RPU.bin" file. For this I used:
{
"remove": [
"157869"
]
}
And I have obtained an RPU identical to the original (Original RPU.bin).
So whatever changes is located in the new last injected frame.
from dovi_tool.
Well it appears to just be different metadata..
The first identical frame from the original is 157864, so I don't really know how it ended up last.
The only possibility is because the video has a different presentation order, and that the metadata you think is last is attached to a frame that's decoded before the others.
There's no way to know for sure without debugging with the video.
For example, frame 157864 could be the last presented frame, and is the metadata source for padding when injecting.
from dovi_tool.
I tested this again with different videos and it is what I explained previously.
The last metadata taken from the original RPU is not guaranteed to be the last in the final video, depending on the presentation order.
from dovi_tool.
Forgiveness for slow to respond. Thanks for answering me.
If you need me to share the video to debug it as you said, tell me. But I think you were already able to reproduce the same case with other videos, right?
So, if I understood you correctly, both RPUs were different because when I do it manually, a frame is duplicated, but when it is done automatically, another different frame is duplicated. Correct?
Thanks!
from dovi_tool.
Related Issues (20)
- [feature] add QSV support HOT 2
- Profile 8.2 Support HOT 7
- Skipping NAL unit 63
- Question about this tool
- DoVi on Xbox Series X using Plex
- Update and complete L11 metadata HOT 2
- dove_tool Profile 8 to 5 conversion for Mac support
- inject-rpu on AV1 (SVT) fails HOT 5
- Please support injecting RPU into HLS streams HOT 1
- Terminating app due to uncaught exception if build with cbuild HOT 8
- HDR10+ from DV json HOT 1
- Add support for Dolby Vision profile 20 HOT 5
- Add support for Dolby Vision Profile 9 (MPEG-4 AVC Dolby Vision, backwards compatible with SDR) HOT 1
- Documentation might need updated HOT 1
- Error reading MaxCLL and MaxFALL while parsing of xml generated by cm_analyze HOT 1
- Feature: Provide frame numbers in RPU.json HOT 1
- Question not an issue.
- Dolby Vision RPU not found for POC HOT 5
- Request: Print out the crop values for the active area offsets HOT 2
- Request: Extend --crop to accept crop values HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dovi_tool.