libdv-dev

[libdv-dev] Delaying a video signal: Some basic questions.

[Sergio R. <sr...@ya...>]

Hi, hope some of the expert in this forum can help me.

For a video art presentation involving several video signal (both recorded 
and live), the specification for one of the live signals calls for a delay 
of around five minutes before been exhibited. The video artist (a friend) 
called me for help but I'm afraid I'm way out of my league on this (I do 
mostly C programming for specialized databases engines under Linux). I 
thought I could use dvconnect to capture the signal (the camera, a SONY 
PC150 has a firewire connection) and playdv to show it five minutes later 
in a scheme like this:

dvconnect - | delay_five_minutes | playdv

Here, delay_five_minutes should be a program (easy to write) that takes its 
input from stdin, stores it in a disk buffer and begins to output it to 
stdout five minutes later (I also have plans to use two disks for these 
buffer, one for getting the data in and one for getting the data out and 
switch its use every five minutes).

The input should be taken through firewire, and the output must be SVHS.
Video quality is not an issue, so I can live with some dropped frames.
The signals will all be PAL, but the only testing environment I has to 
develop the solution is NTSC.

I have several questions regarding this rather crude solution.

1) I don't see any parameter in the man page for playdv to take the video 
stream from stdin. Is it posible?

2) How to use the TV-out connector found in NVIDIA and ATI cards for the 
delayed signal? What parameters should playdv be feed?
Guess it has something to do with the --display=(0|1|2|3) parameter but I 
have not the slightest idea about the differences between gtk, Xv, and SDL, 
and, unfortunately it's beyond the amount of effort I can put in this 
project to study them in detail. (also, since I do all of my work in 
console mode, I'd love to see the solution implemented without having to go 
into X-Windows or depend on some of its libraries).

3) Will it work? (the most I could get for the PC is a 2.4 GHz Pentium 4 
with 256 Mb of RAM).

I don't mind messing around a bit with the source code, but again, I don't 
have the time to study it in detail, so it should be simple and straight to 
the point.

Any other ideas?

Thanks in advance! (and hope you don't mind my poor English)

Sergio Roysen
Buenos Aires,
Argentina

Re: [libdv-dev] [PATCH] Encoding video in threaded applications

[Dan D. <da...@de...>]

On Sun, 2004-06-20 at 04:31, Johannes Sixt wrote:
> Since the video encoding routines make heavy use of static variables, it is 
> necessary to serialize all calls to dv_encode_full_frame() until all static 
> variables are eliminated. The attached patch introduces a mutex. I consider 
> this just a workaround - the proper fix is, of course, to get rid of the 
> static variables.
> 
> To test the current implementation I have used the attached test program. See 
> the comments at the top about compilation and usage. It writes the encoded 
> raw DV frames (which should be all gray) to stdout. You will see (eg. in 
> kino) that the encoded frames are not gray at all if the frames are encoded 
> in parallel, but they are if encoded sequentially.
> 
> Please apply the patch.

I applied your patch in CVS and added your test program too. When I run
the test program in parallel mode without the mutex locks, I am seeing
nice clean, gray images. I do not deny your results, but I am curious.

Re: [libdv-dev] FreeBSD 5.2 pthreads use

[Dan D. <da...@de...>]

On Fri, 2004-06-18 at 23:33, Steven M. Schultz wrote:
> Hi -
> 
> 	Small patch to configure.ac to accomodate FreeBSD (and OpenBSD)
> 	which have neither integrated threads in libc nor -lpthreads.
> 
> 	Instead you need to add "-pthreads" to the CFLAGS and LDFLAGS.
> 
> 	Attached is a patch which works but if there's a better way that's
> 	fine too ;)

applied in CVS

[libdv-dev] [PATCH] Encoding video in threaded applications

[Johannes S. <joh...@te...>]

Since the video encoding routines make heavy use of static variables, it is 
necessary to serialize all calls to dv_encode_full_frame() until all static 
variables are eliminated. The attached patch introduces a mutex. I consider 
this just a workaround - the proper fix is, of course, to get rid of the 
static variables.

To test the current implementation I have used the attached test program. See 
the comments at the top about compilation and usage. It writes the encoded 
raw DV frames (which should be all gray) to stdout. You will see (eg. in 
kino) that the encoded frames are not gray at all if the frames are encoded 
in parallel, but they are if encoded sequentially.

Please apply the patch.

-- Hannes

