[Libav-user] Decoding single NALUs from x264 programmatically (no luck even with parser), works fine with concatenated NALUs

Sat Jul 13 21:54:08 CEST 2013

Sergey,
Passing individual nal units to the decoder does not work (produces errors
I provided you with). Setting CODEC_FLAG2_CHUNKS changes the errors.  This
is the same with or without the parser. Maybe that behavior has changed. If
anyone has information regarding this it'll be awesome!

Btw- if you assemble the frame yourself you can feed it into the decoder
without the parser and its completely happy. This is the way we are
currently doing it.

On Sat, Jul 13, 2013 at 2:30 AM, Sergey Fedorov <
night.rain.whisper at gmail.com> wrote:

> You should split the stream to NAL units anyway before passing to decoder.
> That's what I know about it )
>
>
> 2013/7/8 Faraz Khan <faraz at screenhero.com>
>
>> Sergey,
>> Just tried  - setting decoderContext->flags2 to CODEC_FLAG2_CHUNKS also
>> doesnt work (with or without parser!) Is there something special that needs
>> to be done?
>>
>> Decoder keeps saying:
>>
>> *Screenhero[45392:13803] Current profile doesn't provide more RBSP data
>> in PPS, skipping*
>>
>> *2013-07-07 13:47:38.105 Screenhero[45392:13803] Frame size received is
>> 8476*
>>
>> *2013-07-07 13:47:38.107 Screenhero[45392:13803] out of range intra
>> chroma pred mode at 67358720 -1583242847*
>>
>> *2013-07-07 13:47:38.107 Screenhero[45392:13803] error while decoding MB
>> 67358720 -1583242847*
>>
>> *2013-07-07 13:47:38.108 Screenhero[45392:13803] out of range intra
>> chroma pred mode at 67358720 -1583242847*
>>
>> *2013-07-07 13:47:38.108 Screenhero[45392:13803] error while decoding MB
>> 67358720 -1583242847*
>>
>> *2013-07-07 13:47:38.119 Screenhero[45392:13803] Frame size received is
>> 6464*
>>
>> *2013-07-07 13:47:38.120 Screenhero[45392:13803] Frame size received is
>> 1287*
>>
>> *2013-07-07 13:47:38.126 Screenhero[45392:13803] Frame size received is
>> 9938*
>>
>> *2013-07-07 13:47:38.127 Screenhero[45392:13803] cbp too large
>> (67358720) at -1583242847 67358792*
>>
>> *2013-07-07 13:47:38.127 Screenhero[45392:13803] error while decoding MB
>> 67358720 -1583242847*
>>
>> *2013-07-07 13:47:38.127 Screenhero[45392:13803] negative number of zero
>> coeffs at 67358720 -1583242847*
>>
>> *2013-07-07 13:47:38.128 Screenhero[45392:13803] error while decoding MB
>> 67358720 -1583242847*
>>
>> *2013-07-07 13:47:38.134 Screenhero[45392:13803] Frame size received is
>> 2574*
>>
>> *
>> *
>>
>> *Thanks!*
>>
>> *
>> *
>>
>>
>> On Sun, Jul 7, 2013 at 1:15 PM, Faraz Khan <faraz at screenhero.com> wrote:
>>
>>> Sergey,
>>> I did not - is that supposed to do the trick? Would we need a parser in
>>> that scenario?
>>>
>>>
>>>
>>> On Sun, Jul 7, 2013 at 12:13 AM, Sergey Fedorov <
>>> night.rain.whisper at gmail.com> wrote:
>>>
>>>> Did you try using CODEC_FLAG2_CHUNKS?
>>>>
>>>>
>>>> 2013/7/6 Attila Sukosd <attila.sukosd at gmail.com>
>>>>
>>>>> Hi guys,
>>>>>
>>>>> There was this thread about decoding NALUs one-by-one with
>>>>> parser2/decode2 and I'm having exactly the same issue.
>>>>>
>>>>> I have x264 creating a bunch of NALUs, in annex_b and repeate_headers,
>>>>> and trying to decode them one by one on the client side. When I concatenate
>>>>> all the NALUs per frame into one large packet, and feed that directly into
>>>>> avcodec_decode_video2, everything is fine, the decode is successful.
>>>>> However, when I try to feed single NALs directly to
>>>>> avcodec_decode_video2, it spits out a bunch of errors. After searching for
>>>>> a while on the net, I read some place that certain types of NALs affect the
>>>>> rest of the data stream, and they need to be group together.
>>>>> I've tried to run the NALs through av_parser_parse2 and tried to
>>>>> decode the output buffer when the output size was larger than zero,
>>>>> however, after looking at the output buffer contents, it seems like while
>>>>> the output size seems reasonable (around the size of the NALs or a
>>>>> combination of a number of previous NALs), the output buffer content
>>>>> contains 3-4 bytes, and the rest is zero.
>>>>>
>>>>> The decoding looks like this:
>>>>>
>>>>>  ret = av_parser_parse2(decoder->pParserCtx, decoder->pCodecCtx,
>>>>> decoder->tmp_data, &outsize, buff, size, 0, 0, AV_NOPTS_VALUE);
>>>>>  printf("%p buff, %p outdata, consumed %d, %d bufsize, %d outsize\n",
>>>>> buff, decoder->tmp_data,ret, size, outsize);
>>>>>  disp_buff(decoder->tmp_data, 50);
>>>>>
>>>>>  if (outsize <= 0) return 0;
>>>>>
>>>>>  decoder->avpkt.flags = AV_PKT_FLAG_KEY;
>>>>>  decoder->avpkt.data = decoder->tmp_data;
>>>>>  decoder->avpkt.size = outsize;
>>>>>
>>>>>   got_picture = 0;
>>>>>   if ((ret = avcodec_decode_video2(decoder->pCodecCtx,
>>>>> decoder->pFrame, &got_picture, &decoder->avpkt)) < 0) {
>>>>>                 LOGE(__FUNCTION__, "H264 decoding failed!\n");
>>>>>                 return -1;
>>>>>   }
>>>>>
>>>>>
>>>>> Could someone shed some light on if I'm really off the right track? or
>>>>> am I just missing something very trivial?
>>>>>
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Attila
>>>>>
>>>>> _______________________________________________
>>>>> Libav-user mailing list
>>>>> Libav-user at ffmpeg.org
>>>>> http://ffmpeg.org/mailman/listinfo/libav-user
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Libav-user mailing list
>>>> Libav-user at ffmpeg.org
>>>> http://ffmpeg.org/mailman/listinfo/libav-user
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> --
>>> Faraz Khan
>>> Simple Collaboration Screensharing
>>> www.screenhero.com
>>>
>>
>>
>>
>> --
>>
>> --
>> Faraz Khan
>> Simple Collaboration Screensharing
>> www.screenhero.com
>>
>> _______________________________________________
>> Libav-user mailing list
>> Libav-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/libav-user
>>
>>
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>
>

-- 

--
Faraz Khan
Simple Collaboration Screensharing
www.screenhero.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130713/1a1fdc40/attachment.html>