[mythtv] MPEG4 and seektables

David Asher david.asher at caviumnetworks.com
Sun Apr 2 04:59:53 UTC 2006


Okay, further research.

It turns out the keyframe positions provided by mythcommflag are EXACTLY 
8 bytes ahead of the real position (which aviindex correctly found).  I 
haven't tried to figure out why yet.

I'm still getting the AV sync problem after fast forwarding.  I noticed 
that in the .avi file in question the PTS on the audio packets in the 
file are roughly 400-500ms ahead of the video.  So, if we start at a 
specific byte position within the file (at a keyframe, for instance), 
the first video packet seen is behind the first audio packet seen by 
400-500ms

My question is what mechanism in NuppelVideoPlayer/avformatdecoder is 
supposed to resync after a seek when the RingBuffer is repositioned to a 
keyframe byte position and the next audio packet is 400-500ms ahead of 
the key frame?  This appears to be going a bit haywire here...  Upon 
returning to 1x speed after fast forward I see lastvpts in 
avformatdecoder hold constant waiting for lastapts to catch up.  BUT, as 
I said, the audio is actually AHEAD of the video.  So i'm confused whats 
going on.

Any guidance would be greatly appreciated, otherwise I'll keep slogging 
away.

David.

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.
>>


More information about the mythtv-dev mailing list