On 08/16/2011 03:16 PM, Alex Converse wrote: > On Tue, Aug 16, 2011 at 11:50 AM, Alex Converse <alex.conve...@gmail.com> > wrote: >> On Tue, Aug 16, 2011 at 11:45 AM, Anton Khirnov <an...@khirnov.net> wrote: >>> >>> On Tue, 16 Aug 2011 11:36:23 -0700, Alex Converse <alex.conve...@gmail.com> >>> wrote: >>>> On Tue, Aug 16, 2011 at 1:33 AM, Anton Khirnov <an...@khirnov.net> wrote: >>>>> --- >>>>> avconv.c | 52 >>>>> ++++++++++++++++++++++++++------------------ >>>>> tests/codec-regression.sh | 4 +- >>>>> tests/fate.mak | 4 +- >>>>> tests/lavf-regression.sh | 20 ++++++++-------- >>>>> tests/regression-funcs.sh | 4 +- >>>>> 5 files changed, 47 insertions(+), 37 deletions(-) >>>>> >>>> >>>> Can you explain the motivation of this? >>> >>> It seems to sane to me to not reencode (if possible) unless the user >>> explicitly asked for it. Surely it's better than current insanely >>> low-quality defaults. >>>
I agree about the bitrate/quality defaults not being very useful, but that can be fixed by per-codec defaults and/or by somehow signalling the encoder to choose better values at codec init. >> Unfortunately copy is subtly broken in a lot of situations. >> > > Situations where it generates unexpectedly broken files by default: > > 1) places where we need the mp4_adtstoasc bsf (ADTS source, global > header container) > 2) places where we need the h264_mp4toannexb bsf > 3) places where we need the chomp bsf (zero padded audio in ASF) > 4) places where we lump codecs that are normally signaled individually > under one codec_id (e.g., PRORES (which we can't decode anyway right > now) to a lesser extent AAC). > > Places where this is a behavioral regression but avconv isn't > responsible for the breakage things: > 1) Broken bitstream features (all the workarounds in h263dec) > 2) Rarely used bitstream features. We can decode a lot of oddities and > borken files that many other deocders don't support. These are the > sort of features we never incude in our output (In AAC: PCE based > channel configurations, channel element reordering, CCEs, Main and LTP > profiles: none of these play on iTunes) > > Places where this does something that the user probably doesn't expect: > 1) avconv -i in.mp3 out.wav #user probably wants pcm_s16le not ACM +1. Having to put -acodec pcm_s16le when decoding to wav would be annoying. You can put almost any audio codec in wav, but people will want PCM 99% of the time. I agree with Alex on the IRC vs ML thing. I'm on vacation this week so I am checking email daily and have not been on IRC. -Justin _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
