Channels Not-well separated

DVR RDK do not support dynamic encode channels delete/create as same as decode channels.  Can you please let me know how many encode channels you require and what are the resolution.  If you do not required very high number of channels, may be you can create all required resolution and codec type and dynamically route to different channels. I mean if you want to change from H264 to MPEG4, create two channels, ch1 for H264 and ch2 for MJPEG. then dynamically you can change the data flow from channel-1 to channel-2

regards, shiju

Hi Shiju,

In one project I deal with 1 channel 1920x180 + 4 channels 720x480, in another project I deal with 2 channels of 1920x1080. As I understand, each channel ID has its codec format.  What do you mean by changing the data flow? if the format is attached to channel ID, It seems that changing the data flow will not help. Do you mean to dynamically change channel ID to some other channel ID?  I need some more details to fully understand your solution. I also understand from your answer, that If this is not done dynamically in some solution, we will have to stop/start all encoding chains and that will interfer other channels, as I see. Is it a Link limitation (not a hadrware limitation) ?

Thanks,

Ran

Ran

Ok, if you have ~5 channels and so, then my proposal is not good enough. What i suggested is, if you have only one channel, then you could create 2 ch with first ch as HD ch264 and second one with HD Mpeg4. then using a select link you can dynamically route the data to either ch1 or Ch2.   

regards, shiju

Hi Shiju,

Is there any solution for this problem of interfere between seperated channels ? Is it a hardware limitation ? where in the chain is this limitation (there are 3 codec engines, so it seems that 3 separate channels can be achieved)

Thanks,

Ran

Ran
There is no HW limitation, its a SW limitation.
one solution as I already mentioned is with multiple encode channels and a Dup + merge links just before ENC link

for example,
capture - 1ch HD and encode - either H264 or MJPEG
You might be able to achieve this by create 2 channels of HD encode, first channel - HD H264, second channel - HD MJPEG

Now the data flow as below
Capture output - 1ch HD (420SP format)
connect a dup link after capture to duplicate to 2 outputs
use one merge link to output to one output Q, merge link will have 2 output channels
connect to enc link where 1ch goes to H264 ch (ch1) and second ch goes to MJPEG ch (ch2)
Dynamically we can control the encode stream by input frame drops feature in enc link
if we select output FPS as 0 for channel 0, and 30 for channel 1, then MJPEG only will get encoded, channel 0 drops all frames at the input side of encode link
if we select output FPS as 30 for channel 0, and 0 for channel 1, then H264 ch only will get encoded, channel 1 drops all frames at the input side of encode link

Hi Shiju,

Thank you for the suggested solution! I have added the following figure to visualize the usecase you described. As I understand from this, the "trick" is that Merge Link actually changes channel ID, so that we can have in the encoder input 2 different channel ID with same video.

1. Can I use the same idea of DUP/MERGE Links to support 5 channels for example which are using 2 codecs or is this solution limited to 2-3 channels only ?

2. In decoding it is possible to disable and create a channel on the fly, so it seems to me that this problem is a SW Driver limitation (not Link limit). Is this SW Limit actually a Driver OR Link limitation.?

3. regarding the suggestion to change dynamically fps for each channel. Isn't it simpler just to disable/enable channels to gain the same result ?

4. similar problems of closely-tied-channels in terms of changing single parameter in a single channel happens with the following requirements in my project. The problem: changing a parameter in one channel requires stop/start other channels too.

Is there a solution for the following parameter:

     a. changing scan-type (I/P) in encoder channel

     b. changing scan-type (I/P) in decoder channel

      c. changing capture input resolution (standard) in VIP

Thank you very much!

Ran

<1>

yes, you can use the same idea to support 5ch.  The limitation here is the number of dup link output Q and number of merge link input Q. I guess it is 6 as default. But you can also modify this #define to support more channels in DUP and MERGE link accordingly

<2>

In decoder case, yes you can only delete and create the decode channels.  Encode side its a link limitation ( we did not do it as it is not requited for DVR)

<3>

     a. changing scan-type (I/P) in encoder channel - We support only progressive mode (NO support for interlace encode)

     b. changing scan-type (I/P) in decoder channel - We support only progressive mode (NO support for interlace decode)

      c. changing capture input resolution (standard) in VIP - This is not supported run time.  But can be support as create time

regards, shiju'

Thanks Shiju,

<1> 

Is it that the only cost of adding more Links is the memory consumption for the frame pointers in MsgQ ? 

<2>

So, Is it possible to add Delete/Create channel feature to the encoder Link, and it will be supported by Driver too ?

<3>

     a & b . According to slides in MCFW training guide it is shown that Encoder/Decoder Link support interlaced & progressive.   What should we do to support interlaced if it is not supported ? where is this limitation, is it part of encoder/decoder link or Driver (Codec) ? is it possible to add in encoder/decoder link support for that ?

      c. I don't mind if it is supported only in create time instead of run time, but the big question is if it can it be done without interfering other channel ? What is the time it takes for stop and start usecase with new parameters ? Is it necessary also to delete and create the chain for new initialization ?

Thank you for your time!

Ran

<1>

yes, addtionl memory requiremnt for enc link ouput bitstream buffers is the only cost

<2>

It is possible to add Delete/Create channel feature to the encoder Link, only ENC link need to be upadated

<3>

Interlace support is brocken while we start using the multi-channel (optmized version) codec.  The issues are in both codec and link level

yes, the full chain need to be deleted and create again while capture resolution change.  This is not required if you change the resolution from Higer to any smaller ones.  So another option is always allocate buffers for higest possibel resolution in capture and other links. Update the capture width & height from App, modify capture link to pass the new resolution to next link.  This will be supported in the Nov end RDK release