[libdv-dev] FreeBSD 5.2 pthreads use

[Steven M. S. <sm...@2B...>]

Hi -

	Small patch to configure.ac to accomodate FreeBSD (and OpenBSD)
	which have neither integrated threads in libc nor -lpthreads.

	Instead you need to add "-pthreads" to the CFLAGS and LDFLAGS.

	Attached is a patch which works but if there's a better way that's
	fine too ;)

	Cheers,
	Steven Schultz

[libdv-dev] Another Timecode question

[Vitor T. <vit...@mo...>]

Hi all,


I noticed that in the libdv implementation the timecode is inserted only =
above the 7th sequence of the DIF stream (function dv_encode_timecode). =
However reading the DV specifications there is not a mention to this =
fact and there are quiet of implementations that include the timecode in =
the first DV DIF sequence. It there a reason for this.

Best regards,
Vitor

Re: [libdv-dev] timestamp

[Mikhail R. <mr...@ra...>]

Hello,

Dan Dennedy wrote:

> > Can I use libdv to learn a frame's timestamp? If so - how?
> 
> use one of:
> 
> extern int dv_get_timestamp (dv_decoder_t *dv, char *tstprt),
>            dv_get_recording_datetime (dv_decoder_t *dv, char *dtptr),
>            dv_get_timestamp_int (dv_decoder_t *dv, int *timestamp),
>            dv_get_recording_datetime_tm (dv_decoder_t *dv, struct tm
> *rec_dt),

Thanks.

Now the question is: will this data be available, if the only thing I do
with the frame before this is:

dv_parse_header(dv_decoder, dv_frame);

where dv_decoder is of type dv_decoder_t, and dv_frame is a buffer with
the frame?

The matter is as follows. I want to put the timestamp decoding into a
*demuxer*, not a decoder. The demuxer is the Raw DV demuxer for MPlayer.
I'd like to have it create a subtitle layer with the date and time. Of
course I don't want to waste the CPU power for the full frame decode.

Yours, Mikhail Ramendik

Re: [libdv-dev] timestamp

[Mikhail R. <mr...@ra...>]

Hello,

Roman Shaposhnick wrote:

> > And how will ffmpeg be able to use the timestamp info?
>   
>   DV demuxer will generate an aux. stream with all the DV metadata
>   in it. You will read struct dv_metadata from it and access 
>   any given field.

But this will only be of any use if mplayer gets to use libavformat.  Or
does ffmpeg's own binary have a feature that will allow the making of
this metadata into subtitles?

Yours, Mikhail Ramendik

Re: [libdv-dev] timestamp

[Mikhail R. <mr...@ra...>]

Dan Dennedy wrote:

> Hey, it's neat to see some activity here and to hear from new names! 

Actually I did show up here before, with the problem of "audio block
failures". 

I still need to double-check what is at fault, by capturing the same
video several times and seeing if abf's remain. But if they do, this
might be a libdv bug.

Yours, Mikhail Ramendik 

Re: [libdv-dev] timestamp

[Mikhail R. <mr...@ra...>]

Roman Shaposhnick wrote:

> > Can I use libdv to learn a frame's timestamp? If so - how?
> 
>  Coming to the ffmpeg near you "real soon now" :-)

And how will ffmpeg be able to use the timestamp info?

Re: [libdv-dev] Fix for severe double-free bug and race condition

[Johannes S. <joh...@te...>]

On Freitag, 11. Juni 2004 03:33, Dan Dennedy wrote:
> On Thu, 2004-06-10 at 10:05, Johannes Sixt wrote:
> > But the variables dv_videosegment_t vs and (after my patch was applied)
> > bitstream_t bs can go onto the stack as a first step. I think it is not
> > necessary to allocate and release those objects in dv_decoder_new and
> > dv_decoder_free, because they are obviously only used as scratch
> > variables.
>
> OK, I am testing this.
>
> For now, I have left the bitstream pointer in the decoder struct so as
> not to change the binary interface. I think only the popt table would
> affected by the removal of this. However, is it correct that any
> utilities that are dynamically linked to libdv and libpopt would be
> affected by this ABI change?

I don't think that the libpopt ABI is affected (but I have not worked with 
libpopt, yet). From what I see from the code, only information (in particular 
offsets and pointers) is passed to libpopt from libdv. The libdv that is 
linked dynamically will pass the pointers and offsets that are correct for 
this particular instance, whether it is with or without the bitstream_t 
pointer.

