Klaus Schmidinger wrote:
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
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
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
