Broadcast... on-demand? (hybrid approach?)

[abe.snake]

Hello Everyone,

I've been thinking myself ever-closer to a solution, but then frustrate myself by driving off the intellectual highway into the ditch every time I get really close. And, of course, now my time to spend on this thing has dwindled, so I ask your advice and seek your collective wisdom with almost tangible sense of urgency.

In the final result of this and other inquiries, hopefully there is an instance of a media player receiving a stream over a wireless connection, running on a fairly wimpy piece of hardware, and it is one of many that all have to share the same wireless network. In the worst-case scenario, everyone one of the users is watching a different program, so there is clearly impetus to minimize bandwidth consumption per-stream, but there is also somewhat of a constraint on how much processing can be done on the receiving end.

For the moment, the content being consumed on all the remotes would derive from locally hosted files, pre-packaged but not into entirely pre-planned monolithic Lord of the Rings Director's Cut Marathon Binge-watch behemoths, but more like the community service tv station with a flaky director of operations that is lucky if he remembers to plan out half-a-day's schedule in advance. The channels are going, publically available, and there are bits of content blowing by you that you miss if you aren't watching. So yeah, broadcasts. I would just like to avoid 57 channels spurting thei streams, polluting with their packets without purpose, i.e. nobody listening. (And I will grant you that I'm still fairly new to anything multicast-ish, and know there is a possibility my understanding of such may be wedged, and that's really not A Thing to worry about.)

What I think I want to do is have a broadcast, or at least the functional notion of time going by and dragging a playlist along with it, but only doing so internally, contained within the server hardware, and have the facility for the remotes to request a tap into the playing list whenever they want to watch - and that's the on-demand part, pull not push business.

(Well, actually, after wandering down a mental side road or two, I've been thinking most recently maybe have the remotes each make one and only one ever connection for a viewing session, and it'll connect and establish a long-running stream from a lightweight, dedicated, personalized, individualized, Simonized bit of software instance, which itself is relaying the bits, having made the connection to thingy which is generating the broadcast. And any requested change in what's displayed is actualized by making the relay gremlin change what it has glommed onto for its source.)

I'm not sure what those internal broadcast resources would look like as they're served, but I thought the .ffm[2] files used by ffserver looked rather interesting for their fixed-size/window-of-content they provide. (Just figuring out how to use them in reality...)

So that's about where I am. After churning on it for many days now, I still have a sense that VLM and/or its kin could do all that is wanted. And if not, then surely some clever combination of VLC, VLM, n[et]cat, ffserver, ffsplah and ffmpeg would cover all the bases.

(And, being new to this forum, I hope it's not anathema to mention those in the latter part of the list.)

Thanks in advance, and I'm hugely looking forward to reading your thoughts, comments, suggestions, and peals of laugher.

Mike

[Jean-Baptiste Kempf]

Sorry, but do you think you will need to transcode or not?

[abe.snake]

Hi Jean-Baptiste,

Although I'd like to avoid the extra processing it takes to transcode, I imagine it will be impossible to avoid. I think the local content could probably be subject to some manipulation when first placed upon the system to some standard resolution, bitrate, format, etc. If I intend for all the viewing stations to have uniform screens, would it make sense to up-/down-scale the vids ahead of time? And maybe bring the bitrate closer to an optimistic (total wireless bandwidth) / (estimated average number of users, probably significantly smaller than max supported), acknowledging that further reduction in bitrate would need to occur as the number of users increases.

Thanks,
Mike

[Jean-Baptiste Kempf]

Yes, that would decrease the load significantly.