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