Lost video frames when decoding h264 stream

[Marcin]

Summary of the bug:

I'm trying to transcode h264 stream (DVB-T). It happens that properties of the input stream changes on the fly. Decoder automatically reinitializes context "[h264 @ 0xa29fae0] Reinit context to 720x576, pix_fmt: 0", but avcodec_decode_video2 starts loosing frames. First it looses significant number (around 40) of frames and than repeatedly returns one frame and skips three frames.

Problem is related to the avcodec it can be observed in ffmpeg, ffplay and custom applications.

Full report from ffmpeg and two examples of input (stream copy) are in the attachments.

How to reproduce:

% ffmpeg -i video_decoder-lost_frames_in_dvbt-example2.ts -acodec mp3 -vcodec mpeg4  -b 15000000 out2.mp4
Verified versions: 2.0, master, 1.2
Built on Ubuntu 12.04

[Marcin]

Report from ffmpeg

[Marcin]

Report from ffmpeg

[Marcin]

Media files uploaded to ftp server:
video_decoder-lost_frames_in_dvbt-example1.ts
video_decoder-lost_frames_in_dvbt-example2.ts

[Carl Eugen Hoyos]

How did you record the samples?
(Could you confirm that recording with cat /dev/dvb/adapter0/dvr0 >recording.ts allows to reproduce the problem?)

[Marcin]

The dvb-t stream is broadcasted (by AVerCaster Pro RS3421) in the local network. There is no transcoding before broadcasting.
The samples are recorded as a stream dump with simple command:
ffmpeg -i udp://xxx.xxx.xxx.xxx:1234 -acodec copy -vcodec copy outfile.ts

[Carl Eugen Hoyos]

Isn't there a command to save the udp stream into a file (without using FFmpeg)?
Do you have the possibility to save the stream instead of broadcasting it via udp?

[Marcin]

We tried to save/dump the stream with mplayer:
mplayer -dumpstream -dumpfile ... but the result is the same as in ffmpeg case.

We have some dvb-t cards, so we'll try to record the stream directly from the cards.

[Michael Niedermayer]

ffplay 0.8.14 plays video_decoder-lost_frames_in_dvbt-example1.ts better than master.
someone should bisect to find out which revission introduced the problems

[Carl Eugen Hoyos]

Regression since a64b028.

[Michael Niedermayer]

Fixed by 3c9dd93faa9f3c250428dd0548c075583aa07cc3