On Thu, 2010-06-10 at 15:25 -0400, D. Hugh Redelmeier wrote:
> When I record an analogue signal using my Hauppauge HVR-1600, and pass
> it to ffmped, I get this diagnostic.
>
> Seems stream 0 codec frame rate differs from container frame rate: 59.94
> (60000/1001) -> 29.97 (30000/1001)
>
> I've seen this in lots of postings (including my own) but have not
> seen a reasonable explanation of why this happens. One reply I got
> suggested that the container has the field rate while the stream has
> the frame rate.
59.94 is indeed a field rate for 525-line/60 Hz interlaced color TV
systems. In that ffmpeg gripe, 59.94 is the "frame rate" likely stored
in the Video PES's MPEG-2 Sequence Header. No one in there right mind
actually generates full frames at 60 Hz, so putting a field rate in the
frame rate field may be a hint at interlaced video by the encoder.
The 29.97 Hz in the ffmpeg gripe, is ffmpeg measuring/guessing the frame
rate in the video stream by looking at the timestamps. I have no idea
how ffmpeg really makes that measurement. But NTSC Color TV frames will
come at
(4,500,000 sound carrier cycles/sec)
/ (286 sound carrier cycles/line)
/ (525 lines/frame)
= 29.97 frames/sec.
So its measurment is correct for full frames.
> Googling through the ffmpeg list, it seems that this comes up once in a
> while. They don't seem to answer people's questions on this anymore. But
> this message seems to make it clear that they would consider this a
> bug in whatever created the file.
>
> <http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2008-December/018095.html>
>
> The video container specifies a framerate, as does the video
> stream itself.
That's technically incorrect. ffmpeg is measuring the frame rate in the
video stream.
http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavformat/avformat.h;h=57a6bcec4a8480554d2ea593ba989b0bb00bb3e7;hb=HEAD#l411
(Note that the comment in that code is also not consistent: the
comment's example 50/1 = 90000/1800 is not the lowest frame rate,
90000/3600 = 25/1 is the lowest rate in the example.)
> In some cases, usually caused by badly written
> encoding programs, the two can disagree. When this happens,
> ffmpeg is obviously forced to believe one and not the other.
>
> Is ffmpeg wrong? I don't want to spend the Swiss Francs to buy the
> relevant standards to figure out who is right.
I can't tell if ffmpeg is wrong until you can tell me how ffmpeg is
making its measurment of frame rate and what assumptions go into that
measurement. I'd also need to get a copy of the MPEG-2 standard myself
to see what's permissible for certain fields and how the frame rate
field is to be interpreted when it is over 30 Hz.
> Is MythTV setting up the HVR-1600 incorrectly, causing this problem?
That is unlikely. There are a however number of MPEG encoder related
controls, that you may want to tweak with v4l2-ctl to see the effects.
I have a hard time seeing this as a serious problem. I'm assuming
playback happens properly given the presentation time stamps in every
PES header. What are the symptoms that you are experiencing aside from
an ffmpeg gripe?
> Is the cx18 driver wrong?
The driver only has two things it can tell the firmware about the video
to be encoded using the CX18_CPU_SET_VIDEO_IN firmware command: 0
meaning 29.97 frames/sec, or 1 meaning 25 frames/sec.
> Is the firmware wrong?
If we assume that ffmpeg is reading data out of the MPEG-2 headers
properly, then the firmware is using 59.94 Hz as a "frame rate", which
technically it is not. So maybe that is wrong. However, I also have
not spent the Swiss Francs on a copy of the MPEG-2 standard. It could
be the case that semantically the frame rate field is used for both
frame rates and field rates.
Fixing the problem likely means hacking the firmware - which I have no
plans to do - or asking Conexant to change the firmware - for which I'd
expect some throrough analysis of the output stream is required to show
the suspected non-compliance with the MPEG-2 standard.
Regards,
Andy
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
