[FFmpeg-devel] [patch] mjpeg restart marker parsing

[Michael Niedermayer]

On Tue, Mar 30, 2010 at 03:20:48PM -0700, tom harper wrote:
> I updated the patch per patch check - can we start by getting the fix in for
> not checking the padding bytes and go from there?

I would prefer it without the next_restart_marker related code.
if you want we could print all restart marker values if
debug & FF_DEBUG_STARTCODE is set, but that should be a seperate patch


> 
> re: ff_er_add_slice() and ff_er_frame_end() - it seems like the ff_er api
> could be used but it would require a bit more study/testing, as I would have
> to simulate losing sets of blocks between markers- i don't have an example
> of this off hand.
> 
> Also the loop would need to be advanced by the estimated number of blocks
> lost, which would be wrong if we had cycled past more than mod 8 *
> restart_interval blocks, as far as I understand.

seems so, but loosing 8 or more consecutive slices seems somewhat
unlikely, especially if the whole frame contains less slices for example


>  If you didn't lose a set
> of blocks (i.e. bit error, huffman coding error) I think the code would
> basically exit.  So the safest (and easiest) thing to do would be to just
> bail and call ff_er_frame_end if the code exits before processing all of the
> blocks.  I don't know how useful it would be to recover slices w/o any
> examples.

you can use tools/trasher to damage some jpeg (that assumes you have one
with restart markers) this should do quite well for testing the codes
ability to continue from the next marker

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100331/bd881dab/attachment.pgp>