Conversation
app/xevd_app.c
Outdated
| } | ||
| } | ||
|
|
||
| /* read 'nal_unit_length' syntax in Annex-B of EVC standard */ |
There was a problem hiding this comment.
Shouldn't that be AVCC format instead of Annex-B?
AnnexB format: ([start code] NALU) | ( [start code] NALU) |
AVCC format: ([length] NALU) | ([length] NALU) |
There was a problem hiding this comment.
Using annex-b or not is highly depending on file format.
If the muxing and parsing format is "evc" format which is sequence of elementary stream only, it have to use annex-b for fining bitstream boundary.
but, I guess that annex-b syntax would not be required for mp4 file format.
I remember H.264 and H.265 also doesn't store annex-b start code into mp4 files format (please correct me if it is not correct).
Do you think my comment is reasonable? and it could be handled?
There was a problem hiding this comment.
Everything is clear. I handled "Annex-B" word in the following comment line /* read 'nal_unit_length' syntax in Annex-B of EVC standard */ wrong way.
I handled Annex-B as a bitstream format, meanwhile it is not about bitstream format, it's all about the reference to the section of the ISO document, Annex-B of ISO IEC 23094-: 2020.
There was a problem hiding this comment.
ISO IEC 23094-: 2020 is specification of EVC codec. and Annex-B is a part of it.
Annex-B format is mainly for "xxx.evc" format (elementary stream).
I believe the mp4 file format (exactly named "iso-based file format") doesn't need to store Annex-B syntax to sample data.
If my explanation is different from you, then, let me know.
There was a problem hiding this comment.
The source of my confusion about the Annex-B is the fact that I've made wrong assumptions related to elementary stream formats.
Namely I've assumed that elementary video stream in an application can be in either Annex-B or AVCC format defined as follows:
- The Annex-B format delimits NALUs with two bytes of zeroes, followed by one or three bytes of zeroes, followed by the number 1 (called a start code, for example, 00000001).
([start code] NALU) | ( [start code] NALU) | - The AVCC format also wraps NALUs, but each NALU is preceded by a value that indicates the size of the NALU (usually four bytes).
([length] NALU) | ([length] NALU)
It seems that above definition of Annex-B bitstream format which is true for h264 is not true for EVC.
The Annex-B bitstream format for EVC has been described in SO IEC 23094-: 2020 documents as follows:
aw_bitstream_nal_unit( ) {
nal_unit_length
nal_unit( nal_unit_length )
}
app/xevd_app.c
Outdated
| } | ||
|
|
||
| /* read 'nal_unit_length' syntax in Annex-B of EVC standard */ | ||
| static int read_nalu_len(void * buf) |
There was a problem hiding this comment.
Shouldn't that be part of public API? I mean read_nalu_len function.
XEVD clients have to read NAL unit sizes from EVC stream while decoding EVC stream.
The only place that provides the information on how to do in correct way is the source code of xevd_app reference application.
Do you think it's enough?
There was a problem hiding this comment.
Ok, I will try to add a new API named "xevd_info( )" to get brief information of input bitstream.
I think we can give nal unit length if it is annex-b format, and several more important information.
Please wait a little bit.
There was a problem hiding this comment.
Hi, I added new API for getting brief information of input bitstream.
Review again please.
Espeically, review the funciton "read_bitstream()" in xevd_app.c would be good for understanding.
3 participants
The previous parsing scheme of "nal_unit_length" was not correct.
It should be u(32) syntax.
According to standard the parsing scheme has changed to support u(32).