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

Faraz Khan faraz at screenhero.com
Sun Jul 7 22:50:48 CEST 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130707/ef0c5629/attachment.html>


More information about the Libav-user mailing list