Comment 13 for bug 880840

@ricardo: yes, we have looked into this earlier this week and there is a regression somewhere around syslink. if we enable the gst-ducati traces, we can see that the time to process each frame is ~50ms, hence we are dropping many frames. with 3.0 kernel this does not happen, the processing time is ~25ms. it's just the decoding time, nothing to do with rendering. i tried to measure the processing time on the ducati side using the 32K, and it sounds like this side is fine (~20ms), which would imply that the problem is in syslink...

sebjan is in vacation this week, and with xmas coming around, i am not sure we will be able to tackle this this month.

@warmcat: is that something you can look into? very first thing to do might be to measure the RPC call in a simple syslink samples and see what we get for 3.0 vs 3.1, if we can observe the problem there, it might be simpler to debug. otherwise we will need to debug with MM packages, but it is quite straigtforward.

GST-ducati will end up calling VIDDEC3_process() function which is in dce.c in libdce, and this function will use the RCM exec (RPC) API to send the command and args to the ducati M3 where the actual VIDDEC3_process is executed and uses the IVAHD.