[vlc] RTSP client in vlc 2.1

[Gilles Chanteperdrix]

Hi,

first of all congratulations for the work on vlc, it has really become
the must have swiss-army knife of computer video.

But...

I am working on a mostly recreational RTSP server whose aim is to stream
all sorts of HD video files from a public IP address to my personal
computer behind a NAT, including text sub-titles. After trying several
strategies, I think I have come to a point where it works well, well, at
least with vlc 2.0. But I have two major problems with vlc 2.1.


Problem 1: sub-titles streaming.

When playing the following URL:
rtsp://xenomai.org:8554/video-tests/hd-fast.mp4

The playback works nicely, but when enabling a sub-title track, the
playback suddenly stops. After inspection of the RTSP dialog, here is
what happens. When starting playback, vlc sends a SETUP for every track,
then sends a global PLAY. When the user selects a sub-title track, it
sends a TEARDOWN for every sub-title track, then a SETUP only for the
selected track. At this point live555 (which is what I use for the RTSP
server) refuses to setup the track and returns a 404 error, which causes
vlc to stop playback.

I have found how to workaround this issue in live555 code, by getting
the SETUP to succeed, in which case vlc sends a PLAY command for the
sub-title track, and this happens to work by chance, but I do not think
this is the way to go:

according to what someone who read the RTSP RFC told me, when sending a
PLAY command while a PLAY is already going on causes the second PLAY
command to be acted upon only when the first is done: in other words,
you should start receiving the sub-titles when the movie is finished,
which I believe is not what we want.

So, from my point of view, vlc should:
- either stop the current stream, subscribe to all the wanted tracks,
then restart the stream by first seeking to the position where it stopped
- or do not send any TEARDOWN, as vlc 2.0 did.


Problem 2: RTP jitter effect.

When playing the following URL:
rtsp://xenomai.org:8554/video-tests/hd-slow.mp4

vlc skips some images, resulting in a stuttering video.

Here this may be my fault: the strategy used to stream contents with a
bandwidth near the bandwidth of my DSL line is to spread evenly the RTP
packets over time in order to approximate as much as possible a constant
network bitrate, guaranteeing that the such introduced jitter is
inferior to 1s, counting on the fact that the RTP timestamps contain the
real presentation time information, and that vlc has a 1s jitter buffer
to cope with such (artificial) jitter. But vlc 2.1 does not seem to like
that, whereas it worked with vlc 2.0.

Again however, I think this should be fixed in vlc, since:
- this is the only way I found to stream high-bandwidth contents
- again, the RTP timestamps contain the real presentation time
information, so a jitter inferior to the jitter buffer time should not
be a problem for the player.

Thanks for your attention.
Regards.

[Ross Finlayson]

Post by Gilles Chanteperdrix
Problem 1: sub-titles streaming.
rtsp://xenomai.org:8554/video-tests/hd-fast.mp4
The playback works nicely, but when enabling a sub-title track, the
playback suddenly stops. After inspection of the RTSP dialog, here is
what happens. When starting playback, vlc sends a SETUP for every track,
then sends a global PLAY. When the user selects a sub-title track, it
sends a TEARDOWN for every sub-title track, then a SETUP only for the
selected track. At this point live555 (which is what I use for the RTSP
server) refuses to setup the track and returns a 404 error, which causes
vlc to stop playback.

Gilles,

