[FFmpeg-devel] [PATCH] Mobotix .mxg demixer and MxPEG decoder basic implementation
Anatoly Nenashev
nenashev_as
Wed Aug 11 19:22:48 CEST 2010
On 11.08.2010 20:13, Michael Niedermayer wrote:
>
>> diff -r 02ffe42e2ae2 libavcodec/mjpeg_parser.c
>> --- a/libavcodec/mjpeg_parser.c Sun Aug 01 14:52:28 2010 +0400
>> +++ b/libavcodec/mjpeg_parser.c Tue Aug 10 23:42:47 2010 +0400
>> @@ -26,6 +26,7 @@
>> * MJPEG parser.
>> */
>>
>> +#include "libavutil/intreadwrite.h"
>> #include "parser.h"
>>
>>
>>
>
>> @@ -70,6 +71,22 @@
>> return END_NOT_FOUND;
>> }
>>
>> +static int64_t mxpeg_get_timestamp(const uint8_t *buf, int buf_size)
>> +{
>> + int i;
>> + uint16_t state = 0;
>> + int64_t dts = AV_NOPTS_VALUE;
>> + for (i = 0; i< buf_size - 18; ++i) {
>> + state = (state<<8) | buf[i];
>> + if ((state == 0xFFFE)&& (AV_RL32(buf+i+3) == MKTAG('M','X','F',0))) {
>> + dts = av_rescale(AV_RL64(buf+i+11), 1, 10000);
>> + break;
>> + }
>> + }
>> +
>> + return dts;
>> +}
>>
> this looks wrong and inefficient
> i dont belive scaning the buffer like this is the correct way
>
>
>
Ok. I will reimplement this code. But it works on test data :-)
>> diff -r 02ffe42e2ae2 libavcodec/mjpegdec.c
>> --- a/libavcodec/mjpegdec.c Sun Aug 01 14:52:28 2010 +0400
>> +++ b/libavcodec/mjpegdec.c Tue Aug 10 23:42:47 2010 +0400
>> @@ -331,18 +331,28 @@
>> s->avctx->pix_fmt = PIX_FMT_GRAY16;
>> }
>>
>> - if(s->picture.data[0])
>> - s->avctx->release_buffer(s->avctx,&s->picture);
>> + if (CODEC_ID_MXPEG == s->avctx->codec_id) {
>> + if (s->avctx->reget_buffer(s->avctx,&s->picture)< 0) {
>>
> this makes double buffering with direct rendering impossible
>
>
>
Well, I'm not agree or there is something I don't understand. By my
opinion reget_buffer do 3 things:
1) create new buffer
2) copy data from old buffer to new buffer
3) release old buffer
Decoder is the owner of a picture thus no one must destroy or trash
picture outside the call of ff_mjpeg_decode_frame.
On the other hand decoder will lost the owning of old picture after
reget_buffer call (or release_buffer).
I can't see any problem with delayed direct rendering.
>
>> @@ -1026,6 +1044,12 @@
>> if(8*len + get_bits_count(&s->gb)> s->gb.size_in_bits)
>> return -1;
>>
>> + /* skip MXPEG audio data*/
>> + if ((s->avctx->codec_id == CODEC_ID_MXPEG)&& (s->start_code == APP13)) {
>> + skip_bits(&s->gb, (len-2)<< 3);
>> + return 0;
>> + }
>>
> how does the audio data reach the video decoder?
> this just looks like the demuxer is wrongly implemented
>
> [...]
>
>
On the other hand APP13 is valid marker for JPEG format. So, there no
need to extract this data from video stream.
Also rejecting audio data from video stream will reduce the performance.
Anatoly.
More information about the ffmpeg-devel
mailing list