Mailing List Archive

Re: [mythtv-commits] Ticket #799: DTV recordings sometimes show doubled recording length
* On Sun Sep 30, 2007 at 04:27:40PM -0000, MythTV wrote:
> #799: DTV recordings sometimes show doubled recording length

> Comment(by Tom Dexter <digitalaudiorock@hotmail.com>):

totalLength is also set in NuppelVideoPlayer::SetLength.

When a recording ends, the recorder (TVRec) sends a DONE_RECORDING
event. This event contains the card number and the recording
length. This gets received by the TV class (tv_play.cpp) and
TV::customEvent calls NuppelVideoPlayer::SetLength().

This is how the totalLength is getting set without you seeing it
in your debugging code.

I think the reason that the length is getting hosed up is that
the DVB recorder (and possibly others) doesn't know/set the frame
rate of the video that it is recording, so it defaults to the
29.97 that is set in the construction of RecorderBase.

TVRec::TeardownRecorder() does this:

filelen = (int)((float)GetFramesWritten() / GetFramerate());

TVRec::GetFramerate() calls RecorderBase::GetFrameRate() which
just returns Recorderbase::video_frame_rate.

RecoderBase::video_frame_rate is only set by the DVB recorder
in RecorderBase's constructor.

I see there is even a comment about this in the code in tv_rec.cpp.
It's not specifically about the double length, but saying the way
it calculates the length is wrong because of changing framerates
in DTV recordings.

// This is a bad way to calculate this, the framerate
// may not be constant if using a DTV based recorder.
filelen = (int)((float)GetFramesWritten() / GetFramerate());

The only accurate way for the player to know how long the recording
is in this case is for the recorder to keep track of it which it
doesn't currently. The recorder could look at the frame rate and
do a calculation based on that, but that is not foolproof since
the frame rate could change in the recording (and does in some
places where commercials are at different rates than the show).

The player knows the _current_ frame rate, so the numbers
will jump around when you are playing a video that changes
frame rates in the middle. Calculations based on these changing
frame rates are another big issue that hasn't been solved yet.
The player doesn't handle them in a lot of cases, and neither does
the commercial flagger.

--
Chris
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #799: DTV recordings sometimes show doubled recording length [ In reply to ]
>* On Sun Sep 30, 2007 at 04:27:40PM -0000, MythTV wrote:
>> #799: DTV recordings sometimes show doubled recording length
>
>> Comment(by Tom Dexter <digitalaudiorock[at]hotmail.com>):
>
>totalLength is also set in NuppelVideoPlayer::SetLength.
>
>When a recording ends, the recorder (TVRec) sends a DONE_RECORDING
>event. This event contains the card number and the recording
>length. This gets received by the TV class (tv_play.cpp) and
>TV::customEvent calls NuppelVideoPlayer::SetLength().
>
>This is how the totalLength is getting set without you seeing it
>in your debugging code.
>
>I think the reason that the length is getting hosed up is that
>the DVB recorder (and possibly others) doesn't know/set the frame
>rate of the video that it is recording, so it defaults to the
>29.97 that is set in the construction of RecorderBase.
>
>TVRec::TeardownRecorder() does this:
>
>filelen = (int)((float)GetFramesWritten() / GetFramerate());
>
>TVRec::GetFramerate() calls RecorderBase::GetFrameRate() which
>just returns Recorderbase::video_frame_rate.
>
>RecoderBase::video_frame_rate is only set by the DVB recorder
>in RecorderBase's constructor.
>
>I see there is even a comment about this in the code in tv_rec.cpp.
>It's not specifically about the double length, but saying the way
>it calculates the length is wrong because of changing framerates
>in DTV recordings.
>
>// This is a bad way to calculate this, the framerate
>// may not be constant if using a DTV based recorder.
>filelen = (int)((float)GetFramesWritten() / GetFramerate());
>
>The only accurate way for the player to know how long the recording
>is in this case is for the recorder to keep track of it which it
>doesn't currently. The recorder could look at the frame rate and
>do a calculation based on that, but that is not foolproof since
>the frame rate could change in the recording (and does in some
>places where commercials are at different rates than the show).
>
>The player knows the _current_ frame rate, so the numbers
>will jump around when you are playing a video that changes
>frame rates in the middle. Calculations based on these changing
>frame rates are another big issue that hasn't been solved yet.
>The player doesn't handle them in a lot of cases, and neither does
>the commercial flagger.
>
>--
>Chris