The real problem here seems to be that the LIVE555 code (which you're using as your server) is behaving unexpectedly. Because of this, the best place to discuss this problem is the "live-devel at lists.live555.com" mailing list (see <http://www.live555.com/liveMedia/faq.html#mailing-list-address> for more information) - rather than a VLC mailing list.

If there's a problem with the LIVE555 server code, then the proper solution would be for us (Live Networks, Inc. - the developer of that code) to fix that code, rather than asking VLC to change its behavior.

Post by Gilles Chanteperdrix
Problem 2: RTP jitter effect.

This, on the other hand, appears to be a legitimate VLC-related issue.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc/attachments/20131214/4d2c6e60/attachment.html>

[Ross Finlayson]

Post by Gilles Chanteperdrix
Problem 1: sub-titles streaming.
rtsp://xenomai.org:8554/video-tests/hd-fast.mp4
The playback works nicely, but when enabling a sub-title track, the
playback suddenly stops. After inspection of the RTSP dialog, here is
what happens. When starting playback, vlc sends a SETUP for every track,
then sends a global PLAY. When the user selects a sub-title track, it
sends a TEARDOWN for every sub-title track, then a SETUP only for the
selected track. At this point live555 (which is what I use for the RTSP
server) refuses to setup the track and returns a 404 error, which causes
vlc to stop playback.

Unfortunately - after getting more information from Gilles, and thinking about this some more - I've come to the conclusion that it's VLC's LIVE555-interface code that's in error here, and should be fixed. The basic problem that VLC (again, its LIVE555-interface code) should not be sending a "SETUP" for a track after it's already been torn down. Most RTSP servers will not accept this, because the "TEARDOWN" command (according to the RTSP specification) is supposed to end a session.

So, rather than sending a "TEARDOWN" for all subtitle tracks, and then doing a subsequent "SETUP" for the subtitle track that the user really wants, VLC's LIVE555-interface code should instead send a "TEARDOWN" for all subtitle tracks *except* the one that the user wants (and then not send another "SETUP"). (Note that you can do this using the second form of the "RTSPClient::sendTeardownCommand()" function: the one that takes a "MediaSubsession&" as parameter.)

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc/attachments/20131215/7edaea4e/attachment.html>

[Gilles Chanteperdrix]

Post by Ross Finlayson

Post by Gilles Chanteperdrix
Problem 1: sub-titles streaming.
rtsp://xenomai.org:8554/video-tests/hd-fast.mp4
The playback works nicely, but when enabling a sub-title track,
the playback suddenly stops. After inspection of the RTSP dialog,
here is what happens. When starting playback, vlc sends a SETUP for
every track, then sends a global PLAY. When the user selects a
sub-title track, it sends a TEARDOWN for every sub-title track,
then a SETUP only for the selected track. At this point live555
(which is what I use for the RTSP server) refuses to setup the
track and returns a 404 error, which causes vlc to stop playback.

Unfortunately - after getting more information from Gilles, and
thinking about this some more - I've come to the conclusion that it's
VLC's LIVE555-interface code that's in error here, and should be
fixed. The basic problem that VLC (again, its LIVE555-interface
code) should not be sending a "SETUP" for a track after it's already
been torn down. Most RTSP servers will not accept this, because the
"TEARDOWN" command (according to the RTSP specification) is supposed
to end a session.
So, rather than sending a "TEARDOWN" for all subtitle tracks, and
then doing a subsequent "SETUP" for the subtitle track that the user
really wants, VLC's LIVE555-interface code should instead send a
"TEARDOWN" for all subtitle tracks *except* the one that the user
wants (and then not send another "SETUP"). (Note that you can do
this using the second form of the "RTSPClient::sendTeardownCommand()"
function: the one that takes a "MediaSubsession&" as parameter.)

I had thought about that, but this will not work either, what happens if
the user wants to change the sub-title track later? You have the SETUP
after TEARDOWN issue again.

[Ross Finlayson]

Post by Gilles Chanteperdrix

Post by Ross Finlayson
So, rather than sending a "TEARDOWN" for all subtitle tracks, and
then doing a subsequent "SETUP" for the subtitle track that the user
really wants, VLC's LIVE555-interface code should instead send a
"TEARDOWN" for all subtitle tracks *except* the one that the user
wants (and then not send another "SETUP"). (Note that you can do
this using the second form of the "RTSPClient::sendTeardownCommand()"
function: the one that takes a "MediaSubsession&" as parameter.)

I had thought about that, but this will not work either, what happens if
the user wants to change the sub-title track later? You have the SETUP
after TEARDOWN issue again.

OK, so instead - how about not sending any "TEARDOWN"s at all (for any of the subtitle tracks)? VLC will still receive all of the subtitle tracks (which shouldn't be a problem, because they're generally low-bitrate), but render only the one that the user's interested in.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc/attachments/20131215/ecae5006/attachment.html>

[Gilles Chanteperdrix]

Post by Ross Finlayson

Post by Gilles Chanteperdrix

Post by Ross Finlayson
So, rather than sending a "TEARDOWN" for all subtitle tracks,
and then doing a subsequent "SETUP" for the subtitle track that
the user really wants, VLC's LIVE555-interface code should
instead send a "TEARDOWN" for all subtitle tracks *except* the
one that the user wants (and then not send another "SETUP").
(Note that you can do this using the second form of the
"RTSPClient::sendTeardownCommand()" function: the one that takes
a "MediaSubsession&" as parameter.)

I had thought about that, but this will not work either, what
happens if the user wants to change the sub-title track later? You
have the SETUP after TEARDOWN issue again.

OK, so instead - how about not sending any "TEARDOWN"s at all (for
any of the subtitle tracks)? VLC will still receive all of the
subtitle tracks (which shouldn't be a problem, because they're
generally low-bitrate), but render only the one that the user's
interested in.

Yes, that is what vlc 2.0 used to do, and it worked.

[Jean-Baptiste Kempf]

Post by Gilles Chanteperdrix

Post by Ross Finlayson

Post by Gilles Chanteperdrix

Post by Ross Finlayson
So, rather than sending a "TEARDOWN" for all subtitle tracks,
and then doing a subsequent "SETUP" for the subtitle track that
the user really wants, VLC's LIVE555-interface code should
instead send a "TEARDOWN" for all subtitle tracks *except* the
one that the user wants (and then not send another "SETUP").
(Note that you can do this using the second form of the
"RTSPClient::sendTeardownCommand()" function: the one that takes
a "MediaSubsession&" as parameter.)

I had thought about that, but this will not work either, what
happens if the user wants to change the sub-title track later? You
have the SETUP after TEARDOWN issue again.

OK, so instead - how about not sending any "TEARDOWN"s at all (for
any of the subtitle tracks)? VLC will still receive all of the
subtitle tracks (which shouldn't be a problem, because they're
generally low-bitrate), but render only the one that the user's
interested in.

Yes, that is what vlc 2.0 used to do, and it worked.

Unless you share a patch, I doubt it will get fixed.

[Gilles Chanteperdrix]

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix

Post by Ross Finlayson

Post by Gilles Chanteperdrix

Post by Ross Finlayson
So, rather than sending a "TEARDOWN" for all subtitle tracks,
and then doing a subsequent "SETUP" for the subtitle track that
the user really wants, VLC's LIVE555-interface code should
instead send a "TEARDOWN" for all subtitle tracks *except* the
one that the user wants (and then not send another "SETUP").
(Note that you can do this using the second form of the
"RTSPClient::sendTeardownCommand()" function: the one that takes
a "MediaSubsession&" as parameter.)

I had thought about that, but this will not work either, what
happens if the user wants to change the sub-title track later? You
have the SETUP after TEARDOWN issue again.

OK, so instead - how about not sending any "TEARDOWN"s at all (for
any of the subtitle tracks)? VLC will still receive all of the
subtitle tracks (which shouldn't be a problem, because they're
generally low-bitrate), but render only the one that the user's
interested in.

Yes, that is what vlc 2.0 used to do, and it worked.

Unless you share a patch, I doubt it will get fixed.

So, we tell you: "your client violates the RTSP RFC", and your answer is
"we do not care"?

Quite frankly, given the mass of code in vlc, you would have to at least
provide us with some pointers for not motivating me to write my own dumb
RTSP video viewer.

[Jean-Baptiste Kempf]

Post by Gilles Chanteperdrix
So, we tell you: "your client violates the RTSP RFC", and your answer is
"we do not care"?

It's not what I said.

Not many people really care about RTSP, and the live555 development
model is so obscure that noone of us actually want to work on it.

So if you want it fixed soon, share a patch.

Post by Gilles Chanteperdrix
Quite frankly, given the mass of code in vlc, you would have to at least
provide us with some pointers for not motivating me to write my own dumb
RTSP video viewer.

Great idea. That'll surely help other people that have the same issue.

[Gilles Chanteperdrix]

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
So, we tell you: "your client violates the RTSP RFC", and your answer is
"we do not care"?

It's not what I said.
Not many people really care about RTSP,

And they are wrong, streaming using UDP beats streaming using TCP any
time. But OK, understood, I will stop buggering this list with questions
about RTSP.

Post by Jean-Baptiste Kempf
and the live555 development
model is so obscure that noone of us actually want to work on it.
So if you want it fixed soon, share a patch.

Well, then use ffmpeg: ffplay receives RTSP just fine, and you get
the uniform avformat interface.

I have posted two mails today, one on vlc mailing list, the other
on live555 mailing list. From the answers I got, despite what you say,
live555 looks like a more open project.

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
Quite frankly, given the mass of code in vlc, you would have to at least
provide us with some pointers for not motivating me to write my own dumb
RTSP video viewer.

Great idea. That'll surely help other people that have the same issue.

Well, I already have a dumb player, the thing I do not have is the
sub-titles :-)

