• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 797 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DVRRDK 3.5 MJPEG Decode frames larger than max width/height

abadobid
Intellectual 300 points
Other Parts Discussed in Thread: SYSBIOS

We are using the dvrrdk 3.5 with a usecase derived from multich_progressive_vcap_venc_vdec_vdis.c.

We setup the decoder using Vdec_params_init().  The VDEC_PARAMS_S passed to Vdec_params_init() has the decChannelParams[].maxVideoWidth and maxVideoHeight members set to 720x480.

With this, we are able to decode mjpeg video with 720x480 or lower size with not problem.  As a test, I have fed the decoder mjpeg video with a size larger than the maximum specified above.  I expected to get an unsupported resolution error (the same as the h264 decoder does).  Instead the decoder continues to run with corrupted output and no error.

Shouldn't the call to the codec lib handle->fxns->ividdec.process() in decLink_jpeg.c be setting an unsupported resolution error without decoding?


Also, at run time, we sometimes change codecs between h264 and mjpeg using Vdec_deleteChn()/Vdec_createChn().  Again, this works fine when the mjpeg video fed to the decoder is withing the maximum size configured above.  If we feed it mjpeg video larger than configured, it decodes without error producing corrupted output.

Later, when the system is shut down, I get an assert

[vpss] UTILS: DMA: Free'ed CH (TCC) = 58 (58)
[vpss]!!!XDC RUNTIME ASSERT FAILED
[vpss]xdc.runtime.Error @ ti.sysbios.heaps.HeapMem: line 337:
[vpss]assertion failure: A_invalidFree: Invalid free

Because of the way our device receives the mjpeg stream, we don't know ahead of time the size (unless we parse the jpeg header).  Is there a way to keep the decoder link from attempting to decode images larger than it's output buffers?

  • 0
    Guru 10655 points
    why did you set the max width/height to 1920x1080 ?
  • 0 in reply to 1330hayacool7102
    Intellectual 300 points
    We allow the end user of our device to make tradeoffs between decoder resolution and number of channels, so with high channel count, the max size is set lower to reduce SR1 heap space usage.

    This works as expected with the H264 decoder, just not with the MJPEG.

    I also set the max size to 1080x1920 and fed it QWXGA size mjpeg, and it still attempts to decode it and reports no error.
  • 0 in reply to abadobid
    Guru 10655 points

    We allow the end user of our device to make tradeoffs between decoder resolution and number of channels, so with high channel count, the max size is set lower to reduce SR1 heap space usage.

    > Good. Some products implemented the trade-offs by some calculation, and it will show inhibition in GUI when the resource of connection choice is over the resource of residual.

    I also set the max size to 1080x1920 and fed it QWXGA size mjpeg, and it still attempts to decode it and reports no error.

    > Maybe you can use work-around by pre-parsing header to decide if the BS should be feed.

       But the root cause should be taken care by TI.

  • 0 in reply to 1330hayacool7102
    Intellectual 300 points

    Maybe you can use work-around by pre-parsing header to decide if the BS should be feed.

    Thanks.  That's actually what I started working on yesterday in case there is not fix for the mjpeg codec.  I hate to have the A8 busy parsing JPEG headers, but I suppose it could also be done in the video M3.

  • 0
    Intellectual 300 points
    Anyone familiar with the decoder link / codec lib have a clue? Would this most likely be a problem with the codec lib (which we don't have the source to) or the video m3 decode link?
  • 0 in reply to abadobid
    TI__Guru*** 125430 points
    This was fixed in MJPEG codec 1.00.13.00. I don't know the schedule for if/when this will make it into another RDK release. For now this codec should be obtained through TI sales/apps.