[FFmpeg-devel] mpegvideo_parser outputs incomplete frames [with rough patch]

[Michael Niedermayer]

Hi

On Wed, Aug 29, 2007 at 05:23:39PM -0000, Wolfram Gloger wrote:
> Hi,
> 
> Looking for a sample for the effect of my last patch, I got
> sidetracked on the following more easily reproducible issue
> (I found this with many DVB files):
> 
> ========================================================================
> 1. Run "make test"
> 
> 2. "dd if=tests/data/b-libav.ts of=x.ts ibs=188 skip=100"
>    (this cuts off the initial packets and in particular the
>    initial video frame)
> 
> 3. ./ffmpeg_g -y -acodec copy -vcodec copy  -i x.ts x1.vob
>    this will result in the following error:
> ...
> Press [q] to stop encoding
> error, non monotone timestamps 39600 >= 39600
> frame=   25 fps=  0 q=0.1 Lsize=     344kB time=1.0 bitrate=2935.5kbits/s    
> 
> 4. Apply the appended patch and rebuild, then 3. won't show
>    the error any more.
> ========================================================================
> 
> The reason is that mpegvideo_parser only looks for the end of a frame,
> so if we, for example, start somewhere within a transport stream, it
> will return a partial (initial) frame, _and_ this will always (often
> wrongly) be considered as an I-frame.  Therefore, the timing
> calculations go wrong.
> 
> First I tried to fix this in ff_mpeg1_find_frame_end(), but that
> doesn't give the possibility to drop parsed data.  So it really needs
> to be fixed in the parser with some additional state.  The appended
> patch is mainly for demonstration, maybe there is an even cleaner
> solution.

its not the parsers job to drop damaged frames, this is _WRONG_ a decoder
might in principle be able to decode the truncated frame, (for example by
using the next frame to fill in the values for the missing headers and
guessing/bruteforcing the rest)

for the stream copy case the initial truncated frame should be droped
in the application doing the stream copy

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

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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/20070829/59118bc9/attachment.pgp>