[FFmpeg-devel] [PATCH 2/3] RSD demuxer

[Paul B Mahol]

On 5/10/13, James Almer <jamrial at gmail.com> wrote:
> On 06/05/13 6:40 AM, Michael Niedermayer wrote:
>> On Mon, May 06, 2013 at 11:26:33AM +0200, Michael Niedermayer wrote:
>>> On Mon, Apr 22, 2013 at 04:40:42PM -0300, James Almer wrote:
>>>> +static int rsd_read_packet(AVFormatContext *s, AVPacket *pkt)
>>>> +{
>>>> +    AVCodecContext *codec = s->streams[0]->codec;
>>>> +    RSDDemuxContext *rsd  = s->priv_data;
>>>> +    int i, ret, size = 1024;
>>>> +
>>>> +    if (url_feof(s->pb))
>>>> +        return AVERROR_EOF;
>>>> +
>>>> +    if (codec->codec_id == AV_CODEC_ID_ADPCM_THP) {
>>>> +        uint8_t *dst;
>>>> +
>>>> +        if ((ret = av_new_packet(pkt, size)) < 0)
>>>> +            return ret;
>>>> +        if (!av_packet_new_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
>>>> 32))
>>>> +            return AVERROR(ENOMEM);
>>>> +        dst = pkt->side_data[0].data;
>>>> +        for (i = 0; i < 16; i++)
>>>> +            bytestream_put_be16(&dst, AV_RL16(rsd->table + i * 2));
>>>
>>> extradata is global data, AV_PKT_DATA_NEW_EXTRADATA is when "global"
>>> data changes due to concatenation of 2 streams with different global
>>> data.
>>> In this case here AVCodecContext->extradata should be used probably
>>
>> also consider remuxing rsd -> rsd
>> If you take the global extradata and put it in every packet then
>> the muxer would have to somehow proof that the data never changes
>> or risk failure (theres another demuxer where it can change so it
>> could get either kind of packets)
>>
>> and it would have to get the first packet to write the global table
>> in the header.
>> AVCodecContext.extradata simplifies that alot, the demuxer puts the
>> table in extradata, the muxer writes it again
>
> The reason why I'm using packet side data instead of global extradata is, as
>
> Paul mentioned, to avoid having to write a new decoder that will be
> adpcm_thp
> with some small changes just for this format and RedSpark.
>
> THP and BRSTM files store the table and/or the previous sample inside each
> frame, so in those cases the side data is different in each packet.
> RSD and RedSpark just send the table so the same decoder can be used.
>
> If adding a new decoder for RSD and Redspark to avoid storing the table in
> each packet's side data is preferred, then I have no problem doing that. I
> should be able to avoid duplicating too much code in adpcm.c.
> Also, we don't have any muxer that supports this adpcm codec, so at least
> for
> the time being that's not really a problem.
>
> Sorry for taking so long to reply. I lost track of this thread and only read
>
> what Paul replied in the others.

Well, you can add new type of packed side data.

Also "THP" decoder could do different things if there is extradata and
if there is no
extradata:

If there is no extradata than tables and previous samples are in
packet otherwise
use table from extradata and previous samples (from prev decoded frame).

This means that one set of files will be seekable and others not,
currently neither
demuxers implement seeking (it does not look so trivial).