david.asher at caviumnetworks
Apr 1, 2006, 8:59 PM
Post #5 of 5
(779 views)
Permalink
|
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.
>>
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|
