Added the elementary stream and IVF file parser to rocDecode utilities #433
Conversation
jeffqjiangNew
commented
Oct 16, 2024
jeffqjiangNew
commented
- This PR adds the new built-in stream file parser, in order to reduce ROCm package dependencies on FFMPEG. The goal is to enable rocDecode testing on elementary stream files and IVF container files.
- This PR adds the functions of the parser to rocDecode utilities and example code to decode sample, as the first part. Next part is the enablement of this feature, which will be another PR.
- Currently the parser can parse AVC, HEVC and AV1 elementary stream files and AV1 IVF container files.
…lso cleaned up the bitstream ring buffer code.
…lso fixed a bug in fill ring buffer function.
- The stream type detection checks the unique syntax patterns of the stream type and calculate the likeliheed score. Based on the score, the most likely type is determined. - The current supported stream types are: AVC/HEVC/AV1 elementary streams, IVF AV1 streams.
…opy and paste error.
… check; Added stronger AV1 detection for IVF AV1 stream type.
jeffqjiangNew
requested review from
rrawther and
AryanSalmanpour
as code owners
|
|
||
| #include <string.h> | ||
| #include "video_es_parser.h" | ||
| #include "../../src/parser/hevc_defines.h" |
There was a problem hiding this comment.
as we discussed, we need to expose another api for this and I don't think it will fit within the existing parser api
There was a problem hiding this comment.
Will remove the reference to the internal headers.
Note this is a different parser. Think of it as a simple demuxer, which parses the files of AVC/HEVC/AV1 elementary stream files and get the picture data, and it can also read IVF container files. It is in parallel with roc_video_dec, ffmpeg demuxer in utility. The interface is exposed the same way as roc_video_dec, and ffmpeg demuxer. It is another utility.
| @@ -57,7 +58,8 @@ void ShowHelpAndExit(const char *option = NULL) { | |||
| << "-seek_criteria - Demux seek criteria & value - optional; default - 0,0; " | |||
| << "[0: no seek; 1: SEEK_CRITERIA_FRAME_NUM, frame number; 2: SEEK_CRITERIA_TIME_STAMP, frame number (time calculated internally)]" << std::endl | |||
| << "-seek_mode - Seek to previous key frame or exact - optional; default - 0" | |||
There was a problem hiding this comment.
I think, it is better to add another sample called "video_es_decode" for this instead of clubbing it with videodecode sample
There was a problem hiding this comment.
Agreed. The current code in videodecode.cpp is just a demo sample. When we remove ffmpeg links, we will need a new sample.
There was a problem hiding this comment.
@jeffqjiangNew Here is an idea about how to expose the new ES parser as an independent API and a new sample to show its functionality:
-
Move your implementation of the ES parser somewhere inside of the src/parser inside the rocdedecode library, this way you would have access to the internal codec structures headers.
-
Expose an independent API in the api/rocparser.h for example
extern rocDecStatus ROCDECAPI rocDecParserGetPicData(uint8_t **p_pic_data, int *pic_size);notice that this is going to be an independent API without needing to use RocdecVideoParser parser_handle -
Add a new function into utils/rocvideodecode/roc_video_dec.cpp/roc_video_dec.h
int GetPicData(uint8_t **p_pic_data, int *pic_size);and inside that function call the new independent ES parser API (rocDecParserGetPicData) -
Create a new sample (e.g., videoDecodeElementryStream) and inside that sample use the utils/rocvideodecode functionality and the new GetPicData function to illustrate the new ES parser without using any FFMPEG functionality
I agree we need to expose a new API. But it can be a new class and API instead of clubbing it with existing parser api. Current parser is specifically designed for parsing picture data and sending appropriate information to rocDecode decoding |
