[stevenbg]

I made a plugin, but the flv videos are not seekable in xbmc, because the flash player on the site uses http parameters.

Every time you seek it changes the start parameter and reloads the video, like this:

Code:

http://str.by.host.bg/novatv/zdravei-bulgaria/zdravei-2011-03-23.flv?start=1025743930

Is there a way to make it work in xbmc?

[danillll]

I've been looking for the same answer.
I wonder if someone can explain how the seek feature to a certain point in time would work without having to wait for the buffer to complete.
Right now, the majority of streams take an extra argument at the end of the URL with a value, the time in ms, on where to start playing. It looks like xbmc does not support this and instead waits to buffer when the seek is hit. can anyone confirm?
On the other hand, I noticed some mp4 streams works perfectly when XBMC sends a new http request with the number of bytes range, so it does not wait to buffer.

Thanks

[anarchintosh]

this is literally what i just logged on to enquire about.

the adult Fantasti.cc addon uses xvideos.com which uses the same http seeking you describe,
and obviously i don't want to watch the corny intros for every single porn vid i load.

ps. afaik would be something that needs to be fixed in XBMC core.

[spiff]

show me the standard it adhere's to....

[anarchintosh]

long answer edit: see post 8
short answer for spiff
a query string called fs is passed into the URI, containing the byte we want to seek to.
ie.
http://porn274.xvideos.com/videos/flv/8/...0789030047&fs=13170880

this is the case for xvideos, i'll test some other sites shortly to see how much of a standard this might/not be.

[anarchintosh]

ok, checked another adult tube site, and they all seem to use some pretty non-standard query strings to make the url skip.

i second the request for some way to define in python
a) the query string used for skipping
b) the values from which the skip is calulated (some sites use seconds, some bytes)

[danillll]

anarchintosh, totally agree, although this is not limited to porn it actually affects many plugins and streams, having this issue addressed will enhance the overall experience of XBMC.

I wonder who from the experienced developers would chime in, spending 6 years programming using java and python got me a bit rusty in C/C++

I will add some logs this evening showing the difference behaviors between mp4 and flv seek.
some MP4 streams work as expected, no buffering and you can jump/seek ahead in time
FLV streams just wait for the buffer to complete.

[anarchintosh]

danill, i agree.
i think the bottom line (as spiff hinted at), is that many web players / flv streams use non-standardised query strings to seek, and XBMC needs to provide a way for addon coders to pass the non-standardised stuff to xbmc.

ps. if you are interested in examining the query strings, i recommend this:

after setting up google chrome to capture some traffic,
(really easy btw, you just right click anywhere on page, click Inspect Element, click the Network tab.)

i hit up the vid, just letting it play from start for a few secs, then i skipped as close as i could to the end. i browsed through the capturings for the .flv file requests, looked in the Headers and saw that one of the urls was longer. i basically grabbed that extra bit of the url, which in my case was &fs=76055419. Also scroll down to Query Strings, and you will see it.
since i knew the vid was about 72mb (chrome tells you this in the capturer), i knew that number must refer to bytes. (you can use google to do the necessary conversions)

XBMC will have to have some way to do the seek calulation. All i can think of is either
calling a python function every time the user seeks (which IMHO is messy, and inefficient)
or
EDIT: stupid me, regex is rubbish for maths

I'm thinking it should be defined in xbmc.player.play (and also xbmcplugin's setResolvedURL), when the vid is first played.

Again, I don't think there should be a full onSeek python event, because that muddies XBMC's C++ video player code with too much python calls.

[anarchintosh]

i'm going to put a patch request for this in Feature Requests sub-forum.

i was also thinking it would be good to create a small python script, that you feed the video link along with the query string and any valid value. this script could then calculate the relationship between the query string value and seconds....

[danillll]

anarchintosh

Yeah, go ahead file a bug/patch and please let me know the bug number.
I spent little time yesterday and indeed, MP4 has no such an issue, the issue is only with flv as you described.
I also tested the flv with different seek values and it works as expected, I guess the fix should be simple as long as we figure out the formula for the seek value.

[anarchintosh]

