From patchwork Tue Sep 18 09:20:53 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Klaus Schmidinger X-Patchwork-Id: 14477 Received: from localhost ([127.0.0.1] helo=www.linuxtv.org) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1TDtzM-0002Wk-OD; Tue, 18 Sep 2012 11:21:04 +0200 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1TDtzJ-0002WW-Dn for vdr@linuxtv.org; Tue, 18 Sep 2012 11:21:02 +0200 X-tubIT-Incoming-IP: 188.40.50.18 Received: from racoon.tvdr.de ([188.40.50.18]) by mail.tu-berlin.de (exim-4.75/mailfrontend-2) with esmtps [TLSv1:AES256-SHA:256] for id 1TDtzJ-00066N-GQ; Tue, 18 Sep 2012 11:21:01 +0200 Received: from dolphin.tvdr.de (dolphin.tvdr.de [192.168.100.2]) by racoon.tvdr.de (8.14.5/8.14.5) with ESMTP id q8I9KxX3002460 for ; Tue, 18 Sep 2012 11:20:59 +0200 Received: from [192.168.100.10] (hawk.tvdr.de [192.168.100.10]) by dolphin.tvdr.de (8.14.4/8.14.4) with ESMTP id q8I9KrmX019155 for ; Tue, 18 Sep 2012 11:20:54 +0200 Message-ID: <50583CF5.3050908@tvdr.de> Date: Tue, 18 Sep 2012 11:20:53 +0200 From: Klaus Schmidinger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: vdr@linuxtv.org References: <06C89579EEC449D1A66AD26EDC58D32E@ua0lnjhome><50509D0A.3080602@tvdr.de><11A1B2063C4845EE859E151C6A9EEB4F@ua0lnjhome><5051B47D.3030109@tvdr.de> <50524D0C.8040403@gmx.de> <505252B8.3070805@tvdr.de> <4AACF23EFF384EB5B8D21849FE615BAD@ua0lnjhome> In-Reply-To: <4AACF23EFF384EB5B8D21849FE615BAD@ua0lnjhome> X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.18.90915 X-PMX-Spam: Gauge=X, Probability=10%, Report=' RU_TLD 0.5, HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, BODY_SIZE_6000_6999 0, BODY_SIZE_7000_LESS 0, ECARD_WORD 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __HAS_FROM 0, __HAS_MSGID 0, __HIGHBITS 0, __INT_PROD_TV 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' X-LSpam-Score: -1.1 (-) X-LSpam-Report: No, score=-1.1 required=5.0 tests=BAYES_00=-1.9, RDNS_NONE=0.793 autolearn=no Subject: Re: [vdr] vdr-1.7.29 + h264 MBAFF X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: vdr-bounces@linuxtv.org Errors-To: vdr-bounces@linuxtv.org On 17.09.2012 14:17, ????????? ?????? (Pridvorov Andrey) wrote: > 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. That was a very good pointer in the right direction. However, we can't just blindly look at Data[i + 6], but rather have to search for a NALU start code after the Access Unit Delimiter. The attached patch changes cFrameDetector::Analyze() accordingly, and it still works with the HD channels I have access to, and also the sample you sent me earlier. Please try whether this patch works with all the HD channels you can receive. I would also appreciate if as many other VDR users as possible applied this patch and tested it, so that we can be sure it works before I release the next developer version. Klaus > -----Original Message----- > From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of > Klaus Schmidinger > Sent: Friday, September 14, 2012 8:40 AM > To: vdr@linuxtv.org > Subject: Re: [vdr] 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@linuxtv.org [mailto:vdr-bounces@linuxtv.org] >>>> On Behalf Of >>>> Klaus Schmidinger >>>> Sent: Thursday, September 13, 2012 1:33 AM >>>> To: vdr@linuxtv.org >>>> Subject: Re: [vdr] 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 --- remux.c 2012/09/14 09:06:14 2.65 +++ remux.c 2012/09/18 09:11:24 @@ -843,7 +843,8 @@ int cFrameDetector::Analyze(const uchar *Data, int Length) { - int SeenPayloadStart = false; + bool SeenPayloadStart = false; + bool SeenAccessUnitDelimiter = false; int Processed = 0; newFrame = independentFrame = false; while (Length >= TS_SIZE) { @@ -970,12 +971,16 @@ scanner = EMPTY_SCANNER; if (synced && !SeenPayloadStart && Processed) return Processed; // flush everything before this new frame + SeenAccessUnitDelimiter = true; + } + else if (SeenAccessUnitDelimiter && scanner == 0x00000001) { // NALU start + SeenAccessUnitDelimiter = false; int FrameTypeOffset = i + 1; 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] & 0xE0; - independentFrame = FrameType == 0x00; + uchar FrameType = Data[FrameTypeOffset] & 0x1F; + independentFrame = FrameType == 0x07; if (synced) { if (framesPerPayloadUnit < 0) { payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;