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

[Michael Niedermayer]

On Sat, Mar 19, 2016 at 10:38:15AM +0100, Hendrik Leppkes wrote:
> On Sat, Mar 19, 2016 at 3:21 AM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> > On Sat, Mar 19, 2016 at 03:06:22AM +0100, Michael Niedermayer wrote:
> >> On Thu, Mar 17, 2016 at 02:35:27PM +0000, Mark Thompson wrote:
> >> > 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).
> >>
> >> i had hoped that it was simpler
> >
> >> either way iam perfectly fine with the original patch
> >
> > that is if people prefer it ...
> > i am not sure the debug info is worth the extra code
> >
> > hendrik ?
> 
> h264 doesnt seem to care about warning about this, but i don't really
> have a strong opinion on the debug code.

ok, ive applied the simpler patch then, we can always switch to
a more complex one if someone wants ...

thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160319/617813d3/attachment.sig>