On 14.11.2010 17:45, Eric Valette wrote: > On 14/11/2010 15:15, Udo Richter wrote: > >> In your case, as Klaus already wrote, it may have something to do with >> the fact that VDR wants to start the recording with an I-frame, and >> probably can't find one. > > Some patches have been posted suggesting that replacing in remux.c > > > independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1; > > which, as I read the bit definition is correct in doc > > <http://dvd.sourceforge.net/dvdinfo/mpeghdrs.html> > > For further info: > Frame type = 000 forbidden > Frame type = 001 intra-coded (I) - iframe > Frame type = 010 predictive-coded (P) - p frame > Frame type = 011 bidirectionally-predictive-coded (B) - b frame > Frame type = 100 shall not be used(dc intra-coded (D) in ISO/IEC11172-2) > Frame type = 101 reserved > Frame type = 110 reserved > Frame type = 111 reserved > > > by something equivalent to > > independentFrame = ((Data[i + 2] >> 3) & 0x6 == 0 > > saying basically that what is not a P frame, a D frame or B frame sould > be an I-frame. I haven't yet tested it myself although I have a channel > that I can play but not record. > > Klaus says that the above code is not correct according t specs but > failed to explain how we could get other values than 1, 2, 3, 4 I don't see why I would have to ;-) The specs clearly state that only 001 marks an I-frame. Anything else is either explicitly not an I-frame, forbidden or reserved (i.e. undefined). So unless there is an updated specification that actually assigns valid meanings to values above 4, you might want to contact your provider and ask them what kind of data they are broadcasting. Klaus _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