[Jean-Baptiste Kempf]

Post by Gilles Chanteperdrix
I have posted two mails today, one on vlc mailing list, the other
on live555 mailing list. From the answers I got, despite what you say,
live555 looks like a more open project.

You post on a _users_ mailing list, that has been explained as a
deprecated way of discussing to the project.

But since you think live555 is SO open, I will be delighted to look
at the diff and changes between the last few versions...
I won't even ask for a tarball, because, I know it's too much to ask...

Seriously...

[Gilles Chanteperdrix]

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
I have posted two mails today, one on vlc mailing list, the other
on live555 mailing list. From the answers I got, despite what you say,
live555 looks like a more open project.

You post on a _users_ mailing list, that has been explained as a
deprecated way of discussing to the project.

I am sorry, I am having problems as a user of vlc as an RTSP client. So,
I use the users mailing list, which I found on videolan.org web site. Here:

https://www.videolan.org/support/lists.php

Without any mention of its "deprecatedness".

Post by Jean-Baptiste Kempf
But since you think live555 is SO open, I will be delighted to look
at the diff and changes between the last few versions...

I have been working for several monthes with live555 code, I use:
https://github.com/hackeron/live555

And I daresay I find live555 sources to have a way more manageable size
than those of vlc, which is why I did not even attempt to fix myself the
defects of vlc as an RTSP client and came to this (user) list.

