Klaus Schmidinger wrote:
On 11/16/10 09:42, d...@free.fr wrote:

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


Despite not being a VDR dev, I concur. However I suggest:

1) Samples with problematic MPEG-2 streams should be posted for further examination

2) If it is verified that non-standard flag values are used for I-frames, create a special configuration option for this that is off by default. This will enable users to easily workaround their problems while keeping the correct behavior by default.

And by the way, I'd like to reiterate that my problem is actually in MPEG-4, and not MPEG-2. Could please somebody take a look at that? :-) I can provide a .ts sample if needed or provide any other necessary assistance.

Best regards,
Luboš Doležel

vdr mailing list

Reply via email to