[Ffmpeg-devel] [PATCH] THP PCM decoder (GSoC Qualification)

[Marco Gerards]

Michael Niedermayer <michaelni at gmx.at> writes:

Hi,

> On Mon, Apr 02, 2007 at 07:24:49PM +0200, Marco Gerards wrote:
>> Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
> [...]
>> >> [...]
>> >> +    }
>> >> +    else {
>> >> +       ret = av_get_packet(pb, pkt, thp->audiosize);
>> >> +       if (ret != thp->audiosize) {
>> >> +          av_free_packet(pkt);
>> >> +          return AVERROR_IO;
>> >> +       }
>> >> +      pkt->stream_index = thp->audio_stream_index;
>> >> +      thp->audiosize = 0;
>> >> +      thp->frame++;
>> >
>> > Can't seek be avoided now ? Does audio follow video in data stream ? If
>> > so Im wondering if reading video + audio in the same time, using buffer
>> > then output audio after, would not be cleaner and simpler.
>> 
>> It's convenient that I can make a video and audio packet and read
>> simultaneously.  I think the code otherwise will get more complex.  Do
>> you think it is worth the complexity and reading everything at once?
>> 
>> I do not think seeking can be avoided.  Some data follows the frame,
>> it is not documented.  So there is a gap between the total framesize
>> and the image+audio size.
>
> how does that extra data look ? (iam just curious ...)

Urgh.  It was my mistake, I was printing the wrong values while I was
debugging this code.  I take it back, there is no extra data...  I
shouldn't code after studying for over 8 hours...

> [...]
>> Index: libavcodec/adpcm.c
>> ===================================================================
>> --- libavcodec/adpcm.c	(revision 8597)
>> +++ libavcodec/adpcm.c	(working copy)
>> @@ -442,6 +442,8 @@
>>      switch(avctx->codec->id) {
>>      case CODEC_ID_ADPCM_IMA_QT: /* XXX: can't test until we get .mov writer */
>>          break;
>> +    case CODEC_ID_ADPCM_THP:
>> +        break;
>>      case CODEC_ID_ADPCM_IMA_WAV:
>>          n = avctx->frame_size / 8;
>
> what is this good for?

I thought Baptiste meant I had to do this to skip the encoding.  I
assume it is wrong, so I will remove it.

I will fix my patch according to your comments and resubmit it
tomorrow.

--
Marco