Post by Jean-Baptiste Kempf
I won't even ask for a tarball, because, I know it's too much to ask...

Well, that is true, there is always only the latest tarball in the
download area, but this can easily be worked around using github.

No need to answer, I am unsubscribing from this list. You just lost one
vlc fan, but you probably do not care, since you have so many.

Regards.

[Jean-Baptiste Kempf]

Post by Gilles Chanteperdrix

Post by Jean-Baptiste Kempf
But since you think live555 is SO open, I will be delighted to look
at the diff and changes between the last few versions...

https://github.com/hackeron/live555

Wow! Clearly live555 is very open...
So much open that you must yourself create a repository...

Post by Gilles Chanteperdrix
And I daresay I find live555 sources to have a way more manageable size
than those of vlc, which is why I did not even attempt to fix myself the

Comparing a library supporting one protocol to a full media framework
supported dozens of protocols, hundreds of formats and codecs, in term
of code size.
Nice trolling.

Post by Gilles Chanteperdrix
defects of vlc as an RTSP client and came to this (user) list.

lol. If, instead of trolling, you had given a look at VLC source code,
you would have seen that the RTSP client module is just a single file
of 2000 LoC.

Oh, and you have the history of all changes that could impact it:
http://git.videolan.org/?p=vlc.git;a=history;f=modules/access/live555.cpp;hb=HEAD
And there are not many changes since the 2.0.x fork...

Post by Gilles Chanteperdrix

Post by Jean-Baptiste Kempf
I won't even ask for a tarball, because, I know it's too much to ask...

