• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 97 subscribers
  • Views 1864 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.

Certain problem with VPSS V4l2 capture and VFPC-DEI OMX component

przemek_gajos
Intellectual 290 points

Hello,

In our model, we are doing the following:

[ capture with VPSS v4l2 VIN module ]   ->   [ use OMX VFPC-DEI to scale ]   ->   [ use OMX encoder to encode ]

We have decided to use the VFPC-DEI component as scaler after the discussion with TI guys:

https://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/469287

I am now developing and testing the app and I am having a peculiar problem between VPSS v4l2 VIN capture and OMX VFPC-DEI when trying to scale:

DEI component does not return with EmptyBufferDone callback when capturing from one of the inputs on our card and when telling DEI to scale down.

Here is more details:

- my capture card has 2 inputs; data on one of them is captured through VIN output port 0 and the other one is through VIN output port 1

- initially, data is captured as YUV422 from the one input on the card and as RGB24 from the other, but in both cases the VIN capture module is "told" to output NV12 on both of its output ports and pass it to DEI component with EmptyThisBuffer

-  when capturing through VIN out port 1 (video originally in RGB24), the capture and scaling by DEI works well 

-  when capturing through VIN out port 0 (video originally in YUV422), data is captured but scaling by DEI does not work (as mentioned above, DEI does not return with EmptyBufferDone callback). What is interesting is that for this case, it will all work if data is captured and passed to DEI and DEI is told to not scale but just pass the data 1-to-1 to its output buffers 1:1 (e.g. 1920x1080 -> 1920x1080). DEI will then return with EmptyBufferDone and of course with 2x FillBufferDone on its outputs...

- note that my previous tests with just DEI component and no capture through VIN were successful. They were simple tests where DEI was just processing "dummy" data from its input to output in various combinations of: no scaling, scaling down, scaling up. That's why I think that somehow the the VIN v4l2 capture component is involved in the problem.

My suspicions head towards one of the following (could you please confirm if they can be the case here):

1) DEI is tied to only one of the VPSS VIN output ports when scaling and will not cooperate with the other one? 

2) I am initialising DEI component first and then VPSS VIN is initialised. Is it possible that for the failure case I am overwriting settings in the scaler? Is the inline scaler in VIN the same hardware as the scaler used by DEI? This was my first thought since DEI is first initialised to scale and then VIN is always initialised to capture 1-to-1 (not scale). However, I did a test in which VIN component is initialised first and DEI is initialised after that and the behaviour did not change, that is I was still getting the same failure as described above...

3) Would it matter here that the data on VIN input is in different formats for the success and the failure case (RGB24 vs. YUV422)? I do not understand why that would be relevant since in all cases VIN capture is told to colour-convert the data to NV12 and then pass it to DEI...

I will be grateful for your suggestions / help with this problem.

Also, please see below printouts from the app and from the VIN v4l2 driver which may put more light on this case. The print outs and for the initial loop for 4 allocated buffers. 

1) Working case: capture through VIN output port 1 and pass to DEI, source: 1920x1080, DEI told to scale down to 1280x720

APP:

v4l2_capture_loop: V4L2-1-0, client(0): DQed: outPortParams(0x135270), chain_handle(0x1355f0), chain_omx_comp(0x135338), queued(4) dequeued(1), latest_dq_buf_index(0), pBuffer(0x40783100)
nOutputPortIndex(1), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(0), nTimeStamp(0)(0x0), nFlags(0x0)
v4l2_capture_loop: V4L2-1-0: memcpy 3110400 bytes from pBuffer[0](0x40783100) to DEI's(0x135338) input pBuffer and call ETB on buffer[0](0x41210900):
nOutputPortIndex(1), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(0), nTimeStamp(0)(0x0), nFlags(0x0)

