[mythtv] Mythtv mpeg frame counting - patch?

[David Asher]

I'm way out of my league here, but aren't there timestamps in the mpeg
stream as well?  Can't those be used for the length of the video
instead of making assumptions around # of frames and frame rate?

David.

On 6/15/07, Bill <level42 at sympatico.ca> wrote:
> 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
> 24/29.97.
>
> 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.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>