View unanswered posts    View active topics

All times are UTC - 6 hours





Post new topic Reply to topic  [ 5 posts ] 
Print view Previous topic   Next topic  
Author Message
Search for:
PostPosted: Sun Jun 03, 2007 11:55 pm 
Offline
Joined: Mon Jun 27, 2005 4:42 pm
Posts: 321
Location: Minneapolis, Minnesota, USA
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.]

_________________
Grant


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 04, 2007 12:14 am 
Offline
Site Admin
Joined: Fri Sep 19, 2003 6:37 pm
Posts: 2659
Location: Whittier, Ca
If you have not, I'd suggest posting on the MythTV users mailing list.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 04, 2007 8:42 am 
Offline
Joined: Mon Jun 27, 2005 4:42 pm
Posts: 321
Location: Minneapolis, Minnesota, USA
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.

_________________
Grant


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 04, 2007 10:36 am 
Offline
Joined: Mon Jun 27, 2005 4:42 pm
Posts: 321
Location: Minneapolis, Minnesota, USA
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...

_________________
Grant


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jun 05, 2007 1:33 pm 
Offline
Joined: Mon Jun 27, 2005 4:42 pm
Posts: 321
Location: Minneapolis, Minnesota, USA
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.

_________________
Grant


Top
 Profile  
 

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 


All times are UTC - 6 hours




Who is online

Users browsing this forum: No registered users and 25 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group

Theme Created By ceyhansuyu