DeiCbEmptyBufferDone: client(0), handle(1355f0), count(0), pBuffer(0x41210900)
DeiCbFillBufferDone: DEI-0 nOutputPortIndex(16), nInputPortIndex(0), nSize(80), nAllocLen(1843712), nFilledLen(1843200), pBuffer(0x41def000), latest_dq_buf_index(0)
DeiCbFillBufferDone: DEI-0 nOutputPortIndex(17), nInputPortIndex(0), nSize(80), nAllocLen(1382912), nFilledLen(1382400), pBuffer(0x424f7f00), latest_dq_buf_index(0)
v4l2_capture_loop: V4L2-1-0, client(0): DQed: outPortParams(0x135270), chain_handle(0x1355f0), chain_omx_comp(0x135338), queued(4) dequeued(2), latest_dq_buf_index(1), pBuffer(0x408d4b00)
nOutputPortIndex(1), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(1), nTimeStamp(0)(0x0), nFlags(0x0)
v4l2_capture_loop: V4L2-1-0: memcpy 3110400 bytes from pBuffer[1](0x408d4b00) to DEI's(0x135338) input pBuffer and call ETB on buffer[1](0x41508100):
nOutputPortIndex(1), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(1), nTimeStamp(0)(0x0), nFlags(0x0)

DeiCbEmptyBufferDone: client(0), handle(1355f0), count(1), pBuffer(0x41508100)
DeiCbFillBufferDone: DEI-0 nOutputPortIndex(16), nInputPortIndex(0), nSize(80), nAllocLen(1843712), nFilledLen(1843200), pBuffer(0x41fb1200), latest_dq_buf_index(1)
DeiCbFillBufferDone: DEI-0 nOutputPortIndex(17), nInputPortIndex(0), nSize(80), nAllocLen(1382912), nFilledLen(1382400), pBuffer(0x42649900), latest_dq_buf_index(1)
v4l2_capture_loop: V4L2-1-0, client(0): DQed: outPortParams(0x135270), chain_handle(0x1355f0), chain_omx_comp(0x135338), queued(4) dequeued(3), latest_dq_buf_index(2), pBuffer(0x40a26500)
nOutputPortIndex(1), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(2), nTimeStamp(0)(0x0), nFlags(0x0)
v4l2_capture_loop: V4L2-1-0: memcpy 3110400 bytes from pBuffer[2](0x40a26500) to DEI's(0x135338) input pBuffer and call ETB on buffer[2](0x417ff900):
nOutputPortIndex(1), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(2), nTimeStamp(0)(0x0), nFlags(0x0)

DeiCbEmptyBufferDone: client(0), handle(1355f0), count(2), pBuffer(0x417ff900)
DeiCbFillBufferDone: DEI-0 nOutputPortIndex(16), nInputPortIndex(0), nSize(80), nAllocLen(1843712), nFilledLen(1843200), pBuffer(0x42173400), latest_dq_buf_index(2)
DeiCbFillBufferDone: DEI-0 nOutputPortIndex(17), nInputPortIndex(0), nSize(80), nAllocLen(1382912), nFilledLen(1382400), pBuffer(0x4279b300), latest_dq_buf_index(2)
v4l2_capture_loop: V4L2-1-0, client(0): DQed: outPortParams(0x135270), chain_handle(0x1355f0), chain_omx_comp(0x135338), queued(4) dequeued(4), latest_dq_buf_index(3), pBuffer(0x40b77f00)
nOutputPortIndex(1), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(3), nTimeStamp(0)(0x0), nFlags(0x0)
v4l2_capture_loop: V4L2-1-0: memcpy 3110400 bytes from pBuffer[3](0x40b77f00) to DEI's(0x135338) input pBuffer and call ETB on buffer[3](0x41af7100):
nOutputPortIndex(1), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(3), nTimeStamp(0)(0x0), nFlags(0x0)

DeiCbEmptyBufferDone: client(0), handle(1355f0), count(3), pBuffer(0x41af7100)
DeiCbFillBufferDone: DEI-0 nOutputPortIndex(16), nInputPortIndex(0), nSize(80), nAllocLen(1843712), nFilledLen(1843200), pBuffer(0x42335600), latest_dq_buf_index(3)
DeiCbFillBufferDone: DEI-0 nOutputPortIndex(17), nInputPortIndex(0), nSize(80), nAllocLen(1382912), nFilledLen(1382400), pBuffer(0x428ecd00), latest_dq_buf_index(3)

DRIVER (vin and vpss):

