In the below, I am assuming we use either <audio>/<video> or flash (with the video on freenet and the flash player recipe provided by the content filter) to provide some sort of embedded player, and we have content filters with streaming support (e.g. implemented as InputStream's). This is definitely not practical before 0.8's performance improvements, but maybe we should think about it; in any case it's good to post it here for future reference.
[13:26:46] * toad_ ponders live streaming of stored content ... lots of p2p's provide streaming of stored content, but they can safely assume that if the beginning exists so does the end; we have always fetched the whole file before displaying it, and fetched it in random order, to ensure that blocks fall out at the same rate ... the question is, *is it a problem* that the end falls out before the beginning? [13:27:45] <toad_> a 128kbps audio file is approx 128 seconds per 2MB segment, so it is likely that we would be able to keep up with it and fetch both the next segment linearly and later segments randomly ... [ a 512kbps video stream is 32 seconds per segment ] [13:28:57] <toad_> and we could change the UI to give the user an idea of how the fetch is going... [13:30:16] <toad_> e.g. if we have failed to fetch some later segments, we could tell the user that and emphasise the fetch-in-background button [13:31:35] <toad_> while still fetching the first segment first, and letting the user judge the content on the basis of the first 128 seconds [13:33:17] <toad_> the other thing we need to show on the ui would be whether we are managing to keep up with the rate at which the content is being played ... I guess any kind of embedded player has where-we-are/where-we-have-up-to as part of its UI so it probably isn't an issue [13:33:18] --> Anarhist has joined this channel (i=volodya at gateway/gpg-tor/key-0x520283ED). [13:35:35] <-- DuClare has left this server (Remote closed the connection). [13:40:20] <digger3> toad_: sounds alright so far :) [13:40:56] <toad_> digger3: the central issue is this: is it a problem that the beginning may be present when the end has fallen out? [13:42:20] <digger3> toad_: imho no, it's fairly common to pause playback when the content isn't there yet. Lots of sites are doing it and users understand it, so it wouldn't be confusing for a freenet users if he conceptualizes the whole thing like "It's like the internet, but slower" [13:43:18] <toad_> digger3: well, the metaphor is other p2p's, where if the beginning is present then the end will be present too, unless the source goes offline [13:44:13] <toad_> i'm leaning towards showing a preview, but telling the user that this is a preview and just because the preview loads doesn't mean the whole file will [13:44:16] <-- kurmiashish has left this server (Remote closed the connection). [13:45:12] <toad_> so the preview would be part of the progress page [13:46:48] <digger3> toad_: I'd use an availability bar like you have in many torrent clients, that combined with a streaming-video like interface will make it easy to understand [13:46:56] <toad_> otoh that isn't so far from streaming with UI changes ... [13:47:18] <toad_> hmmm [13:47:23] <toad_> digger3: how does an availability bar work? [13:47:56] <toad_> there are various cases e.g. a later segment may have broken, in which case we know we won't be able to fetch beyond that point [13:48:21] <digger3> toad_: you split the content into chunk, each chunk is mapped to availability bar, chunk status influences the color the chunk has on the bar (for example green for available, red for unavailable) [13:48:47] <digger3> excuse my English... /me pays better attention to what he's producing [13:48:52] <toad_> we definitely want the ability to queue the download ... we definitely want the ability to tell it to wait until the whole thing is fetched, i guess you get that transparently by just not clicking Play ... [13:49:10] <digger3> toad_: yep [13:49:35] <toad_> if you haven't started playing then when it is all fetched it should get rid of the progress page [13:49:46] <digger3> an availability bar will also allow the user to skip a segment which couldn't be retrieved [13:50:13] <digger3> which in many cases is better than to wait for the next segment [13:50:19] <toad_> i guess that's just a matter of deleting the UI elements related to progress, so we don't need to refresh; if the user wants it fullscreen that's their problem [13:50:33] <toad_> digger3: hmmm [13:50:55] <toad_> we used to have something like that on 0.5 ... that was the era when we introduced the random-block-fetch rule ... [13:51:16] <toad_> but yes it should be on segments not on blocks [13:52:11] <toad_> so we have various statuses for a segment - green (fetched), red (given up), pending with different numbers of blocks fetched/failed ... [13:52:57] <digger3> toad_: yes, that sounds okay to me [13:53:40] <toad_> we would also need to ensure that segments are individually filterable ... i guess all audio/video formats can do that easily enough, just dump everything until the first valid packet ... compression might be an issue, might have to be per-segment ... [13:53:49] <toad_> or we might have to turn it off ... [13:54:41] <digger3> toad_: what content types are you considering for this? [13:54:54] <toad_> digger3: so we'd want linear playback, a playback bar matching the availability bar, and the ability to click on a segment to play it ... [13:55:02] <toad_> digger3: mostly video, also audio [13:55:13] <toad_> digger3: anything we can filter and easily display [13:55:46] <toad_> the UI would probably have to be built with flash ... otoh it should be possible to script video adequately with HTML5 i guess ... [13:56:13] <toad_> there must be a way to tell the video element to seek to a specific point from javascript [13:56:19] <digger3> downside is that most of the header info for video/audio formats is in the first block, I'm unsure if there are alternatives [13:56:36] <toad_> digger3: well if we are showing a preview then we always need to fetch the first block first [13:56:54] <toad_> there has to be a certain amount of linear fetch going on ... [13:57:28] <digger3> but on average (due to the random block fetch rule), you'll have like 50% of the content before it starts playing, not ideal for streaming? [13:57:34] <toad_> but we can pass the parameters extracted from the first segment in to later segments [13:58:01] <toad_> digger3: exactly, we have to turn off the random block fetch rule, or at least we have to mix it with a linear policy [13:58:23] <digger3> toad_: not to spoil anything, but isn't the random block fetch rule there for a good reason? [13:58:27] <toad_> which means frequently the preview will work even though the later blocks are not immediately fetchable [13:58:37] <toad_> digger3: yes, that's the core of the problem [13:58:49] * digger3 starts to understand [13:58:52] <toad_> the random fetch rule is there for one main reason, to prevent the end falling out before the beginning falls out [13:59:43] <toad_> if we show a preview it needs to be clear to the user that the rest of the file may not be available [14:00:27] <kork> I think some youtube-ish thing would be awesome for freenet [14:00:34] <toad_> "Warning: Just because the preview shows up does *not* mean that the whole file will be available." [14:00:42] <toad_> maybe we should just tell the user like that [14:00:46] <toad_> above the preview [14:01:04] <digger3> toad_: but you get that for free with a red availability bar right? [14:01:10] --> weilawei has joined this channel (n=weilawei at 151.203.163.46). [14:01:15] <toad_> digger3: yes ... well sort of ... [14:01:27] <toad_> it takes some time for us to figure out that a segment isn't available [14:02:28] <toad_> if we are talking about a newbie, he'll see that the first segment is green, and the preview works, and assume it will just stream, and be very disappointed [14:03:17] <toad_> I guess he'll discover the true situation soon enough though, and a block-based availability tracker if well designed should convey some of it ... [14:03:57] <digger3> a user sure isn't going to read some kind of disclaimer stating that the preview is no guarantee, /me ponders some more.... [14:04:21] <toad_> well, maybe a block based availability tracker is sufficient ... [14:05:25] <toad_> we would also show some of the standard progress page elements - a progress bar maybe (clashes with the got-up-to indicator on the player?), an ETA definitely once we can give it with some confidence... [14:05:56] <toad_> availability tracker could replace the progress bar in fact ... [14:06:06] <digger3> toad_: exactly [14:06:48] * toad_ notes that this is reintroducing a number of things from 0.5 that we took out ... [14:07:30] <digger3> I'm not sure if the html5 video element likes a setup like this though, it isn't a nice stream with these segments and stuff [14:07:32] <toad_> we should probably think about fetching a segment at a time ... we already do that for persistent requests, but it does seem to make sense for streaming too ... [14:07:39] <-- ordex has left this server (Read error: 113 (No route to host)). [14:08:38] <toad_> digger3: well it will stall at a certain point ... I take your point though, we'd want to override the player's progress bar and provide our own ... [14:08:55] <toad_> so that we can click on a later segment and have the progress bar go to the right place [14:09:12] <toad_> in fact, we'd probably want the player pointer to be integrated to the availability tracker [14:09:56] <digger3> preferably, yes [14:11:03] <saces> MPEG7 is the right format for freenet [14:11:12] <toad_> so there would be quite a lot of javascript/flash work here, and some changes to the fetching algorithm, and video/audio format filtering with partial-with-passed-in-params support, and possibly changes to compression (easiest thing is simply to turn it off), ... [14:11:27] <toad_> saces: shame the format is closed and patented and the documentation costs $$$$ :< [14:11:32] <toad_> saces: how about SMIL? [14:11:35] <toad_> SMIL plus theora [14:11:48] <toad_> recent versions of theora are way higher quality than old versions were [14:12:18] <toad_> well okay the format is open and patented and the documentation costs $$$$ [14:12:30] <toad_> it's just not a definition of open that i'm happy with :| [14:12:35] <-- ahuxley has left this server. [14:12:43] <toad_> SMIL ~= MPEG7 in terms of functionality iirc [14:13:12] <toad_> hmmm no i'm thinking of MPEG4 [14:14:13] <toad_> MPEG4, the main format, not the codecs, is a means to synthesise streams and fixed graphics into a whole, conserving bandwidth and preserving visual elements in a relatively easy to edit format [14:14:33] <toad_> so for news and so on it saves a fair chunk of bandwidth [14:14:40] <toad_> SMIL does exactly the same thing [14:14:57] <toad_> MPEG7 is a labelling system [14:15:22] <toad_> anyway, i'm assuming simple video for the time being, because almost everything is [14:16:29] <toad_> so just theora for the time being [14:16:41] <toad_> "the time being" likely being 0.9 or 0.10 [14:17:29] <toad_> imho improved performance is a prerequisite for streaming-like UI changes etc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20090629/6fcc3339/attachment.pgp>
