Recording length has doubled

[tahoward@…]

When I upgraded from svn 14021 to 14929, all my recordings started taking twice the amount of space they used to. My recording settings are still the same - mpeg4, 480x480, bitrate 2100 kbps scaled for frame size. My recordings used to take about .7 gb per hour, now they're about 1.4. This is happening on a bt848 card, with cable. I also have a PVR 500, and it's recordings take the same amount of size, but when I transcode them, they also take twice the space they used to.

I'm attatching nuvinfo output from 2 half hour shows, one recorded before the upgrade, and one after.

[rodago@…]

Replying to tahoward@nc.rr.com:

When I upgraded from svn 14021 to 14929, all my recordings started taking twice the amount of space they used to. My recording settings are still the same - mpeg4, 480x480, bitrate 2100 kbps scaled for frame size. My recordings used to take about .7 gb per hour, now they're about 1.4. This is happening on a bt848 card, with cable. I also have a PVR 500, and it's recordings take the same amount of size, but when I transcode them, they also take twice the space they used to.

I can confirm this issue. I'm using a PVR 150 on antenna input, and it's transcoding to a much bigger file size than it did before I ran an svn update earlier this month. Actually, my file size increase is about the same as the one mentioned above.

[tahoward@…]

I've been trying various svn versions, and this problem first occurs in 14799.

[michael bishop <clever@…>]

ive made a formula using mysql to output the real bitrate for all of my recordings when im set to record at 1100 the formula says the files wind up as 2200

i beleive it started at the ffmpeg sync near 14799/14800

it appears to affect all software encoding(framegrabbers+transcoding)

[Janne Grunau]

I'm a little bit lost here. I doesn't depend on the AVCodecContextOptions we use. I tried using the same as the commandline ffmpeg uses but got different bitrates.

A brief examination of the modifactions of mythtv's libavcodec showed nothing fishy.

[nswint@…]

I've noticed it as well and it looks like recordings that have closed captioning are about double the size after transcoding. It only loses .1 GB after transcoding whereas the recording. This is not happening on my bttv cards but recordings from my pvr-350 have that problem.

[bjm]

When I first noticed this, I saw that the file sizes varied dramatically. This made me wonder if the quality min and max where misbehaving. However, after several tests I found that cutting the bitrate in half resulted in a file size that I would expect for the full bitrate although it might not be exactly 2 to 1.

The reason the sizes varied is that with a bitrate twice the configured rate, "clean" signals with low motion would max out and fill the full bitrate.

So, my default profile is 528x480 scaled bitrate of 2700.

(2700 * 528 / 640) * 1024 / 8 bits = 285056bytes/sec.

Times 1800sec should be 513100800/half-hour

Times 3600sec should be 1026201600/hr

The sizes of some recent 30 minute recordings are 1033069233, 1029005950 and 1007334788.

This suggests that it may be a simple error where something is multiplied or divided by 2 somewhere.

This can be seen when recording MPEG4 with a bttv card but is probably easier to test by transcoding a test file to MPEG4.

[Janne Grunau]

it is reproduceable with mythtranscode

I fail to see where the cause might be.

the ffmpeg merge commit [14800] has no suspicious changes in libmythtv and I looked more than twice at the diff between our libav* and ffmpeg's of the last merged revision 11051 without noticing something remotely related.

[bjm]

It may take some divide and conquer to determine where the target bit rate first has an unexpected value. Another kind of suspect may be if bits are rolled one too many or one too few.

[Janne Grunau]

(In [16406]) Fix the double bit rate problem for software encoding

Reverting the effect of FFmpeg's changeset 10477 as workaround until NuppelVideoRecorder? sets proper pts.

Refs #4862, Refs #4240

[Janne Grunau]

(In [16407]) Merges revision [16406] from trunk: Fix the double bit rate problem for software encoding

Reverting the effect of FFmpeg's changeset 10477 as workaround until NuppelVideoRecorder? sets proper pts.

Refs #4862, Refs #4240

[bjm]

Verified workaround. Three 5:27 recordings of The Weather Channel:

mysql> select title, filesize from recorded;
...
| A (Manual Record)       |   171787461 |
| B (Manual Record)       |   103316671 |
| C (Manual Record)       |   195562085 |
+-------------------------+-------------+

Where:

"A" is pre- [16406] with 2700 @ 528x480 scaled bitrate.

"B" is post [16406] with 2700 @ 528x480 scaled bitrate.

"C" is post [16406] with 5400 @ 528x480 scaled bitrate.

[Shane Shrybman <gnome42@…>]

I believe the attached patch (mythtv_NVR_double_length_fix.diff) also fixes the double length problem.

It uses avcodec_get_frame_defaults() to initialize the AVFrame. avcodec_get_frame_defaults() memsets the structure and does pic->pts= AV_NOPTS_VALUE which eliminates the need for the workaround.

[Janne Grunau]

(In [21320]) set AVPicture.pts to AV_NOPTS_VALUE in NuppelVideoRecorder?. Fixes #4240

revert the workaround in [16406], Refs #4240