On Thu, 13 Oct 2011, Luca Barbato wrote:
You made a good point. I'd keep this syntax and use it to fill the
options but might be just overkill.
Keep which one, the current, or the new with rtsp+tcp://?
The new one.
The current
one is just crap IMO, but rtsp+tcp:// would be more convenient, I do
agree about that. The downside would be that we'd have two different
nondeprecated ways of doing one thing, which is confusing and inconsistent.
only if you mix them up, but yes it might cause more harm than good.
So, what's the consensus on how to move forward with this?
For new readers of this thread, there's three ways of passing these
options, one old that we're trying to move away from, one new suggested
scheme, and one purely avoption based one.
That is, currently, one chooses betwen different transport modes in RTSP
by adding query parameters, e.g. like this:
avplay rtsp://server/path?tcp
These parameters are stripped out within the RTSP demuxer and only used
for setting parameter internally there. This is obviously quite messy,
especially if the original path would contain other query parameters (e.g.
"avplay rtsp://server/path?param=value&tcp", where the user expects
param=value to be sent to the server, but not the &tcp part). This is the
status quo that we want to get rid of.
The second choice is purely avoptions based, like this:
avplay -rtsp_transport tcp rtsp://server/path
This completely avoids having to meddle with the actual RTSP url, and is
easy to use for users of the library.
The third option as suggested by Luca, would be to move to something like
this:
avplay rtsp+tcp://server/path
This is easier for the commandline avplay/avconv user, but more complex
for users of the library (where the library caller would have to munge the
url to add the +tcp part, and libavformat would have to remove it again
when adding the plain rtsp://server/path url into the requests).
So, opinions please. AVOptions, protocol+protocol://, or both?
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
