[Ffmpeg-devel] Strange problem with H.264 video in MPEG2 TS...

[Måns Rullgård]

Luca Abeni said:
> Hi all,
>
> On Fri, 2006-01-20 at 11:48 +0100, Luca Abeni wrote:
> [...]
>> I am analysing the problem with the help of strace, and it seems that
>> the problem is due to the fact that sometimes read() from pipe returns
>> less bytes than the requested amount.
>> In other words, strace produces lines like
>> read(3, "\4oP\33\372\230\311#\30\26\243\207\340\2064\10\21\r\340"..., 8192)
>> = 6660
>>
>> I do not know why, but it seems that the mpeg1,2,4 decoders in ffmpeg
>> can correctly cope with this situation, but the h264 decoder cannot...
> After some investigation, I think that this is the problem: when read()
> returns less than the requested amount of bytes, libavformat cannot
> properly parse a TS containing H.264 video (it can properly parse a raw
> H.264 stream, or a TS containing MPEG1,2,4 video).
>
> If, instead, file_read() returns the requested amount of bytes (as when
> reading from a file) then libavformat can properly parse a TS containing
> H.264 video. As a proof, I developed the attached patch. It is not
> intented for inclusion (since I think that it just hides the real), but
> it is only a workarond... With the patch applied, ffmpeg can properly
> parse a TS containg H.264 video even if it is read from a named pipe.
>
> Now, I am trying to understand where the real bug is, but I am
> completely lost... I tried to look at libavformat internals, to
> understand how the fps is computed, but I still have no clue.
> Does anyone have any hint about how to identify the real bug? I do not
> know the libavformat internals very much, so a short summary about how
> the pts and dts fields are computed/assigned (with maybe a description
> of the codepath involved) would help a lot...

I'll look into it this evening.  Meanwhile, have you tested the x264 global
headers patch I suggested?

-- 
M?ns Rullg?rd
mru at inprovide.com