[FFmpeg-devel] [RFC] Browser remote content API
lukasz.m.luki at gmail.com
Mon Feb 10 23:16:46 CET 2014
On 10 February 2014 03:29, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sun, Feb 09, 2014 at 10:18:32PM +0100, Lukasz Marek wrote:
> > On 09.02.2014 06:02, Michael Niedermayer wrote:
> > >On Sun, Feb 09, 2014 at 02:14:22AM +0100, Lukasz Marek wrote:
> > >>Hi,
> > >>
> > >>I have an idea of new API, hopely useful.
> > >>
> > >>FFmpeg allows to use content on remote servers via network protocols
> > >>(http, ftp, sftp). It can be read, written, played, probed etc, but
> > >>in case user want to make application with some UI that displays
> > >>that content (file names, dirs) then they need to implement it
> > >>aside.
> > >>It would be nice to extend URLProtocol with some kind of "readdir"
> > >
> > >yes
> > >
> > >reordered your mail a bit
> > >
> > >>Maybe this is a project for GSoC?
> > >
> > >how much does a student need to read and understand (i means specs)
> > >to implement this, is that together with implementation realistic
> > >within the 12 weeks ?
> > Yes, it is realistic.
> > >
> > >iam a bit concerned that theres maybe too much code and specs
> > >reading involved. That is a student would have to wrap his head
> > >around 3 different protocol implementations and specifications
> > I would add also file protocol, to have one API for all protocols.
> > sftp is done on top of libssh library and it has ready functions for
> > this. It doesn't require any protocol knowledge. Authorization,
> > connection etc is already done.
> > ftp may also reuse existing code. One difference is to send
> > different command instead of STOR/RETR. Server responds with the
> > same format like "ls -l" on linux shell. So all student have to
> > understand is how ftp works at high level and read deeply about LIST
> > command (mostly about response format).
> > http I don't know, but probably it is also not complicated.
> > >but if you think it can be done, then make one of the 3 protocols
> > >the qualification task, a student passing that not only shows that
> > >he can do it he also would have 1/3 less work in the summer
> > OK, I will prepare this tomorrow.
> > >also i would suggest you design and implement the API without the
> > >student to not complicate that further
> > Not sure I understand.
> > You want a student to implement this at protocol level only (new
> > callback) and lavf would be prepared before?
> it will take you less time to design and add the framework/API
> without a student than with.
> so why do it with one ?
> you know ffmpeg and the API, the student doesnt
> > >>
> > >>Furhtermore, it would be nice to have single function that read
> > >>media related metadata like resolution, duration, codec,maybe
> > >>thumbnail etc. (copy paste from ffprobe can be probably done).
> > >
> > >i dont understand how this is related to the rest of your mail
> > >
> > It is not really related, but I think extending protocols by
> > listening remote dirs is quite easy as for 3 months project. This
> how many webservers are out there ?
> how standarized is their html output for directory listings ?
> > second API is also quite useful when you build UI in player (all
> > good iOS players I saw present this kind of metadata). But it can be
> > omitted or moved to another project if you think it's too much.
> nothing stops you from adding some optional stuff
> "in case there is lots of time left" but it should be clear that
> doing this is not neccessary for the student to finish the task
> also to have a practical properties gathering API you need multiple
> threads id guess, and you want the user app to receive partial data
> as it comes in, so this all doesnt look all that easy to me.
> and then you probably also want to cache the results maybe so they
> dont need to be re-retrieved if for example file dates / sizes havent
> id say this sounds like it could be better off as a seperate project
OK, I agree
I added this project in "unmentioned project secion".
I would like to ask someone to review it (especially grammar)
I set myself as possible backup mentor.
I may help on protocol related things, but I cannot promise I will be able
to be accessible on IRC for most of the time.
More information about the ffmpeg-devel