[plex]

I have been having problems playing remote flv files or octet streams from megavideo.com

Here's an example url, that has given me this problem that you can try yourself:
http://www05.megavideo.com/files/40c1aa1...a1fe07ad9/

or

http://www05.megavideo.com/files/40c1aa1.../index.flv



Basically it makes a loud screeching noise when i try to play it, and then quits playing the file. I've tried playing it on VLC player & km player and it plays with no problems..
So what's wrong with xbmc's flv player?

[plex]

its bad that nobody cares.

[plex]

i'm on the latest march 9 tech build btw

[elupus]

we do care, just not as quick as you seem to think.

mplayer fails to detect what that stream contains and plays it as raw audio. thus things go haywire. not sure why it's not detected as flv.

[elupus]

plays fine if you append filename.flv to it..

like this.
http://www05.megavideo.com/files/40c1aa1...lename.flv

then it spots that it's a flv file from the filename, and it plays allright.

[plex]

thanks for the explanation elupus!
yes I would like to know the answer to this also "not sure why it's not detected as flv."

Obviously any program or media player that tries to ID a file must do it from other methods than looking at its file extension, like file structure or file headers.. So what is going on with this file that xbmc cannot do this....

[elupus]

agreed, it should do that. something is throwing it off thou.

[elupus]

ok, fixed now. it thought it was mp3 as it contains mp3 headers. i moved libavformat detection above audio detection as we hardly use mplayer for audio nowadays anyway.

[plex]

great work, elupus!
I will upgrade to the latest version of xbmc...

However, here's another I noticed. Megavideo has the special behavior in seeking to any position within a flv stream that they have. It does something like this when you seek to a new position:
http://www19.megavideo.com/files/videoID/new number goes here

the higher the "new number" is the farther in time the position you have chosen to seek in the video is.
An example is this:
http://www19.megavideo.com/files/3354981...1f/3465163
That seeks something like a minute into a 2 minute video...

The cool thing about it is that it seems to access a new video file that starts from this position in time that you have chosen to seek to, so in other words you can do this in any flv player (vlc, km player) and it will work fine:
http://www19.megavideo.com/files/3354981.../index.flv


XBMC can't seem to handle this new video stream though, and it caches it till about 2 bars from finishing and then spits out a "warning cannot seek to...." message and never finishes caching it.
Here's an example file:
http://www19.megavideo.com/files/3354981.../index.flv

If the file this url is referencing is in fact a different video file that simply starts at a different time, that megavideo stores on its server, this behavior is truly weird, because it shouldn't be any different than what xbmc normally does with flv files.

Of course, it must not be the same, and whatever this url points to it must send some dynamic call to the player to seek to this position on its own, which km player, vlc player can do, but xbmc's mplayer cannot....
That's my hypothesis on it...

[plex]

bump, the "seek into" megavideo links I shared above expire within about 24 hours
Here's a fresh one if you want to see what I'm talking about, make sure you try it before it expires.
http://www56.megavideo.com/files/b1135b1...0d/3653696