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

-- eric

-- eric

On 14/11/2010 18:12, Klaus Schmidinger wrote:

On 14.11.2010 17:45, Eric Valette wrote:

...

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 ;-)

Klaus,

I think I said clearly that the code looks correct and gave the pointer to the specs for unconvinced people. Those wanting to read the full specs http://neuron2.net/library/mpeg2/iso13818-2.pdf

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.

That the only point where I start to disagree: dedicated DVB-T recorders manage to record this channel so here must be something else.

You now have got more than 10 identical reports on various country and various channels.

But thanks again for your work and support.

-- eric

On 14/11/2010 19:05, Udo Richter wrote:

Am 14.11.2010 18:21, schrieb Eric Valette:

...

I think I said clearly that the code looks correct and gave the pointer to the specs for unconvinced people. Those wanting to read the full specs http://neuron2.net/library/mpeg2/iso13818-2.pdf

Page 72, Table 6-12, picture_coding_type: 000 forbidden 001 intra-coded (I) 010 predictive-coded (P) 011 bidirectionally-predictive-coded (B) 100 shall not be used (dc intra-coded (D) in ISO/IEC11172- 2) 101 reserved 110 reserved 111 reserved

As listed in my first mail indeed.

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.

For the record for myself in france, I can see gulli channels (a kid channel) but fail to record it and m kids are just complaining when I told them to go to sleep and that I will record it and it failed. Now I have more difficulties to send them to sleep ;-)

-- eric

On 14/11/2010 23:20, Klaus Schmidinger wrote:

On 14.11.2010 19:17, Eric Valette wrote:

...

On 14/11/2010 19:05, Udo Richter wrote:

...

Am 14.11.2010 18:21, schrieb Eric Valette:

...

I think I said clearly that the code looks correct and gave the pointer to the specs for unconvinced people. Those wanting to read the full specs http://neuron2.net/library/mpeg2/iso13818-2.pdf

Page 72, Table 6-12, picture_coding_type: 000 forbidden 001 intra-coded (I) 010 predictive-coded (P) 011 bidirectionally-predictive-coded (B) 100 shall not be used (dc intra-coded (D) in ISO/IEC11172- 2) 101 reserved 110 reserved 111 reserved

As listed in my first mail indeed.

...

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.

Of course it may be possible that VDR "looks" at the wrong byte in order to recognize the frame type. In that case, somebody should try to find the proper location and check that byte. Simply allowing undefined values to trigger the I-frame detection is a crude workaround, which is ok if it works for you, but doesn't qualify as an actual *fix*.

I never said it is a valid fix. But we just did get one more example of someone that gets 0 instead of the expected one. Are they all using the same buggy stream encoder?

-- eric

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?

If any non-I-Frame starts with picture_coding_type=0, the editing function won't be able to show an editing mark on an wrongly detected I-Frame, recordings may start with an non-I-Frame although they're supposed not to, and stuff like that.

Cheers,

Udo

+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

We can help !!

Best regards

Selon Eric Valette eric.valette@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.

--eric

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Klaus Schmidinger wrote:

On 11/16/10 09:42, dplu@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 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,