linux1394-devel

libdv

[Arne S. <ar...@sc...>]

This is very cool.

To display an AVI file generated by dvgrab using playdv:

dd bs=1 skip=65032 if=test001.avi > test001.raw

playdv test001.raw

It works only on NTSC images though. And it displays only the first frame.

Great job!

Arne

-----Original Message-----
From:	Charles 'Buck' Krasic [SMTP:kr...@cs...]
Sent:	Wednesday, April 19, 2000 4:23 PM
To:	Simon Vogl
Cc:	lin...@li...
Subject:	Re: xdv version 0.1


Yes, libdv does 4:1:1.  See:  

	http://libdv.sourceforge.net/

The ftp area for libdv has an NTSC bitstream file we captured with a
Canon Elura.  

-- Buck

Simon Vogl <si...@tk...> writes:

> btw, does anybody have a device working with the 4:1:1 coding as
> defined by the SMPTE standard? I originally wrote the decoder for
> this scheme, and had a hell of a time figuing out the 4:2:0
> arrangement of the Macroblocks :)

> Have fun,
> Simon 

_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

Re: libdv

[Charles 'B. K. <kr...@cs...>]

Arne Schirmacher <ar...@sc...> writes:

> It works only on NTSC images though. 

If someone were to provide us with some PAL data, we could get it
working very easily indeed.  

PAL is one area where IEC 61834 and SMPTE 314M differ slightly.  IEC
61834 uses 4:2:0 for PAL.  I havn't looked to closely at that yet.
SMPTE 314M uses 4:1:1, and is trivial to accomodate.

> And it displays only the first frame.

This is very easy to fix.  Erik should have that done shortly.

> Great job!

> Arne

Thanks!

-- Buck

Re: libdv

[Erik W. <om...@cs...>]

On 19 Apr 2000, Charles 'Buck' Krasic wrote:

> > And it displays only the first frame.
> This is very easy to fix.  Erik should have that done shortly.
Though... I don't have a working firewire setup here at home, and the only
dvgrab-captured AVI file I have is bogus.  If someone could send me a
short (5-frame) AVI from dvgrab, I can get this working pretty quickly.

Alternately, Arne seems to know best precisely what format it is and how
to deal with the AVI code he's got.  Perhaps it'd be easier to hack up an
extractor as part of dvgrab, sharing the RIFF code?

         Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user

Re: libdv

[Alastair M. <ala...@aj...>]

Arne Schirmacher wrote:

> To display an AVI file generated by dvgrab using playdv:
> 
> dd bs=1 skip=65032 if=test001.avi > test001.raw
> 
> playdv test001.raw


It looks to me (after a very cursory glance) that playdv wants a raw
input stream that looks like the "--raw" output from dvgrab minus the
short packets and length data, which is a simple enough change to do.
(I was playing with just that a couple of days ago.)

Alas I don't have access to the system I have all that loaded on right
now (it's at home, I'm at work), it's something I'll play with tonight.
And maybe have raw output go to stdout so one could try something like
   dvgrab --raw | playdv

This is cool, the DV stuff is all starting to come together.  Now if
we could only write it back...

-- Alastair

So much unwritten code, so little time...

dvgrab patch supports playdv (libdv)

[Alastair M. <ala...@aj...>]

Hi,

  I modified dvgrab a bit (added an option) so that it can output files
in a format that 'playdv' (part of libdv) will recognize directly.  The
patches are appended below, basically it adds a "--dv" option, i.e.
   dvgrab --ntsc --dv --frames 150 foo
would write 150 frames to foo.dv, and then
   playdv foo.dv
would display it.

The performance of playdv has room for improvement: I get about 2 to
3 frames/second on my machine (a 233MHz winchip -- which supports
MMX and 3DNow but otherwise has only about 156 bogoMips performance),
this with the first release of libdv (I think there've been some
improvements since).

On other note -- the "pond.dv" file from the libdv folks seems to be
recorded in progressive-scan mode, not interlaced.  The interlaced
data from my Sony TRV-103 that I've been testing with has a lot of
motion (the camera was panning) so playdv spends about 40% of its
time doing the 2-4-8 idct (and another 40% doing ycrcb->rgb conversion).
To make the image look nicer at the low frame rate I added code to
playdv to deinterlace the image just prior to display (basically
just copy every second scan line to the previous one, effectively
doubling the pixel height and halving the vertical resolution).
I'm working on adding sound decoding now.

--- here's the patch for dvgrab to output playdv-friendly files ---

*** dvgrab.cc   Tue Apr 18 12:28:24 2000
--- new/dvgrab.cc       Fri Apr 21 23:43:22 2000
***************
*** 35,39 ****
  #define RAW_BUF_SIZE  (10240)
  
! enum { PAL_FORMAT, NTSC_FORMAT, AVI_FORMAT, RAW_FORMAT, TEST_FORMAT,
UNDEFINED };
  
  int   g_alldone;
--- 35,39 ----
  #define RAW_BUF_SIZE  (10240)
  
! enum { PAL_FORMAT, NTSC_FORMAT, AVI_FORMAT, RAW_FORMAT, TEST_FORMAT,
DV_FORMAT, UNDEFINED };
  
  int   g_alldone;
***************
*** 129,133 ****
  }
  
- 
  int raw_iso_handler(raw1394handle_t handle, int channel, size_t
length,
                      quadlet_t *data)
