Could this be added to a future build of ST ? I am thinking to MP4, OGM and MKV.

Probably not... The basic rule is if WMP8 plays it, ST can play it as well. If not, bad luck. I have no knowledge of writing my own media player

Yes, I know about WMP, but was just hoping.
My WMP6.4 plays MP4 files, so does ST but didn't manage to play MKV files.
WMP play wmv files, ST doesn't or plays them with errors (123,733 frames , playing at 1,71 fps

well, if you find somebody, who could write a code for player that would be possible to import through package to builder and could implement all the methods and properties I need for ST, it would be no problem at all

Same thing happening with those formats like the ones from the Vista support post

http://forum.mironto.sk/index.php?showtopi...&st=0&#entry603

I can confirm that when playing mkv files from ST, instead of showing frames we have seconds. Could this be related ? And have the same solution ?

OK, the solution can be simple, in fact it's just avoiding a complex situation. When importing frame numer, can the function import the number as an Integer and not a floating point number ? After the import it's done, you can multiply the numbers by framerate (using different methodes) and all should work fine from now.

Not quite sure what you mean. I do not import the frame number or anything, there is a parameter in WMP container that holds the current position. I can set variable in WMP container whether it should be frame number or time position.

I could be possible to always get time position (as this should work for all media files) and then recompute it to frame. But it may require massive rewriting of the code. Or maybe not, if I find some time, will have a look at it.

OK, let's try harder. I believe ST acces the splitter in a wrong manner. The splitter reports back, instead of "number of frames| (it's SUB based program, when you press the import current frame button, it will call a number, that it's usually an integer one, being a frame number) but you get somehow a value that is not an integer, rather the numer of frame divided by the framerate and it hase some 6-8 digits after the decimal point. So, into frame start and frame end columns you will get values like: 2.579 and 3,1535624 and again 4,0174583 and 4,7460833. Those values are seconds, rendered by ST from dividing the frame number to the frame rate. Tested that. So. When pressing "import current frame into subtitle" button, you must force this value to be an integer, so the values above will become 3 and 3 and again 4 and 5. After that, if you multiply this value with the framerate the subtitle will be OK. Am a little bit more clear in what I mean ?

Once again - since some containers cannot output the position in frames (even though I ask WMP to provide frames and also expect them), they output it in time (usually seconds).
As I said, I could change the routine to always get time instead of frames (which works for every container) and compute the actual frame by multiplying the time by frame rate (no need to round the time to integer first, as you would loose precision) and then round it to integer.

This is not a flaw of ST, it's WMP's "fault" that it cannot report video position in frames for all containers.

I never said it's ST flaw or something, just searching for a workaround. So, you can call time ? That should be even better, this is .srt format.

LE: or do that calculus you posted