On 11/16/10 09:42, dplu@xxxxxxx wrote: > +1 > > There is a problem here, nobody says that it is VDR fault but saying simply that > VDR adopt the full standard and nothing can be done is not enough .. we have a > solution for now and implement patch every time we change the release. > > This solution cannot be part of VDR core , why not , but my though is : if > tomorrow private channels like SAT1 or Kabel1 change their streams, will you let > all VDR machine fail to records > > Broadcasters do what they want with their stream as long it works for TV and > external receiver and absolutely don't care about software receiver .. very few > of them take care of what they do, I remember this old story about ac3 stream id > in BBC HD who was wrong .. after years they fix it, why doing that ? because it > was not OK on hard receiver > > At our level , and at mine, I do not understand all source code and dvb > specification so as user I (we) try to do our best to help , uploading samples, > testing and returning results or bug if any I really don't understand all this turmoil about this! Apparently you have a workaround that suits your needs. Just blindly allowing an undocumented and explicitly forbidden value to indentify an I-frame is not the right thing to do. You can either point me to a DVB spec that clearly defines this value as indicating an I-frame, or you can try to find out whether VDR makes a mistake when detecting the byte that contains the frame type information. Klaus > Selon Eric Valette <eric.valette@xxxxxxx>: > >> On 15/11/2010 19:46, Udo Richter wrote: >>> Am 14.11.2010 19:17, schrieb Eric Valette: >>>> On 14/11/2010 19:05, Udo Richter wrote: >>>>> 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. >>>> >>>> What really annoys me, is rather the duplication of identical bug >>>> reports for various DVB type (DVB-S2, DVB-T), various adapter in various >>>> countries when playing the stream is just fine. >>> So the next question is whether accepting picture_coding_type=0 as >>> I-Frame is a proper fix. To be precise: Since VDR depends on knowledge >>> of I-Frames, does picture_coding_type=0 guarantee that an I-Frame is >>> starting? Does this hold for ALL TV streams ALL over the world, not just >>> yours? >> As mentioned its not juts mine and that's exactly what worries me: there >> are too much reports from many countries and many channels. So unless >> they all use the same buggy mpeg2ts encoder, it's the sign something is >> wrong and I don't think a non valid value for picture type for things >> broadcasted all over the world is likely given the number of DVB >> recorder but maybe I'm wrong. _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
