Le primidi 1er prairial, an CCXXIV, Michael Niedermayer a écrit : > applications which supported both libav and ffmpeg cannot use symbols > that exist in only one of the forks as it would break linking. > > the same AVOption based code works with both forks though > > using accessors 2 different pieces of code would be needed and thus > also different binaries
Note: since we stopped ABI compatibility, this point is now moot. But I want to make things clears. It was not clear at the time that achieving this was your goal. If so, I think I would have objected: it was not our task to help people use the extra features of FFmpeg while still staying with libav. > Also with just accessors and no entry in AVOption > ffmpeg.c, ffplay.c and ffprobe.c would have needed explicit support > for each individual parameter instead of just generically exposing > the whole set of options Once again, you confuse everything. Accessors are for applications, AVOption are for users. If you add an AVOption for something that the user needs to set, that is perfectly fine. I was referring to a case you added an AVOption for something completely inaccessible to the user; I do not remember the specifics. > Theres the case ronald raised, that is the huge mess of options in > AVCodecContext and AVFormatContext > the type of these structures is known generally but not which of > the options apply to the codec at hand Please keep focused on the question at hand, or at least try to be aware and explicit when you take a tangent. We do not have a differentiated set of AVOption for AVCodecContext / AVFormatContext depending on the codec or muxer or whatever, and therefore it does not give any information not carried by the C structure and its documentation. > A user application and the user want to know what options are relevant > to the codec at hand > is thebit_rate_tolerance going to be honored, is the gop_size, > the max_b_frames, the intra_matrix or the block align value ? Well, they can not know that with the current API, but it is an unrelated question. > an AVClass in the first element of AVCodecContext with its AVOption > list can give an application this precisse list of > which of the options work on the actual used codec It could, but it does not, and nobody proposed that. IMHO, this is not a good approach. If some codecs use gop_size and some don't, then it should just be a private option. > C tells you about the fields that where listed at build time in the > included header, that are all fields that any codec could use from > AVCodecContext. Like ronald said that is a mess from the user > applications point of view > AVClass&AVOption could provide your application with a list of what > the actually linked lib at runtime with the actually selected codec > supports Still the same confusion. AVOption for user interaction is fine.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel