[mythtv] Mythtv mpeg frame counting - patch?

Bill level42 at sympatico.ca
Sat Jun 16 02:53:11 UTC 2007

Thanks for the feedback, very helpful.  It does appear the problem I have is 
related to telecine.
The recordings are from DVB, they are movies with no commercials and they 
have been cut so there is no lead or tail just the movie.  So the frame rate 
I assume should be constant.

The pattern of the frame interlace (0),  repeat_pict (1010) and 
top_field_first (1001) bits every four frames matches the 3-2 sequence where 
the redundant frame has been drop or not transmitted.  This makes sense for 
DVB to save bandwidth, in the same way it is done for DVDs.  Because it 
hasn't been transmitted mythtv doesn't count it in 
AvFormatDecoder::GetFrame.  Because it isn't counted, the OSD length is 
reported wrong, because the mpeg header says the file is 29.97 fps assuming 
that the redundant frame is filled in at playback.  The OSD time is 
calculated based on the frame count and using the 29.97 fps from the header. 
But in reality, because the redundant frame isn't counted, the frame count 
really increments at a rate of 24 fps.  So the OSD time is in error by 

I guess the easiest thing for me to do is patch the mpeg header to 24fps.  I 
don't think this will affect seeking or anything.

So I think this is really a different problem than described in Ticket #799. 
Because in this case Mythtv is in fact counting the frames correctly on both 
the recording side (record position map is good), and on the player side.

I assume the "double length" problem in #799 is because HDTV frames probably 
span two or more data packets, as mythtv counts packets, it counts twice for 
every frame.

These two problems could possibly be fixed in the same way.  As Daniel 
mentioned, a partial decode needs to be done to identify the frame 
boundaries in the packets, to count frames.  When we find the frame, we 
could check the frame interlace,  repeat_pict and top_field_first bits to 
see if need to increment the frame count by 5 for every 4 frames.  I hope 
that a lot of decoding isn't needed to see these bits, since this would add 
a lot of overhead.  I wonder if this might have some other side affects on 
playback cause AvFormatDecoder::GetFrame will need to count by two every 
four frames.

The second option for this particular problem maybe to leave the frame 
counting as it is (cause it works well otherwise; seeking works) and only 
fix the OSD display.  If we detect the four frame 3-2 sequence by the frame 
interlace,  repeat_pict and top_field_first bits, we assume the redundant 
frame has been dropped and adjust the OSD time accordingly.

Daniel how about the second option?  I can make a patch for this, I would 
prefer this to patching all my video headers, cause that will only fix 
videos under mythvideo, won't fix any new recordings I make.

For the original problem (#799) I had an idea to try to take some code from 
av_read_frame since it does partial parsing to return us exactly one video 
frame, and incorporate into the recorders.  But I haven't had time to check 
the av_read_frame code to see if this is practical.  In any case the problem 
I would have, is I can't test it, since I don't have HDTV and in my case 
mythtv is actually counting the frames correctly. 

More information about the mythtv-dev mailing list