[x265] [PATCH] Add: End Of Bitstream and End Of Sequence NAL units

[Niranjan Bala]

Removed the new API for EOS and EOB NAL insertion at the end and
implemented it inside the existing API. Sent out the patch in a separate
email thread. Please ignore the patches in this thread.

On Wed, Mar 24, 2021 at 11:16 PM Niranjan Bala <
niranjan at multicorewareinc.com> wrote:

> We checked the feasibility of adding these NAL insertions to already
> existing APIs at the end. But they didn't seem meaningful and then we
> decided to add a new API for that.
>
> On Wed 24 Mar, 2021, 11:07 PM Aruna Matheswaran, <
> aruna at multicorewareinc.com> wrote:
>
>>
>>
>> On Wed, Mar 24, 2021 at 6:22 PM Niranjan Bala <
>> niranjan at multicorewareinc.com> wrote:
>>
>>>
>>>
>>> On Mon, Mar 22, 2021 at 10:17 PM Aruna Matheswaran <
>>> aruna at multicorewareinc.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Mar 22, 2021 at 11:25 AM Niranjan Bala <
>>>> niranjan at multicorewareinc.com> wrote:
>>>>
>>>>>
>>>>>>>
>>>>>>> +.. option:: --eob, --no-eob
>>>>>>> +
>>>>>>> + Emit an end of bitstream NAL unit at the end of the bitstream.
>>>>>>> +
>>>>>>> +.. option:: --eos, --no-eos
>>>>>>> +
>>>>>>> + Emit an end of sequence NAL unit at the end of every coded
>>>>>>> + video sequence.
>>>>>>> +
>>>>>>>
>>>>>> [AM] Please mention the default settings.
>>>>>> Also, API documentation for x265_encoder_end_nal_units() is missing.
>>>>>>
>>>>> Default settings and API documentation are added.
>>>>>
>>>>>> +            if ((m_param->bEnableEndOfBitstream ||
>>>>>>> m_param->bEnableEndOfSequence) && outFrameCount ==
>>>>>>> (uint32_t)m_param->totalFrames)
>>>>>>>
>>>>>> [AM] This may not work with live input streams. Please check.
>>>>>>
>>>>> EOB and EOS NAL units should be added at the end when we know the end
>>>>> of the bitstream. Since we do not know the end in live input streams, it is
>>>>> not added in that scenario.
>>>>>
>>>> [AM] Number of frames is not known in live input cases at the beginning
>>>> of the encode. However, input pipes will indicate the end of the file and
>>>> you can still handle EOD insertion after flushing all the input pictures.
>>>>
>>> Addressed this and sent out the patch in a separate email thread.
>>>
>>>> +            {
>>>>>>> +                if (api->encoder_end_nal_units(m_encoder, &p_nal,
>>>>>>> &nal) < 0)
>>>>>>> +                {
>>>>>>> +                    x265_log(NULL, X265_LOG_ERROR, "Failure
>>>>>>> generating end nal units\n");
>>>>>>> +                    m_ret = 3;
>>>>>>> +                    goto fail;
>>>>>>> +                }
>>>>>>> +                else
>>>>>>> +                    m_cliopt.totalbytes +=
>>>>>>> m_cliopt.output->writeHeaders(p_nal, nal);
>>>>>>>
>>>>>> [AM] Should we mark --eob as `CLI only` option? Given that EOB
>>>>>> insertion is handled completely in the application, I don't see the need
>>>>>> for the APIs specific to EOB. Please clarify.
>>>>>>
>>>>> No. --eob is not a 'CLI only' option. EOB insertion is handled in
>>>>> x265lib using the API. We need to add EOB after the main encoder loop. I
>>>>> think it's not appropriate to add EOB insertion in any previously existing
>>>>> APIs after x265_encoder_encode. Hence, added an API for handling the end
>>>>> NAL units similar to x265_encoder_headers.
>>>>>
>>>> [AM] If you expect the integrating application to call
>>>> x265_encoder_end_nal_units, what is the use of  bEnableEndOfBitstream
>>>> param?
>>>>
>>> In x265_encoder_end_nal_units, we are adding EOB and EOS NAL units at
>>> the end based on these params. If  bEnableEndOfBitstream param is set, EOB
>>> NAL unit is added. If bEnableEndOfSequence param is set, EOS NAL unit is
>>> added.
>>>
>> [AM] Ok. My suggestion is that, if EOS and EOD NALs are inserted in the
>> NAL list of the last frame encoded inside the library, we don't have to
>> expect the integrating application to call  x265_encoder_end_nal_units API.
>> Else, it will be a burden for the integrating application to update its
>> wrapper app.
>> Please check if this is feasible.
>>
>>> --
>>>>>
>>>>> Thanks & Regards
>>>>> *Niranjan Kumar B*
>>>>> Video Codec Engineer
>>>>> Media & AI Analytics
>>>>> +91 958 511 1449
>>>>> <https://multicorewareinc.com/>
>>>>> _______________________________________________
>>>>> x265-devel mailing list
>>>>> x265-devel at videolan.org
>>>>> https://mailman.videolan.org/listinfo/x265-devel
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> *Aruna Matheswaran,*
>>>> Video Codec Engineer,
>>>> Media & AI analytics BU,
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> x265-devel mailing list
>>>> x265-devel at videolan.org
>>>> https://mailman.videolan.org/listinfo/x265-devel
>>>>
>>>
>>>
>>> --
>>>
>>> Thanks & Regards
>>> *Niranjan Kumar B*
>>> Video Codec Engineer
>>> Media & AI Analytics
>>> +91 958 511 1449
>>> <https://multicorewareinc.com/>
>>> _______________________________________________
>>> x265-devel mailing list
>>> x265-devel at videolan.org
>>> https://mailman.videolan.org/listinfo/x265-devel
>>>
>>
>>
>> --
>> Regards,
>> *Aruna Matheswaran,*
>> Video Codec Engineer,
>> Media & AI analytics BU,
>>
>>
>>
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
>>
>

-- 

Thanks & Regards
*Niranjan Kumar B*
Video Codec Engineer
Media & AI Analytics
+91 958 511 1449
<https://multicorewareinc.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20210325/a537dba3/attachment.html>