Conversation
I understand the Table B.2 sizes to be hard targets, even with variable GOP sizes. RDD 9-2009 required “an integer number of GOPs per partition” (Table 1) but this constraint is gone in RDD 9:2013. So I think the |
I'm not sure that they are hard targets because that particular section uses "should" whilst the other sections in the appendix use "shall". It's hard to say what leeway was intended by the authors but starting partitions with I-frames is what bmx does for RDD9 and OP1a. Do you maybe have a file generated by a Sony product that doesn't start a partition with an I-frame? If so then that changes things.
Would a flag that is not enabled by default, and a commandline option, that forces equal partition duration in RDD9 work for your use case? |
For my use case, default to existing behaviour, flag / commandline option for new behaviour is great.
I have been told that round-tripping a file to an XDCAM drive (PDW-U1/U2/U4) results in fixed partition sizes, but I haven’t been able to double-check. I should be able to follow up within a couple of days whether that is really the case. Doesn’t the index byte count fix you just made for section B.6 also point to an expectation of equal partition sizes though? |
OK.
Similar to the index duration changes, I wanted to have the index count sizes match the expectation / "shoulds" in the spec. for the (majority?) cases where an integer number of GOPs fit into the index durations listed. I expect Sony products use (fixed?) GOP sizes that do fit and 240 / 300 is divisible by most sizes <=15. It would be interesting to see what happens in that roundtrip when the GOPs don't fit. |
|
@ajhoddinott Did you manage to check the round-tripping support? Happy to wait or merge what I have now where it requires use of the |
|
@philipnbbc Sorry for the extreme delay in getting back to you. I’ve been trying to chase two contacts who have Sony XDCAM hardware to round-trip a test file for me, but I haven’t received anything back yet. As I said, for my own use case, it doesn’t matter which is the default, but if you could wait on the merge a little longer, I am still hoping to get some more evidence one way or the other. |
|
@ajhoddinott the merge can wait, that's not a problem. Just thought I'd check just in case. |
philipnbbc
force-pushed
the
philipn-rdd9-partition-len
branch
from
1f8f732 to
510d0b8
Compare
RDD 9 2013, section B.6 says that the partition durations in Table B.2 "should" be used.
RDD 9 2013 (and 2009) specify an approximate 10 second partition duration limit, not a hard maximum. This commit will result in a partition duration matching the values in section B.6 if a fixed GOP size of 12 or 15 frames is used. If a different GOP structure is used then the partition may be larger (up to 15 frames) than the value in the spec (because a partition needs to start with a key frame), but that's fine as the 10 second is not a hard limit.
RDD 9 2013, section B.6 states that the Index Byte Count of the last Index Table Segment should equal the value of the other Index Table Segments even when the Index Duration of the last Index Table Segment is shorter.
A new partition is started at the set partition frame count even if the new partition doesn't begin with a GOP start.
An extra margin was added in #43
philipnbbc
force-pushed
the
philipn-rdd9-partition-len
branch
from
510d0b8 to
dde5853
Compare
2 participants
This PR ensures that the partition duration matches the value in RDD 9 2013, Table B.2 for fixed GOP sizes that divide into the partition frame counts and for compliant frame rates.
RDD 9 files with variable GOP sizes for example may end up having partition durations just over 10 seconds. However, the 10 second target is an approximation, not a hard limit.
The AS-10 test needed to be changed because of the way that the partition logic changed.
Fixes #11