[Ffmpeg-devel] Function to parse encoded frame for macroblocks (was: which codecs support rtp_callback)

[leon zadorin]

I would probably be just as happy if there was a utility to parse
encoded frame and issue a callback whenever a macroblock is found -
this way even if the encoder did not support macroblock-delimited
encoding process there would be a way to find out where macroblocks
"live" in a given frame data... is there such function in ffmpeg (e.g.
libavcodec, libavutil, libavformat, ... etc.)?

Why would I want one?

I have H263 hanging on me (for about 10 to 20 seconds with 100% cpu
usage) somewhere in the:

h263_decode_gob_header called from
ff_h263_resync called from
ff_h263_decode_frame

I used to allow incomplete encoded frames (i.e. some large artibtrary
areas of data were missing in the encoded buffer, those areas were
effectively containing some arbitrary data such as contents of
previous frames, etc. - those holes were not aligned to any boundaries
of macroblocks, etc., just "random" locations with "random" data). The
frames are reasonably large in size (e.g. 704x576) and I figured H263
decoder was "looping in a hole" a lot because it was trying to sieve
for the right data to begin.

So perhaps the best thing would be to try to not include the holes
(e.g. the UDP packets which were lost during transmission process from
encoder to decoder) but rather join the received packets together...
and even better thing would be to make sure that transmitted UDP
packets contained whole number of macroblocks, this way if some packet
is missing at least the one preceeding it will be able to decode ok
(as it will not potentially have a half of the last macroblock in its
payload and possibly cause decode to "sieve" through the bits of the
last, partial macroblock data eating away at CPU)...

The second best option, I guess, would be to join the arrived packets
AND live with "incomplete/teared" macroblocks potentially present at
the end of every UDP packet. [i presume that H263 going into a heavy
loop is not a bug but rather a feature/fact-of-life when trying to
recover in a corrupted bitstream]...

I realise that rtp_callback does just that (i.e. allows one to have an
integral number of macroblocks in any given payload) but would like to
extend the whole network transmission to streams generated by hardware
encoders (e.g. from firewire hdv cameras) where incoming-from-camera
(already encoded) stream (e.g. MPEG2) still needs to be parsed for
macroblocks in order to ensure correct payload "boundary" for UDP
transmission where every UDP packet has an integral number of
macroblocks (or am I missing something... I think I am :-)

Also, rtp_callback is supported on H263, but I would like to establish
single, consisten transportation code for my application which would
be able to accept any macroblock-based encoded frame (i.e. support
codecs other than MPEG/H263... like may be DV... or is it not
macroblock based?)

Kind regards,
Leon.