1. 20 Mar, 2012 2 commits
  2. 19 Mar, 2012 2 commits
  3. 18 Mar, 2012 1 commit
  4. 17 Mar, 2012 1 commit
  5. 14 Mar, 2012 2 commits
  6. 12 Mar, 2012 1 commit
  7. 05 Mar, 2012 3 commits
    • Justin Ruggles's avatar
      lavf: Use av_get_audio_frame_duration() in get_audio_frame_size() · 6c65cf58
      Justin Ruggles authored
      Also, do not give AVCodecContext.frame_size priority for muxing.
      
      Updated 2 FATE references:
      dxa-feeble - adds 1 audio frame that is still within 2 seconds as specified
                   by -t 2 in the FATE test
      wmv8-drm-nodec - durations are not needed. previously they were estimated
                       using the packet size and average bit rate.
      6c65cf58
    • Justin Ruggles's avatar
      aiffdec: do not set AVCodecContext.frame_size · 8d1a20aa
      Justin Ruggles authored
      It is unnecessary. Also, for some codecs we're reading more than 1 frame per
      packet. Instead we use a private context variable to calculate the bit rate,
      stream duration, and packet durations.
      
      Updated FATE seek test, which has slightly different timestamps due to a
      more accurate bit rate calculation.
      8d1a20aa
    • Anton Khirnov's avatar
      lavf: deobfuscate read_frame_internal(). · 27c7ca9c
      Anton Khirnov authored
      Split off packet parsing into a separate function. Parse full packets at
      once and store them in a queue, eliminating the need for tracking
      parsing state in AVStream.
      
      The horrible unreadable loop in read_frame_internal() now isn't weirdly
      ordered and doesn't contain evil gotos, so it should be much easier to
      understand.
      
      compute_pkt_fields() now invents slightly different timestamps for two
      raw vc1 tests, due to has_b_frames being set a bit later. They shouldn't
      be more wrong (or right) than previous ones.
      27c7ca9c
  8. 04 Mar, 2012 1 commit
  9. 03 Mar, 2012 5 commits
  10. 02 Mar, 2012 4 commits
    • Martin Storsjö's avatar
      g722: Fix the QMF scaling · b087ce2b
      Martin Storsjö authored
      This fixes clipping if the encoder input used the full 16 bit
      input range (samples with a magnitude below 16383 worked fine).
      The filtered subband samples should be 15 bit maximum, while
      the code earlier produced them scaled to 16 bit.
      
      This makes the decoder output have double the magnitude
      compared to before.
      
      The spec reference samples doesn't test the QMF at all, which
      was why this part slipped past initially.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      b087ce2b
    • Anton Khirnov's avatar
      electronicarts: set timebase for tgv video. · efec3bc6
      Anton Khirnov authored
      The container has no timestamps and the framerate isn't stored in the
      data either.
      The decoder sets codec timebase to experimentally found value 1/15. Do
      the same for the demuxer too, it should at least be better than the
      default 1/90000.
      efec3bc6
    • Anton Khirnov's avatar
      e39400c3
    • Anton Khirnov's avatar
      electronicarts: don't set codec timebase · 1d3144c3
      Anton Khirnov authored
      Demuxers are not supposed to set it.
      Set stream timebase and framerates instead (this is a cfr container with
      no timestamps).
      1d3144c3
  11. 29 Feb, 2012 6 commits
  12. 27 Feb, 2012 1 commit
  13. 26 Feb, 2012 3 commits
  14. 25 Feb, 2012 1 commit
  15. 22 Feb, 2012 1 commit
  16. 21 Feb, 2012 4 commits
  17. 20 Feb, 2012 1 commit
    • Justin Ruggles's avatar
      adpcmenc: Use correct frame_size for Yamaha ADPCM. · 770a5c6d
      Justin Ruggles authored
      Output packet size should match avctx->block_align. The target output packet
      size is 1024 bytes.
      Before:
      mono   - 1024 samples -> 512 bytes
      stereo - 2048 samples -> 2048 bytes
      After:
      mono   - 2048 samples -> 1024 bytes
      stereo - 1024 samples -> 1024 bytes
      770a5c6d
  18. 16 Feb, 2012 1 commit
    • Justin Ruggles's avatar
      bethsoftvid: synchronize video timestamps with audio sample rate · c9fdf324
      Justin Ruggles authored
      According to unofficial documentation, the video rate is locked to the audio
      sample rate. This results in proper synchronization of audio and video
      timestamps from the demuxer. This only works if the first audio packet occurs
      before the first video packet or the audio sample rate is the default rate of
      11111 Hz, both of which are true for all samples in our archive.
      c9fdf324