From: "Gaëtan Carlier" <gcembed@gmail.com>
To: Philipp Zabel <p.zabel@pengutronix.de>, linux-media@vger.kernel.org
Cc: javier Martin <javier.martin@vista-silicon.com>,
Fabio Estevam <festevam@gmail.com>,
Fabio Estevam <fabio.estevam@freescale.com>
Subject: Re: [coda6] Error while decoding second h.264 chunk
Date: Fri, 03 Oct 2014 15:34:13 +0200 [thread overview]
Message-ID: <542EA5D5.7080709@gmail.com> (raw)
In-Reply-To: <542A61A8.3030504@gmail.com>
Hi,
Do you have time to take a look at this (with the PC values) ?
On 09/30/2014 09:54 AM, Gaëtan Carlier wrote:
> Hi,
> The problem can also come from register address or bit offset because
> depending source used (GStreamer for 2.6.22 or new coda kernel driver
> 3.6 or datasheet), registers do not have same addresses or do not even
> exists !
>
> On 09/30/2014 08:00 AM, Gaëtan Carlier wrote:
>> Hi Philipp and Fabio,
>> First of all, thanks a lot for your reply.
>>
>> On 09/29/2014 03:53 PM, Philipp Zabel wrote:
>>> Hi Gaëtan,
>>>
>>> Am Mittwoch, den 24.09.2014, 11:18 +0200 schrieb Gaëtan Carlier:
>>>> Hello Dears,
>>>> I am back with my Coda6 (i.MX27). I have ported decoding from libvpu
>>>> code to kernel 3.6 but I have a little problem. DEC_SEQ_INIT runs fine,
>>>> the internal RdPtr increases by 512 bytes but when I run the
>>>> DEC_PIC_RUN
>>>> (PRESCAN disabled), the RdPTr has increased to 1024 (0x400), but
>>>> macroblock error are reported and next DEC_PIC_RUN does not increase
>>>> anymore the internal RdPtr.
>>>> If I enable PRESCAN, the first DEC_PIC_RUN does not event finish
>>>> (timeout).
>>>
>>> where is the PC pointer at when it times out? Maybe do a complete
>>> register dump before DEC_PIC_RUN and after the timeout to see if
>>> something stands out.
>> I will do that and post reply today (I really don't know what to do with
>> Program Counter of the FW. I hope you do :)).
> Here is the dump reg when PRESCAN is enable (and leads to timeout):
> Chunk 0[6269] : key frame 67 (00000001674218D4)
> Chunk 1[1154] : frame 41 (00000001419AFFBF)
> Chunk 2[1293] : frame 41 (00000001419A8110)
> Chunk 3[1256] : frame 41 (00000001419A7590)
> Chunk 4[1887] : frame 41 (00000001419A0989)
> Chunk 5[2609] : frame 41 (00000001419A6E54)
> Chunk 6[2463] : frame 41 (00000001419A0865)
> Chunk 7[2087] : frame 41 (00000001419AB42D)
> Chunk 8[2394] : frame 41 (00000001419AB52F)
> Chunk 9[2210] : frame 41 (00000001419A2CC2)
>
> coda_fill_decoder_bitstreambuf - c8c7f000 - 6269 bytes added - 6269
> bytes bufferd
> WrPtr @ a73c187d - RdPtr @ a73c0000
> 00000001674218D4
> coda coda-imx27.0: Int occurs : 00000002
> CODA_REG_DEC_FUNC_CTRL (0x0114): 00000000
> CODA_RET_DEC_SEQ_SRC_SIZE (0x01C4): 000A01E0
> CODA_RET_DEC_SEQ_SRC_F_RATE (0x01C8): 00000000
> CODA_RET_DEC_SEQ_FRAME_NEED (0x01CC): 00000003
> CODA_RET_DEC_SEQ_FRAME_DELAY (0x01D0): 00000000
> CODA_RET_DEC_SEQ_INFO (0x01D4): 00000000
> CODA_RET_DEC_SEQ_CROP_LEFT_RIGHT (0x01D8): 00000000
> CODA_RET_DEC_SEQ_CROP_TOP_BOTTOM (0x01DC): 00000000
> CODA_RET_DEC_SEQ_NEXT_FRAME_NUM (0x01E0): 00000001
> CODA_REG_BIT_RUN_INDEX (0x0168): 00000000
> CODA_REG_BIT_RD_PTR0 (0x0120): A73C0200
> CODA_REG_BIT_WR_PTR0 (0x0124): A73C187D
> Framebuffers allocated 10
> coda coda-imx27.0: Int occurs : 00000010
> coda_device_run_decoder
>
> coda_fill_decoder_bitstreambuf - c8d80000 - 1154 bytes added - 7423
> bytes bufferd
> WrPtr @ a73c1cff - RdPtr @ a73c0200
> 00000001419AFFBF
>
> CODA_REG_BIT_INT_STATUS (0x0010): 00000000
> CODA_REG_BIT_CUR_PC (0x0018): 00000069
> CODA_REG_BIT_CODE_BUF_ADDR (0x0100): A7130000
> CODA_REG_BIT_WORK_BUF_ADDR (0x0104): A7200000
> CODA_REG_BIT_PARA_BUF_ADDR (0x0108): A7300000
> CODA_REG_BIT_STREAM_CTRL (0x010C): 00000006
> CODA_REG_BIT_FRAME_MEM_CTRL (0x0110): 00000000
> CODA_REG_DEC_FUNC_CTRL (0x0114): 00000000
> CODADX6_REG_BIT_SEARCH_RAM_BASE_ADDR (0x0140): FFFF4C00
>
> coda coda-imx27.0: CODA PIC_RUN timeout, stopping all streams
>
> CODA_RET_DEC_PIC_FRAME_NUM (0x01C0): 00000001 size 460800
> CODA_RET_DEC_PIC_IDX (0x01C4): 000A01E0
> CODA_RET_DEC_PIC_ERR_MB_NUM (0x01C8): 00000000
> CODA_RET_DEC_PIC_TYPE (0x01CC): 00000003
> CODA_RET_DEC_PIC_SUCCESS (0x01D4): 00000003
> CODA_RET_DEC_PIC_OPTION (0x01D0): 00000000
> CODA_RET_DEC_PIC_CUR_IDX (0x01DC): FFFFFFFF
> CODA_RET_DEC_PIC_NEXT_IDX (0x01E0): 00000001
>
> CODA_REG_BIT_INT_STATUS (0x0010): 00000000
> CODA_REG_BIT_CUR_PC (0x0018): 00000DC6
> CODA_REG_BIT_CODE_BUF_ADDR (0x0100): A7130000
> CODA_REG_BIT_WORK_BUF_ADDR (0x0104): A7200000
> CODA_REG_BIT_PARA_BUF_ADDR (0x0108): A7300000
> CODA_REG_BIT_STREAM_CTRL (0x010C): 00000006
> CODA_REG_BIT_FRAME_MEM_CTRL (0x0110): 00000000
> CODA_REG_DEC_FUNC_CTRL (0x0114): 00000000
> CODADX6_REG_BIT_SEARCH_RAM_BASE_ADDR (0x0140): FFFF4C00
>
>>>
>>>> I attach the kernel driver (+fw), the h264 raw file (encoded using this
>>>> coda6 driver and played without error using ffplay), the userspace test
>>>> program and the log file.
>>>>
>>>> Can you give me some advise to know where to search. I have tried to
>>>> reset WrPtr and RdPtr before first DEC_PIC_RUN and reload h264 raw file
>>>> from the beginning, let RdPtr and WrPtr unchanged and h264 raw file
>>>> from
>>>> the beginning but this is even worst...
>>>
>>> I don't think you are supposed to write RdPtr.
>> That is what I think too but I have tried many things before asking
>> help :)
>>> It is under firmware
>>> control, at least between SEQ_INIT and SEQ_END. There is a DEC_BUF_FLUSH
>>> command, maybe that does what you need.
>> I supposed that DEC_BUF_FLUSH command is needed after DEC_PIC_RUN
>> command in case of last chunk or one frame decoding. As my problem
>> occurs while this first DEC_PIC_RUN, I don't even try to implement this
>> command.
>>> What happens if you queue a third ~1200 byte frame before calling the
>>> first DEC_PIC_RUN?
>>>
>> I already try to increase v4l2buffer from userspace and queue upto 10
>> h.264 chunk in bitstreambuffer but same behaviour.
>>>> The firmware is version 2.2.5.
>>>>
>>>> Thanks a lot for your help.
>>>> Best regards,
>>>> Gaëtan Carlier.
>>>>
>>>> ps: I do not post this on mailing list due to attachments that may
>>>> not work
>>>
>>> You could extract the relevant parts of the log.
>> I send this reply on mailing list, as people will already see your
>> advise and avoid duplication. Here is the log:
>>
>> ...
>> coda coda-imx27.0: Initialized CodaDx6.
>> coda coda-imx27.0: Firmware version: 2.2.5
>> coda coda-imx27.0: codec registered as /dev/video2
>> ...
>> Chunk 0[6269] : key frame 67 (00000001674218D4)
>> Chunk 1[1154] : frame 41 (00000001419AFFBF)
>> Chunk 2[1293] : frame 41 (00000001419A8110)
>> Chunk 3[1256] : frame 41 (00000001419A7590)
>> Chunk 4[1887] : frame 41 (00000001419A0989)
>> Chunk 5[2609] : frame 41 (00000001419A6E54)
>> Chunk 6[2463] : frame 41 (00000001419A0865)
>> Chunk 7[2087] : frame 41 (00000001419AB42D)
>> Chunk 8[2394] : frame 41 (00000001419AB52F)
>> Chunk 9[2210] : frame 41 (00000001419A2CC2)
>>
>> coda_fill_decoder_bitstreambuf - c8c7f000 - 6269 bytes added - 6269
>> bytes bufferd
>> WrPtr @ a73c187d - RdPtr @ a73c0000
>> 00000001674218D4
>> coda coda-imx27.0: Int occurs : 00000002 (SEQ_INIT)
>> coda coda-imx27.0: CODA_REG_DEC_FUNC_CTRL : 00000000
>> coda coda-imx27.0: CODA_RET_DEC_SEQ_SRC_SIZE : 000A01E0
>> coda coda-imx27.0: CODA_RET_DEC_SEQ_SRC_F_RATE : 00000000
>> coda coda-imx27.0: CODA_RET_DEC_SEQ_FRAME_NEED : 00000003
>> coda coda-imx27.0: CODA_RET_DEC_SEQ_FRAME_DELAY : 00000000
>> coda coda-imx27.0: CODA_RET_DEC_SEQ_INFO : 00000000
>> coda coda-imx27.0: CODA_RET_DEC_SEQ_CROP_LEFT_RIGHT : 00000000
>> coda coda-imx27.0: CODA_RET_DEC_SEQ_CROP_TOP_BOTTOM : 00000000
>> coda coda-imx27.0: CODA_RET_DEC_SEQ_NEXT_FRAME_NUM : 00000001
>> coda coda-imx27.0: CODA_REG_BIT_RUN_INDEX : 00000000
>> coda coda-imx27.0: CODA_REG_BIT_RD_PTR0 : A73C0200
>> coda coda-imx27.0: CODA_REG_BIT_WR_PTR0 : A73C187D
>> Framebuffers allocated 10
>> coda coda-imx27.0: Int occurs : 00000010 (SET_FRAME_BUF)
>> coda_device_run_decoder
>>
>> coda_fill_decoder_bitstreambuf - c8d80000 - 1154 bytes added - 7423
>> bytes bufferd
>> WrPtr @ a73c1cff - RdPtr @ a73c0200
>> 00000001419AFFBF
>> coda coda-imx27.0: Int occurs : 00000008 (PIC_RUN)
>> CODA_RET_DEC_PIC_FRAME_NUM : 00000001 size 460800
>> CODA_RET_DEC_PIC_IDX : 00000000
>> CODA_RET_DEC_PIC_ERR_MB_NUM : 00000442
>> CODA_RET_DEC_PIC_TYPE : 00000000
>> CODA_RET_DEC_PIC_SUCCESS : 00000001
>> CODA_RET_DEC_PIC_OPTION : 00000002
>> CODA_RET_DEC_PIC_CUR_IDX : 00000001
>> CODA_RET_DEC_PIC_NEXT_IDX : 00000001
>> coda_device_run_decoder
>>
>> coda_fill_decoder_bitstreambuf - c8e81000 - 1293 bytes added - 8716
>> bytes bufferd
>> WrPtr @ a73c220c - RdPtr @ a73c0400
>> 00000001419A8110
>> Image 1 decoded : 0
>> Chunk 10[2841] : frame 41 (00000001419A09A2)
>> Chunk 11 loaded
>> coda coda-imx27.0: Int occurs : 00000008
>> CODA_RET_DEC_PIC_FRAME_NUM : 00000002 size 460800
>> CODA_RET_DEC_PIC_IDX : 00000001
>> CODA_RET_DEC_PIC_ERR_MB_NUM : 000000EA
>> CODA_RET_DEC_PIC_TYPE : 00000001
>> CODA_RET_DEC_PIC_SUCCESS : 00000001
>> CODA_RET_DEC_PIC_OPTION : 00000002
>> CODA_RET_DEC_PIC_CUR_IDX : 00000002
>> CODA_RET_DEC_PIC_NEXT_IDX : 00000001
>> coda_device_run_decoder
>> ...
>>
>> A log with PRESCAN enabled and register dump before/after the timeout
>> will be posted later.
>>>
>>> regards
>>> Philipp
>>>
>>
>> Best regards,
>> Gaëtan.
> Regards,
> Gaëtan.
>
Thanks
Regards,
Gaëtan.
prev parent reply other threads:[~2014-10-03 13:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <54228C77.7040004@gmail.com>
[not found] ` <1411998818.3050.4.camel@pengutronix.de>
2014-09-30 6:00 ` [coda6] Error while decoding second h.264 chunk Gaëtan Carlier
2014-09-30 7:54 ` Gaëtan Carlier
2014-10-03 13:34 ` Gaëtan Carlier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=542EA5D5.7080709@gmail.com \
--to=gcembed@gmail.com \
--cc=fabio.estevam@freescale.com \
--cc=festevam@gmail.com \
--cc=javier.martin@vista-silicon.com \
--cc=linux-media@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).