On 16 August 2011 21:16, Alex Converse <alex.conve...@gmail.com> 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. >>> >> >> 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).
Can these situations be covered by some requirement of the bitstream format and automagic selection or avoidance of the usage of the bsf for relevant mappings? > 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) This is indeed more tricky to do automatically without explicitly identifying those properties and acting accordingly. And even then some properties might be unknown or not yet have detection implemented. Bleh. > 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 > 2) avconv -i in.y4m out.mkv #user probably doesn't want to slap on mkv > header on uncompressed input I personally think using command lines like this under-specifies what avconv should do and would prefer mandatory explicit specification of the target format. I recognise that users might have other expectations and want to write a shorter command line or not have to think about what the command could do and expect it to do what they want it to do. Those two seem to suggest that perhaps for some container formats there is a general acceptance that they would normally contain uncompressed or compressed streams. Mapping such somehow would cause inconsistency, but perhaps it would improve usability for what people might expect anyway. Are people more strongly tied to expectations on file formats or to consistency of operation? Best regards, Rob _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
