[Ffmpeg-devel] Strange problem with H.264 video in MPEG2 TS...
Fri Jan 20 12:32:00 CET 2006
Luca Abeni said:
> Hi M?ns,
> On Fri, 2006-01-20 at 10:10 +0000, M?ns Rullg?rd wrote:
>> > So, summing up, it seems that the problem is limited to H.264 video in
>> > MPEG2TS when the input is read from a pipe...
>> > Any ideas?
>> It looks like you are using the latest x264 version and a slightly older
>> ffmpeg. Update both to the very latest.
> Thanks for the tip. However, I am already using ffmpeg from today's CVS.
> I am using a 2-week old x264, so I'll try to update it.
A couple of days ago I corrected the frame rate encoding in x264 to match
the standard (several vendors misread those specs, so we're in good company).
I made the corresponding change to lavc, with a workaround for streams
encoded with old x264 versions. Old lavc versions will get the framerate
from new x264 wrong, but on second thoughts it would report twice the correct
rate, not half as you are seeing. Could you try it with raw H.264 files?
That should remove any interference from container timestamps or frame rate
specifications. If you could post a few samples that would be great too.
Maybe the x264 version detection is failing for some reason. Did the problem
show up only in the last few days?
> However, I think the problem is somewhere else, since ffmpeg can
> correctly parse MPEG2 TS containing H.264 video, if they are read from
> file (and not from a pipe).
This could be because (I think) lavf reads a few frames and computes the
frame rate from the timestamps if it is reading from a file.
> 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) =
> 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...
> I am still investigating this stuff, so I might be wrong.
This should be handled invisibly by the file reader.
mru at inprovide.com
More information about the ffmpeg-devel