here is the thread i made in XBMC development (which i've now deprecated)
http://forum.xbmc.org/showthread.php?tid=101021

my stupidity, it is not feasible to use regexs for math operations.

I made a trac ticket
http://trac.xbmc.org/ticket/11523

Which details possibly using muparser or shed skin (to have the onSeek executed in bytecode), if an onSeek is implemented and found to be too slow... (it might be fast enough)

PS. i have found 'fs' and bytes to be a fairly standard way of skipping, so maybe that could go straight into the core code. I've also found ec_seek to be used on at least a couple of flv sites.

[danillll]

I did a little research and updated http://trac.xbmc.org/ticket/11523
Now that the solution and logic is there, the implementation should be simple.
I wonder who from the core team can help us implementing this and how can we get their attention, in my opinion this feature is very important and enhance the overall experience for most of the video plugins

[anarchintosh]

I did a little research and updated http://trac.xbmc.org/ticket/11523
Now that the solution and logic is there, the implementation should be simple.
I wonder who from the core team can help us implementing this and how can we get their attention, in my opinion this feature is very important and enhance the overall experience for most of the video plugins

Are you suggesting we can process the flv metadata to get the query string and valid query string values? Remember only some vids use 'start', others use things like 'fs' and 'ec_seek'.

In that metadata you posted, i only saw string values, not the name of the actual string ('start').

i think we need to take a look at the metadata of a few flv from web players (xvideos etc).

PS. i'm doing exams atm, so i can't really do much experimenting, but if i get some time i will check.

[anarchintosh]

I mean, the query string name must be defined somewhere? Or how would the web player know what it is? If it isn't defined in the actual .flv , then i guess it will be defined in the web player flash code

also, confusingly, megavideo doesn't even use query strings eg.
http://www.megavideo.com/?v=I1CZJKEG
it literally just appends a number onto the end of the url


basically, i still think it would be good to implement a proper python callback onSeek event

the flv metadata could be really useful, and give us some 'smart' functions, but as much as i would love it, i'm not sure the problem can be completely solved by some auto generated logic...

[danillll]

I mean, the query string name must be defined somewhere? Or how would the web player know what it is? If it isn't defined in the actual .flv , then i guess it will be defined in the web player flash code

also, confusingly, megavideo doesn't even use query strings eg.
http://www.megavideo.com/?v=I1CZJKEG
it literally just appends a number onto the end of the url


basically, i still think it would be good to implement a proper python callback onSeek event

the flv metadata could be really useful, and give us some 'smart' functions, but as much as i would love it, i'm not sure the problem can be completely solved by some auto generated logic...

I agree, the seek keyword should be determined by the plugin developer and passed to the core player, as I am not sure you can find this info in the metadata and like you said it might be in the player code.

I am not sure about the seek callback event, is this an expensive operation? time-wise?
Is it easy to implement?

This is a dirty pseudo code of what I was thinking about.




In Python:
IF SeekPoints in Metada //Plugin developers need to verify this condition
--Find/Parse SeekKeyword //SeekKeyword is what gets appended to end of the url and before the seek value. It can be an empty string or any other keyword (start,ec_seek, etc..)
--CALL xbmc.player(URL, SeekKeyword)

In Core Player:

//Method to parse metada from stream. This is very easy to implement, I already have it implemented in java.
ParseMetadata (FLV)
--return filepositions[], time[]

//Find the index of the closest valid queued time from metadata (this is for forward, it can be changed for rewind/backward)
IndexClosestTime (seconds, time[])
--while (time[i] < length.time )
----If seconds <= time[i]
------Exit Loop
----Else i++
--//you can add more logic to get a closest value between second and time +or- 1
--return i

XBMC Core Player (URL, SeekKeyword)
--URL //The FLV URL you pass to xbmc player
--SeekKeyword //Keyword that gets appended to the URL, it can be an empty string
--FilePositions //Array of the queued bytes parsed from the metatadata
--time //Array of the actual time in seconds parsed from the metadata and mapped to the filepositions array

----Play (URL)
------filepositions, time = ParseMetadata (URL)
------play //start the movie as normal

----Seek (seonds)
------If buffered //check the normal cache to see if the seek request is in the current buffer. The current code already does that
--------seek //seek as normal
------ElseIf SeekKeywords Not Null
--------index IndexClosestTime (seconds, time[])
--------NewURL = URL + SeekKeyword + FilePositions[i]
--------Play(NewURL)
------Else
--------Wait for it to buffer //current behavior