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*. Klaus _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
