From dan@dennedy.org Thu Dec 20 04:46:35 2001 Return-Path: Delivered-To: jimmac@peabody.ximian.com Received: (qmail 27275 invoked from network); 20 Dec 2001 04:46:35 -0000 Received: from trna.ximian.com (141.154.95.22) by peabody.ximian.com with SMTP; 20 Dec 2001 04:46:35 -0000 Received: from warblade.dennedy.org (mail@ip-216-23-49-132.adsl.one.net [216.23.49.132]) by trna.ximian.com (8.11.6/8.11.6) with ESMTP id fBK4krc23800 for ; Wed, 19 Dec 2001 23:46:53 -0500 Received: from [10.143.0.98] (helo=xtremedia.dennedy.org) by warblade.dennedy.org with esmtp (Exim 3.12 #1 (Debian)) id 16GoAi-0003gA-00; Wed, 19 Dec 2001 16:22:40 -0500 Subject: Re: [gst-devel] mpeg2 instead of DV From: Dan Dennedy To: Erik Walthinsen Cc: Jakub Steiner , libdv-devel@lists.sourceforge.net In-Reply-To: References: Content-Type: text/plain X-Mailer: Evolution/0.16 (Preview Release) Date: 19 Dec 2001 23:57:04 -0500 Message-Id: <1008824225.4532.199.camel@xtremedia> Mime-Version: 1.0 X-Evolution-Source: pop://jimmac@localhost:1100/inbox Content-Transfer-Encoding: 8bit On Tue, 2001-12-18 at 19:45, Erik Walthinsen wrote: > This is definitely MPEG, a program stream. So you should be able to feed > it to a demuxer and get the video and audio out separately. The sample > starts at a rather random location, so `mpeg2dec -s` can't play it, but > something can. Looking at it closer, it appears somewhat malformed, so I have been in discussion with Jakub. I downloaded the sample, and I have been analyzing the hex dump. Keep in mind the file first contains a quadlet (4 bytes) indicating packet size. That does not come from the 1394 isochronous stream; Arne writes it into his "test" file format. Really, it is superfluous because the next quadlet is the iso packet header where the first 16 bit int contains the length of the packet! OK, I see from the iso packet header that this contains CIP headers (2 quadlets), which are extra headers above and beyond the MPEG data. Next, I need to see if there are empty packets that need to be stripped out. (Empty packets are a way to slow the data.) As I go through the data packet-by-packet, it appears that the data becomes misaligned. I wonder if it has been text munged? Anyway, yes, there are empty packets. For empty packets Arne reports a length of 12 and the iso packet header indicates 8. The 8 is for the two quadlets of CIP headers added to each packet. The pure MPEG data packets are 192 bytes each. With this info you can modify dvgrab's ieee1394io.cc:capture_raw(); however, as Erik points out, we do not know the start of frame indicator. int capture_raw() { int frames_read; int length; int dst_fd; raw1394handle_t handle; bool found_first_frame; int skipped = 0; char filename[256]; sprintf(filename, "%s.mpeg", g_dst_file_name); if ((dst_fd = open(filename, O_WRONLY | O_CREAT, 00644)) < 0) { perror("problem with output file"); usage(); exit(1); } fail_null(g_frame = (unsigned char*)malloc(RAW_BUF_SIZE)); handle = open_1394_driver(g_channel, raw_iso_handler); frames_read = 0; found_first_frame = false; while (!g_alldone) { raw1394_loop_iterate(handle); length = *(int*)g_frame; if (length >= 204) { frames_read++; if (frames_read > g_frame_count) break; write(dst_fd, (g_frame + 16), 192); } } close_1394_driver(g_channel, handle); free(g_frame); close(dst_fd); return 0; } Apply this new version of the function and try capturing using raw mode (not test). Then, try playing it with a couple of different players. Let us know!