[vdr] VDR 1.7.16 - emergency exit on recording HD shows

Eric Valette eric.valette at free.fr
Mon Nov 15 08:35:24 CET 2010

On 14/11/2010 23:20, Klaus Schmidinger wrote:
> On 14.11.2010 19:17, Eric Valette wrote:
>> On 14/11/2010 19:05, Udo Richter wrote:
>>> Am 14.11.2010 18:21, schrieb Eric Valette:
>>>> I think I said clearly that the code looks correct and gave the pointer
>>>> to the specs for unconvinced people. Those wanting to read the full
>>>> specs
>>>> <http://neuron2.net/library/mpeg2/iso13818-2.pdf>
>>> Page 72, Table 6-12, picture_coding_type:
>>> 000 forbidden
>>> 001 intra-coded (I)
>>> 010 predictive-coded (P)
>>> 011 bidirectionally-predictive-coded (B)
>>> 100 shall not be used
>>>       (dc intra-coded (D) in ISO/IEC11172-
>>>       2)
>>> 101 reserved
>>> 110 reserved
>>> 111 reserved
>> As listed in my first mail indeed.
>>> The patch changes the behavior of VDR to accept picture_coding_type=0
>>> and picture_coding_type=1 as I-Frame. picture_coding_type=0 is clearly
>>> specified as forbidden. Anything I've missed?
>> No. And *as Klaus* I dunno why this should be needed except if other
>> parts of the logics for finding an I-frame is not robust enough for
>> certain streams.
> Of course it may be possible that VDR "looks" at the wrong byte in order
> to recognize the frame type. In that case, somebody should try to find
> the proper location and check that byte. Simply allowing undefined values
> to trigger the I-frame detection is a crude workaround, which is ok if
> it works for you, but doesn't qualify as an actual *fix*.

I never said it is a valid fix. But we just did get one more example of 
someone that gets 0 instead of the expected one. Are they all using the 
same buggy stream encoder?

-- eric

More information about the vdr mailing list