From patchwork Sun Jul 17 10:17:43 2005 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Reinhard Nissl X-Patchwork-Id: 11948 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by www.linuxtv.org with smtp (Exim 4.34) id 1Du6E4-0000A5-Qr for vdr@linuxtv.org; Sun, 17 Jul 2005 12:18:24 +0200 Received: (qmail invoked by alias); 17 Jul 2005 10:17:50 -0000 Received: from Af370.a.pppool.de (EHLO [192.168.101.15]) [213.6.243.112] by mail.gmx.net (mp031) with SMTP; 17 Jul 2005 12:17:50 +0200 X-Authenticated: #527675 Message-ID: <42DA3047.6000504@gmx.de> Date: Sun, 17 Jul 2005 12:17:43 +0200 From: Reinhard Nissl User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Klaus Schmidinger's VDR X-Y-GMX-Trusted: 0 Subject: [vdr] VDR-1.3.27: updated cVideoRepacker X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Klaus Schmidinger's VDR List-Id: Klaus Schmidinger's VDR List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 10:18:24 -0000 Status: O X-Status: X-Keywords: X-UID: 3582 Hi, I'd like to invite you to test the attached patch which now also supports MPEG1 video streams (vdr-1.3.27-remux-repacker.patch). Besides that, a major change has been made in error reporting. Previous versions often reported a buffer overflow (although there was no buffer overflow) just as an indication for not beeing able to handle the data. Most likely this lead to the assumption that the repacker got stuck. VDR-1.3.28 will also (most likely) receive the second attached patch "vdr-1.3.27-dvbplayer-sequence-end-code.patch". It will cause a still image to be immediately shown by (softdevices like) vdr-xine, e. g. when moving or jumping to cutting marks. Does this patch have any bad impact on FF-devices? As old recordings (prior to VDR-1.3.26 or 1.3.27 with cVideoRepacker disabled) can have fragmented frames and VDR doesn't handle them correctly when passing still images to a device, it is hardly possible to edit cutting marks (at least) in vdr-xine for such recordings. The patch http://home.vr-web.de/~rnissl/vdr-1.3.24-dvbplayer.patch is a hack to at least fix the I-frames needed for fast forward, fast rewind, slow rewind and editing cutting marks. As you may see, it collides with the attached dvbplayer patch, so you have to decide whether to use the attached one and just edit new recordings or to use the one taken at version 1.3.24 and be able to edit new and old -- but only MPEG2 -- recordings. Bye. --- ../vdr-1.3.27-orig/dvbplayer.c 2005-05-22 13:26:51.000000000 +0200 +++ dvbplayer.c 2005-07-16 22:57:43.000000000 +0200 @@ -666,11 +666,34 @@ void cDvbPlayer::Goto(int Index, bool St int FileOffset, Length; Index = index->GetNextIFrame(Index, false, &FileNumber, &FileOffset, &Length); if (Index >= 0 && NextFile(FileNumber, FileOffset) && Still) { - uchar b[MAXFRAMESIZE]; + uchar b[MAXFRAMESIZE + 4 + 5 + 4]; int r = ReadFrame(replayFile, b, Length, sizeof(b)); if (r > 0) { if (playMode == pmPause) DevicePlay(); + // append sequence end code to get the image shown immediately with softdevices + if (r > 6) { // should be always true + b[r++] = 0x00; + b[r++] = 0x00; + b[r++] = 0x01; + b[r++] = b[3]; + if (b[6] & 0x80) { // MPEG 2 + b[r++] = 0x00; + b[r++] = 0x07; + b[r++] = 0x80; + b[r++] = 0x00; + b[r++] = 0x00; + } + else { // MPEG 1 + b[r++] = 0x00; + b[r++] = 0x05; + b[r++] = 0x0F; + } + b[r++] = 0x00; + b[r++] = 0x00; + b[r++] = 0x01; + b[r++] = 0xB7; + } DeviceStillPicture(b, r); } playMode = pmStill;