On 04/18/10 18:53, dplu wrote:
> Le Sunday 18 April 2010 16:11:20 Klaus Schmidinger, vous avez écrit :
> Hi
>> On 13.04.2010 17:44, dplu wrote:
>>> Hi
>>>
>>> When we delete index file on some HD recording due to synchronous problem
>>> for editing, sometimes vdr is not able to rebuild it , start for few
>>> seconds and generate an errors
>>>
>>> Stream has "something" in it, you can add mark but not navigate between
>>> without crashing vdr , when playing records, time goes not seconds to
>>> seconds but every two seconds
>> If the index is initially wrong, and ok after regenerating it,
> It is not ok until the buffer size is increased ...
>> this patch may fix the initial index creation:
>>
>> --- remux.c 2010/02/28 14:42:07 2.42
>> +++ remux.c 2010/04/05 09:32:57 2.43
>> @@ -817,7 +817,7 @@
>> if (synced && Processed)
>> return Processed;
>> if (Length < MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE)
>> - return 0; // need more data, in case the frame type is
>> not stored in the first TS packet + 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 (numPtsValues < MaxPtsValues && numIFrames < 2) { // collect
>> a sequence containing at least two I-frames
>>
>>> Is it possible for next release to increase the buffer size to 300
>>> instead of 100 in recording.c , class cIndexFileGenerator ? This has been
>>> tested successfully by at least two users with same problem
>> I don't see how increasing this buffer size would change anything.
>> cFrameDetector::Analyze() needs to see MIN_TS_PACKETS_FOR_FRAME_DETECTOR
>> packets, which is a mere 376 byte. So even a much smaller buffer should
>> work.
>>
>> But maybe I'm missing something here and somebody can point out why
>> increasing this buffer size would actually change anything.
> Not sure but what happen if the size of data stream between two keyframes is
> greater than max buffer value ? You will never be able to have inside one
> buffer range two I frames at the same time ? HD stream in France are not full
> standard, maybe to prevent copy or other
Only two subsequent TS packets are used to analyze the where a new frame starts.
> Will test your patch this week and see if it change or not index problem
I would expect this patch to fix the problem. I don't see why increasing the
buffer size would help.
Klaus
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
