oapve_encode API returns an raw_bitstream_access_unit() instead of an access_unit()

[jamrial]

This is not ideal as it requires the library user to remove the first four bytes containing the au_size field in order to store the output access unit into an ISOBMFF Sample.

[kpchoi]

I also think it would be worth to support encoding frame without au_size field of 'Raw bistream format' defined in https://www.ietf.org/archive/id/draft-lim-apv-04.html#name-raw-bitstream-format .
On/off decision of using the au_size needs to be set in encoder creation time.

FYI, I'd like to comment one thing about APV's ISOBMFF sample format.
APV sample format has an au_length field before an access unit data. The syntax name is different from au_size, but semantics is same.
Therefore, I believe that you could use the current encoder output for building APV sample box without removing au_size syntax.

[jamrial]

Yes, an option to enable that field would be good.
I see you updated the isombff spec with the addition of that field, but is it necessary? Samples already have an explicit size stored in the stsz box.

[kpchoi]

APV standard contributers have discussed about ISOBMFF sample format.
Finally dominant proposal was that AVC-like format is the best way.
As you know, AVC uses length+NALU format, which doesn't have to access stsz box and it can contain several access units in a sample box if required in future.
After that, many implementors like OS and chip company have developed APV parser and muxer by that way.
The APV ISOBMFF format description in openapv project should have updated for clarification because it was not clear description. Today, I found your comments and updated the document for clear undersanding.
This decision is the results of standard activity based on the concensus of contributors.

[jamrial]

Sure, just wanted to share my thoughts.

[kpchoi]

@jamrial
Check PR #85

[kpchoi]

Check PR #89 again

[kpchoi]

No additional comments