View Full Version : ML_OPEN_XCODE_MODE default

03-17-2005, 05:49 PM
I sure hope someone is still alive here.

The default value for ML_OPEN_XCODE_MODE_INT32 is set in mlpublic.c to ML_XCODE_MODE_ASYNCHRONOUS. This has an enum value of 20. MODE_SYNCHRONOUS has an enum value of 10. mlDIparseOpenOptions() prevents the user from decreasing the default value.

Therefore a transcoder can never be opened in synchronous mode?


03-17-2005, 07:37 PM
I'm a bit confused about the ML_XCODE_MODE_SYNCHRONOUS. page 28 of the OpenML Specification tells that:
If a software transcoder is opened with the ML_XCODE_MODE_SYNCHRONOUS option, the transcoder will not spawn any threads and will not do any processing on its own.
In the other hand, in page 86 we see this explaination:
mlXcodeWork only applies to software transcoders that are opened with the ML_XCODE_MODE_SYNCHRONOUS open option.
So it seems that something is incorrect in the specification :confused: .But from your comments, it seems that the meaning of the specification is that we can't use from the
ML_XCODE_MODE_SYNCHRONOUS for software transcoders.

Note also that you should use from the symbolic constants-Not the enum values - to ensure that your code works for all the implementations of OpenML.

[ March 18, 2005: Message edited by: Ehsan Kamrani ]

03-18-2005, 03:05 AM
Hello Jarno,

There should be nothing preventing you from choosing a different xcode mode -- as long as the device (transcoder) you are using supports the mode. I assume you're trying the nullxcode sample transcoder, and it does, in theory, support both modes...

I've looked through the code rapidly, and can't spot an obvious bug. Could you send some more details about the problem, ie symptoms, error msgs etc. (You say you've traced the problem to mlDIparseOpenOptions -- could you show me where?)

Ehsan: there is no contradiction in the spec. In Asynchronous mode, the transcoder starts a thread that performs the work. The application does not need to worry about it -- and hence does not need to call mlXcodeWork. In Synchronous mode, however, no thread is automatically spawned -- it is the application's responsibility to ensure the xcode work gets done. This is achieved by calling mlXcodeWork.

03-18-2005, 02:46 PM
I think I see what my misunderstanding is. The OpenML default is async (as given in the defaultOpenOptions in mlpublic.c), which can't be changed to synchronous by the user through an mlOpen() option (as MODE_SYNCHRONOUS < MODE_ASYNCHRONOUS, and mlDIparseOpenOptions() prevents setting an option's value less than its default).

However, a transcoder can set what the default value should be through the capabilities. If the xcoder wants to support synchronous mode, it apparently has to set that as a capability.

It's just that the (rapidly becoming infamous) nullxcode.c example doesn't. So it uses the OpenML default of async, which the user can never override to synchronous, even though the nullxcode_test.c program tries to.


03-19-2005, 12:42 AM
Hello Jarno,
You wrote that:
mlDIparseOpenOptions() prevents setting an option's value less than its default
As i have understood, you are using from the values to change the defalut case.You *only* have two options:ML_XCODE_MODE_SYNCHRONOUS and ML_XCODE_MODE_ASYNCHRONOUS. If the enum value of ML_XCODE_MODE_ASYNCHRONOUS is 20 and the enum value of ML_XCODE_MODE_SYNCHRONOUS is 10 then you can't use from another values to set the options.You can't decrease the value of 20 to any value.
Using the values that haven't been defined in the header files, is a violation.

[ March 19, 2005: Message edited by: Ehsan Kamrani ]

03-19-2005, 01:00 AM
Hi Fabrice,
Any processing is started after the mlBeginTransfer.In both mode-sync and async-the process should starts after the mlBeginTransfer.So in synchronous mode, why we you use from the mlXcodeWork--Why have you witten the mlXcodeWork function?

03-21-2005, 05:23 PM
Hi Ehsan

the issue is about what thread performs the work, i.e.: whether the work is done in a thread that is started and controlled by the ML device (in which case mlXcodeWork is *not* required -- the ML device decides when to schedule the work), or whether the work is only performed in a thread owned and managed by the application, at a time determined by the application. In this latter case, the mlXcode work function is used by the application to trigger the processing.

03-21-2005, 05:32 PM

yes, I see what you're saying. This certainly seems to be a bug -- it should be possible to change the default mode; it shouldn't matter that one enum is "less than" the other.

It would be interesting to see what happens if the nullXcode device supplied a default value of MODE_SYNCHRONOUS (currently, it sets no default).

I'll make a note of this, and see if the rules in mlDIparseOpenOptions can be relaxed.

Thank you for the bug report.