<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 2018-11-21 3:40 p.m., Jaka Bac
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPQ1XRG5FSQcA2_SJDWv2sZHJ9W3C8=h5F_=UV9iGPE8AUhHnw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">Hi Jon,
            <div class="gmail_quote">
              <div><br>
              </div>
              <div>The decode example here: <a
                  href="https://www.ffmpeg.org/doxygen/trunk/decode_audio_8c-example.html"
                  moz-do-not-send="true">https://www.ffmpeg.org/doxygen/trunk/decode_audio_8c-example.html</a></div>
              <div>uses the new API.</div>
              <div><br>
              </div>
              <div>But you have to be aware that it does not involve
                libavformat for demuxing and it expects the "raw"
                bitstream for the specified codec, if you are opening a
                file which has a wrapper, you should use libavformat to
                first extract the packets and then just send the packets
                to the codec.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p>Hi Jaka,</p>
    <p>That was the issue...I was sending the decoder a container and
      not the raw bitstream.  I guess I assumed av_parse_parse2() would
      demux.</p>
    <p>I tried the old api demux and decode example....</p>
    <p><a class="moz-txt-link-freetext" href="https://www.ffmpeg.org/doxygen/trunk/demuxing_decoding_8c-example.html">https://www.ffmpeg.org/doxygen/trunk/demuxing_decoding_8c-example.html</a></p>
    <p>Should I be able to send a wav file to this example and get
      correct output (it maybe expects video+audio)?</p>
    <p>./example input.wav video.mkv output.wav</p>
    <p>The output is distorted.  When I compare input.wav and output.wav
      (beginning of each attached) they are identical until offset /
      position 0x82C.  The input is a 440Hz sine wave, so it is easy to
      see the periodic data in the hex viewer.  It looks like every so
      often the output stream skips over parts of the sign wave (at for
      example offset / position 0x82C).  Maybe the decoder is doing some
      time re-synchronization?  My application is audio only and has the
      same behavior if I use the new or old apis.  I thought I could use
      the example to compare against to see where I went wrong.<br>
    </p>
    <p>built on Debian 9.....</p>
    <p>gcc example.c -lavcodec -lavformat -lavutil -o example<br>
    </p>
  </body>
</html>