Well, that is true, there is always only the latest tarball in the
download area, but this can easily be worked around using github.

You must be kidding, right?
A project with no open source-control, no tarballs, no history and a
single commiter is more open than a project where all the decisions are
in the open, with all sources, all forks open, tarballs and binaries of
all versions, with hundreds of commitors per year.

Post by Gilles Chanteperdrix
No need to answer, I am unsubscribing from this list. You just lost one
vlc fan, but you probably do not care, since you have so many.

Clearly, you are a basic troll with extreme agressivity. I won't cry.


So let's summarize:
- you call a project with no public source repo, one commitor only, no
history tarballs, no diffs, more open than VLC that has all the opposite;
- you call VLC source code bloated compared to a single library that
does on thousandth of what VLC can do;
- you don't even look at the code that could be faulty (aka a single
file) or the 20 commits that are involved, but complain that other
people don't do it for you (for free).

So yes, just based on those three points, you are basically a troll.

Moreover, when people tell you that you probably should fix it yourself,
which you obviously have the skills to do, you turn into bersek mode and
full aggressivity.
Not to mention that this is probably just a revert to do.

So yes, please write your own RTSP client (that I hope will be under
2000 lines of code, of course! With full subtitles rendering!) and don't
use VLC.
I just hope for you that you won't need VLC ever in your life...

With my kindest regards,

[Gilles Chanteperdrix]

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix

Post by Jean-Baptiste Kempf
But since you think live555 is SO open, I will be delighted to look
at the diff and changes between the last few versions...

https://github.com/hackeron/live555

Wow! Clearly live555 is very open...
So much open that you must yourself create a repository...

I was talking about openness of the project towards its users reports,
not the openness of the development model.

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
And I daresay I find live555 sources to have a way more manageable size
than those of vlc, which is why I did not even attempt to fix myself the

Comparing a library supporting one protocol to a full media framework
supported dozens of protocols, hundreds of formats and codecs, in term
of code size.
Nice trolling.

Indeed. But you are not bad at that game yourself. You forget to answer
all the remarks that embarrass you. Like the report on the effects of
network jitter on playback of timestamped sources, or the remark that
the user mailing list address is still available on the web site,
whereas you claim that it is not appropriate, not to mention the fact
that you could have said that in answer to my first post, instead of
waiting for the tone to have become ridiculously over-aggressive.

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
defects of vlc as an RTSP client and came to this (user) list.

lol. If, instead of trolling, you had given a look at VLC source code,
you would have seen that the RTSP client module is just a single file
of 2000 LoC.
http://git.videolan.org/?p=vlc.git;a=history;f=modules/access/live555.cpp;hb=HEAD
And there are not many changes since the 2.0.x fork...

Well, I asked for pointers, you could not send them. Now that I became
aggressive you give them to me. So, maybe becoming aggressive was useful
after all?

Post by Jean-Baptiste Kempf
Moreover, when people tell you that you probably should fix it yourself,
which you obviously have the skills to do, you turn into bersek mode and
full aggressivity.
Not to mention that this is probably just a revert to do.
So yes, please write your own RTSP client (that I hope will be under
2000 lines of code, of course! With full subtitles rendering!) and don't
use VLC.

I already have a player with an RTSP client, and it takes 1 line of
code, because I simply pass the RTSP URL to avformat_open_input, as I do
any other.

Ok, so you have made your summary. Let me make mine. Hopefully
dispassionately if that is still possible.

Like I said in the original report, mostly for fun, I am developing a
server to stream videos using the RTSP protocol, from an internet
connected server to my PC through a DSL line. After several monthes of
trials (which would tend to disprove your claims about my skills), I
finally come to a solution which works well, but has issues with vlc, I
know that the server works well, because it works fine with ffplay for
instance.

Being an afficionado of vlc, a (one-time) donator even, and vlc being
what other users with which I wish to share videos will probably use
anyway, I decide that I should help fixing vlc. Maintaining myself a
free-software project I decide that what is most needed is a way for vlc
developers to reproduce my issue, so I take time to:
- set up a server using the public address of the free-software project
I am maintaining, with some pieces of videos, transcoded from Blu-rays;
- send a very detailed bug report, where I not only describe the
symptoms, but what informations I could gather by debugging the RTSP
dialog, and most of all two rtsp URLs allowing vlc developers to
reproduce the issues.