The conservative approach is certainly to leave the bitstream_t member in 
place, in particular, since dv_decoder_t is a publically announced type.

-- Hannes

Re: [libdv-dev] timestamp

[Roman S. <Rom...@su...>]

On Sat, Jun 12, 2004 at 07:33:55PM +0400, Mikhail Ramendik wrote:
> Hello,
> 
> Roman Shaposhnick wrote:
> 
> > > And how will ffmpeg be able to use the timestamp info?
> >   
> >   DV demuxer will generate an aux. stream with all the DV metadata
> >   in it. You will read struct dv_metadata from it and access 
> >   any given field.
> 
> But this will only be of any use if mplayer gets to use libavformat. 

 I think they are using it. May be in CVS ?

> Or
> does ffmpeg's own binary have a feature that will allow the making of
> this metadata into subtitles?

  No, not really. But you can always hack ffmpeg.c into something
  that's suitable for your purposes.

Thanks,
Roman.

Re: [libdv-dev] timestamp

[Roman S. <Rom...@su...>]

On Sat, Jun 12, 2004 at 02:21:40AM +0400, Mikhail Ramendik wrote:
> Roman Shaposhnick wrote:
> 
> > > Can I use libdv to learn a frame's timestamp? If so - how?
> > 
> >  Coming to the ffmpeg near you "real soon now" :-)
> 
> And how will ffmpeg be able to use the timestamp info?
  
  DV demuxer will generate an aux. stream with all the DV metadata
  in it. You will read struct dv_metadata from it and access 
  any given field.

Thanks,
Roman.

Re: [libdv-dev] timestamp

[Dan D. <da...@de...>]

On Fri, 2004-06-11 at 08:08, Mikhail Ramendik wrote:

> I still need to double-check what is at fault, by capturing the same
> video several times and seeing if abf's remain. But if they do, this
> might be a libdv bug.

abf's are the result of error flags set in the dv stream from the
device. AFAIK, either a problem occured during the acquisition of the
footage on the device or the writing or reading of the storage media.

Re: [libdv-dev] timestamp

[Roman S. <Rom...@su...>]

On Thu, Jun 10, 2004 at 04:16:32AM +0400, Mikhail Ramendik wrote:
> Hello,
> 
> DV streams are known to contain timestamps for every frame (at least the
> camera can decode it).
> 
> Can I use libdv to learn a frame's timestamp? If so - how?

 Coming to the ffmpeg near you "real soon now" :-)

Thanks,
Roman.

Re: [libdv-dev] timestamp

[Dan D. <da...@de...>]

Hey, it's neat to see some activity here and to hear from new names! 

Re: [libdv-dev] timestamp

[Dan D. <da...@de...>]

On Thu, 2004-06-10 at 23:23, Jan Schmidt wrote:
> <quote who="Dan Dennedy">
> 
> > On Thu, 2004-06-10 at 22:03, Mikhail Ramendik wrote:
> > > Now the question is: will this data be available, if the only thing I do
> > > with the frame before this is:
> > > 
> > > dv_parse_header(dv_decoder, dv_frame);
> > 
> > Yes, no need to decode the frame. 
> 
> Isn't timestamp decoding done in dv_parse_packs? 

Yes, also call that. Thanks for the reminder.

Re: [libdv-dev] timestamp

[Jan S. <th...@ma...>]

<quote who="Dan Dennedy">

> On Thu, 2004-06-10 at 22:03, Mikhail Ramendik wrote:
> > Now the question is: will this data be available, if the only thing I do
> > with the frame before this is:
> > 
> > dv_parse_header(dv_decoder, dv_frame);
> 
> Yes, no need to decode the frame. 

Isn't timestamp decoding done in dv_parse_packs? 

Just checking...

J.
-- 
Jan Schmidt                                  th...@ma...

Open Source Software: Free as in Free Speech, not Free Beer

Re: [libdv-dev] timestamp

[Dan D. <da...@de...>]

On Thu, 2004-06-10 at 22:03, Mikhail Ramendik wrote:
> Now the question is: will this data be available, if the only thing I do
> with the frame before this is:
> 
> dv_parse_header(dv_decoder, dv_frame);

Yes, no need to decode the frame. 

Re: [libdv-dev] timestamp

[Dan D. <da...@de...>]

On Wed, 2004-06-09 at 20:16, Mikhail Ramendik wrote:

