Opened 12 years ago

Closed 10 years ago

#4240 closed defect (fixed)

Recording length has doubled

Reported by: tahoward@… Owned by: Janne Grunau
Priority: minor Milestone: 0.22
Component: mythtv Version: head
Severity: high Keywords:
Cc: Ticket locked: no

Description

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.

Attachments (3)

nuvinfo.single (952 bytes) - added by tahoward@… 12 years ago.
nuvinfo.double (952 bytes) - added by tahoward@… 12 years ago.
mythtv_NVR_double_length_fix.diff (696 bytes) - added by Shane Shrybman <gnome42@…> 11 years ago.

Download all attachments as: .zip

Change History (20)

Changed 12 years ago by tahoward@…

Attachment: nuvinfo.single added

Changed 12 years ago by tahoward@…

Attachment: nuvinfo.double added

comment:1 Changed 12 years ago by Janne Grunau

Milestone: unknown0.21
Owner: changed from Isaac Richards to Janne Grunau
Status: newassigned

comment:2 in reply to:  description Changed 12 years ago by 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.

comment:3 Changed 12 years ago by tahoward@…

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

comment:4 Changed 12 years ago by 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)

comment:5 Changed 12 years ago by Janne Grunau

Status: acceptedstarted

comment:6 Changed 12 years ago by Janne Grunau

Status: startedassigned

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.

comment:7 Changed 11 years ago by 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.

comment:8 Changed 11 years ago by Janne Grunau

Priority: majorblocker

comment:9 Changed 11 years ago by 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.

comment:10 Changed 11 years ago by 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.

comment:11 Changed 11 years ago by 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.

comment:12 Changed 11 years ago by 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

comment:13 Changed 11 years ago by Janne Grunau

Milestone: 0.210.22
Priority: blockerminor

comment:14 Changed 11 years ago by 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

comment:15 Changed 11 years ago by 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.

comment:16 Changed 11 years ago by 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.

Changed 11 years ago by Shane Shrybman <gnome42@…>

comment:17 Changed 10 years ago by Janne Grunau

Resolution: fixed
Status: assignedclosed

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

revert the workaround in [16406], Refs #4240

Note: See TracTickets for help on using tickets.