Discussion:
[PATCH 0/2] [GSoC] Extend avio with move and delete for urls
(too old to reply)
Mariusz Szczepańczyk
2015-06-20 12:52:47 UTC
Permalink
This patches add avio_move() and avio_delete() functions and implement
appropriate callbacks for file protocol provided as a working example.

Mariusz Szczepańczyk (2):
lavf/avio: Extend API with avio_move() and avio_delete()
lavf/file: implement move and delete callbacks

doc/APIchanges | 4 ++++
libavformat/avio.c | 38 ++++++++++++++++++++++++++++++++++++++
libavformat/avio.h | 19 +++++++++++++++++++
libavformat/file.c | 38 ++++++++++++++++++++++++++++++++++++++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
6 files changed, 102 insertions(+), 1 deletion(-)
--
2.3.6
Mariusz Szczepańczyk
2015-06-20 12:52:48 UTC
Permalink
---
doc/APIchanges | 4 ++++
libavformat/avio.c | 38 ++++++++++++++++++++++++++++++++++++++
libavformat/avio.h | 19 +++++++++++++++++++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 6e64a05..a9efd12 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -17,6 +17,10 @@ API changes, most recent first:

-------- 8< --------- FFmpeg 2.7 was cut here -------- 8< ---------

+2015-xx-xx - xxxxxxx - lavf 56.38.100 - avio.h url.h
+ Add avio_move(), avio_delete().
+ Extend URLProtocol with url_move(), url_delete().
+
2015-06-04 - cc17b43 - lswr 1.2.100
Add swr_get_out_samples()

diff --git a/libavformat/avio.c b/libavformat/avio.c
index 261ff2a..bd32944 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -421,6 +421,44 @@ int avio_check(const char *url, int flags)
return ret;
}

+int avio_move(const char *url_src, const char *url_dst)
+{
+ URLContext *h_src, *h_dst;
+ int ret = ffurl_alloc(&h_src, url_src, AVIO_FLAG_READ_WRITE, NULL);
+ if (ret < 0)
+ return ret;
+ ret = ffurl_alloc(&h_dst, url_dst, AVIO_FLAG_WRITE, NULL);
+ if (ret < 0) {
+ ffurl_close(h_src);
+ return ret;
+ }
+
+ if (h_src->prot == h_dst->prot && h_src->prot->url_move)
+ ret = h_src->prot->url_move(h_src, h_dst);
+ else
+ ret = AVERROR(ENOSYS);
+
+ ffurl_close(h_src);
+ ffurl_close(h_dst);
+ return ret;
+}
+
+int avio_delete(const char *url)
+{
+ URLContext *h;
+ int ret = ffurl_alloc(&h, url, AVIO_FLAG_WRITE, NULL);
+ if (ret < 0)
+ return ret;
+
+ if (h->prot->url_delete)
+ ret = h->prot->url_delete(h);
+ else
+ ret = AVERROR(ENOSYS);
+
+ ffurl_close(h);
+ return ret;
+}
+
int avio_open_dir(AVIODirContext **s, const char *url, AVDictionary **options)
{
URLContext *h = NULL;
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 9f3a992..5ac5d38 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -230,6 +230,25 @@ const char *avio_find_protocol_name(const char *url);
int avio_check(const char *url, int flags);

/**
+ * Move or rename a resource.
+ *
+ * @note url_src and url_dst should share the same protocol and authority.
+ *
+ * @param url_src url to resource to be moved
+ * @param url_dst new url to resource if the operation succeeded
+ * @return >=0 on success or negative on error.
+ */
+int avio_move(const char *url_src, const char *url_dst);
+
+/**
+ * Delete a resource.
+ *
+ * @param url resource to be deleted.
+ * @return >=0 on success or negative on error.
+ */
+int avio_delete(const char *url);
+
+/**
* Open directory for reading.
*
* @param s directory read context. Pointer to a NULL pointer must be passed.
diff --git a/libavformat/url.h b/libavformat/url.h
index 1a845b7..99a3201 100644
--- a/libavformat/url.h
+++ b/libavformat/url.h
@@ -90,6 +90,8 @@ typedef struct URLProtocol {
int (*url_open_dir)(URLContext *h);
int (*url_read_dir)(URLContext *h, AVIODirEntry **next);
int (*url_close_dir)(URLContext *h);
+ int (*url_delete)(URLContext *h);
+ int (*url_move)(URLContext *h_src, URLContext *h_dst);
} URLProtocol;

/**
diff --git a/libavformat/version.h b/libavformat/version.h
index 99b7190..ec84570 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -30,7 +30,7 @@
#include "libavutil/version.h"

#define LIBAVFORMAT_VERSION_MAJOR 56
-#define LIBAVFORMAT_VERSION_MINOR 37
+#define LIBAVFORMAT_VERSION_MINOR 38
#define LIBAVFORMAT_VERSION_MICRO 100

#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
--
2.3.6
Timothy Gu
2015-06-21 07:37:44 UTC
Permalink
El sábado, 20 de junio de 2015, Mariusz Szczepańczyk <
Post by Mariusz Szczepańczyk
---
doc/APIchanges | 4 ++++
libavformat/avio.c | 38 ++++++++++++++++++++++++++++++++++++++
libavformat/avio.h | 19 +++++++++++++++++++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6e64a05..a9efd12 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
-------- 8< --------- FFmpeg 2.7 was cut here -------- 8< ---------
+2015-xx-xx - xxxxxxx - lavf 56.38.100 - avio.h url.h
+ Add avio_move(), avio_delete().
+ Extend URLProtocol with url_move(), url_delete().
+
This goes above the 2.7 release cut line.

Timothy
Mariusz Szczepańczyk
2015-06-21 15:04:10 UTC
Permalink
El sábado, 20 de junio de 2015, Mariusz Szczepańczyk
---
doc/APIchanges | 4 ++++
libavformat/avio.c | 38 ++++++++++++++++++++++++++++++++++++++
libavformat/avio.h | 19 +++++++++++++++++++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6e64a05..a9efd12 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
-------- 8< --------- FFmpeg 2.7 was cut here -------- 8< ---------
+2015-xx-xx - xxxxxxx - lavf 56.38.100 - avio.h url.h
+ Add avio_move(), avio_delete().
+ Extend URLProtocol with url_move(), url_delete().
+
This goes above the 2.7 release cut line.
Timothy
You're right. Thanks!

Mariusz
Michael Niedermayer
2015-06-22 11:23:17 UTC
Permalink
Post by Mariusz Szczepańczyk
El sábado, 20 de junio de 2015, Mariusz Szczepańczyk
---
doc/APIchanges | 4 ++++
libavformat/avio.c | 38 ++++++++++++++++++++++++++++++++++++++
libavformat/avio.h | 19 +++++++++++++++++++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6e64a05..a9efd12 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
-------- 8< --------- FFmpeg 2.7 was cut here -------- 8< ---------
+2015-xx-xx - xxxxxxx - lavf 56.38.100 - avio.h url.h
+ Add avio_move(), avio_delete().
+ Extend URLProtocol with url_move(), url_delete().
+
This goes above the 2.7 release cut line.
Timothy
You're right. Thanks!
Mariusz
doc/APIchanges | 4 ++++
libavformat/avio.c | 38 ++++++++++++++++++++++++++++++++++++++
libavformat/avio.h | 19 +++++++++++++++++++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
1a7bf656f7e0a71b313c14fad1684083b148636a 0001-lavf-avio-Extend-API-with-avio_move-and-avio_delete.patch
From 283f81e40b8776ac485e0e575ba351618a5c2332 Mon Sep 17 00:00:00 2001
Date: Wed, 17 Jun 2015 20:12:00 +0200
Subject: [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
applied

thanks

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
Hendrik Leppkes
2015-06-21 08:11:53 UTC
Permalink
On Sat, Jun 20, 2015 at 2:52 PM, Mariusz Szczepańczyk
Post by Mariusz Szczepańczyk
---
doc/APIchanges | 4 ++++
libavformat/avio.c | 38 ++++++++++++++++++++++++++++++++++++++
libavformat/avio.h | 19 +++++++++++++++++++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
Why do we need moving and deleting files in avio? Whats the use-case for ffmpeg?

- Hendrik
Mariusz Szczepańczyk
2015-06-21 15:19:17 UTC
Permalink
Post by Hendrik Leppkes
On Sat, Jun 20, 2015 at 2:52 PM, Mariusz Szczepańczyk
Post by Mariusz Szczepańczyk
---
doc/APIchanges | 4 ++++
libavformat/avio.c | 38 ++++++++++++++++++++++++++++++++++++++
libavformat/avio.h | 19 +++++++++++++++++++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
Why do we need moving and deleting files in avio? Whats the use-case for ffmpeg?
- Hendrik
Suppose you're writing a video player with browsing capabilities for
network protocols (like Kodi/XBMC). Now you can have file rename/delete
functionality in it.

Mariusz
Kieran Kunhya
2015-06-21 18:20:53 UTC
Permalink
Suppose you're writing a video player with browsing capabilities for network
protocols (like Kodi/XBMC). Now you can have file rename/delete
functionality in it.
Suppose you are writing a video player and need to change the screen resolution.
Can we have that feature in libavutil too?

Kieran
wm4
2015-06-21 18:24:09 UTC
Permalink
On Sun, 21 Jun 2015 19:20:53 +0100
Post by Kieran Kunhya
Suppose you're writing a video player with browsing capabilities for network
protocols (like Kodi/XBMC). Now you can have file rename/delete
functionality in it.
Suppose you are writing a video player and need to change the screen resolution.
Can we have that feature in libavutil too?
Don't give them ideas... there's "space" for such features in
libavdevice.

(I'd like to have a more general multimedia framework around FFmpeg
too, but messing such features into the existing libav*s for the lack
of a better place is _not_ a good idea.)
Mariusz Szczepańczyk
2015-06-21 19:04:30 UTC
Permalink
Post by wm4
On Sun, 21 Jun 2015 19:20:53 +0100
Post by Kieran Kunhya
Post by Mariusz Szczepańczyk
Suppose you're writing a video player with browsing capabilities for
network
Post by Kieran Kunhya
Post by Mariusz Szczepańczyk
protocols (like Kodi/XBMC). Now you can have file rename/delete
functionality in it.
Suppose you are writing a video player and need to change the screen
resolution.
Post by Kieran Kunhya
Can we have that feature in libavutil too?
Don't give them ideas... there's "space" for such features in
libavdevice.
(I'd like to have a more general multimedia framework around FFmpeg
too, but messing such features into the existing libav*s for the lack
of a better place is _not_ a good idea.)
You know you can just say why do you think it's an unneeded feature and
don't have to be trolling.

Anyway, this is a part of my GSoC task that has been accepted and I'm
compelled to implement it so I won't be getting into further discussion.

Mariusz
Derek Buitenhuis
2015-06-22 12:11:26 UTC
Permalink
Post by Mariusz Szczepańczyk
Anyway, this is a part of my GSoC task that has been accepted and I'm
compelled to implement it so I won't be getting into further discussion.
Let's just say a large portion of the community didn't and don't think
this idea has any place in libav* in the first place, but were ignored,
or our complaints pushed aside.

- Derek
James Almer
2015-06-22 16:33:17 UTC
Permalink
Post by Derek Buitenhuis
Post by Mariusz Szczepańczyk
Anyway, this is a part of my GSoC task that has been accepted and I'm
compelled to implement it so I won't be getting into further discussion.
Let's just say a large portion of the community didn't and don't think
this idea has any place in libav* in the first place, but were ignored,
or our complaints pushed aside.
- Derek
I have no opinion one or way or another regarding this addition, but if this
is a GSoC project then i guess the time to show disagreement was back in
February when it was a suggested project waiting for applications, and not in
the middle of the program long after a student got the project assigned.
Derek Buitenhuis
2015-06-22 17:06:58 UTC
Permalink
Post by James Almer
I have no opinion one or way or another regarding this addition, but if this
is a GSoC project then i guess the time to show disagreement was back in
February when it was a suggested project waiting for applications, and not in
the middle of the program long after a student got the project assigned.
We did. Several times. It was ignored or pushed aside.

- Derek
Michael Niedermayer
2015-06-22 17:52:44 UTC
Permalink
Post by Derek Buitenhuis
Post by James Almer
I have no opinion one or way or another regarding this addition, but if this
is a GSoC project then i guess the time to show disagreement was back in
February when it was a suggested project waiting for applications, and not in
the middle of the program long after a student got the project assigned.
We did. Several times. It was ignored or pushed aside.
When and where ?

Also, the "Browsing content on the server" project was added 17 months ago
to the GSoC 2014 page:
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2014?confirm_email=&email_confirm=&action=diff&version=28&old_version=27&confirm_email=&email_confirm=

Thats a long time prior to GSoC 2015 in which anyone could have
removed it if they wanted, its a publically editable wiki basically

And theres another aspect to this, theres quite some code that
needs the rename function (git grep ff_rename).
What options exist here
1. leave it so it only works with local files
2. support other "protocols" than file:// by the API here
3. support other "protocols" than file:// by some other API
4. remove the code that uses ff_rename (hls, hds, dash, smoothstreaming, ...)

I might be wrong but i think people really like none of the options
here
for 3. also some other API would need to be suggested, this may very
well be the solution if someone does have a better idea for a better
API, that is one that everyone likes or at least can live with

also another use case for this may be simple cleanup on errors,
a muxer might (possibly not by default if people prefer) remove
files that failed to be created at an early stage
that is for example when writing the header fails in the middle and
before any content is stored in a file deleting the file is probably
what some users would want ...

Also lets rather encourage work toward a solution, everyone is happy
with instead of disencouraging people from working

Thanks
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
Derek Buitenhuis
2015-06-22 21:24:11 UTC
Permalink
Post by Michael Niedermayer
When and where ?
Example: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/179883

And also *constantly* on IRC, although I am sure "IRC doesn't count"
or somesuch.

My argument then is the same as now: this does not belong in libav*. It
belongs in the player or user application who uses the libav* API.

(And before you say "but that is for smb", the argument is the same, and
the end goal and author+mentor are the same. It's the same issue.)

You may also recall I brought up the fact that the GSOC qualification
task was mostly reworking the patch set from Lukasz, and thinking
that was a bit sketchy.

P.S. I'm getting pretty tired of the demand for proof every time a bad
design shows itself for the Nth time. A bad design is a bad design. The
burden is on the designer to prove it is WORTH including, not the
other way around. The burden should not be on the review to have to
respond and register their dissent for every Nth iteration of an idea
or patch set, lest it be pushed through anyway, be it as a GSOC or patch
set. If it was bad once, it is still bad.
Post by Michael Niedermayer
Also, the "Browsing content on the server" project was added 17 months ago
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2014?confirm_email=&email_confirm=&action=diff&version=28&old_version=27&confirm_email=&email_confirm=
Thats a long time prior to GSoC 2015 in which anyone could have
removed it if they wanted, its a publically editable wiki basically
And pissed off Lukasz?
Post by Michael Niedermayer
And theres another aspect to this, theres quite some code that
needs the rename function (git grep ff_rename).
What options exist here
1. leave it so it only works with local files
[...]
Post by Michael Niedermayer
2. support other "protocols" than file:// by the API here
3. support other "protocols" than file:// by some other API
"protocol" indeed.
Post by Michael Niedermayer
4. remove the code that uses ff_rename (hls, hds, dash, smoothstreaming, ...)
Very funny.
Post by Michael Niedermayer
I might be wrong but i think people really like none of the options
here
for 3. also some other API would need to be suggested, this may very
well be the solution if someone does have a better idea for a better
API, that is one that everyone likes or at least can live with
Yes, let us dump every idea someone has into libav*. Everything belongs
in libav.
Post by Michael Niedermayer
also another use case for this may be simple cleanup on errors,
a muxer might (possibly not by default if people prefer) remove
files that failed to be created at an early stage
[...]
Post by Michael Niedermayer
that is for example when writing the header fails in the middle and
before any content is stored in a file deleting the file is probably
what some users would want ...
"Probably what some users want" can pretty much be quoted as the reasoning
for every insane design choice in libav*...
Post by Michael Niedermayer
Also lets rather encourage work toward a solution, everyone is happy
with instead of disencouraging people from working
I don't think encouraging work just for the sake of encouraging work is
a good idea. It leads to bad technical design is we just go "well we
shouldn't discourage work, even if it's a bad idea."

I get now it's "too late" as it was registered for GSOC, but crikey.

Bonus random IRC logs found by grepping for "directory listing" in #ffmpeg-devel:

17:54 < cone-632> ffmpeg Lukasz Marek master:184084c6998c: lavf: add directory listing API
18:02 <+wm4> Daemon404: shit ^
18:02 <+wm4> damage done, maintain forever
18:05 <@Daemon404> D:

Days later:

16:38 <+kierank> ffmpeg has too much mission creep
16:38 <+kierank> an in built web server
16:38 <+kierank> directory listing api
16:38 <+kierank> wtf
16:40 <@iive> avsystemd
16:40 <@BBB_> yeah the directory listing api kind of confused me
16:41 < rcombs> isn't that supposed to be MKV ordered chapters and such
16:41 <@BBB_> as long as I can disable it I don't care I guess
16:41 <+wm4> rcombs: fuck no
16:41 < rcombs> well then I have no idea what that's for then
16:41 <+wm4> nobody knows
16:42 <+wm4> because Lukasz wanted it and mini can't say no?
16:42 <+kierank> wm4: ding ding ding

- Derek
Derek Buitenhuis
2015-06-22 22:17:25 UTC
Permalink
Post by Derek Buitenhuis
You may also recall I brought up the fact that the GSOC qualification
task was mostly reworking the patch set from Lukasz, and thinking
that was a bit sketchy.
I went and looked. It wad *directly* brought up by Keiran on ffmpeg-mentors.

He was, of course, shat on.

- Derek
Mariusz Szczepańczyk
2015-06-22 20:15:27 UTC
Permalink
Post by Derek Buitenhuis
Post by Mariusz Szczepańczyk
Anyway, this is a part of my GSoC task that has been accepted and I'm
compelled to implement it so I won't be getting into further discussion.
Let's just say a large portion of the community didn't and don't think
this idea has any place in libav* in the first place, but were ignored,
or our complaints pushed aside.
- Derek
Thank you for clarification. I understand there are people who are not
happy with additions like this. However, there are also people who think
these changes are needed and trying to stop them just because "we don't
want this here" or worse, making fun of their work is not the way to go
to be honest.

I don't really know how/when this conflict started or have your
complaints been answered or not but it seems to me there are some of you
who are really frustrated with the direction ffmpeg have taken.

So why don't you propose something constructive, e.g. partition into
distinct libraries so muxing/demuxing code is not getting "spoiled"?
There must be some kind of solution everyone can agree with.

Mariusz
Derek Buitenhuis
2015-06-22 21:31:00 UTC
Permalink
Post by Mariusz Szczepańczyk
Thank you for clarification. I understand there are people who are not
happy with additions like this. However, there are also people who think
these changes are needed and trying to stop them just because "we don't
want this here" or worse, making fun of their work is not the way to go
to be honest.
Considering whether a feature should be in a particular library by design
is a legitimate consideration. You can't just blindly accept all features
someone might find useful. Some may also think a GUI toolkit and X protocol
implementation would be awesome to have in libav*, but does it belong? No.

May I add, that I do not think pushing through APIs and and design choices
that have registered dissent is kinda of sketchy at best. That is not on
you though, and I apologize for dragging your GSOC application into it.

(Also I'm not making fun of your work. If you point out where I've done
that, I'd be glad to retract and apologize.)
Post by Mariusz Szczepańczyk
I don't really know how/when this conflict started or have your
complaints been answered or not but it seems to me there are some of you
who are really frustrated with the direction ffmpeg have taken.
Yes, it predates your GSOC task, and involves your mentor. Again, apologies
for it being dumped on you in this thread.
Post by Mariusz Szczepańczyk
So why don't you propose something constructive, e.g. partition into
distinct libraries so muxing/demuxing code is not getting "spoiled"?
There must be some kind of solution everyone can agree with.
We did. We proposed it is *not* the task of libav* to do this. It belongs in
the layer above, in the application (e.g. a player). And indeed, this is
what VLC and mplayer/mpv already do. Your mentor is the only one who
decided it belongs here, because he wanted to use it.

- Derek
Derek Buitenhuis
2015-06-22 22:05:11 UTC
Permalink
Post by Derek Buitenhuis
That is not on
you though, and I apologize for dragging your GSOC application into it.
To follow up on this, I do understand how GSOC works, and it is too late
to say 'no' to this, and I feel bad for you having negatives dumped on
you like this.

I suppose you should continue on.

- Derek
Michael Niedermayer
2015-06-22 22:18:22 UTC
Permalink
On Mon, Jun 22, 2015 at 10:31:00PM +0100, Derek Buitenhuis wrote:
[...]
Post by Derek Buitenhuis
Your mentor is the only one who
decided it belongs here, because he wanted to use it.
Please stop the finger pointing and work toward a resolution of this
its not just one man, iam not even sure he intended to use it himself.

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
Derek Buitenhuis
2015-06-22 22:51:09 UTC
Permalink
Post by Michael Niedermayer
Please stop the finger pointing and work toward a resolution of this
its not just one man, iam not even sure he intended to use it himself.
I agree I was a too aggressive.

However, I am not aware of a single person.

As for working towards a resolution, I don't think that will
happen, since "it shouldn't have been done at all / it should
not be done at all" is likely not an acceptable solution to
those involved.

Instead, I will relegate myself to being an annoying guy on
IRC, and leave the thread be.

- Derek
Mariusz Szczepańczyk
2015-06-22 22:58:19 UTC
Permalink
On Mon, Jun 22, 2015 at 11:31 PM, Derek Buitenhuis <
Post by Derek Buitenhuis
Post by Mariusz Szczepańczyk
Thank you for clarification. I understand there are people who are not
happy with additions like this. However, there are also people who think
these changes are needed and trying to stop them just because "we don't
want this here" or worse, making fun of their work is not the way to go
to be honest.
Considering whether a feature should be in a particular library by design
is a legitimate consideration. You can't just blindly accept all features
someone might find useful. Some may also think a GUI toolkit and X protocol
implementation would be awesome to have in libav*, but does it belong? No.
May I add, that I do not think pushing through APIs and and design choices
that have registered dissent is kinda of sketchy at best. That is not on
you though, and I apologize for dragging your GSOC application into it.
(Also I'm not making fun of your work. If you point out where I've done
that, I'd be glad to retract and apologize.)
No offence taken. Actually this remark wasn't directed at you any way, just
an observation of what's going on in this thread (and some other).
Post by Derek Buitenhuis
Post by Mariusz Szczepańczyk
I don't really know how/when this conflict started or have your
complaints been answered or not but it seems to me there are some of you
who are really frustrated with the direction ffmpeg have taken.
Yes, it predates your GSOC task, and involves your mentor. Again, apologies
for it being dumped on you in this thread.
Post by Mariusz Szczepańczyk
So why don't you propose something constructive, e.g. partition into
distinct libraries so muxing/demuxing code is not getting "spoiled"?
There must be some kind of solution everyone can agree with.
We did. We proposed it is *not* the task of libav* to do this. It belongs in
the layer above, in the application (e.g. a player). And indeed, this is
what VLC and mplayer/mpv already do. Your mentor is the only one who
decided it belongs here, because he wanted to use it.
I don't think it's fair to say Lukasz is the only one standing for these
changes. But let's not make it personal and hold on any grudges for a
moment.

My point is that ongoing fights like this are counterproductive and only
discourage people from contributing into open source. I also think everyone
wants the best for the project regardless they are pro or against the
changes.

I see the current situation is as follows: there is increasing amount of
code in libav* that you and some others find out of place. This is
obviously not good.

Is there any viable solution not involving removing functionality from
ffmpeg would you agree on and make adding changes like this less painful?
What do you think about making a temporary fork, moving things around there
and showing something that is satisfactory to you?

Mariusz
Derek Buitenhuis
2015-06-22 23:09:19 UTC
Permalink
Post by Mariusz Szczepańczyk
I don't think it's fair to say Lukasz is the only one standing for these
changes. But let's not make it personal and hold on any grudges for a
moment.
I hold no ill will against anyone, as long as no ill will is held against me.

I do, however, think it was pretty dishonest of some people to push this
forward as a GSOC project when there was internal dissent for it (on IRC,
on the ffmpeg-mentor list, etc.). This is of course not your problem,
nor should it be. We're here now, so we should make the best of it.
Post by Mariusz Szczepańczyk
My point is that ongoing fights like this are counterproductive and only
discourage people from contributing into open source. I also think everyone
wants the best for the project regardless they are pro or against the
changes.
Agreed.
Post by Mariusz Szczepańczyk
I see the current situation is as follows: there is increasing amount of
code in libav* that you and some others find out of place. This is
obviously not good.
Is there any viable solution not involving removing functionality from
ffmpeg would you agree on and make adding changes like this less painful?
What do you think about making a temporary fork, moving things around there
and showing something that is satisfactory to you?
The crux of the issue here is that there is disagreement on whether some features
should be in libav* at all. It's separation of functionality. It's not really
possible to show something satisfactory when it's the wrong place for it in
the first place, in someone's mind. I speak for myself here, only, of course.
Take it with a grain of salt.

As far as I see this situation, the damage is done already (it's in libav*), so we
may as well make it (the API) as decent as possible.

(P.S. I wouldn't use the word fork here, people get angsty :P)

- Derek
Nicolas George
2015-06-23 09:05:31 UTC
Permalink
Post by Derek Buitenhuis
The crux of the issue here is that there is disagreement on whether some features
should be in libav* at all. It's separation of functionality. It's not really
possible to show something satisfactory when it's the wrong place for it in
the first place, in someone's mind. I speak for myself here, only, of course.
Take it with a grain of salt.
As someone who pushed for a project that had similar opposition (the HTTP
server), I believe I must intervene.

First, let us try to agree on a few basic points.

Statement: you only get to decide on what you spent your own time. Other
developers decide for themselves. You can try to persuade them that
optimizing a codec is more important than writing a spell checker, but in
the end, if they want to write a spell checker, they will write a spell
checker, for FFmpeg or for another project.

Agreed?

Second, and this is rather a big point, so it will be itemized; please read
to the end before replying:

What actual harm does it do if someone works on something that you believe
is outside the scope of the project? I understand that you do not want to
endorse committing "lavu: add a spell checker", and even less spend time on
it, but why actually oppose it?

I can see a few reasons, let us discuss them.

1. It looks silly. Yes it does. And for that reason, nobody will actually
support adding a spell checker to lavu. But that does not apply to
exposing extra features of protocols that are already implemented.

2. It is a waste of valuable developer time. See my first statement: you
do not get to decide that, each person decide for themselves. If
someone decides to implement it now, if someone else decides to
maintain it later, that is their decision, they do so because they find
value in it. And if nobody does, you can let it bitrot and have the
pleasure of removing it when it has become obvious it was useless.

3. It pollutes the code. That, I can agree with, but that can be
mitigated: separate source files, optional compilation, well-defined
entry points. You can insist on such things.

Note that the notion of maintainership applies: AFAIK, you never wrote
a line about the libssh client, so your say in what happens in it is
limited. Limited, I would say, to the parts of the code that can be
reached by your use cases.

In other words: if it does not affect the code you actively work on and
if it does not change the run path of the features you really use, let
it be.

4. It wastes compilation time. That, I could agree too, having worked on
under-powered boxes. But let us be realistic: all these features we are
talking about are tiny. All together, they take less time building than
the file for the optimized DSP code of a single major codec.

5. It wastes limited resources, in particular funding and sponsorship.
Does it? Did we have a promising candidate that did not get a slot
because of one of these project? As far as I can see, the limiting
factor until now was the number of motivated candidates.

6. Anything else?


There is another point I wish to make before ending this too long mail: I
believe we can agree on a few very generic guidelines about what should be
accepted in the project. In other words, I wish to explain why I support the
directory listing API and the HTTP server but I would oppose
libavspellcheck.

I believe any of at least three conditions can make a new feature
acceptable:

1. A feature that is similar, in essence, to an already widely accepted
feature. New codecs are ok, because FFmpeg already has a lot of codecs.
We already have a X11 screen capture device, that means a windows
screen capture device or a Wayland capture device would have its place.

2. If we already have code that we need, then exposing the feature as a
clean API makes sense. With a caveat: exposing a public API freezes it,
so the evolution must be considered carefully.

An example: we need FFTs for the codecs. Then exposing a public AVFFT
interface makes sense.

Another example: hashes, we need them for some the checksums in some
formats, they have a rather natural an well-delimited interface, it
would be absurd not to expose them.

Well, we already have a HTTP server! It is hidden in ffserver and
duplicates some of the HTTP client code. If Stephan can merge the code
and give it a good overhaul, how is that bad?

Same goes for the output devices in lavd: ffplay needs a window to
display the video, other apps would benefit from it too. It does not
look very good currently because the work is only less than halfway
done: the devices are added, but they are not used in ffplay because
the API has some missing features. But theoretically it would look
really good.

3. If it makes existing feature cleaner and more orthogonal, then it
deserves to be considered.

For example, we already have a libsmb client (I know you objected to
it, but I was not convinced by your objections, and it brings us back
to my previous point: what harm does it do?), we also have a globbing
feature to turn a list of images into a video. But we can not use
globbing with files accessed through libsmb. How silly is that? The
directory listing API fixes that.

You complain about creeping featurism in FFmpeg, but the creeping
featurism is not in FFmpeg, it is in the multimedia world. The multimedia
world is incredibly complex because it is used by end-users that enjoy
fancy features.

I, personally, am perfectly happy of having my video collection identified
by directory and path name and run MPlayer on them by command lines. Most
end-users are not satisfied by that, they want fancy features, browsing
with preview, seamless migrating from their phone to their tablet to their
home cinema, etc. To support all these needs, eventually a multimedia
framework must encompass a whole lot of things.

Even a spell checker.

Yes, even a spell checker, and I prove it. There are bitmap subtitles
formats; there are also text subtitles formats. Bitmap subtitles are
easier to use together with video, but text subtitles formats are more
convenient to edit. Therefore, we need something to convert between text
and bitmap subtitles. For the text to bitmap direction, we need a font
rasterizer; FFmpeg can already use Freetype. For the other direction, we
need an OCR, and an OCR needs a spell checker to polish the result.

Yes, libavspellcheck! I used it as an absurd example, but if you think
carefully on it, it is not actually absurd.


Well, now it has really been too long, but I hope I did manage to sway you a
bit.

Regards,
--
Nicolas George
wm4
2015-06-23 10:27:45 UTC
Permalink
On Tue, 23 Jun 2015 11:05:31 +0200
Post by Nicolas George
Yes, libavspellcheck! I used it as an absurd example, but if you think
carefully on it, it is not actually absurd.
I think you're alone with this.

libav* are for (de)muxing and decoding/encoding. That's why people are
using it. Everything else FFmpeg does extremely badly, and thus is
better done somewhere else. It all boils down to API and organization
really.

It wouldn't be much of a problem to add a separate git repo that
contains libavspellchecker. This would be truly independent. But I know
what would happen... you'd add subtitle support to libavfilter, and the
spell checker would be implemented as a filter.

We could have libavremotefileoperations too, but no, it will just end
up in libavformat.

Oh, and even if we had libavspellchecker or libavremotefileoperations,
it would have to be part of The Big Git Repo. For some reason. Even
though the sub-libs are supposed to be independent. (Totally.)

Your arguments all make sense, but the way things will actually be done
is different and usually terrible.

(Just think about it. Things such as adding video outputs through a
muxer API just because the original authors didn't know a better place
for it. Using a muxer API for video output is absurd, but if you bang
your head against ffmpeg.c enough, your brain matter becomes squished
enough that it starts making sense.)

Regarding bloat: distro versions of FFmpeg are typically extremely
bloated. It's fun to watch: merely linking a C source file containing
only a main function to Debian's build of libavformat will allocate
at least 10 MB of RAM on program start. Bloat is bad because it adds
up. And you can't escape it either. If you link to a distro build of
libavformat, your program will use more memory and will take longer to
load as it would if you'd compile it yourself.

I'm also not sure why you think maintaining essentially dead code is
hard. Hint: it is pretty hard if you actually want to make FFmpeg saner
overall. Bloat is like the concrete that keeps entangled software
entangled.
Nicolas George
2015-06-23 10:51:18 UTC
Permalink
Post by wm4
I think you're alone with this.
I do not intend to push for it, it was just an extreme example. I do maths,
and there is one thing we learn: if you want to know how solid an argument
is, push it to the extreme. If you suspect f is monotonic and want to know
whether it is increasing or decreasing, look at its asymptotic behaviour. If
you want to know if libavremotefileoperations makes sense, wonder about
libspellcheck.
Post by wm4
libav* are for (de)muxing and decoding/encoding.
libav* are for what developers want to make them for.
Post by wm4
It wouldn't be much of a problem to add a separate git repo that
contains libavspellchecker. This would be truly independent. But I know
what would happen... you'd add subtitle support to libavfilter, and the
spell checker would be implemented as a filter.
Yes, exactly. We want everything in FFmpeg because multimedia is an
entangled topic: if you want to do anything non-trivial, you need
everything.
Post by wm4
We could have libavremotefileoperations too, but no, it will just end
up in libavformat.
Please give us ONE GOOD REASON to split the libraries. I myself advocate for
one single libffmpeg.so, because the only practical consequences I see to
the split is the hassle of intra-project ABI stability, with all the
avpriv_frobnicate() stuff. Even libavformat and libavcodec belong together:
demuxers require parsers, and parsers share code with decoders. The rest is
peanuts.

By having all together, we can have a common testing framework.

Look at what happens in the Linux kernel: even for modules that could be
shipped separately, the policy is to have it all in one huge repository. The
FFmpeg code base is not nearly as big as the Linux code base.
Post by wm4
is different and usually terrible.
For your information, I consider the paragraphs that contain that kind of
gratuitous abuse non-existent.
Post by wm4
I'm also not sure why you think maintaining essentially dead code is
hard.
That is exactly the opposite, I think it is easy: just run the bulldozer on
the oldest parts of the graveyard once in a while.

Regards,
--
Nicolas George
wm4
2015-06-23 11:19:54 UTC
Permalink
On Tue, 23 Jun 2015 12:51:18 +0200
Post by Nicolas George
Post by wm4
I think you're alone with this.
I do not intend to push for it, it was just an extreme example. I do maths,
and there is one thing we learn: if you want to know how solid an argument
is, push it to the extreme. If you suspect f is monotonic and want to know
whether it is increasing or decreasing, look at its asymptotic behaviour. If
you want to know if libavremotefileoperations makes sense, wonder about
libspellcheck.
People don't follow mathematic rules, and neither do human arguments.
Not even software development does.
Post by Nicolas George
Post by wm4
libav* are for (de)muxing and decoding/encoding.
libav* are for what developers want to make them for.
The current architecture just doesn't allow it without committing API
atrocities. (You might consider this "abuse", but I gave enough
convincing examples.)
Nicolas George
2015-06-23 15:33:42 UTC
Permalink
Post by wm4
People don't follow mathematic rules, and neither do human arguments.
Not even software development does.
And yet, even so, the reasoning discipline gives valuable results even in
these areas. Wonderful, isn't it?
Post by wm4
The current architecture just doesn't allow it without committing API
atrocities.
There is no doubt that FFmpeg has a lot of round pegs in square holes. Just
repeating it ad nauseam is not a constructive contribution. There are two
kind of constructive contributions that you can do:

1. Help design round holes for the round pegs.

2. Build a case to prove that FFmpeg is better without the round pegs.

For now, I have not yet seen you do any of these things.

Personally, I consider that we should strive to make sure that all pegs,
even the square ones and even the very useful ones, do not have a cost when
they are not used (i.e. an application that uses lavf and lavc to demux and
decode MP3 should not be burdened by initiating the H.266 tables or loading
the TLS certificates). And in that case, it is better to have the pegs, even
if we do not have the correctly shaped holes yet.

Regards,
--
Nicolas George
wm4
2015-06-23 16:56:43 UTC
Permalink
On Tue, 23 Jun 2015 17:33:42 +0200
Post by Nicolas George
Post by wm4
People don't follow mathematic rules, and neither do human arguments.
Not even software development does.
And yet, even so, the reasoning discipline gives valuable results even in
these areas. Wonderful, isn't it?
Post by wm4
The current architecture just doesn't allow it without committing API
atrocities.
There is no doubt that FFmpeg has a lot of round pegs in square holes. Just
repeating it ad nauseam is not a constructive contribution. There are two
1. Help design round holes for the round pegs.
I've often enough suggested alternative ways how to do something, but
you just keep calling me a troll instead of listening.

Michael Niedermayer
2015-06-21 21:06:15 UTC
Permalink
On Sat, Jun 20, 2015 at 2:52 PM, Mariusz Szczepańczyk
Post by Mariusz Szczepańczyk
---
doc/APIchanges | 4 ++++
libavformat/avio.c | 38 ++++++++++++++++++++++++++++++++++++++
libavformat/avio.h | 19 +++++++++++++++++++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
Why do we need moving and deleting files in avio? Whats the use-case for ffmpeg?
In addition to what has been mentioned there is also the need to
atomically replace files in some muxers
we currently use ff_rename() for that, but that is specific to local
files, It would be better / more ideal if that was not specific to
just local files

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
Reynaldo H. Verdejo Pinochet
2015-06-22 23:46:01 UTC
Permalink
Hi everyone

Not really getting into the whole discussion on blocking
remarks to a running (sponsored) project. I sincerely hope
we all agree that once work has started on these, we should
try to be constructive and let the student do their job while
benefiting from all we can feed to them on the do-it-better
side.

Now, on the hopes of being constructive:

I do understand resource renaming and removing are borderline
use cases, but I also see the need for such functionality when, for
instance, there's no easy way to properly inform the application
about what and how to rename/move. It been a protocol:// issue,
a loosely defined naming%0Xd*.ext convention, etc (there are
similar examples for renaming). Lacking a better solution and
considering we should be at least responsible for our own cleanup,
I'd just make sure this API stays in the avpriv_ realm and work
together on designing a solution that would let us have this
functionality available for internal use while being maintainable
, have good platform coverage, and be as uncluttered (use-case wise)
as it can possibly be.

Humbly,
--
Reynaldo H. Verdejo Pinochet
Open Source Group
Samsung Research America / Silicon Valley
Michael Niedermayer
2015-06-22 23:49:49 UTC
Permalink
Post by Reynaldo H. Verdejo Pinochet
Hi everyone
Not really getting into the whole discussion on blocking
remarks to a running (sponsored) project. I sincerely hope
we all agree that once work has started on these, we should
try to be constructive and let the student do their job while
benefiting from all we can feed to them on the do-it-better
side.
I do understand resource renaming and removing are borderline
use cases, but I also see the need for such functionality when, for
instance, there's no easy way to properly inform the application
about what and how to rename/move. It been a protocol:// issue,
a loosely defined naming%0Xd*.ext convention, etc (there are
similar examples for renaming). Lacking a better solution and
considering we should be at least responsible for our own cleanup,
I'd just make sure this API stays in the avpriv_ realm and work
together on designing a solution that would let us have this
functionality available for internal use while being maintainable
, have good platform coverage, and be as uncluttered (use-case wise)
as it can possibly be.
+1

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
Derek Buitenhuis
2015-06-22 23:53:57 UTC
Permalink
Post by Reynaldo H. Verdejo Pinochet
Not really getting into the whole discussion on blocking
remarks to a running (sponsored) project. I sincerely hope
we all agree that once work has started on these, we should
try to be constructive and let the student do their job while
benefiting from all we can feed to them on the do-it-better
side.
As noted in my other mail(s), I agree, since work has started already
on GSOC.
Post by Reynaldo H. Verdejo Pinochet
I do understand resource renaming and removing are borderline
use cases, but I also see the need for such functionality when, for
instance, there's no easy way to properly inform the application
about what and how to rename/move. It been a protocol:// issue,
a loosely defined naming%0Xd*.ext convention, etc (there are
similar examples for renaming). Lacking a better solution and
considering we should be at least responsible for our own cleanup,
I'd just make sure this API stays in the avpriv_ realm and work
together on designing a solution that would let us have this
functionality available for internal use while being maintainable
, have good platform coverage, and be as uncluttered (use-case wise)
as it can possibly be.
That's the most reasonable thing I've read so far.

- Derek
Mariusz Szczepańczyk
2015-06-20 12:52:49 UTC
Permalink
---
libavformat/file.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)

diff --git a/libavformat/file.c b/libavformat/file.c
index 6511328..c689e04 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -131,6 +131,42 @@ static int file_check(URLContext *h, int mask)
return ret;
}

+static int file_delete(URLContext *h)
+{
+#if HAVE_UNISTD_H
+ int ret;
+ const char *filename = h->filename;
+ av_strstart(filename, "file:", &filename);
+
+ ret = rmdir(filename);
+ if (ret < 0 && errno == ENOTDIR)
+ ret = unlink(filename);
+ if (ret < 0)
+ return AVERROR(errno);
+
+ return ret;
+#else
+ return AVERROR(ENOSYS);
+#endif /* HAVE_UNISTD_H */
+}
+
+static int file_move(URLContext *h_src, URLContext *h_dst)
+{
+#if HAVE_UNISTD_H
+ const char *filename_src = h_src->filename;
+ const char *filename_dst = h_dst->filename;
+ av_strstart(filename_src, "file:", &filename_src);
+ av_strstart(filename_dst, "file:", &filename_src);
+
+ if (rename(filename_src, filename_dst) < 0)
+ return AVERROR(errno);
+
+ return 0;
+#else
+ return AVERROR(ENOSYS);
+#endif /* HAVE_UNISTD_H */
+}
+
#if CONFIG_FILE_PROTOCOL

static int file_open(URLContext *h, const char *filename, int flags)
@@ -198,6 +234,8 @@ URLProtocol ff_file_protocol = {
.url_close = file_close,
.url_get_file_handle = file_get_handle,
.url_check = file_check,
+ .url_delete = file_delete,
+ .url_move = file_move,
.priv_data_size = sizeof(FileContext),
.priv_data_class = &file_class,
};
--
2.3.6
Michael Niedermayer
2015-06-22 11:23:36 UTC
Permalink
Post by Mariusz Szczepańczyk
---
libavformat/file.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
applied

thanks

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
Loading...