Is there a way to avoid MM_STATUS_TICK_UPDATE? | developer.brewmp.com Is there a way to avoid MM_STATUS_TICK_UPDATE? | developer.brewmp.com

Developer

Is there a way to avoid MM_STATUS_TICK_UPDATE?

Forums:

I'm using MM_STATUS_TICK_UPDATE and keeping track of the current time of my file playback by adding 1000 to a state holder int but at the end of the file the total time and the current time don't match up (for a 3 minute file, the discrepancy is about 12 seconds).

Clearly the TICK is not being reported accurately enough. Is there a way for me to get the current media playhead position or do I have to resort to setting my own clock at media play inception and subtracting from the progressing clock every time the tick comes around? I don't see an alternative, though the prospect of doing it this way seems kind of a$$ backwards.

all thoughts greatly appreciated.

thanks.

so... I implemented the clock watcher and it works more accurately than the TICK event notifier, but, the problem is that if there's any network congestion that forces a pause in the video as it rebuffers, time doesn't stop in the universe and my clock gets thrown off.

so... I implemented the clock watcher and it works more accurately than the TICK event notifier, but, the problem is that if there's any network congestion that forces a pause in the video as it rebuffers, time doesn't stop in the universe and my clock gets thrown off.

Hi:
When you get MM_STATUS_TICK_UPDATE and MM_STATUS_SEEK notify, get the notify's param which format is AEEMediaCmdNotify
extract its pCmdData field and cast it to uint32 type, the result is the exact current tick time
add 1000 is only a backup method when the param field is sometimes 0(perhaps)
when reaching finish point, the time may not be so accurate, but you know the play is finished, so you can force the tick time equal to total time.
Hope it helps

Hi:
When you get MM_STATUS_TICK_UPDATE and MM_STATUS_SEEK notify, get the notify's param which format is AEEMediaCmdNotify
extract its pCmdData field and cast it to uint32 type, the result is the exact current tick time
add 1000 is only a backup method when the param field is sometimes 0(perhaps)
when reaching finish point, the time may not be so accurate, but you know the play is finished, so you can force the tick time equal to total time.
Hope it helps

Hi,
When I am getting MM_STATUS_TICK_UPDATE event notification, pCmdData value is NULL. Any idea?
Thanks in advance

Hi,
When I am getting MM_STATUS_TICK_UPDATE event notification, pCmdData value is NULL. Any idea?
Thanks in advance

kooladish wrote:Hi,
When I am getting MM_STATUS_TICK_UPDATE event notification, pCmdData value is NULL. Any idea?
Thanks in advanceThis probably should have been posted to a separate thread as it is not really related to the original question other than involving MM_STATUS_TICK_UPDATE. Looking at the BREW API Reference documentation for AEEMediaCmdNotify, the MM_STATUS_TICK_UPDATE notification for both MM_CMD_PLAY and MM_CMD_RECORD does not have a pCmdData return value, so this is the expected behavior. What were you expecting it to return?

kooladish wrote:Hi,
When I am getting MM_STATUS_TICK_UPDATE event notification, pCmdData value is NULL. Any idea?
Thanks in advanceThis probably should have been posted to a separate thread as it is not really related to the original question other than involving MM_STATUS_TICK_UPDATE. Looking at the BREW API Reference documentation for AEEMediaCmdNotify, the MM_STATUS_TICK_UPDATE notification for both MM_CMD_PLAY and MM_CMD_RECORD does not have a pCmdData return value, so this is the expected behavior. What were you expecting it to return?

AEEMedia.h has documentaion as below.
// AEEMediaCmdNotify structure is returned via registered callback function to client.
// Value of pCmdData depends on combination of (clsMedia, nCmd, nSubCmd, nStatus).
// For IMedia class, it can be one of the following:
// uint32 dwElapsedTime; // [MM_CMD_PLAY/MM_CMD_REC, MM_STATUS_TICK_UPDATE] Milliseconds
I am receiving first MM_STATUS_TICK_UPDATE event notification after ~1700ms and consecutive MM_STATUS_TICK_UPDATE event notifications are in interval of ~1000ms only. What may be possible reasons for first time delay and how much actual media data is rendered in that interval of time?

AEEMedia.h has documentaion as below.
// AEEMediaCmdNotify structure is returned via registered callback function to client.
// Value of pCmdData depends on combination of (clsMedia, nCmd, nSubCmd, nStatus).
// For IMedia class, it can be one of the following:
// uint32 dwElapsedTime; // [MM_CMD_PLAY/MM_CMD_REC, MM_STATUS_TICK_UPDATE] Milliseconds
I am receiving first MM_STATUS_TICK_UPDATE event notification after ~1700ms and consecutive MM_STATUS_TICK_UPDATE event notifications are in interval of ~1000ms only. What may be possible reasons for first time delay and how much actual media data is rendered in that interval of time?

Well, obviously one section of the documentation must be wrong and considering that you are getting 0 for pCmdData, I would assume that the section that says there is no return value is correct. As for the delay, from AEEMedia.txt:
Quote:# [MM_STATUS_TICK_UPDATE] gives periodic tick updates. It is typically one second. This is not a real-time clock feedback and it is a coarse time update that is usually used to display the playback progress by applications.So the tick update isn't really supposed to be used as a timer as you really shouldn't rely on it triggering at regular intervals, it is more just a way to send "reminders" to your app to update the playback progress. Second, when are you starting your timer when you get 1700ms? You should be starting it when you receive the [MM_CMD_PLAY, MM_STATUS_START] event, rather than at the time when you call IMedia_Play().

Well, obviously one section of the documentation must be wrong and considering that you are getting 0 for pCmdData, I would assume that the section that says there is no return value is correct. As for the delay, from AEEMedia.txt:
Quote:# [MM_STATUS_TICK_UPDATE] gives periodic tick updates. It is typically one second. This is not a real-time clock feedback and it is a coarse time update that is usually used to display the playback progress by applications.So the tick update isn't really supposed to be used as a timer as you really shouldn't rely on it triggering at regular intervals, it is more just a way to send "reminders" to your app to update the playback progress. Second, when are you starting your timer when you get 1700ms? You should be starting it when you receive the [MM_CMD_PLAY, MM_STATUS_START] event, rather than at the time when you call IMedia_Play().

I am starting the clock once receiving [MM_CMD_PLAY, MM_STATUS_START] event. I need to know how much data is rendered/played in each MM_STATUS_TICK_UPDATE event interval.
For me, first MM_STATUS_TICK_UPDATE event notification is coming after ~1700ms, but only ~1000ms data is rendered in this interval. So, there is ~700ms offset from actual clock.
Any idea?

I am starting the clock once receiving [MM_CMD_PLAY, MM_STATUS_START] event. I need to know how much data is rendered/played in each MM_STATUS_TICK_UPDATE event interval.
For me, first MM_STATUS_TICK_UPDATE event notification is coming after ~1700ms, but only ~1000ms data is rendered in this interval. So, there is ~700ms offset from actual clock.
Any idea?