| LinHES Forums http://forums.linhes.org/ |
|
| Seek table problems with re-encoded ATSC MPEG2 files. http://forums.linhes.org/viewtopic.php?f=15&t=15491 |
Page 1 of 1 |
| Author: | grante [ Sun Jun 03, 2007 11:55 pm ] |
| Post subject: | Seek table problems with re-encoded ATSC MPEG2 files. |
I've got a user job set up that converts ATSC recordings (HDHR) into a format suitable for playback using a PVR350. I've got playable files but the seek tables always get trashed when I run "mythcommflag --rebuild". The original seek table seems to match up with the original file, but I'm unable to build a seek table for the re-encoded file. I think it's because of this bug that's been open for a year and a half: http://cvs.mythtv.org/trac/ticket/1088 How are people getting around this bug? I'm in the process of cobbling together something to generate a seek table, but I can't be the first person who's had a problem with this. [I'm also rather surprised this has been broken for a year.] |
|
| Author: | cecil [ Mon Jun 04, 2007 12:14 am ] |
| Post subject: | |
If you have not, I'd suggest posting on the MythTV users mailing list. |
|
| Author: | grante [ Mon Jun 04, 2007 8:42 am ] |
| Post subject: | |
cecil wrote: If you have not, I'd suggest posting on the MythTV users
mailing list. I haven't -- mainly because the list admin refuses to allow access via the gmane.org gateway which I use exclusively for mailing lists. It's been requested a few times, but the request is always vehemently refused for reasons I don't understand. 10,000 other mailing lists are happy to be carried by gmane.org, but the mythtv list is too good for it or something. I have found that if you just delete the seek table records for a recording, it will work fine: The OSD will then show the correct program length and seeks will work as expected. That's probably my short-term fix. On the most recent recording it appears that mythcommflag --rebuild _did_ work, but that's a unique event so far. If simply deleting the old seek table data continues to work, I may not have to finish my seek-table generator. FWIW, it's based on code from gop_fixup: http://vivara.net/software/gop_fixup/. The actual code is quite trivial -- it only takes about 100 lines of C to parse the stream and generate seek table data. I still need to munge it into mysql commands to get it into the table, but all that takes is a fancier format string for the fprintf() call that is currently printing out the data. |
|
| Author: | grante [ Mon Jun 04, 2007 10:36 am ] |
| Post subject: | |
grante wrote: If simply deleting the old seek table data continues to work, I
may not have to finish my seek-table generator. FWIW, it's based on code from gop_fixup: http://vivara.net/software/gop_fixup/. The actual code is quite trivial -- it only takes about 100 lines of C to parse the stream and generate seek table data. Hmm. It looks like the code in gop_fixup may be a bit too simple. AFAICT, MythTV's seek logic assumes that the frame rate is constant within a stream, so that for a 480i recording, time is frame_number * 29.97. Looking at the seek table for a 60-minute recording, the last entry is frame number 107779. That shows up as a length of 59:56 on the OSD (which is correct). However, the stream in question appears to have bursts of 60fps video (commercials in 480p, I suspect). gop_fixup ignores (but warns about) frame-rate changes, so the actual frame count seen by gop_fixup is 109557. MythTV is going to think that means a program length of 60:55. The offset in total length doesn't matter (to me, anyway), but during a 60fps commercial, skipping forward "30 seconds" will only skip 15 seconds. I think. I really should just upgrade to an HDTV... |
|
| Author: | grante [ Tue Jun 05, 2007 1:33 pm ] |
| Post subject: | |
Deleting the seek table info for a transcoded recording results in usable playback. The length of the show shown on the OSD wanders around -- presumably it's being calculated based on either the current or average bit rate and the number of bytes remaining in the file. That's harmless, but it was annoying enough that I went ahead an added my own seek-table generation. The program length is stable now, though it's a bit off. I think this is due to segments of frames with a different frame. Do ATSC transmissions switch frame-rates (e.g. program is 29.97 fps but commercials are 24 or 60). Instead of generating seek-table entries based on frame count, I may try generating them based on the timestamps on the frames. |
|
| Page 1 of 1 | All times are UTC - 6 hours |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|