[FFmpeg-devel] [PATCH] MJPEG: emulate EOI also on two consecutive SOI.

[Michael Niedermayer]

On Sat, Aug 27, 2011 at 07:40:40PM +0200, Reimar Döffinger wrote:
> On Sat, Aug 27, 2011 at 06:52:21PM +0200, Michael Niedermayer wrote:
> > On Sat, Aug 27, 2011 at 02:43:04PM +0200, Reimar Döffinger wrote:
> > > Fixes issue #362.
> > > 
> > > Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> > > ---
> > >  libavcodec/mjpegdec.c |    4 ++++
> > >  1 files changed, 4 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> > > index 6331e3d..57ce821 100644
> > > --- a/libavcodec/mjpegdec.c
> > > +++ b/libavcodec/mjpegdec.c
> > > @@ -1430,6 +1430,10 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx,
> > >  
> > >                      s->restart_count = 0;
> > >                      /* nothing to do on SOI */
> > > +                    if (s->got_picture) {
> > > +                        av_log(avctx, AV_LOG_WARNING, "EOI missing, emulating\n");
> > > +                        goto eoi_parser;
> > 
> > should that not jump to 3 lines earlier to emulate EOI fully ?
> 
> No idea, should it?
> The existing code to emulate EOI at the end of a buffer jumps to exactly
> that location.
> restart_interval is 0 anyway after SOI, so that break will not trigger
> in the normal case, and neither should it I think.

> Should the buggy_avid case skip the cur_scan = 0 code?

I dont think it should skip it


> Should cur_scan possibly be reset on every SOF anyway, or rather instead?

i think cur_scan should be reset and it possibly needs to be checked
somewhere, the code using it looks a bit risky

[...]

--
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110827/a7ad9cb6/attachment.asc>