--- 129,132 ----
***************
*** 254,257 ****
--- 253,258 ----
                  } else if (strcmp("--test", argv[i]) == 0) {
                          g_file_format = TEST_FORMAT;
+               } else if (strcmp("--dv", argv[i]) == 0) {
+                       g_file_format = DV_FORMAT;
                  } else if (strcmp("--pal", argv[i]) == 0) {
                          g_dv_format = PAL_FORMAT;
***************
*** 567,575 ****
  
          frames_read = 0;
          while ((!g_alldone) && (frames_read < g_frame_count)) {
                  raw1394_loop_iterate(handle);
                  length = *(int*)g_frame;
!                 write(dst_fd, g_frame, length + 4);
!                 frames_read++;
          }
          close_1394_driver(handle);
--- 568,631 ----
  
          frames_read = 0;
+ 
+         while ((!g_alldone) && (frames_read < g_frame_count)) {
+                 raw1394_loop_iterate(handle);
+                 length = *(int*)g_frame;
+               write(dst_fd, g_frame, length + 4);
+               frames_read++;
+         }
+         close_1394_driver(handle);
+         free(g_frame);
+         close(dst_fd);
+ 
+         return 0;
+ }
+ 
+ /* capture in a format suitable for playdv (part of libdv) */
+ 
+ int capture_dv()
+ {
+         int   frames_read;
+         int   length;
+         int   dst_fd;
+         raw1394handle_t handle;
+       bool    found_first_frame;
+       int     skipped = 0;
+ 
+       char    filename[256];
+       sprintf(filename, "%s.dv", 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) && (frames_read < g_frame_count)) {
                  raw1394_loop_iterate(handle);
                  length = *(int*)g_frame;
!             if (length == 496) {
!               if (!found_first_frame) {
!                       if (g_frame[16] == 0x1f &&
!                           g_frame[17] == 0x07)
!                               found_first_frame = true;
!                       else skipped++;
!               }
!               if (skipped > 500) {
!                       printf("skipped too many without finding
frame\n");
!                       break;
!               }
!               if (found_first_frame) {
!                       write(dst_fd, (g_frame+16), length-16);
!                       if (g_frame[16] == 0x1f && g_frame[17] == 0x07)
!                               frames_read++;
!               }
!           }
          }
          close_1394_driver(handle);
***************
*** 612,615 ****
--- 668,675 ----
                          capture_avi();
                          break;
+ 
+               case DV_FORMAT:
+                       capture_dv();
+                       break;
  
                  default:

Re: dvgrab patch supports playdv (libdv)

[Charles 'B. K. <kr...@cs...>]

Alastair Mayer <ala...@aj...> writes:

> Hi,

>   I modified dvgrab a bit (added an option) so that it can output files
> in a format that 'playdv' (part of libdv) will recognize directly.  The
> patches are appended below, basically it adds a "--dv" option, i.e.
>    dvgrab --ntsc --dv --frames 150 foo
> would write 150 frames to foo.dv, and then
>    playdv foo.dv
> would display it.

Very nice.

> The performance of playdv has room for improvement: I get about 2 to
> 3 frames/second on my machine (a 233MHz winchip -- which supports
> MMX and 3DNow but otherwise has only about 156 bogoMips performance),
> this with the first release of libdv (I think there've been some
> improvements since).

Yes, our first priority has been to achieve correct playout.
Synchronizing with sound is an exception, since video performance has
to be better than real-time for normal playout.

> On other note -- the "pond.dv" file from the libdv folks seems to be
> recorded in progressive-scan mode, not interlaced.  

Yep.  A nice feature to have in a camcorder.  :)

> The interlaced data from my Sony TRV-103 that I've been testing with
> has a lot of motion (the camera was panning) so playdv spends about
> 40% of its time doing the 2-4-8 idct (and another 40% doing
> ycrcb->rgb conversion).

You observations are very astute.  Videos with motion and lots of
2-4-8 dcts suffer a major penalty in the current version of libdv.

The 2-4-8 idct in libdv is pathologically slow.  

I have a C version of 2-4-8 idct based on the AAN algorithm, the same
one that the Intel 8-8 MMX'd idct is based on, nearly complete.
MMX'ing that will follow.  Once that gets integrated, presence of
2-4-8's will have no impact on performance.

The ycrcb->rgb code has a similar story.  

Actually, we consider everything after macroblock placement to be the
"final video mile", which isn't really properly part of libdv.
Playdv.c does it out of necessity, in probably the dumbest way
possible, for the purpose of testing.

Eventually, that "final video mile" is better handled by format
independent components.  This is where the current soup that are Xv,
DGA, SDL, DRI, Hermes, gstreamer, etc. will hopefully come together.

> To make the image look nicer at the low frame rate I added code to
> playdv to deinterlace the image just prior to display (basically
> just copy every second scan line to the previous one, effectively
> doubling the pixel height and halving the vertical resolution).

Sounds like a sensible interim approach.

> I'm working on adding sound decoding now.

Great!  

-- Buck

> --- here's the patch for dvgrab to output playdv-friendly files ---

  [ snip ]

Re: dvgrab patch supports playdv (libdv)

[Arne S. <ar...@sc...>]

Alastair Mayer wrote:
> 
> Hi,
> 
>   I modified dvgrab a bit (added an option) so that it can output files
> in a format that 'playdv' (part of libdv) will recognize directly.  The
> patches are appended below, basically it adds a "--dv" option, i.e.
>    dvgrab --ntsc --dv --frames 150 foo
> would write 150 frames to foo.dv, and then
>    playdv foo.dv
> would display it.




Great, I will merge it in the next release.

The "correct" way to do it (imho) however is modifying the playdv
program so that it can use a common file format for DV. But it is good
to have an intermediate solution available.

Arne