Then the only help I get is from the live555 maintainer, which should
not even have got involved, then a laconic:

"we will not fix it, send a patch", not even answering the second, more
serious bug.

to which I answer "your answer is demotivating, your code is scary, send
me pointers to get my feet wet", at which point you simply decide to not
send me the pointers. Then yes, I became aggressive, and I should not have.

So if you are wondering why I do not want to contribute to vlc, lack of
time, code size, and architectures questions aside, well, then look at
how poorly you seem to have handled a report which from my point of view
was more than adequate.

Regards.

[Gilles Chanteperdrix]

Post by Gilles Chanteperdrix
"we will not fix it, send a patch", not even answering the second, more
serious bug.
to which I answer "your answer is demotivating, your code is scary, send
me pointers to get my feet wet", at which point you simply decide to not
send me the pointers. Then yes, I became aggressive, and I should not have.
So if you are wondering why I do not want to contribute to vlc, lack of
time, code size, and architectures questions aside, well, then look at
how poorly you seem to have handled a report which from my point of view
was more than adequate.

Also, being a maintainer myself, if a piece of code is such that I do
not want to maintain it, I remove it, purely and simply. I find it a
much saner attitude than having some code in my codebase but refusing to
maintain it when users report bugs. Again, you have the choice to use
ffmpeg instead of live555 as an RTSP client for instance.

Of course, in the end, you maintain vlc codebase the way you see fit,
but please do not be surprised if others which do not like the way you
are doing your job do not want to participate.

[Jean-Baptiste Kempf]

Post by Gilles Chanteperdrix
Also, being a maintainer myself, if a piece of code is such that I do
not want to maintain it,

Oh please. Noone said that we will not maintain it.
And this is exactly what is happening to the RTSP module, that is
getting denoted under the avformat module priority

Post by Gilles Chanteperdrix
I remove it, purely and simply. I find it a

Wow, you are so grand, please tell us how to maintain a 100-million
users software. Could you teach us?

You realize what it means for user to change protocol implementations or
remove some implementations? I don't think so.
Every .0 release is a fultitude of complaints, that get fixed during the
following minor releases.

Post by Gilles Chanteperdrix
much saner attitude than having some code in my codebase but refusing to
maintain it when users report bugs. Again, you have the choice to use

You did not report a bug. Bugs get reported on the trac.

Post by Gilles Chanteperdrix
ffmpeg instead of live555 as an RTSP client for instance.

Which already exists in VLC codebase, for RTMP and other protocols.
And which is getting discussed as a higher-priority than live555 for
RTSP, for the very reasons explained above.

Post by Gilles Chanteperdrix
but please do not be surprised if others which do not like the way you
are doing your job do not want to participate.

Sure. I am not surprised and I don't complain.

[Gilles Chanteperdrix]

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
Also, being a maintainer myself, if a piece of code is such that I do
not want to maintain it,

Oh please. Noone said that we will not maintain it.

Again, that is how I understood your reaction.

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
ffmpeg instead of live555 as an RTSP client for instance.

Which already exists in VLC codebase, for RTMP and other protocols.
And which is getting discussed as a higher-priority than live555 for
RTSP, for the very reasons explained above.

Please be careful, I am not so sure ffmpeg as an RTSP client works well
with MPEG TS over RTSP used for instance when watching TV with "Free
multi-poste". If you break that, you will get a lot of complaints I
suppose :-)

[Jean-Baptiste Kempf]

Post by Gilles Chanteperdrix
Please be careful, I am not so sure ffmpeg as an RTSP client works well
with MPEG TS over RTSP used for instance when watching TV with "Free
multi-poste". If you break that, you will get a lot of complaints I
suppose :-)

Exactly what I said about support.

But as live555 refuse to act like an open source project, we have no
choices left.
We've tried asking nicely, asking less nicely, threatening. But nothing
changes.
So we can either fork or drop it.

