I analyzed the streams.
I-frame have Sequence Parameter Set always, and NAL type = 7.
My suggestion:
....
int FrameTypeOffset = i + 6;//Offset to Sequence parameter set
if (FrameTypeOffset >= TS_SIZE) // the byte to check is in the next TS
packet
i = SkipPackets(Data, Length, Processed, FrameTypeOffset);
newFrame = true;
uchar FrameType = Data[FrameTypeOffset]&0x1F;//NAL Unit Type is last 5 bit
independentFrame = FrameType == 0x07;//NAL Unit Type = 7 if I-frame
...
It's works all time.
-----Original Message-----
From: vdr-bounces@xxxxxxxxxxx [mailto:vdr-bounces@xxxxxxxxxxx] On Behalf Of
Klaus Schmidinger
Sent: Friday, September 14, 2012 8:40 AM
To: vdr@xxxxxxxxxxx
Subject: Re: vdr-1.7.29 + h264 MBAFF
On 13.09.2012 23:15, Reinhard Nissl wrote:
> Hi,
>
> Am 13.09.2012 12:25, schrieb Klaus Schmidinger:
>
>> On 12.09.2012 17:19, Придворов Андрей (Pridvorov Andrey) wrote:
>>> Progress display show correct time, but at the end play freeze.
>>> Other player (on MS windows) play correct.
>>>
>>> Try http://rghost.ru/40326577
>>
>> It looks like the frame type is 0xF0 for *all* frames of this
>> stream.
>> But when I play it on my TT S2-6400 card, even though I can move an
>> editing mark to every single frame, only every 10th or so frame
>> is actually
>> displayed on the tv.
>>
>> So my guess is, the frame types are not set correctly in this
>> stream.
>> 0xF0 seems bogus to me. So far I have seen only 0x10, 0x30 and
>> 0x50 (IIRC).
>
> Well, testing for the whole byte is not according to the specs, as only
the upper 3 bits denote primary_pic_type. So the typical primary_pic_types
are 0, 2 and 4 while 0xF0 yields 7.
So I guess in cFrameDetector::Analyze() it should then be
uchar FrameType = Data[FrameTypeOffset] &
0xE0;
independentFrame = FrameType == 0x00;
which doesn't make much of a difference for this particular case, but
at least would look at only the valid bits.
> primary_pic_type tells you, which slice_types (among I, SI, P, SP, B) may
be used to describe the picture, so one can derive the MPEG1/2 I, B and P
picture type meaning from it for the typical cases.
>
> primary_pic_type 7 indicates that all slice types may be used to describe
the picture, so the best match for a MPEG1/2 picture type would be a B
picture.
>
> Hence, the byte value 0xF0 is valid and correct, but doesn't help
anyfurther to find independent pictures.
I really wonder what kind of crack the people who came up with this stuff
have smoked. Why didn't they just put in there a simple, straightforward
bit that says "an independent picture starts here"?
Klaus
>>> -----Original Message-----
>>> From: vdr-bounces@xxxxxxxxxxx [mailto:vdr-bounces@xxxxxxxxxxx]
>>> On Behalf Of
>>> Klaus Schmidinger
>>> Sent: Thursday, September 13, 2012 1:33 AM
>>> To: vdr@xxxxxxxxxxx
>>> Subject: Re: vdr-1.7.29 + h264 MBAFF
>>>
>>> On 12.09.2012 16:06, Придворов Андрей (Pridvorov Andrey) wrote:
>>>> Hi.
>>>>
>>>> I have trouble with some h264 HD channels.
>>>>
>>>> It have MBAFF scan type, live tv on vdr works, but no recordings.
>>>>
>>>> Recorded file have 0 size.
>>>>
>>>> But, if in remux.c, in int cFrameDetector::Analyze(const uchar
>>>> *Data, int
>>> Length)
>>>>
>>>> change
>>>>
>>>> independentFrame = FrameType == 0x10
>>>>
>>>> to
>>>>
>>>> independentFrame = (FrameType == 0x10 || FrameType == 0xf0)
>>>>
>>>> Than all recordings fine.
>>>>
>>>> Is this correct?
>>>
>>> I tend to doubt that.
>>> What about the progress display when you replay such a recording?
>>> Does it show the correct times?
>>>
>>> Can you make a short recording available for further
>>> investigation?
>>>
>>> Klaus
>>>
>>> _______________________________________________
>>> vdr mailing list
>>> vdr@xxxxxxxxxxx
>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>>
>>>
>>> _______________________________________________
>>> vdr mailing list
>>> vdr@xxxxxxxxxxx
>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>>
>>
>> _______________________________________________
>> vdr mailing list
>> vdr@xxxxxxxxxxx
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