Sorry for not replying properly to this. I didn't belong to the list
at the time it was posted.

Thanks for the explanation of this and all the related issues. I'm
curious on one thing here: What situation is it that actually
requires that tv_play call NuppelVideoPlayer::SetLength using the
length reported by the recorder when changing from WatchingRecording
to a WatchingPreRecorded state? I imagine there is, but in my
situation anyway (all DVB recordings) simply commenting out that
SetLength call in tv_play seems to prevent this bug with no ill
affects, as NuppelVideoPlayer already has a correct length (or
reasonably correct) based on the DB and the remote encoder.

The situation where stations use different frame rates certainly
sounds like an ugly one. I've been noticing the incorrect total
lengths on NBC broadcasts (53 minutes rather than an hour for example)
from that one. Is this something these stations have just started
doing recently? Sounds like a pretty awful practice to me.

Thanks again.
Tom
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #799: DTV recordings sometimes show doubled recording length [ In reply to ]
On 10/02/2007 10:28 AM, Tom Dexter wrote:
> The situation where stations use different frame rates certainly
> sounds like an ugly one. I've been noticing the incorrect total
> lengths on NBC broadcasts (53 minutes rather than an hour for example)
> from that one. Is this something these stations have just started
> doing recently? Sounds like a pretty awful practice to me.

IMHO, it's a /much/ better idea to broadcast a movie recorded at 24fps
at 1080p24 than to telecine that video just so you can transmit at "the
usual" 1080i60. Similarly, interlacing a 1080p30 source to transmit at
1080i60 is just a waste. (Yes, both 1080p24 and 1080p30 are valid ATSC
formats: http://www.hdtvprimer.com/ISSUES/what_is_ATSC.html . When
people say there is no "1080p" in ATSC, they mean 1080p60.)

Now, switching resolutions may be a bit more evil for the playback
system (depending on the smoothness with which the display transitions),
but I don't know of any broadcasters who are doing that.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #799: DTV recordings sometimes show doubled recording length [ In reply to ]
Maybe I'm not following along, but why try to calculate the recording
length based on total frames / frame rate when we _know_ what time we
started recording and what time we ended? time(now) - time(start) = length?
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #799: DTV recordings sometimes show doubled recording length [ In reply to ]
On Wed, 2007-10-03 at 08:17 -0500, Robert Kulagowski wrote:
> Maybe I'm not following along, but why try to calculate the recording
> length based on total frames / frame rate when we _know_ what time we
> started recording and what time we ended? time(now) - time(start) = length?

The reported length is just a side effect. We skip around the recording
based on the keyframe map, so unless we know the frame rate those
keyframes are delivered at we can't say skip backwards by 30 seconds
when the user asks us to. But it might make sense to record a timestamp
in the keyframe map and then we could always skip based on time no
matter what the current framerate. The only problem with that is that
it might be space inefficient. When the framerate changes it really
only changes one or two dozen times during a recording so putting a
timestamp in every keyframe entry, while the simplest option, would
probably make the DB 30% larger in one fell swoop.

There are also other problems that this ticket covers, such as when
we miscount frames simply because our frame scanning method for MPEG-2
video is quite crude.

-- Daniel


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #799: DTV recordings sometimes show doubled recording length [ In reply to ]
On Wednesday 03 October 2007 15:29:51 Daniel Kristjansson wrote:
> On Wed, 2007-10-03 at 08:17 -0500, Robert Kulagowski wrote:
> > Maybe I'm not following along, but why try to calculate the
> > recording length based on total frames / frame rate when we _know_
> > what time we started recording and what time we ended? time(now) -
> > time(start) = length?
>
> The reported length is just a side effect. We skip around the
> recording based on the keyframe map, so unless we know the frame rate
> those keyframes are delivered at we can't say skip backwards by 30
> seconds when the user asks us to. But it might make sense to record a
> timestamp in the keyframe map and then we could always skip based on
> time no matter what the current framerate. The only problem with that
> is that it might be space inefficient. When the framerate changes it
> really only changes one or two dozen times during a recording so
> putting a timestamp in every keyframe entry, while the simplest
> option, would probably make the DB 30% larger in one fell swoop.