> DV streams are known to contain timestamps for every frame (at least the
> camera can decode it).
> 
> Can I use libdv to learn a frame's timestamp? If so - how?

use one of:

extern int dv_get_timestamp (dv_decoder_t *dv, char *tstprt),
           dv_get_recording_datetime (dv_decoder_t *dv, char *dtptr),
           dv_get_timestamp_int (dv_decoder_t *dv, int *timestamp),
           dv_get_recording_datetime_tm (dv_decoder_t *dv, struct tm
*rec_dt),

timestamp is for timecode. recording_datetime returns a date and time,
but its time is only to one second precision.

Re: [libdv-dev] Fix for severe double-free bug and race condition

[Dan D. <da...@de...>]

On Thu, 2004-06-10 at 10:05, Johannes Sixt wrote:

> The "statefulness" reduces to the use of global variables as temporaries in:
> 
> dct_block_mmx.S: scratch*
> idct_block_mmx.S: scratch*
> rgbtoyuv.S: TEMP*, [YUV]R0GR, [YUV]BG0B
> vlc_x86.S: m, mb_start, n_blocks

Thanks for the analysis on this guys.

> But the variables dv_videosegment_t vs and (after my patch was applied) 
> bitstream_t bs can go onto the stack as a first step. I think it is not 
> necessary to allocate and release those objects in dv_decoder_new and 
> dv_decoder_free, because they are obviously only used as scratch variables.

OK, I am testing this.

For now, I have left the bitstream pointer in the decoder struct so as
not to change the binary interface. I think only the popt table would
affected by the removal of this. However, is it correct that any
utilities that are dynamically linked to libdv and libpopt would be
affected by this ABI change?

Re: [libdv-dev] Fix for severe double-free bug and race condition

[Andraz T. <And...@gu...>]

V =E8et, 10.06.2004 ob 16:05 je Johannes Sixt napisal(a):
> Anyway, please consider to apply the patch I posted. It's minimally inv=
asive=20
> and fixes one obvious bug and a race condition.

and fast in order to get the thing out to distribution makers. some
programs will start to fail miserably if too many distributors go out
with a buggy 0.102.

bye
andraz

Re: [libdv-dev] Fix for severe double-free bug and race condition

[Johannes S. <joh...@te...>]

On Donnerstag, 10. Juni 2004 07:22, Stefan Lucke wrote:
> On Donnerstag, 10. Juni 2004 00:19, Dan Dennedy wrote:
>
> [ .. ]
>
> > Of course, I would love to remove the mutex. However, there are some
> > globals libdv uses, and I need to make sure they are simply tables and
> > not stateful.
>
> They are stateful, at least is vlc_x86.S "n_blocks, mb_start, ..?". Maybe
> that there are some in other assember sources too.

The "statefulness" reduces to the use of global variables as temporaries in:

dct_block_mmx.S: scratch*
idct_block_mmx.S: scratch*
rgbtoyuv.S: TEMP*, [YUV]R0GR, [YUV]BG0B
vlc_x86.S: m, mb_start, n_blocks

The use of $vlc in vlc_x86.c puzzles me. It doesn't seem to be used after 
dv_decode_vlc was invoked...

In principle, all these variables could be moved onto the stack. But as long 
as this has not been done, a mutex is required :-(

But the variables dv_videosegment_t vs and (after my patch was applied) 
bitstream_t bs can go onto the stack as a first step. I think it is not 
necessary to allocate and release those objects in dv_decoder_new and 
dv_decoder_free, because they are obviously only used as scratch variables.

Anyway, please consider to apply the patch I posted. It's minimally invasive 
and fixes one obvious bug and a race condition.

(and yes, I am subscribed ;-)

-- Hannes

Re: [libdv-dev] Fix for severe double-free bug and race condition

[Stefan L. <st...@lu...>]

On Donnerstag, 10. Juni 2004 00:19, Dan Dennedy wrote:

[ .. ]

> Of course, I would love to remove the mutex. However, there are some
> globals libdv uses, and I need to make sure they are simply tables and
> not stateful.

They are stateful, at least is vlc_x86.S "n_blocks, mb_start, ..?". Maybe that
there are some in other assember sources too.


-- 
Stefan Lucke

[libdv-dev] timestamp

[Mikhail R. <mr...@ra...>]

Hello,

DV streams are known to contain timestamps for every frame (at least the
camera can decode it).

Can I use libdv to learn a frame's timestamp? If so - how?

Yours, Mikhail Ramendik