[mythtv-users] Seek broken after transcode from MPEG4

[Steve Briggs]

Problem: After transcode MPEG-4 -> MPEG-4 or RTJPEG, seeking no longer works.

Setup
Fedora Core 4, with Myth 0.18.1-114 from atrpms
2 backends, both with Hauppauge WinTV / Bt878 capture cards
multiple frontends, including a frontend on each backend

I record to MPEG-4 with auto commercial flagging,
then transcode to MPEG-4 to save disk space
After transcoding, seeking no longer works properly
In addition, I've discovered that the error occurs independent
of commercial flagging -- transcoding an unflagged file
gives the same problem.

I get the following errors from mythfrontend when seeking:
  0 length seek table
  [mpeg4 @ 0x4d415b4]warning: first frame is no keyframe
and in the logs for mythfrontend:
  Video timecode = 1740
  DoFastForward: Not enough info in positionMap, we need frame \
     2628 but highest we have is 1740
  SyncPositionMap prerecorded, from DB: 58 entries
  DoFastForward: Still Not enough info in positionMap, we need \
    frame 2628 but highest we have is 1740.  Will seek frame-by-frame
The picture then freezes while it seeks forward; in the log it
runs through all the video timecodes until it gets "close" to 2628, then
the picture resumes, but with artifacts (like it's not resuming on a
keyframe?) Skipping forward doesn't take long, but doesn't work reliably.
Jumping forward takes "forever" -- just what I would expect from seeking
frame-by-frame.
I don't see any errors in the backend, either during transcode or during
playback.

I've tried transcoding to a different size MPEG-4.
I've tried transcoding to a RT-JPEG format.
I've tried checking for a corrupt database, but there's no problems there.
My /etc/localtime is fine.  The problem is reproducible across both
backends (transcode machine) and several frontends.
I've tried mythcommflag --rebuild, but that didn't help -- nor do I think
it's a database problem:
 * after transcoding, I note the recordedmarkup table is empty (for that file)
 * I save the original file (*.nuv.old).  If I copy the old one back to the
   original filename and play it, it seeks fine (even with no entries inthe
   recordedmarkup table).  If I copy the transcoded file to the original file
   name, it doesn't seek properly.  The problem seems to be with the file
   itself, not the database.

One other interesting tidbit:  My /video/mythtv file storage is on an NFS
mount on a third machine.  If I don't mount /video/myth from the
frontend, I can watch either video: original or transcoded, and I see log
entries indicating the backend is streaming data (it sees the NFS mount)
to the frontend -- but seeking is hosed.  If I *do* mount /video/myth
from the frontend, the original plays fine (direct from the NFS mount,
not streamed from the backend), but the transcoded version refuses to
play at all.

I've downloaded source and I see a fair amount of code using
postionMap -- my *guess* is that it's written into the .nuv
file during recording, but somehow not written during transcoding.
I'm a long way from ready to start debugging (particulary I'm
clueless with C++)... but can do testing.


TIA

Steve


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com