On Sat, Mar 19, 2016 at 3:21 AM, Michael Niedermayer
<mich...@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 <m...@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.
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
