From patchwork Mon Apr 7 00:04:35 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Ryley Angus X-Patchwork-Id: 23423 X-Patchwork-Delegate: hverkuil@xs4all.nl Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1WWx3U-0005ct-4m; Mon, 07 Apr 2014 02:04:52 +0200 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.72/mailfrontend-7) with esmtp id 1WWx3R-0006Vk-3C; Mon, 07 Apr 2014 02:04:51 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754722AbaDGAEs (ORCPT + 1 other); Sun, 6 Apr 2014 20:04:48 -0400 Received: from mail-pd0-f178.google.com ([209.85.192.178]:57477 "EHLO mail-pd0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754649AbaDGAEr (ORCPT ); Sun, 6 Apr 2014 20:04:47 -0400 Received: by mail-pd0-f178.google.com with SMTP id x10so5779345pdj.9 for ; Sun, 06 Apr 2014 17:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=yxiPyK6aO5YybSGktl40o1mTbhItboJgR5uX7z60sII=; b=BH8baNTQTTalPm+9I+ZoGVXbEOMFeL9gtfbtC0o+v11tzAGxhEYO1rDqvhrO6dnjzq Gd+GvuxrKYdis2MpyIw3O4M/MqOHg4rwxj2QiSl7JOhxrq2hb/RfxgBvA5/Sde3S6N30 aYbe9VX14DZ0Qgk8lYYpv/T9QuDXf12b1B6t9T8SEFP7YMK+2fyclwJNi7pgx4XeicVK L3XycTapgArHp63AAJTzGFRLYUY8S+wQOsMbkaabGot5KEQ/4gTWpIcOSLEYO4S78SSr K4OYIB2xRzdEB790FE5FEA3QnsjB6NewZAJrjMLaTNJoyHbBzN3A3DlyBtIZUA8ZCp11 jiGw== X-Received: by 10.68.162.1 with SMTP id xw1mr6401pbb.128.1396829086866; Sun, 06 Apr 2014 17:04:46 -0700 (PDT) Received: from [192.168.20.3] ([120.155.51.210]) by mx.google.com with ESMTPSA id ir10sm32606494pbc.59.2014.04.06.17.04.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Apr 2014 17:04:45 -0700 (PDT) From: Ryley Angus Subject: [RFC] Fix interrupted recording with Hauppauge HD-PVR Message-Id: Date: Mon, 7 Apr 2014 10:04:35 +1000 To: linux-media@vger.kernel.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.6.235416 X-PMX-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' FORGED_FROM_GMAIL 0.1, HTML_00_01 0.05, HTML_00_10 0.05, MIME_LOWER_CASE 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_5000_5999 0, BODY_SIZE_7000_LESS 0, DKIM_SIGNATURE 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __ATTACHMENT_SIZE_0_10K 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FRAUD_BADTHINGS 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_VERSION 0, __MSGID_APPLEMAIL 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT_APPLEMAIL 0, __X_MAILER_APPLEMAIL 0, __YOUTUBE_RCVD 0' (Sorry in advance for probably breaking a few conventions of the mailing lists. First time using one so please let me know what I’m doing wrong) I’m writing this because of an issue I had with my Hauppauge HD-PVR. I record from my satellite set top box using component video and optical audio input. I basically use "cat /dev/video0 > ~/video.ts” or use dd. The box is set to output audio as AC-3 over optical, but most channels are actually output as stereo PCM. When the channel is changed between a PCM channel and (typically to a movie channel) to a channel utilising AC-3, the HD-PVR stops the recording as the set top box momentarily outputs no audio. Changing between PCM channels doesn’t cause any issues. My main problem was that when this happens, cat/dd doesn’t actually exit. When going through the hdpvr driver source and the dmesg output, I found the hdpvr driver wasn’t actually shutting down the device properly until I manually killed cat/dd. I’ve seen references to this issue being a hardware issue from as far back as 2010: http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-on-channel-change-Hauppauge-says-too-bad . I tracked my issue to the file “hdpvr-video.c”. Specifically, “if (wait_event_interruptible(dev->wait_data, buf->status = BUFSTAT_READY)) {“ (line ~450). The device seems to get stuck waiting for the buffer to become ready. But as far as I can tell, when the channel is changed between a PCM and AC-3 broadcast the buffer status will never actually become ready. I haven’t really ever done much coding, but I wrote a really nasty patch for this which tracks the devices buffer status and stops/starts the devices recording when the buffer is not ready for a period of time. In my limited testing it has worked perfectly, no output is overwritten, the output is in sync and the recording changes perfectly between stereo AC-3 (PCM input is encoded to AC-3 by the hardware) and 5.1 AC-3 no matter how frequently I change the channels back and forth. All changes are transparent to cat/dd and neither exit prematurely. Manually killing cat/dd seems to properly shut down the device. There is a half-second glitch in the resultant where the recording restarts, but this amounts to less than a second of lost footage during the change and compared to having the device hang, I can live with it. I haven’t had the device restart recording when it shouldn’t have. So considering my code is really messy, I’d love it if someone could make some suggestions to make the code better and make sure I don’t have too many logic errors. I don’t really know too much about kernel coding practices either. And if anyone who’s experienced my issue could try out my change and let me know that’d be great. You will have to run "v4l2-ctl --verbose -d /dev/video0 -c audio_encoding=4” to ensure the 5.1 AC-3 is captured properly (AAC capture of 5.1 sources doesn’t seem possible) and "v4l2-ctl --verbose -d $MPEG4_IN --set-audio-input=2” to capture from the optical input. Thanks in advance, ryley --- a/hdpvr-video.c 2014-04-07 09:34:31.000000000 +1000 +++ b/hdpvr-video.c 2014-04-07 09:37:44.000000000 +1000 @@ -453,11 +453,17 @@ ret = -EAGAIN; goto err; } - - if (wait_event_interruptible(dev->wait_data, - buf->status == BUFSTAT_READY)) { - ret = -ERESTARTSYS; - goto err; + int counter=0; + while (buf->status != BUFSTAT_READY) { + counter++; + msleep(20); + if (counter == 30) { + v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev, + "limit hit, counter is %d, buf status is %d\n", counter, buf->status); + counter=0; + ret = hdpvr_stop_streaming(dev); + ret = hdpvr_start_streaming(dev); + } } }