[FFmpeg-devel] [RFC] Browser remote content API

[Michael Niedermayer]

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" callback.
> >
> >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
successfully

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
changed.
id say this sounds like it could be better off as a seperate project

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140210/b74c2008/attachment.asc>