regards, shiju

Hi Shiju,

<1>

I meant here any other Link, like merge and Dup, the cost here is of frame pointers (frame header) in msgQ, right ?

<2>

Adding delete/create feature for encoder will save the added usecase design that was suggested in the previous message. It seems like a better and more generic solution. Is it planned to be added to RDK release ?

<3>

a&b. this issue is a problem because codecs data sheet for h.264 (and other codecs too)  show that it support interlace and progressive input, and also Link slides (training doc) also show support for interlace scan-type. Can you please give guidelines how we can add interlace support in encoder & decoder ?

c. Does the following API from RDK 3.0 support dynamic change of capture resolution  Vcap_setDynamicParamChn(chId, &params, VCAP_RESOLUTION) ? if not - what should I add to support the dynamic capture resolution ?

Best Regards,

Ran

Hi Shiju,

Thanks for all the given answers, it is very helpful!

I have a few more questions, just to make it all clear...

<3>

- you wrote that the issue of interlace is also not supported in driver level.  Is interlace planned to be added to codec next releases ?

- If interlace mode will be added to encoder/decoder link, will it also be allowed to be added as one of the parameters of disable/create channel i.e. the parameters in create_channel(xxx) don't have to be dynamic parameters of codec algorithm, right ?

5. regarding the previous suggestion to change dynamically fps for each channel. Isn't it simpler just to disable/enable channels to gain the same result ?

6. Is there an estimation for the time it takes to stop/start the channels ? Is it needed also to delete and create the channel for changing of parameter ?

Many Thanks,

Ran

Hi Shiju,

Thank you very much for the replies in this thread, it is most helpful.
Can you please refer to the questions in previous message ?
This issue of interfere between channels on configuring parameter on some channel is crucial in my project. 

Thanks!  

Ran

Ran

sorry, i missed the query

There are multiple issues with interlaced, 

1. Codec not tested for this recently, there were artifacts and crash issues when we verified last

2. HDVPSS drivers such as DEI and SC does not support field merged form of buffers, so some changes required in RDK to support this mode.  Otherwise only TOP field get displayed and all bottom ones got eliminated while De-interlacing

Let me see, if we can get the interlace support back in RDK. i will not be able to commit now, but we will try our best

>>> - If interlace mode will be added to encoder/decoder link, will it also be allowed to be added as one of the parameters of disable/create channel i.e. the parameters in create_channel(xxx) don't have to be dynamic parameters of codec algorithm, right ?

Yes, this can be done

>>> regarding the previous suggestion to change dynamically fps for each channel. Isn't it simpler just to disable/enable channels to gain the same result ?

disable/enable channels makes the FPS either 0 or the last configured value.  If you want to change FPS say 30 to 15 run time, then disable/enable channels will not be enough

>>> Is there an estimation for the time it takes to stop/start the channels ? Is it needed also to delete and create the channel for changing of parameter ?

This is different for ENc and DEC link.  

Enc link even if you want to change the channel resolution to a higher value than the create time resolution, the whole chanin need to be deleted and created. This will takes a few seconds.  But certain configurations are supported run time such as CBR/VBR, FPS setting, Changing resolution to any lower value than the create time resolution etc

Dec link, a few are supported run time even without delete and create the channels, such as FPS setting, moving to any lower resolution compared to the create time resolution etc.  But moving to higher resolution, codec type change etc required delete/create individual channels. Never required to delete and create the entire links and chain. One channel delete/create takes ~1sec

regards, Shiju

Hi Shiju,

Regarding the DEI & SC support for field merge, I actually thought of using the following usecase for dealing with interlace input which will be encoded as interlaced (this usecase also deals with other input and encoded scan types . As you can see I don't use DEI for interlace bypass mode, but I use the chain of SC & NSF for the interlace input , which is also encoded as interlaced. When you wrote in 2. that there is problem in DEI & SC for support  field merge, will it be a problem in this chain too (which uses SC) ?

Thank you very much for all given answers !!!

Ran

Ran

Sorry for the confusion.

The DEI and SC i mentioned are not part of the DEI or SCLR link.  I am referring the SWMS module which also uses DEI IP, where one set of fields will get rejected currently if we put both TOP and bottom fields in the same frame 

Normally enc link there is no issue as there is no HDVPSS process link after enc link, just send for streaming

But normally SWMS link comes after dec link.  For you what is the next process link after the dec link

regards, shiju

Hi Shiju,

I consider 2 alternatives at this point:

1. using dei/sc links after DEC link to suppot progressive/interlace scan types at the outputs (vout0,vout1)

2. using only display links after dec:

I did not fully understand if the problem is in DEI and SC in general. SWMS uses SC(5) as I understand.

Regards,

Ran

Hi Shiju,

I will not use SWMS in any case, but I will probably use DEI, and SC after DEC (you can see that in the figure in my previous message). Should I expect any problems with that or is the problem of interlaced, you mentioned before, is relevant only when using SWMS ? Do you notice any expected problem with this usecase  ?

Thank you very much,

Ran

Ran

Earlier mentioned issue related to interlaced mode will occur even if you use SWMS or DEI/SC after DEC link.  I recommend you to use progressive encode and decode.

regards, shiju

Hi Shiju,

Thank you very much. Interlaced feature is a must requirement in encode and decode in out project.

Is interlaced mode planned to be added to RDK ?

Thanks, Ran

Ran

Thanks 

We have thought of getting interlaced mode support back in RDK, but at present not much clarity on date.  Feature set for our next planed release is freezed (Mid-Nov).  We will pick interlace support after this release

Regards, shiju