[mythtv] AVI and Seeking and also H264

[Bill Stewart]

What is needed to getting seeking (rewind / fastforward) with AVIs (Xvid)?  What I mean is to remove the blocky artifacts during rewind and fastforward?  I found this post http://www.gossamer-threads.com/lists/mythtv/dev/191021 which talks about the problem but no further discussions after that.  I also have problems with bookmarks on some avi, the bookmark doesn't work.

Is a fix needed to the code as suggested below to fix the seek table (filemarkup) for avi's and if so what about the audio sync problem discussed below?

I'd be willing to look further at this in the code, but thought I'd post here if anyone else has looked at this since the original message.

On another related note, does seeking working in H264 encoded files?  I've tried MKV, but mythcommflag can't build a seektable for that.  Will I have better success with AVI or MP4 containers for H264?  If so I would imagine there will be similar seek problems in the AVI container.


David Asher wrote: 
> I've done some more research into this. 
> 
> I looked for another way to find keyframes other than mythcommflag. I 
> found aviindex from transcode-1.0.2. So, just for fun I had it 
> generate a list of key frames and inserted the key frames it found 
> into the recordedmarkup table. Lo-and-behold the video seeking is 
> perfect. 
> 
> Interestingly, it found roughly the same number of keyframes (771 vs 
> 769 for mythcommflag), but their positions are completely different. 
> 
> Unfortunately, all is not right: after seeking @ >= 20x when I go back 
> to normal play speed the audio is badly out of sync. If I exit 
> (saving the position) and return it syncs the video to where the audio 
> was perfectly. (i.e. it starts in the correct place for the last 
> audio that was heard, not for the last video seen) 
> 
> So, my next step is to understand why I'm getting this audio sync 
> problem. Then, hopefully, I'll have a good enough understanding of 
> how this all works to figure out why mythcommflag's seek table isn't 
> really pointing to key frames. 
> 
> Any tips on looking into these issues would be greatly appreciated. 
> 
> Thanks, 
> 
> David. 
> 
> P.S. I'm running SVN 9372. 
> 
> David Asher wrote: 
>> I started using Steve Adeff's tv.com script (thanks Steve!) to load 
>> some videos into the MythTV database. 
>> 
>> The are MPEG4 .avi's. They play fine, but seeking is terrible. I 
>> kinda expected that since there was no seek table. 
>> 
>> So, I thought: "lets create a seek table for them". I tried: 
>> 
>> $ mythcommflag --rebuild -f <avifile> 
>> 
>> This acted like it was working, but the resulting seek table is 
>> horribly broken. 
>> 
>> I get all sorts of blocky artifacts (BIG blocks), and when first 
>> entering the playback after saving position on exit I get a black 
>> screen which slowly fills in -- sounds like we didn't start on a 
>> keyframe? 
>> 
>> On starting playback I see (-v playback): 
>> 
>> 2006-03-16 22:51:40.079 Resyncing position map. posmapStarted = 0 
>> livetv(0) watchingRec(0) 
>> 2006-03-16 22:51:40.096 Position map filled from DB to: 59546 
>> 2006-03-16 22:51:40.096 SyncPositionMap prerecorded, from DB: 769 
>> entries 
>> 2006-03-16 22:51:40.096 SyncPositionMap, new totframes: 59546, new 
>> length: 2483, posMap size: 769 
>> 2006-03-16 22:51:40.096 AFD: Position map found 
>> 
>> on FF I get: 
>> 
>> [mpeg4 @ 0x1191a84]warning: first frame is no keyframe 
>> 
>> So, I'm thinking the key frames weren't correctly found. 
>> 
>> I've got 2 questions: 
>> 
>> 1. should i expect seek table generation to work for an MPEG4 ? 
>> 
>> 2. what is the difference between the --video and --rebuild -f 
>> options for creating the seek table? 
>> 
>> Thanks, 
>> 
>> David. 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20081231/0df7f071/attachment.htm