Once VLC stop using live555, I think many distributions will just drop
it. But I doubt they understand that.

With my kindest regards,

[Jean-Baptiste Kempf]

Post by Gilles Chanteperdrix

Post by Jean-Baptiste Kempf
Wow! Clearly live555 is very open...
So much open that you must yourself create a repository...

I was talking about openness of the project towards its users reports,
not the openness of the development model.

Yeah, let's redefine terms.

Post by Gilles Chanteperdrix

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
And I daresay I find live555 sources to have a way more manageable size
than those of vlc, which is why I did not even attempt to fix myself the

Comparing a library supporting one protocol to a full media framework
supported dozens of protocols, hundreds of formats and codecs, in term
of code size.
Nice trolling.

Indeed. But you are not bad at that game yourself. You forget to answer
all the remarks that embarrass you. Like the report on the effects of
network jitter on playback of timestamped sources, or the remark that

Sorry, I don't know all codebase of VLC and all issues, notably the
live555 part.

Post by Gilles Chanteperdrix
the user mailing list address is still available on the web site,
whereas you claim that it is not appropriate, not to mention the fact

- https://mailman.videolan.org/pipermail/vlc/2012-February/020611.html
- The introduction mail when you subscribe should have told you
- Any look at the archives of this list should have told you it's almost
dead. Compare the amount of messages per month compared to any other
mailing-list like vlc-devel, for eg.

Post by Gilles Chanteperdrix
that you could have said that in answer to my first post, instead of
waiting for the tone to have become ridiculously over-aggressive.

Your answer to me was overly aggressive.

Post by Gilles Chanteperdrix

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
defects of vlc as an RTSP client and came to this (user) list.

lol. If, instead of trolling, you had given a look at VLC source code,
you would have seen that the RTSP client module is just a single file
of 2000 LoC.
http://git.videolan.org/?p=vlc.git;a=history;f=modules/access/live555.cpp;hb=HEAD
And there are not many changes since the 2.0.x fork...

Well, I asked for pointers, you could not send them. Now that I became
aggressive you give them to me. So, maybe becoming aggressive was useful
after all?

No, your first answer to me was the aggressive one.

I tell you that it's unlikely to get fixed unless someone does a patch
and your answer was that I refuse to fix it.
I've help hundreds of people fixing bugs of VLC and I've merged more
people patches in VLC that any other person...

Post by Gilles Chanteperdrix

Post by Jean-Baptiste Kempf
Moreover, when people tell you that you probably should fix it yourself,
which you obviously have the skills to do, you turn into bersek mode and
full aggressivity.
Not to mention that this is probably just a revert to do.
So yes, please write your own RTSP client (that I hope will be under
2000 lines of code, of course! With full subtitles rendering!) and don't
use VLC.

I already have a player with an RTSP client, and it takes 1 line of
code, because I simply pass the RTSP URL to avformat_open_input, as I do
any other.

Please keep doing that. And of course, there is no need to set avformat
or to control it...

Oh, btw, we also have an avio/avformat module in VLC... We use it for
RTMP, and it's not even 500 LoC.

Post by Gilles Chanteperdrix
Like I said in the original report, mostly for fun, I am developing a
server to stream videos using the RTSP protocol, from an internet
connected server to my PC through a DSL line. After several monthes of
trials (which would tend to disprove your claims about my skills), I
finally come to a solution which works well, but has issues with vlc, I
know that the server works well, because it works fine with ffplay for
instance.

You also said that VLC 2.1 does not work while 2.0 worked.
Finding the right commit is probably not hard knowing your skills.
And would help everyone.

Post by Gilles Chanteperdrix
anyway, I decide that I should help fixing vlc. Maintaining myself a

No, you did not offer that. You attacked me when I suggested that you
fix it yourself to help the community.

Post by Gilles Chanteperdrix
Then the only help I get is from the live555 maintainer, which should
"we will not fix it, send a patch", not even answering the second, more
serious bug.

You are a basic troll.
The quote said differently: "Unless you share a patch, I doubt it will get
fixed"...

And indeed, who do you think people fixing bugs are? Magicians?
No, people like you who know a problem and have the skills to fix it.

The core dev team of VLC is extremly limited, and we have very low time.
So, yes, minor issues are not priotorized.

Post by Gilles Chanteperdrix
to which I answer "your answer is demotivating, your code is scary, send
me pointers to get my feet wet", at which point you simply decide to not
send me the pointers. Then yes, I became aggressive, and I should not have.

No, your first mail to me was aggressive. I refuse to answer to those
people.

Post by Gilles Chanteperdrix
So if you are wondering why I do not want to contribute to vlc, lack of
time, code size, and architectures questions aside, well, then look at
how poorly you seem to have handled a report which from my point of view
was more than adequate.

Fine. Have fun!

[Gilles Chanteperdrix]

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix

Post by Jean-Baptiste Kempf
Wow! Clearly live555 is very open...
So much open that you must yourself create a repository...

I was talking about openness of the project towards its users reports,
not the openness of the development model.

Yeah, let's redefine terms.

No, I merely explain you what I meant when I said:
"I have posted two mails today, one on vlc mailing list, the other
on live555 mailing list. From the answers I got, despite what you say,
live555 looks like a more open project."

I am sorry, as you no doubt have guessed, english is not my mother tongue,

Post by Jean-Baptiste Kempf
Your answer to me was overly aggressive.

I apologize for that, it was not meant to be.

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
I already have a player with an RTSP client, and it takes 1 line of
code, because I simply pass the RTSP URL to avformat_open_input, as I do
any other.

Please keep doing that. And of course, there is no need to set avformat
or to control it...

Yeah, but do not compare oranges and apples, 2000 lines in vlc is the
size of the RTSP stuff. With ffmpeg, there is no particular code needed.

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
Like I said in the original report, mostly for fun, I am developing a
server to stream videos using the RTSP protocol, from an internet
connected server to my PC through a DSL line. After several monthes of
trials (which would tend to disprove your claims about my skills), I
finally come to a solution which works well, but has issues with vlc, I
know that the server works well, because it works fine with ffplay for
instance.

You also said that VLC 2.1 does not work while 2.0 worked.
Finding the right commit is probably not hard knowing your skills.
And would help everyone.

Ok, will do.

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
anyway, I decide that I should help fixing vlc. Maintaining myself a

No, you did not offer that. You attacked me when I suggested that you
fix it yourself to help the community.

My intent when posting the original bug report, was to help fixing vlc.

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
"we will not fix it, send a patch", not even answering the second, more
serious bug.

You are a basic troll.
The quote said differently: "Unless you share a patch, I doubt it will get
fixed"...

Again, english not being my mother tongue, I do not perceive the nuance.

[Jean-Baptiste Kempf]

Post by Gilles Chanteperdrix

Post by Jean-Baptiste Kempf

Post by Gilles Chanteperdrix
I already have a player with an RTSP client, and it takes 1 line of
code, because I simply pass the RTSP URL to avformat_open_input, as I do
any other.

Please keep doing that. And of course, there is no need to set avformat
or to control it...

Yeah, but do not compare oranges and apples, 2000 lines in vlc is the
size of the RTSP stuff. With ffmpeg, there is no particular code needed.

libvlc_new is one line too...

Even for FFmpeg or a avio module in VLC, if you want to have trick-play,
or other complex features, you will need to extend FFmpeg API and code
them to use them from VLC.
Adding a FFmpeg protocol does not magically add it to the above software...

Post by Gilles Chanteperdrix
Again, english not being my mother tongue, I do not perceive the nuance.

The difference is that the VLC core team is extremely limited, and
extremely time-constrained, with an extrem large number of user, so that some
"niche" bugs, like RTSP issues, are usually not priotirized highly.

So, per my experience, if you want a quick fix on this issue, and you
have the skills, you should do it.

One is refusing to do something, the other is knowing it will not be
prioritized with the highest prio and that 2.2.0 will be out before
that...

With my kindest regards,