Mailing List Archive: ivtv: devel

CX18: ffmpeg -i says: Seems stream 0 codec frame rate differs from container frame rate: 59.94 (60000/1001) -> 29.97 (30000/1001)

Index | Next | Previous | View Threaded

hugh at mimosa

Jun 10, 2010, 12:25 PM

Post #1 of 4 (4223 views)
Permalink

CX18: ffmpeg -i says: Seems stream 0 codec frame rate differs from container frame rate: 59.94 (60000/1001) -> 29.97 (30000/1001)

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.

I'm running Ubuntu 10.4 AMD64 with Mythbuntu packages. I'm using a
driver fetched from <http://linuxtv.org/hg/v4l-dvb> on June 6 (but it
has happened with all the previous versions that I've fetched).

I used this as a guide to setting up the HVR-1600 in MythTV:
<http://www.mythtv.org/wiki/Hauppauge_HVR-1600>
The firmware in /lib/firmware/ matches a freshly fetched set from
<http://linuxtv.org/downloads/firmware/>

Originally I reported this problem the the MythTV Users' list. But
now I've tested with a simple dd from the tuner card:
dd if=/dev/video1 of=junk.mpeg
I interrupted this after a little bit and then examined the result.
ffmpeg gives the diagnostic on that file. (The card was initialized by
previous MythTV recording activities.)

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. 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.

Is MythTV setting up the HVR-1600 incorrectly, causing this problem?

Is the cx18 driver wrong?

Is the firmware wrong?

Futher details of my system here:
<http://www.mythtv.org/pipermail/mythtv-users/2010-June/290280.html>
<http://www.mythtv.org/pipermail/mythtv-users/2010-May/288527.html>

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

mark.paulus at verizonbusiness

Jun 10, 2010, 12:41 PM

Post #2 of 4 (4137 views)
Permalink

Re: CX18: ffmpeg -i says: Seems stream 0 codec frame rate differs from container frame rate: 59.94 (60000/1001) -> 29.97 (30000/1001) [In reply to]

--
Mark Paulus
2424 Garden of the Gods Rd | Phone: v622-5578 / 719-535-5578
0419/117 - LEC Access ; C1-1207 | FAX: 719-535-7060
Colorado Springs, CO 80919
AIM : mgpaulus1 / sametime : mark.paulus [at] vzb
> -----Original Message-----
> From: ivtv-devel-bounces [at] ivtvdriver [mailto:ivtv-devel-
> bounces [at] ivtvdriver] On Behalf Of D. Hugh Redelmeier
> Sent: Thursday, June 10, 2010 1:25 PM
> To: ivtv-devel [at] ivtvdriver
> Subject: [ivtv-devel] CX18: ffmpeg -i says: Seems stream 0 codec frame
> rate differs from container frame rate: 59.94 (60000/1001) -> 29.97
> (30000/1001)
>
> 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.
>
> I'm running Ubuntu 10.4 AMD64 with Mythbuntu packages. I'm using a
> driver fetched from <http://linuxtv.org/hg/v4l-dvb> on June 6 (but it
> has happened with all the previous versions that I've fetched).
>
> I used this as a guide to setting up the HVR-1600 in MythTV:
> <http://www.mythtv.org/wiki/Hauppauge_HVR-1600>
> The firmware in /lib/firmware/ matches a freshly fetched set from
> <http://linuxtv.org/downloads/firmware/>
>
> Originally I reported this problem the the MythTV Users' list. But
now
> I've tested with a simple dd from the tuner card:
> dd if=/dev/video1 of=junk.mpeg
> I interrupted this after a little bit and then examined the result.
> ffmpeg gives the diagnostic on that file. (The card was initialized by
> previous MythTV recording activities.)
>
> 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. 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.
>
> Is MythTV setting up the HVR-1600 incorrectly, causing this problem?
>
> Is the cx18 driver wrong?
>
> Is the firmware wrong?
>
> Futher details of my system here:
> <http://www.mythtv.org/pipermail/mythtv-users/2010-June/290280.html>
> <http://www.mythtv.org/pipermail/mythtv-users/2010-May/288527.html>

What about installing M$ Windows on that machine, or moving the card
to a M$ Windows machine, and make a recording there? Then you can run
ffmpeg against that file and see if it's the card or firmware.

>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel [at] ivtvdriver
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

awalls at md

Jun 10, 2010, 6:30 PM

Post #3 of 4 (4148 views)
Permalink

Re: CX18: ffmpeg -i says: Seems stream 0 codec frame rate differs from container frame rate: 59.94 (60000/1001) -> 29.97 (30000/1001) [In reply to]

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
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

hugh at mimosa

Jun 14, 2010, 10:52 PM

Post #4 of 4 (4102 views)
Permalink

Re: CX18: ffmpeg -i says: Seems stream 0 codec frame rate differs from container frame rate: 59.94 (60000/1001) -> 29.97 (30000/1001) [In reply to]

| From: "Paulus, Mark G" <mark.paulus [at] verizonbusiness>

| What about installing M$ Windows on that machine, or moving the card
| to a M$ Windows machine, and make a recording there? Then you can run
| ffmpeg against that file and see if it's the card or firmware.

Good suggestion. With some effort, I switched the card to a machine
with a Vista installation, installed the card and played.

The recording by Vista's recorder also had the same characteristic:
ffmpeg made the same complaint.

| From: Chris Kennedy <ivtv [at] groovy>

| I think this is because the MPEG2 is interlaced and so technically
| holding 60 half frames but displayed as 30~ whole frames per second.
| Actually ffmpeg will give you this error from files it has created
| itself, like asf/wmv1/wmav2 do this.
|
| Newer versions of ffmpeg don't output the message for the MPEG2 produced
| by the cx3241X chips, older ffmpeg's didn't always calculate this
| correctly because of the interlaced nature of the MPEG.

That too seems to be true. I built an ffmpeg from the development
tree and did not get that message. Too bad that the version in Ubuntu
10.04 isn't that new.

| From: Andy Walls <awalls [at] md>

| On Thu, 2010-06-10 at 15:25 -0400, D. Hugh Redelmeier wrote:

| > 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.)

Very interesting! Thanks for sussing this out.

| > 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?

My real problem is my MythTV recordings are failing to play back on
various devices that claim to be able to play back MPEG-2 recordings.
Since they don't really say *why* they are unhappy, I'm grasping at
any anomallies that I do find. This message from ffmpeg was one.

You can see more about my problems here:
<http://www.mythtv.org/pipermail/mythtv-users/2010-May/288527.html>
<http://www.mythtv.org/pipermail/mythtv-users/2010-June/290280.html>
(The second is the same thread but the "next" link doesn't cross month
boundaries.)

| > 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.

Sounds hard to get wrong.

| > 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.

Yeah.

A cheap hack would be to find what bits to zap in a particular
recording and then try the result on some ot the players.

Thanks!

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads