Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#9126 closed defect (Fixed)

bogus seektables built for h.264 content

Reported by: gigem Owned by: beirdo
Priority: minor Milestone: 0.24
Component: MythTV - General Version: 0.24-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Bogus seektables are built for h.264 content when "mythcommflag --rebuild" or "mythtranscode --buildindex" are used. The problem has been seen by both stuartm and myself.

When mythcommflag --rebuild is used, the seektable is completely bogus. For example, no matter how long the recording actually is, mythtv thinks it is only around one or two minutes long.

When mythtranscode --buildindex is used on interlaced content, the result is mythtv thinks the recording is twice as long as it really is. For example, a 2.5 hour recording is reported as being 5 hours long.

Using mythtranscode --buildindex on progressive content appears to work correctly. Additionally, stuartm says the seektable generated by the recorder is correct. I am not currently able to test the recorder generated case.

Change History (11)

comment:1 Changed 9 years ago by robertm

Owner: set to Janne Grunau
Status: newassigned

comment:2 Changed 9 years ago by sphery

comment:3 Changed 9 years ago by beirdo

Owner: changed from Janne Grunau to beirdo
Status: assignedaccepted

comment:4 Changed 9 years ago by beirdo

Resolution: Fixed
Status: acceptedclosed

(In [27098]) Fix the H.264 seektable rebuild.

Turns out that the GetFrame?() would return for both top and bottom field (in 1080i) and the mythcommflagplayer would count each field as a frame, even though, internally, the seektable building had proper *frame* numbers. The fix was to propogate up correctly whether or not a new frame was found, and only count frames.

As the saving to database is done in chunks, after the first chunk is saved, the mythcommflagplayer's view of where the second chunk started didn't match reality, so it very happily saved empty chunks of the map to the DB, resulting in a very short recording length being seen as only the first chunk made it to the db.

This has been tested against HD-PVR generated H.264, and regression tested with MPEG2 recordings to make sure I didn't mess them up.

Fixes #9126

comment:5 Changed 9 years ago by beirdo

(In [27099]) Backport [27098] from trunk.

Fixes H.264 seektable rebuilds. See commit message on [27098] for more details.

Fixes #9126

comment:6 Changed 9 years ago by beirdo

Resolution: Fixed
Status: closednew

comment:7 Changed 9 years ago by beirdo

(In [27110]) Back out part of [27098] which actually broke the playback of 1080i and 480i H.264 in the process of fixing the seektable rebuild.

Refs #9126

comment:8 Changed 9 years ago by beirdo

(In [27111]) Back out part of [27099] which actually broke the playback of 1080i and 480i H.264 in the process of fixing the seektable rebuild.

Refs #9126

comment:9 Changed 9 years ago by beirdo

Now I need to fix the seektables again. Crap.

comment:10 Changed 9 years ago by beirdo

Resolution: Fixed
Status: newclosed

(In [27112]) Replaced uses of GetDecoder?() with decoder (it's internal to the base class, no need to use the external method). Also changed myFramesRead so instead of counting locally, read decoder->GetFramesRead?(), as the decoder is properly counting frames, and we are getting *fields* returned to us for H.264. Trying to count locally broke H.264 interlaced playback. This is a better way.

Fixes #9126 again, and without breaking playback this time.

comment:11 Changed 9 years ago by beirdo

(In [27113]) Backport of [27112] from trunk

Replaced uses of GetDecoder?() with decoder (it's internal to the base class, no need to use the external method). Also changed myFramesRead so instead of counting locally, read decoder->GetFramesRead?(), as the decoder is properly counting frames, and we are getting *fields* returned to us for H.264. Trying i to count locally broke H.264 interlaced playback. This is a better way.

Fixes #9126 again, and without breaking playback this time.

Note: See TracTickets for help on using tickets.