On Wed, 28 Oct 2015 13:17:23 +0100 Vittorio Giovara <[email protected]> wrote:
> On Wed, Oct 28, 2015 at 11:52 AM, wm4 <[email protected]> wrote: > > On Wed, 28 Oct 2015 11:25:43 +0100 > > Luca Barbato <[email protected]> wrote: > > > >> On 28/10/15 02:45, Vittorio Giovara wrote: > >> > imho go for "rawframes", no space like other codes, different from > >> > >> Changed this way, will hit the tree this night. > > > > Wrong color. IMHO it's misleading, because it sounds very similar to > > rawvideo, without making clear that it's a very special encoder to wrap > > AVFrames. This is not just another codec, but a mechanism to pass > > through AVFrames, with a very unusual packet format. (It's the only > > format that requires you to read pointers to normal memory from packet > > data.) > > > > While I agree that "wrapped_avframe" is not ideal, "rawframes" doesn't > > sound very telling. > > > > I suggest "rawvideo_avframe". > > _avframe still exposes libav internals and the point of the patch was > to hide them to the cli user. Well, it _should_ expose Libav internals, because it makes only sense with Libav internals. You can't e.g. use this encoder and mux the result into nut, or something. > How about keeping rawframes (or rawvideo if you prefer) and editing > the category, (internal) instead of (native)? Makes sense to add this to avconv.c, I guess. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
