Re: [vdr] Framerates
On 28.12.2010 00:30, Tobias Grimm wrote:
> Am Dienstag, den 28.12.2010, 00:01 +0100 schrieb Christopher Reimer:
>
>> That's a Bug in VDR. Klaus already posted a quick'n'dirty bugfix here
>> -> http://vdr-portal.de/board/thread.php?postid=951626#post951626
>
> Ah, ok - Thx!
Actually the complete fix is in the attached patch.
Klaus
--- remux.h 2010/06/05 13:27:55 2.26
+++ remux.h 2010/11/01 11:24:20 2.27
@@ -347,12 +347,10 @@
int numPtsValues;
int numIFrames;
bool isVideo;
- int frameDuration;
+ double framesPerSecond;
int framesInPayloadUnit;
int framesPerPayloadUnit; // Some broadcasters send one frame per payload unit (== 1),
-// some put an entire GOP into one payload unit (> 1), and
-// some spread a single frame over several payload units (< 0).
- int payloadUnitOfFrame;
+// while others put an entire GOP into one payload unit (> 1).
bool scanning;
uint32_t scanner;
public:
@@ -380,7 +378,7 @@
///< Returns true if a new frame was detected and this is an independent frame
///< (i.e. one that can be displayed by itself, without using data from any
///< other frames).
- double FramesPerSecond(void) { return frameDuration ? 9.0 / frameDuration : 0; }
+ double FramesPerSecond(void) { return framesPerSecond; }
///< Returns the number of frames per second, or 0 if this information is not
///< available.
};
--- remux.c 2010/06/05 13:32:15 2.47
+++ remux.c 2010/11/01 12:29:17 2.48
@@ -780,9 +780,8 @@
newFrame = independentFrame = false;
numPtsValues = 0;
numIFrames = 0;
- frameDuration = 0;
+ framesPerSecond = 0;
framesInPayloadUnit = framesPerPayloadUnit = 0;
- payloadUnitOfFrame = 0;
scanning = false;
scanner = EMPTY_SCANNER;
}
@@ -804,7 +803,6 @@
void cFrameDetector::Reset(void)
{
newFrame = independentFrame = false;
- payloadUnitOfFrame = 0;
scanning = false;
scanner = EMPTY_SCANNER;
}
@@ -831,8 +829,8 @@
return Processed;
if (Length < MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE)
return Processed; // need more data, in case the frame type is not stored in the first TS packet
- if (!frameDuration) {
-// frame duration unknown, so collect a sequence of PTS values:
+ if (!framesPerSecond) {
+// frame rate unknown, so collect a sequence of PTS values:
if (numPtsValues < MaxPtsValues && numIFrames < 2) { // collect a sequence containing at least two I-frames
const uchar *Pes = Data + TsPayloadOffset(Data);
if (PesHasPts(Pes)) {
@@ -857,28 +855,22 @@
uint32_t Delta = ptsValues[0];
// determine frame info:
if (isVideo) {
- if (Delta % 3600 == 0)
- frameDuration = 3600; // PAL, 25 fps, exact timing
- else if (abs(Delta % 3600) == 3599 || abs(Delta % 3600) == 1)
- frameDuration = 3600; // PAL, 25 fps, timing with jitter
+ if (abs(Delta - 3600) <= 1)
+ framesPerSecond = 25.0;
else if (Delta % 3003 == 0)
- frameDuration = 3003; // NTSC, 29.97 fps
- else if (abs(Delta - 1800) <= 1) {
- frameDuration = 3600; // PAL, 25 fps
- framesPerPayloadUnit = -2;
- }
- else if (Delta == 1501) {
- frameDuration = 3003; // NTSC, 29.97 fps
- framesPerPayloadUnit = -2;
- }
+ framesPerSecond = 30.0 / 1.001;
+ else if (abs(Delta - 1800) <= 1)
+ framesPerSecond = 50.0;
+ else if (Delta == 1501)
+ framesPerSecond = 60.0 / 1.001;
else {
- frameDuration = 3600; // unknown, assuming 25 fps
- dsyslog("unknown frame duration (%d), assuming 25 fps", Delta);
+ framesPerSecond = 25.0;
+ dsyslog("unknown frame delta (%d), assuming 25 fps", Delta);
}
}
else // audio
- frameDuration = Delta; // PTS of audio frames is always increasing
- dbgframes("\nframe duration = %d FPS = %5.2f FPPU = %d\n", frameDuration, 9.0 / frameDuration, framesPerPayloadUnit);
+ framesPerSecond = 9.0 / Delta; // PTS of audio frames is always increasing
+
Re: [vdr] Architecture difference between recording and viewing?
On 27.12.2010 20:59, Torsten Kunkel wrote: > Hello, > > I still have problems with my Tevii S470 with DVB-S2-channels. > The problem (as already posted long ago at > http://www.vdr-portal.de/board/thread.php?threadid=93713) is: > The buffer runs full > > buffer usage: 70% (tid=12493) > buffer usage: 60% (tid=12493) > buffer usage: 70% (tid=12493) > buffer usage: 60% (tid=12493) > buffer usage: 70% (tid=12493) > buffer usage: 60% (tid=12493) > buffer usage: 70% (tid=12493) > buffer usage: 60% (tid=12493) > buffer usage: 100% (tid=12493) > ERROR: driver buffer overflow on device 2 > ERROR: skipped 11 bytes to sync on TS packet on device 2 > > > This repeats over and over again in a timeloop of about 2mins. > > Remarkable for me is the fact, I can record any HD-channel without any > problems and I even can watch this recording at once. In my oppinion > this cannot be a problem with the S470, because I wouldn't be able to > record anything. > > I'm running vdr vdr-1.7.16 with latest xineliboutput (git) and latest > xine-sources (hg). The system load is low (<5%) and the menue is smooth > and this only happens with DVB-S2-channels. > > > This brings me to the question where is the difference between watching > a channel and recording it? When recording, the data is written to the disk, which usually works a lot faster than the incoming data rate. In live mode, if the primary device doesn't receive the channel by itself (i.e. is not a Full Featured card), the data stream is conveyed from the receiving device to the primary (replaying) device in "Transfer Mode". The replaying device must consume the data at the same overall rate as it comes in from the receiving device. If the replaying device is "slower" than the incoming data stream, data will accumulate in some buffer, and eventually that buffer will run full. So my guess is that your output device isn't working at the correct rate. For testing this theory, you could make a recording of well known length and replay that, measuring the time with a stopwatch. If the replay takes longer than the recording, the theory is proven. To rule out any differences in behavior between record/replay and Transfer Mode, you could try to find a channel that shows a clock, watch that channel in live mode and see if the clock runs slower than real time. In order to make sure the buffer doesn't overflow during that test, you could increase tsBuffer = new cTSBuffer(fd_dvr, MEGABYTE(2), CardIndex() + 1); in dvbdevice.c to like MEGABYTE(100) or even more (assuming this is the buffer that actually overflows). If you have a commercial receiver, you could tune to the same channel with VDR and that receiver, and check whether the two live programmes always are in sync (a minor constant offset is ok), or drift apart. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Recordings starting with B-Frame?
I don't known how much I can trust avidemux, but it tells me, that my HD-VDR recordings (1.7.16) start with a B-Frame. Shouldn't all *.ts Files start with an I-Frame? Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings starting with B-Frame?
Le 28/12/2010 15:41, Tobias Grimm a écrit : I don't known how much I can trust avidemux, but it tells me, that my HD-VDR recordings (1.7.16) start with a B-Frame. Shouldn't all *.ts Files start with an I-Frame? There has been some debate about the vdr frame type detection as some recording fails because it does not detect I frame. It would be indeed interestting to know if what VDR thinks is a iframe is not. --eric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings starting with B-Frame?
On 28.12.2010 15:41, Tobias Grimm wrote: > I don't known how much I can trust avidemux, but it tells me, that my > HD-VDR recordings (1.7.16) start with a B-Frame. Shouldn't all *.ts > Files start with an I-Frame? Yes, they should. Maybe somebody would like to take a close look at cFrameDetector::Analyze() to find out whether there's an off-by-one problem when starting a recording or so. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
