On 11/16/10 09:42, d...@free.fr 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


> Selon Eric Valette <eric.vale...@free.fr>:
>> 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

Reply via email to