On Wed, Jul 16, 2014 at 5:31 AM, Dalai Felinto <[email protected]> wrote: > @Fasekas: we are wrapping some of the functionality directly from the > FFmpeg library so unless ffmpeg can do it I believe we can't. That's > besides the point though, why to reinvent the wheel if we are already > using a library that provides streaming. > > @Sergey >> And maintain means communicate with the users in the tracker, making sure >> this stuff works in upcoming blender releases, invest time on fixing stuff >> when it becomes broken (and stuff tends to become broken in FFmpeg). > > As I said in IRC I can commit to the Blender side of this (in this > particular subset of FFmpeg features). Meaning replying to tracker > entries and orienting clueless users. This will be used by BGE > anyways, so it won't affect Blender users in general. That said, even > with the backend RTSP support in the ffmpeg the feature is not fully > working. But I believe it's an issue in BGE code (more details in the > tracker). > >> But seems we need to update FFmpeg anyway (because of >> https://developer.blender.org/T41065) so technically tweaking configuration >> flags is not that much an issue. > > Anyways we support so many bizarre things (webcam!), I can't see this > going over whatever line we drawn. I think in cases like this we > should have reasons to not include things, not to include them (when > it comes to 'readers [decoders]'). Either way the reason/use case was > explained in the original email. I'm just not sure about the h264, if > this violates any GPL/patent thing.
On the other hand we end up loosing time to support various configurations, its hard to know beforehand if enabling options incurs maintenance overhead. Seems like a special case - couldn't the BlenderCAVE/remote-camera users who want RTSP do their own builds? _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
