On Sun, Jul 15, 2012 at 6:22 PM, Martin Storsjö <[email protected]> wrote: > On Sat, 14 Jul 2012, Luca Barbato wrote: > >> On 7/14/12 12:24 AM, Martin Storsjö wrote: >>> >>> On Sat, 14 Jul 2012, Luca Barbato wrote: >>> >>>> On 07/13/2012 10:56 PM, Martin Storsjö wrote: >>>>> >>>>> On Thu, 12 Jul 2012, Martin Storsjö wrote: >>>>> >>>>>> Unrelated question to others: Should we perhaps add a ff prefix to >>>>>> these protocols (rtmphttp, rtmpenc) that only are internal >>>>>> abstractions, to better separate them from the normal end-user >>>>>> protocols? >>>>> >>>>> >>>>> Luca and others, what do you think about this? It would make the whole >>>>> concept of internal protocols as abstraction layer be a bit nicer. >>>>> (I've >>>>> got a patch for converting the HTTP tunneling in RTSP into a separate >>>>> protocol layer as well, which would both abstract it nicely, as well as >>>>> add support for it in a few cases where it doesn't work right now.) >>>>> >>>> >>>> The only problem I could foresee is if somebody wants to use them >>>> programmatically for specific purposes. >>> >>> >>> I guess you could still use them, but it would be a bit clearer then - >>> opening ffrtmphttp:// IMO clearly indicates that it's a non-standard >>> libavformat specific thing, compared to opening rtmpe:// or http:// >>> which has a (more or less) standard meaning, and one shouldn't try >>> rtmphttp:// or rtmpenc:// when one is looking for rtmpt:// and rtmpe:// >>> respectively, which a prefix "namespace" would help clarify. >> >> >> instead of ff I'd use something impossible like "+" > > > Hmm. In this case, the proto still needs some other prefix in places like > configure and allformats.c and so on, since you can't use + as prefix there. > (The names that are printed there is half of the reason why I'd like to have > it renamed.) Underscore doesn't work either since it's not a valid url > scheme character.
Okay, I'll rename rtmpenc to ffrtmpenc and I'll do the same change for rtmphttp. -- Best regards, Samuel Pitoiset. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
