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.

Dynamic resolution change with IPNC RDK 3.5?

Other Parts Discussed in Thread: DM385

We are using the IPNC RDK 3.5 with a DM8127 to encode and stream H.264 and would like to be able to change the resolution of a channel on the fly.  I have read http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/246846/863553.aspx#863553, which says that the encoder will automatically change resolution if the output resolution of an upstream Scaler link is changed.  We are not using a Scaler, but  I have tried something similar by dynamically changing the output dimensions of the Resizer in an upstream ISP link.  When the resolution is changed while the output stream is being viewed with VLC, the result is that an image of the correct new (smaller) dimensions appears in the upper left portion of the window, but the dimensions of the window do not change (it looks like picture-in-picture).  It appears that the ISP's resizer is doing what we want, but the encoder still thinks the frames have the original dimensions.

How is the encoder supposed to learn that an upstream link has dynamically changed the frame dimensions?  I've looked through all the frame metadata sent downstream by the ISP link, but I haven't found width and height information in it.  Thanks!

- Dave Beal

  • Hi,

    May be it is not encoder issue, it is just the gui issue where it is not changing the resolution.

    Regards,

    Brijesh

  • Thank you, Brijesh.  The picture-in-picture result seems to imply that the ISP's resizer is using the new resolution, but the fact that the frames remain the same size implies that the encoder doesn't know about the resolution change.

    Can anyone explain how the encoder is supposed to find out about the resolution change, as indicated by Badri in the link in my original post?  Thanks!

    - Dave

  • Associated with each video frame in DVR RDK a meta data structure called rtChannelInfo exists. The rtChannelInfo has info such as frame resolution , data format etc. The encoder check the rtChannelInfo associated with a frame and compares it with previous frame info and if it detects a change in resolution it reconfigures itself according to the new resolution. For this to work the link sending frames to the encoder should populate the rtChannelInfo correctly and also update it when there is a change in resolution. In DVR RDK this is done in all links. I dont know if this is done in the IssLink in IPNC RDK.

  • Thank you, Badri.  I've looked in the H.264 Encoder code of IPNC 3.5.  I see it pulling a System_FrameInfo pointer out of the appData field of incoming FVID2_Frames, but the only field of System_FrameInfo that it looks at is the timestamp.  I don't see it looking for frame dimensions.  I added code to the ISP link to put frame width and height into System_FrameInfo, but this had no effect on the encoder.

    It appears that the encoder in IPNC RDK 3.5 is the same as that in DVR RDK 3.0.  Was the encoder that dynamically adapts to resolution changes new in DVR RDK 3.5?  If so, that would explain why I don't have it.

    - Dave

  • Hi Dave,

    Could you please see if rtChInfoUpdate flag is getting set to TRUE when resolution is updated?

    Regards,

    Brijesh Jadav

  • Hi Dave,

    the encoder is checking the resolution update for every frame in the function EncLink_codecDynamicResolutionChange.

    In order to inform the encoder about any dynamic resolution change, in the ISP link you need to set rtChInfoUpdate to TRUE and also feed new parameters into rtChInfo.

    You don't need to do this for every frame, but just the first frame with the new resolution.

  • It works!  Thanks to Zhuoran, Brijesh and Badri.

    I can now switch back and forth between two resolutions on the fly by resizing in the ISP link, placing the new dimensions into rtChInfo and setting the rtChInfoUpdate flag.  However, if I try to change to a third resolution (also smaller than the original) on the fly, the encoder crashes.  Is this a known problem?  Any workaround?

    - Dave

  • what are the resolutions you use during your test?

    If you are sure that the crash happens on the encoder, this may be due to some improper settings on the codec, I believe you didn't update any codec settings after the dynamic resolution change and some of them may not be adapted for a very small resolution.

  • The problem was apparently caused by specifying invalid values as new dimensions.  My test was taking the original resolution (1920x1080) and multiplying both dimensions by an arbitrary value, like 0.9.  The result was sometimes an odd number.  I've changed the code to always round the new width down to a multiple of 16 and the new height to an even number, and the test now runs fine. 

    Thanks again!

    - Dave

  • Hi

    I am using  IPNC_RDK_DM812x_DM385_Version3.5.0 , my selected usecase is "multich_tristream_fullfeature" .

    With this I am able to stream 720x480 H264 encoded data but when i am changing this resolution to 320x240 , I am not able to stream. Kindly suggest