> Discussion I had regarding this kind of integration, whether it was about non-
> parsing decoder or slice encoder, is that two planes shall be used (mplane
> API will allow seperate allocation of those planes). About slice encoder, a lot
> of specification work is needed. I believe the hardest part and what no one
> could agree on, is the data structure standard that would be used to
> represent the required metadata and headers. In the end, libv4l should
> probably have some new feature to transform slice encoded data into byte-
> stream so existing software can use those encoder without porting.
Thanks for your answer
It seems that what you are talking about is the case of a slice encoder, where the user side would generate the header/metadata.
In our case the HW is not a slice encoder, as it also generates the header/metadata, but it can generate it in some separate buffer, and this is required in some use-cases.
So I don’t think there is a lot of specification work needed . We just need a way to output several buffers instead of one, and to specify which one is the header buffer, and which one contains slice data.
Regards
Sebastien
��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
