bbc
Improve RDD 9 partition duration
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 https://github.com/bbc/bmx/issues/11
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.
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 mIndexTable->CanStartPartition() has to go too, or at least be optional under control of a _FLAVOUR flag?
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.
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.
So I think the
mIndexTable->CanStartPartition()has to go too, or at least be optional under control of a _FLAVOUR flag?
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?
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.
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.
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?
For my use case, default to existing behaviour, flag / commandline option for new behaviour is great.
OK.
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?
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 --fixed-part to enable strict partition sizes rather than the other way round.
@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.