ti81xxvin ti81xxvin: ti81xxvin_check_format: START
ti81xxvin ti81xxvin: ti81xxvin_check_format: pf(0x3231564e) cs(0x3) fld(0x1) w(1920) h(1080)
ti81xxvin ti81xxvin: ti81xxvin_check_format: check pixel format: 0x3231564e
ti81xxvin ti81xxvin: ti81xxvin_check_format(2) - after update: check pixel format: 0x3231564e
ti81xxvin ti81xxvin: ti81xxvin_check_format: inst(0xd0230000)->win.w(0xd0230280) l(0) w(0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: check width: 1920 (min: 0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: using width: 1920 (min: 0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: check height: 1080 (min: 0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: using height: 1080 (min: 0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: set hpitch: bpl(1920)
ti81xxvin ti81xxvin: ti81xxvin_check_format: switch pixelformat(0x3231564e)
ti81xxvin ti81xxvin: ti81xxvin_check_format: YUYV(0x56595559) NV12(0x3231564e)
ti81xxvin ti81xxvin: ti81xxvin_check_format: NV16(0x3631564e) RGB24(0x33424752)
ti81xxvin ti81xxvin: ti81xxvin_check_format: check hpitch: 1920 (min: 0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: set numlines: sizeimage(3110400) / hpitch(1920) = 1620)
ti81xxvin ti81xxvin: ti81xxvin_check_format: check numlines: 1620 (min: 1620)
ti81xxvin ti81xxvin: ti81xxvin_check_format(1): Check for 8 byte alignment: hpitch(1920)
ti81xxvin ti81xxvin: ti81xxvin_check_format: END - ret: 0 - pf(0x3231564e), width(1920) height(1080), bytesperline(1920), sizeimage(3110400)
VPSS_CAPTURE: capture_create(2.1): ccparams->videoCaptureMode(6)(0x6), ccparams->videoIfMode(2)(0x2), ccparams->inDataFormat(4103)(0x1007)
ccparams->numCh(1), ccparams->numStream(1)
ccparams->vipParserInstConfig(0xbfbaf774), ccparams->vipParserPortConfig(0xbfbaf77c), ccparams->cscConfig(0x (null)), ccparams->inScanFormat(1)
ccparams->outStreamInfo[0].dataFormat(7)(0x7)
ccparams->outStreamInfo[0].memType(0), ccparams->outStreamInfo[0].pitch[0](1920), outStreamInfo[0].maxOutWidth(0), outStreamInfo[0].maxOutHeight(0), outStreamInfo[0].scEnable(0)
outStreamInfo[0].subFrameModeEnable(0), outStreamInfo[0].numLinesInSubFrame(0)

2) Not-working case: capture through VIN output port 0 and pass to DEI, source: 1920x1080, DEI told to scale down to 1280x720

APP:

v4l2_capture_loop: V4L2-0-0, client(0): DQed: outPortParams(0x135270), chain_handle(0x1355f0), chain_omx_comp(0x135338), queued(4) dequeued(1), latest_dq_buf_index(0), pBuffer(0x4063a100)
nOutputPortIndex(0), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(0), nTimeStamp(0)(0x0), nFlags(0x0)
v4l2_capture_loop: V4L2-0-0: memcpy 3110400 bytes from pBuffer[0](0x4063a100) to DEI's(0x135338) input pBuffer and call ETB on buffer[0](0x410c7900):
nOutputPortIndex(0), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(0), nTimeStamp(0)(0x0), nFlags(0x0)

v4l2_capture_loop: V4L2-0-0, client(0): DQed: outPortParams(0x135270), chain_handle(0x1355f0), chain_omx_comp(0x135338), queued(4) dequeued(2), latest_dq_buf_index(1), pBuffer(0x4078bb00)
nOutputPortIndex(0), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(1), nTimeStamp(0)(0x0), nFlags(0x0)
v4l2_capture_loop: V4L2-0-0: memcpy 3110400 bytes from pBuffer[1](0x4078bb00) to DEI's(0x135338) input pBuffer and call ETB on buffer[1](0x413bf100):
nOutputPortIndex(0), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(1), nTimeStamp(0)(0x0), nFlags(0x0)

v4l2_capture_loop: V4L2-0-0, client(0): DQed: outPortParams(0x135270), chain_handle(0x1355f0), chain_omx_comp(0x135338), queued(4) dequeued(3), latest_dq_buf_index(2), pBuffer(0x408dd500)
nOutputPortIndex(0), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(2), nTimeStamp(0)(0x0), nFlags(0x0)
v4l2_capture_loop: V4L2-0-0: memcpy 3110400 bytes from pBuffer[2](0x408dd500) to DEI's(0x135338) input pBuffer and call ETB on buffer[2](0x416b6900):
nOutputPortIndex(0), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(2), nTimeStamp(0)(0x0), nFlags(0x0)

v4l2_capture_loop: V4L2-0-0, client(0): DQed: outPortParams(0x135270), chain_handle(0x1355f0), chain_omx_comp(0x135338), queued(4) dequeued(4), latest_dq_buf_index(3), pBuffer(0x40a2ef00)
nOutputPortIndex(0), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(3), nTimeStamp(0)(0x0), nFlags(0x0)
v4l2_capture_loop: V4L2-0-0: memcpy 3110400 bytes from pBuffer[3](0x40a2ef00) to DEI's(0x135338) input pBuffer and call ETB on buffer[3](0x419ae100):
nOutputPortIndex(0), nInputPortIndex(0), nSize(80), nAllocLen(3110912), nFilledLen(3110400), nOffset(0), nTickCount(3), nTimeStamp(0)(0x0), nFlags(0x0)

DRIVER (vin and vpss):

ti81xxvin ti81xxvin: ti81xxvin_check_format: START
ti81xxvin ti81xxvin: ti81xxvin_check_format: pf(0x3231564e) cs(0x3) fld(0x1) w(1920) h(1080)
ti81xxvin ti81xxvin: ti81xxvin_check_format: check pixel format: 0x3231564e
ti81xxvin ti81xxvin: ti81xxvin_check_format(2) - after update: check pixel format: 0x3231564e
ti81xxvin ti81xxvin: ti81xxvin_check_format: inst(0xd0393400)->win.w(0xd0393680) l(0) w(0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: check width: 1920 (min: 0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: using width: 1920 (min: 0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: check height: 1080 (min: 0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: using height: 1080 (min: 0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: set hpitch: bpl(1920)
ti81xxvin ti81xxvin: ti81xxvin_check_format: switch pixelformat(0x3231564e)
ti81xxvin ti81xxvin: ti81xxvin_check_format: YUYV(0x56595559) NV12(0x3231564e)
ti81xxvin ti81xxvin: ti81xxvin_check_format: NV16(0x3631564e) RGB24(0x33424752)
ti81xxvin ti81xxvin: ti81xxvin_check_format: check hpitch: 1920 (min: 0)
ti81xxvin ti81xxvin: ti81xxvin_check_format: set numlines: sizeimage(3110400) / hpitch(1920) = 1620)
ti81xxvin ti81xxvin: ti81xxvin_check_format: check numlines: 1620 (min: 1620)
ti81xxvin ti81xxvin: ti81xxvin_check_format(1): Check for 8 byte alignment: hpitch(1920)
ti81xxvin ti81xxvin: ti81xxvin_check_format: END - ret: 0 - pf(0x3231564e), width(1920) height(1080), bytesperline(1920), sizeimage(3110400)
VPSS_CAPTURE: capture_create(2.1): ccparams->videoCaptureMode(0)(0x0), ccparams->videoIfMode(1)(0x1), ccparams->inDataFormat(6)(0x6)
ccparams->numCh(1), ccparams->numStream(1)
ccparams->vipParserInstConfig(0xbfb0720c), ccparams->vipParserPortConfig(0xbfb07214), ccparams->cscConfig(0x (null)), ccparams->inScanFormat(1)
ccparams->outStreamInfo[0].dataFormat(7)(0x7)
ccparams->outStreamInfo[0].memType(0), ccparams->outStreamInfo[0].pitch[0](1920), outStreamInfo[0].maxOutWidth(0), outStreamInfo[0].maxOutHeight(0), outStreamInfo[0].scEnable(0)
outStreamInfo[0].subFrameModeEnable(0), outStreamInfo[0].numLinesInSubFrame(0)

Thanks,

Przemek

  • 0
    TI__Guru* 80190 points

    Hello,

    przemek_gajos said:
    3) Would it matter here that the data on VIN input is in different formats for the success and the failure case (RGB24 vs. YUV422)? I do not understand why that would be relevant since in all cases VIN capture is told to colour-convert the data to NV12 and then pass it to DEI...

    The accept NV12/422 as input.

    przemek_gajos said:
    when capturing through VIN out port 0 (video originally in YUV422), data is captured but scaling by DEI does not work

    You tested this stand alone right?

    Are you trying dual capture?

    You could try simple gstreamer pipeline and connect the dei output port 00 to fakesink since this port provides 422 output and I assume you does not need it. 

    BR
    Margarita

  • 0 in reply to Margarita Gashova
    Intellectual 290 points

    Helo,

    Thank you for replying.

     >>> You tested this stand alone right?

    Could you specify?  

    At the moment I am testing [ capture with VPSS v4l2 VIN ]   ->   [ OMX VFPC-DEI to scale ] .

    The setup is simple for this initial test (without the encoder). It just "goes around" like this: I am initially queuing buffers for capture, passing data to DEI with EmptyThisBuffer and then requeuing capture buffer in FillBufferDone callback for the 2nd of the DEI's output ports (the one which ouputs NV12) - later I would use that port with the encoder so in its FBD callback buffers will be passed to the encoder.

    On the first DEI's output port (the one which outputs YUV422) I repeatedly call FillThisBuffer in its FillBufferDone calback - anyway, I will not be using it as you figured so I think this is the correct thing to do, right (as far as I remember, Margarita suggested doing this for the not-used output in our other discussion - link given in the first post)?

    There is an interesting outcome of 2 test I have done so far:

    1) In the first test setup, DEI is initialised first and then the capture after that. For this test, DEI does not accept data on its input (does not return with EmptyBufferDone callback) when capturing through VIN port 0 and with DEI told to scale down (details in my first post in which I described that test).

    2) For the second test which I just did, capture component is first initialised and then DEI after that. What I found from this test is that DEI will now correctly scale down what it gets on its input to both of its outputs... so hurra, it's working! ... but video is captured incorrectly:/ It looks like the capture component thinks it should scale down, while it is set up to capture source 1-to-1 and only DEI is setup to scale down.

    => that is why my suspicion is that there is a common bit used by both the v4l2 VIN capture component and DEI so that the setup of one component is affecting the work of the other one in my tests. Do you think it can be the case? Do both these components use the same hardware as scaler? Or would there be a common logic / element in setup? This is just the suspicion. I will now do more tests which should put more light on it and will write back to you with what I found. 

      >>> Are you trying dual capture?

    So far, I have been testing with a single client.

    Best regards,

    Przemek

  • 0 in reply to przemek_gajos
    TI__Guru* 80190 points
    Hello,


    From the log it seems that for VIN port 1 + DEI scale down is working, it does not work for port 0, right?

    For more information about DEI
    e2e.ti.com/.../589719
    e2e.ti.com/.../557538

    BR
    Margarita
  • 0 in reply to Margarita Gashova
    Intellectual 290 points

    Hello Margarita,

     >>> From the log it seems that for VIN port 1 + DEI scale down is working, it does not work for port 0, right?

    Yes, that is correct.

    [ VIN port 1 + DEI ]: scale down and 1-to-1 capture are working 

    [ VIN port 0 + DEI ]: only 1-to-1 capture is working

    To give more details on this project: the card has 2 inputs and from the 1st input (captured through VIN port 0) the data is given to the capture component as YUV422 and for the 2nd input it's RGB24. Capture component should always colour-convert so that it is NV12 on it's output.

    To have scaling (ideally both down and up) is a crucial feature in our product and since in our model at the end of the chain, data will be encoded (encoder accepts NV12), the range of OMX components we could use for scaling is limited because they must output NV12. First, we started investigating the inline scaler but it will not scale RGB24 on its input (plus it does not upscale) and now we are testing the scaler in DEI component. At the beginning DEI looked really good as scaler in our use case: it will output NV12 to feed the encoder, and we would always feed DEI's input with NV12 data (the capture component would colour-convert it to NV12). It is this latest problem with scaling with [DEI + VIM port 0] which I encountered just now that stops the development...

    Best regards,

    Przemek

  • 0 in reply to przemek_gajos
    TI__Guru* 80190 points

    Hello,

    I am sorry I have few more questions.

    In both cases you are feeding the DEI with NV12 same format for both cases. I mean cases "working" and "not working".

    When "not working" case when you are using scale down what you are observing hang, errors, wrong data?

    If there is a hang or error could you provide this log:

    ./loggerSMDump.out 0x9e400000 0x100000 all

    BR
    Margarita

  • 0 in reply to Margarita Gashova
    Intellectual 290 points

    Hello Margarita,

      >>> In both cases you are feeding the DEI with NV12 same format for both cases. I mean cases "working" and "not working".

    Yes, in "working" and "not working" case DEI is fed with NV12 data.

    In both cases, the v4l2 capture is set up to capture into DEI's input buffers and when a buffer is DQed, I call EmptyThisBuffer to give buffer with captured data to DEI for processing.

      >>> When "not working" case when you are using scale down what you are observing hang, errors, wrong data?

    In "not working" case, what I observe is: I pass the DQed buffer to DEI but do not see EmptyBufferDone callback (note that the when passing the captured buffer to DEI, EmptyThisBuffer does not return an error). EmptyThisBuffer is called 4 times on all 4 allocated buffers and then "nothing" more happens really, because DEI is not giving the buffers back so they are not requeued for capture.

    Please see attached the captured frames (go into DEI's input, captured 1-to-1) and frames processed by DEI (from its 2 output ports; scaled down; frames from DEI's output attached only for the working case for obvious reason) for the working case and for the not working case. Source resolution was 1920x1080 and the scaled-down dimensions were 1280x720. You can open the files with a YUV player to confirm about their data format and size.

    frames.zip

    I will now be working on generating the logs which you requested and will send them as soon as they are ready. Would you know of a tutorial on generating the logs with the LoggerSMDump utility?

    Thanks,

    Przemek

  • 0 in reply to przemek_gajos
    TI__Guru* 80190 points
    Hello,

    Have you tried to connect the both output ports,like capture_encode demo in EZSDK?

    BR
    Margarita
  • 0 in reply to Margarita Gashova
    Intellectual 290 points

    Hello,

     >>> Have you tried to connect the both output ports,like capture_encode demo in EZSDK?

    Can you specify? In my tests both of the DEI output ports are populated. For the 1st DEI output, FillThisBuffer is called in its FillBufferDone callback so that data is also produced on that port. 

     

    Best regards,

    Przemek

  • 0 in reply to przemek_gajos
    Intellectual 290 points
    Hello Margarita,

    I am still working on producing the logs. I am having problems to produce the logs and will send them as soon as they are ready.

    In the meantime, does this problem ring a bell?:
    e2e.ti.com/.../871128

    It looks very similar to what I am experiencing. Ken Eppinett could not scale down data captured through VIN port 0 on DEI's 2nd port. In his example, capture component was receiving data as RGB24. In my case, data format is YUV422 through VIN port 0 (not-working case) and it is RGB24 through VIN port 1 (working case).

    Do you think the capture mode the capture component is configured with is relevant here?
    - for my working case it is: VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_DISCRETE_SYNC_ACTVID_VSYNC
    - for my not working case it is: VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_EMBEDDED_SYNC

    I am not in control of setting the above.

    Ken worked around the problem by commenting out some code in omx_vfcc_drvif.c. I already tried the "work-around" fix but it does not work for me.

    Best regards,
    Przemek
  • 0 in reply to Margarita Gashova
    Intellectual 290 points

    Hello Margarita,

    Please see attached the logs you requested. They were generated with:

    ./loggerSMDump.out 0x9e400000 0x100000 all

    and the debug level was increased to 3 so that data exchanges were logged as well as the initialisations (to my knowledge:-)).

    The 2 attached logs are: one for the working case and the other for the not working case; the test was as described before so 1920x1080 source scaled to 1280x720. You will note from the logs that the encoder component is initialised there but not used (no data is sent to it at the moment; it will be done at a later stage once capture-DEI is working) and I believe the existence of the encoder is not relevant. 

    loggerSMDump_input1_and_input3.zip

    Do these logs show the relevant information for debugging this case? Please, let me know if I can help further (generate more logs?) 

    Best regards,

    Przemek

  • 0 in reply to przemek_gajos
    TI__Guru* 80190 points

    Hello,

    Could you try with the OMX capture_encode demo not with v4l2 and let us know the result.

    The OMX capture encode demo is already using VIP A port0.



    BR
    Margarita

  • 0 in reply to Margarita Gashova
    Intellectual 290 points

    Hello Margarita,

    Please note that for for our project, OMX capture component (VFCC) cannot be used for capture because only YUV422 is supported at VFCC's input, while in our model data is YUV422 16bit on one card's input and it is RGB24 on another one (and we cannot change it).

    Would it help if I generate and send you the logs, like previously but with debug level increased to maximum (5)?

    Regards,

    Przemek

  • 0 in reply to przemek_gajos
    TI__Guru* 80190 points
    Hello,

    I know but the OMX capture encode demo is working and it is using VIP A port0.
    The scale down is working.

    Check this topic:
    e2e.ti.com/.../871128

    BR
    Margarita