On Fri, Aug 28, 2015 at 05:23:44PM -0400, Ronald S. Bultje wrote: > Hi, > > On Fri, Aug 28, 2015 at 5:15 PM, Michael Niedermayer <mich...@niedermayer.cc > > wrote: > > > On Fri, Aug 28, 2015 at 03:02:47PM -0400, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Mon, Aug 17, 2015 at 9:56 PM, Michael Niedermayer > > <mich...@niedermayer.cc > > > > wrote: > > > > > > > On Mon, Aug 17, 2015 at 01:38:19PM -0400, Ronald S. Bultje wrote: > > > > > Hi, > > > > > > > > > > On Mon, Aug 17, 2015 at 1:12 PM, Michael Niedermayer > > > > <mich...@niedermayer.cc > > > > > > wrote: > > > > > > > > > > > On Mon, Aug 17, 2015 at 11:52:16AM -0400, Ronald S. Bultje wrote: > > > > > > > --- > > > > > > > libavcodec/options_table.h | 2 ++ > > > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > > > googling for > > > > > > ffmpeg "-ab" > > > > > > has 332.000 matches > > > > > > > > > > > > ffmpeg "-b:a" > > > > > > has 64.100 matches > > > > > > > > > > > > this patch is simply a bad idea > > > > > > > > > > > > > > > So, there's a few practical problems here. A) if we remove flag/mask > > from > > > > > the set_defaults calls (other patch in this set), the audio is also > > used > > > > > for the video ones (since we ignore media type), and thus we use > > (after > > > > > FF_API_OLD_AVOPTIONS is 0) the audio bitrate as default for video > > also. > > > > > That's bad, and causes some fate failures. We can workaround that by > > > > > inverting the ordering of these two, but then, the general one > > _always_ > > > > > (even before FF_API_OLD_AVOPTIONS=0) takes precedence over the audio > > one, > > > > > so all fate results without explicit bitrate change from ab=128k to > > > > > ab=200k. (I'm working around that by making each fate test set > > bitrate > > > > > explicit where relevant.) > > > > > > > > > > > > > > Alternate suggestion: I don't mind if -ab gets a workaround in > > ffmpeg.c, > > > > > but I'd like to remove it from the libav* code. > > > > > > > > ffserver seems to have "ab" hardcoded in > > > > ffserver_config.c > > > > this will need some change too, i dont know the code so i dont know > > > > what needs to be done / if a simple change to "b" is sufficient > > > > it seems to work with "b" better than with "ab" though after > > > > FF_API_OLD_AVOPTIONS=0) > > > > > > > > > This is done now, so are you now OK with this? > > > > if people want to remove it and it doesnt break anything, yes > > > > ill add a workaround to ffmpeg.c so this doesnt break command > > lines which depend on the default audio bitrate > > > There's other ways to accomplish that. For example, we could add two "b" > entries in the AVOptions, one for video, one for audio (I don't think this > makes sense for other media types?), and assign a default value to each. > That still prevents the duplication in ffm header, but keeps media-specific > defaults. Maybe there's other ways also...
two "b" entries break fate, i did not investigate why [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
