[FFmpeg-devel] H.264: passing 2 fields at once to avcodec_decode_video() gives errors

[Reinhard Nissl]

Hi,

once again, I have some trouble using ffmpeg through xine-lib.
When I pass field data in separate calls to
avcodec_decode_video(), everything is fine. Some debug output shows:

***** 1st field *****

xxx NAL 9 at 3/254860 length 1


xxx NAL 7 at 9/254860 length 42


xxx NAL 8 at 58/254860 length 5


xxx NAL 6 at 68/254860 length 79


xxx NAL 5 at 154/254860 length 254704


consumed size: 254860, got_picture: 0



***** 2nd field *****

xxx NAL 9 at 3/56934 length 1


xxx NAL 6 at 9/56934 length 10


xxx NAL 1 at 25/56934 length 56907


consumed size: 56934, got_picture: 296



***** 3rd field *****

xxx NAL 9 at 3/10431 length 1


xxx NAL 6 at 9/10431 length 68


xxx NAL 1 at 84/10431 length 10344


consumed size: 10431, got_picture: 0



***** 4th field *****

xxx NAL 9 at 3/9104 length 1


xxx NAL 6 at 9/9104 length 10


xxx NAL 1 at 26/9104 length 9076


consumed size: 9104, got_picture: 0



When I pass almost (see below for details) the same data from
above of two fields in a single call to avcodec_decode_video(),
the output looks like that:

***** 1st and 2nd field *****

xxx NAL 9 at 4/311794 length 1

xxx NAL 7 at 10/311794 length 42

xxx NAL 8 at 59/311794 length 5

xxx NAL 6 at 69/311794 length 79

xxx NAL 5 at 155/311794 length 254704

xxx NAL 9 at 254864/311794 length 1

xxx NAL 6 at 254870/311794 length 10

xxx NAL 1 at 254886/311794 length 56907

[h264 @ 0x105a500]Missing reference picture

[h264 @ 0x105a500]left block unavailable for requested intra4x4
mode -1 at 0 0
[h264 @ 0x105a500]error while decoding MB 0 0, bytestream (-3)

consumed size: 311794, got_picture: 296


***** 3rd and 4th field *****

xxx NAL 9 at 4/19535 length 1

xxx NAL 6 at 10/19535 length 68

xxx NAL 1 at 85/19535 length 10344

[h264 @ 0x105a500]B picture before any references, skipping

[h264 @ 0x105a500]decode_slice_header error

xxx NAL 9 at 10435/19535 length 1

xxx NAL 6 at 10441/19535 length 10

xxx NAL 1 at 10458/19535 length 9076

[h264 @ 0x105a500]B picture before any references, skipping

[h264 @ 0x105a500]decode_slice_header error

consumed size: 19535, got_picture: 0


As you can see, NAL length is the same in both cases, just offset
is off by one. This is due to different preprocessing steps
before data is passed to xine-lib. The data is equal besides a
single 0 byte that appears at a different location. E. g. when []
encompass the data passed to a single call of
avcodec_decode_video(), the first case looks like that:

[00 00 01 ... 00][00 00 01 ... 00][00 00 01 ... 00][00 00 01 ... 00]

And the second case looks like that:

[00 00 00 01 ... 00 00 00 01 ...][00 00 00 01 ... 00 00 00 01 ...]

Besides this 0 byte, the passed data is the same.

I wonder why I get a totally different behavior in the second
case. As I only get a picture after passing two fields of the
picture I do not see why it shouldn't work to pass both fields
into a single call. And I don't think that the 0 byte issue
matters as it yields the same NAL lengths.

Some more information regarding the different data of the two
cases. Originally the data exists as a TS file. In the second
case, xine-lib's demux_ts takes care to extract the PES payload.
Whenever it sees the payload unit start indicator on a TS packet,
it sends the so far accumulated data to the decoder.

In the first case, the TS file's content goes through VDR's
cVideoRepacker which detects frame or field boundaries. Later,
field data (in the above example) is sent to the decoder. VDR's
repacker can only detect start codes of the form 00 00 01 xx.
That's why the leading 0 byte compared to second case is missing
in front of the field data and appears as tail of the previous
field. I know that start codes like 00 00 00 01 xx have a certain
meaning in H.264, but the strange thing is, that the mangled
version works properly (case 1) while the other one doesn't.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de