[FFmpeg-devel] [PATCH] lavc/hevc: Allow arbitrarily many trailing_zero_8bits after a NAL unit in bytestream format.

[Mark Thompson]

On 17/03/16 14:11, Mark Thompson wrote:
> On 17/03/16 13:57, Michael Niedermayer wrote:
>> On Thu, Mar 17, 2016 at 01:48:37PM +0000, Mark Thompson wrote:
>>>  hevc_parse.c |   10 ++++++++--
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>> daf73b16f8185221a1e8112ab1928157a855fe76  0001-lavc-hevc-Allow-arbitrary-garbage-in-bytestream-as-l.patch
>>> From 725fb99402fa468e5f11f94e0ec09b2e0c91e6b2 Mon Sep 17 00:00:00 2001
>>> From: Mark Thompson <mrt at jkqxz.net>
>>> Date: Thu, 17 Mar 2016 13:41:02 +0000
>>> Subject: [PATCH] lavc/hevc: Allow arbitrary garbage in bytestream as long as
>>>  at least one NAL unit is found.
>>>
>>> ---
>>>  libavcodec/hevc_parse.c | 10 ++++++++--
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
>>> index 63ed84a..d557cc7 100644
>>> --- a/libavcodec/hevc_parse.c
>>> +++ b/libavcodec/hevc_parse.c
>>> @@ -232,8 +232,14 @@ int ff_hevc_split_packet(HEVCContext *s, HEVCPacket *pkt, const uint8_t *buf, in
>>>                  ++buf;
>>>                  --length;
>>>                  if (length < 4) {
>>> -                    av_log(avctx, AV_LOG_ERROR, "No start code is found.\n");
>>> -                    return AVERROR_INVALIDDATA;
>>> +                    if (pkt->nb_nals > 0) {
>>> +                        // No more start codes: we discarded some irrelevant
>>> +                        // bytes at the end of the packet.
>>> +                        return 0;
>>
>> does the case of garbage still print something at some level?
>> if not, it should. It could be usefull for debuging to know if theres
>> something funky going on with NAL parsing
> 
> It already doesn't print anything for the garbage it accepts between NAL units
> in a packet; this change just makes it consistent by silently accepting garbage
> at the end as well.  If we want to log something for all of these cases then it
> would have to look more like the first version of the patch to skip zeroes and
> then log a warning if the second search does not find a start code immediately.

Something like this, perhaps (not thoroughly tested).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lavc-hevc-Log-warnings-for-garbage-found-when-parsin.patch
Type: text/x-diff
Size: 2831 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160317/57f9f207/attachment.patch>