I want to replace chanid and starttime for the recordedseek table with a
recordedid (Chris Pinkham's multiple files per recording work might
atually include it).
That would save 6 bytes per entry. If we add a int as timestamp we still
save 2 bytes.

It has one big problem though, updating the old seek tables.

> There are also other problems that this ticket covers, such as when
> we miscount frames simply because our frame scanning method for
> MPEG-2 video is quite crude.

I'm still not sure how we can solve this issue. Reusing ffmpeg is at
least for the recorders not feasible.
I doubt that the simplistic parsing is to blame for the seeing twice the
number of frames. Bogus start codes in video stream can only occur
cross the PES packet header payload boundary.
The picture header is not nice to parse but I'll add it.

Janne
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: [mythtv-commits] Ticket #799: DTV recordings sometimes show doubled recording length [ In reply to ]
On 10/2/07, Michael T. Dean <mtdean@thirdcontact.com> wrote:
>
> IMHO, it's a /much/ better idea to broadcast a movie recorded at 24fps
> at 1080p24 than to telecine that video just so you can transmit at "the
> usual" 1080i60. Similarly, interlacing a 1080p30 source to transmit at
> 1080i60 is just a waste. (Yes, both 1080p24 and 1080p30 are valid ATSC
> formats: http://www.hdtvprimer.com/ISSUES/what_is_ATSC.html . When
> people say there is no "1080p" in ATSC, they mean 1080p60.)
>
> Now, switching resolutions may be a bit more evil for the playback
> system (depending on the smoothness with which the display transitions),
> but I don't know of any broadcasters who are doing that.
>
> Mike

I don't know what NBC is doing with their 1080i OTA broadcasts these
days...though I'm not very knowledgeable when it comes to technical
aspects of video. I noticed today that when I play HD recordings from
NBC with '-v playback' it constantly disables and then re-enables
de-interlacing...apparently it sees interlaced and then progressive
frames:

2007-10-04 13:47:11.831 NVP: interlaced frame seen after 95 progressive frames
2007-10-04 13:47:11.914 Set video sync frame interval to 33366
2007-10-04 13:47:11.914 Enabled deinterlacing
2007-10-04 13:47:12.015 NVP: progressive frame seen after 4 interlaced frames
2007-10-04 13:47:12.082 Set video sync frame interval to 33366
2007-10-04 13:47:12.082 Disabled deinterlacing
2007-10-04 13:47:12.347 NVP: interlaced frame seen after 9 progressive frames
2007-10-04 13:47:12.431 Set video sync frame interval to 33366
2007-10-04 13:47:12.431 Enabled deinterlacing
2007-10-04 13:47:12.682 NVP: progressive frame seen after 9 interlaced frames
2007-10-04 13:47:12.749 Set video sync frame interval to 33366
2007-10-04 13:47:12.749 Disabled deinterlacing

If I manually play one of those mpeg files in mplayer, every few
seconds it reports that the frame rate has changed from 24000/1001fps
to 30000/1001fps....odd stuff.

None of this seems to happen on other 1080i broadcasts I get such as CBS or PBS.

Luckily mythtv plays them ok in spite of this. I occasionally get
video speeding up for an instant, but only right after commercials and
even then, usually only when I'm skipping forward or back.

By the way...nobody responded to a question I had earlier about
tv_play.cpp calling NuppelVideoPlayer::SetLength() from customEvent
when it receives the DONE_RECORDING event. In my situation (DTV
recordings only) commenting out that SetLenth() call prevents the
erroneous double length (reported by the recorder) from being used by
the OSD, and leaves it as it was from the DB and the remote encoder
and doesn't appear to cause any problems. If nobody knows of any
potential side affects of doing this, I was thinking of posting that
to the ticket as an unsupported work around for anyone who wants to
use it.

Thanks.

Tom
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev