Quantcast

RTSP client in vlc 2.1

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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.

--
                                                                Gilles.
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Ross Finlayson
Problem 1: sub-titles streaming.

When playing the following URL:
<a href="rtsp://xenomai.org:8554/video-tests/hd-fast.mp4">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 "[hidden email]" 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.


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/


______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Ross Finlayson
In reply to this post by Gilles Chanteperdrix
Problem 1: sub-titles streaming.

When playing the following URL:
<a href="rtsp://xenomai.org:8554/video-tests/hd-fast.mp4">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/


______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Gilles Chanteperdrix
On 12/14/2013 05:50 PM, Ross Finlayson wrote:

>> 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.
>
>
> 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.

--
                                                                Gilles.
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

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/


______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Gilles Chanteperdrix
On 12/14/2013 06:08 PM, Ross Finlayson wrote:

>>> 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.

--
                                                                Gilles.
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Jean-Baptiste Kempf
On 14 Dec, Gilles Chanteperdrix wrote :

> On 12/14/2013 06:08 PM, Ross Finlayson wrote:
> >>> 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.

--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Gilles Chanteperdrix
On 12/14/2013 06:13 PM, Jean-Baptiste Kempf wrote:

> On 14 Dec, Gilles Chanteperdrix wrote :
>> On 12/14/2013 06:08 PM, Ross Finlayson wrote:
>>>>> 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.

--
                                                                Gilles.
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Jean-Baptiste Kempf
On 14 Dec, Gilles Chanteperdrix wrote :
> 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.

> 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.


--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device

______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Gilles Chanteperdrix
On 12/14/2013 06:38 PM, Jean-Baptiste Kempf wrote:
> On 14 Dec, Gilles Chanteperdrix wrote :
>> 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.

> 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.

>
>> 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 :-)

--
                                                                Gilles.
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Jean-Baptiste Kempf
On 14 Dec, Gilles Chanteperdrix wrote :
> 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...

--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Gilles Chanteperdrix
On 12/14/2013 06:55 PM, Jean-Baptiste Kempf wrote:
> On 14 Dec, Gilles Chanteperdrix wrote :
>> 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".

>
> 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.

> 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.


--
                                                                Gilles.
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Jean-Baptiste Kempf
On 14 Dec, Gilles Chanteperdrix wrote :
> > 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

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

> 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.

> 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...

> > 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.

> 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,

--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Gilles Chanteperdrix
On 12/15/2013 02:33 AM, Jean-Baptiste Kempf wrote:
> On 14 Dec, Gilles Chanteperdrix wrote :
>>> 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
>
> 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.

>
>> 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.

>
>> 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...

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?

>
> 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.
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Gilles Chanteperdrix
On 12/15/2013 08:57 AM, Gilles Chanteperdrix wrote:

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

--
                                                                Gilles.
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Jean-Baptiste Kempf
In reply to this post by Gilles Chanteperdrix
On 15 Dec, Gilles Chanteperdrix wrote :
> > 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.

> >> 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.

> 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.

> 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.

> >> 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...
>
> 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...

> > 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.

> 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.

> 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.

> 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.

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.

> 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.

> 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!


--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Jean-Baptiste Kempf
In reply to this post by Gilles Chanteperdrix
On 15 Dec, Gilles Chanteperdrix wrote :
> 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

> 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.

> 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.

> 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.

> 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.

--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Gilles Chanteperdrix
In reply to this post by Jean-Baptiste Kempf
On 12/15/2013 11:41 AM, Jean-Baptiste Kempf wrote:
> On 15 Dec, Gilles Chanteperdrix wrote :
>>> 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,

> Your answer to me was overly aggressive.

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


>> 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.

>> 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.

>
>> 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.

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


--
                                                                Gilles.
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Gilles Chanteperdrix
In reply to this post by Jean-Baptiste Kempf
On 12/15/2013 11:47 AM, Jean-Baptiste Kempf wrote:
> On 15 Dec, Gilles Chanteperdrix wrote :
>> 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.

>> 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 :-)


--
                                                                Gilles.
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RTSP client in vlc 2.1

Jean-Baptiste Kempf
In reply to this post by Gilles Chanteperdrix
On 15 Dec, Gilles Chanteperdrix wrote :
> >> 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...

> 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,

--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
______________________________________________________
vlc mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc
12
Loading...