headers
Kent Loobey | 1 Jan 2004 01:33
Favicon

ADS Technology PYRO A/V Link

The "ADS Technology PYRO A/V Link" is supposed to read Composite, S-VHS, and 
Component formats in through an IEEE 1394 (DV) link.  Does anyone know why 
this wouldn't work?

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Permalink | Reply | 0 comments |
headers
Egor Kobylkin | 2 Jan 2004 16:36
Picon

DV pipe to Mencoder (does not work)

Hi,

I have had good experience with mencoder triple pass dv->divx encoding 
so I want to use it with the Kino DV pipe feature.
But I can not make even one pass mencoder get the piped stream from 
Kino. When I put the following line in ffmpeg_divx.sh as one of the 
case options:

"4")  mencoder -ovc divx4 -divx4opts br=1300 -vop pp=0x20000 -oac 
mp3lame -lameopts br=224 -o outputKino.divx - ;;	

I keep getting the error message

No such file or directory 
MPEG: FATAL: EOF while searching for sequence header.

The same line works just fine with command line pipe (DV file is the 
same as loaded in Kino)

 cat MyGrabbedDVfile.dv | mencoder same_options_here - ;

FFMPEG piped input (that is originally in the ffmpeg_divx.sh) works 
also just fine. 

Any suggestions what should I do here? 
To me it seems like mencoder does not get enough data in the first 
moment to recognize the input format and start sucking from the pipe, 
so it drops out. But why?

<lyrics>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Yates | 3 Jan 2004 17:40
Picon

Re: DV pipe to Mencoder (does not work)

On Fri, 2004-01-02 at 16:36, Egor Kobylkin wrote:

> I have had good experience with mencoder triple pass dv->divx encoding 
> so I want to use it with the Kino DV pipe feature.
> But I can not make even one pass mencoder get the piped stream from 
> Kino. When I put the following line in ffmpeg_divx.sh as one of the 
> case options:

Well, I had no idea that mencoder could (finally) read DV on stdin -
thanks for letting us know...

As a general rule, the theory is that you can create your own private
scripts in ~/kino/exports (so, if you or anyone can create any more
working scripts, please let us know :-)).

> "4")  mencoder -ovc divx4 -divx4opts br=1300 -vop pp=0x20000 -oac 
> mp3lame -lameopts br=224 -o outputKino.divx - ;;	
> 
> I keep getting the error message
> 
> No such file or directory 
> MPEG: FATAL: EOF while searching for sequence header.

Current CVS of mencoder is failing similarly. Had different results when
I added a -cache 4096 to mencoder (different != good - really hung
kino... :-/). My gut reaction is that it has something to do with
[utterly horrible] g_spawn glib functions I was forced to use....

I'll investigate further - would be nice to get this one working...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florin Andrei | 5 Jan 2004 04:10
Gravatar

Re: dvgrab verbosity and man page question

On Tue, 2003-12-09 at 08:26, Dan Dennedy wrote:
> On Tue, 2003-12-09 at 02:42, Florin Andrei wrote:
> > I'm using dvgrab-1.4 with the following flags:
> > dvgrab --autosplit --size 0 --format dv2 --opendml \
> >     --noavc --buffers 200 name-
> > If i experimentally drop "--size 0" then i get some messages, but only
> > when a new file is generated because of size, not when because of scene
> > change!
> 
> Yes, that is a bug then. The goal was to display the same message each
> time a file is closed. 
> 
> > Issue #2:
> > In the man page, there are these two entries:
> > -i, --interactive
> > -i, --noavc
> > Obviously, one of them must be wrong! :-)
> 
> Right, --noavc has no short option.

Any chance for a bugfix release any time soon?
I'm asking this because i'm doing some packaging, and i'd like to know
if the software is going to change soon after i make the packages. And,
of course, i'd like to use releases as bug-free as possible.

--

-- 
Florin Andrei

http://florin.myip.org/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Dennedy | 5 Jan 2004 04:23
Favicon

Re: dvgrab verbosity and man page question

On Sun, 2004-01-04 at 22:10, Florin Andrei wrote:
> On Tue, 2003-12-09 at 08:26, Dan Dennedy wrote:
> > On Tue, 2003-12-09 at 02:42, Florin Andrei wrote:
> > > I'm using dvgrab-1.4 with the following flags:
> > > dvgrab --autosplit --size 0 --format dv2 --opendml \
> > >     --noavc --buffers 200 name-
> > > If i experimentally drop "--size 0" then i get some messages, but only
> > > when a new file is generated because of size, not when because of scene
> > > change!
> > 
> > Yes, that is a bug then. The goal was to display the same message each
> > time a file is closed. 
> > 
> > > Issue #2:
> > > In the man page, there are these two entries:
> > > -i, --interactive
> > > -i, --noavc
> > > Obviously, one of them must be wrong! :-)
> > 
> > Right, --noavc has no short option.
> 
> Any chance for a bugfix release any time soon?

both of these are fixed in cvs along with some other important bugfixes.

> I'm asking this because i'm doing some packaging, and i'd like to know
> if the software is going to change soon after i make the packages. And,
> of course, i'd like to use releases as bug-free as possible.

yes, I will try to release in the next couple days.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florin Andrei | 5 Jan 2004 06:45
Gravatar

dvgrab-1.4 and CTRL-C

I was running this script:

#!/bin/sh
name=$1
dvgrab --autosplit --size 0 --format dv2 --opendml \
    --noavc --buffers 200 ${name}-

While the camera was playing, i hit CTRL-C in the xterm running the
script. Result: the dvgrab process became unkillable (well, kill -9 is
not the _real_ solution).

Finally, i did a "killall -9 dvgrab", the last file seems to be more or
less ok (will do a more thorough test later).

--

-- 
Florin Andrei

http://florin.myip.org/

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Permalink | Reply | 0 comments |
headers
The Surprises | 7 Jan 2004 07:43
Picon

multitrack timeline

Hello,
I sent an email out a few days ago, but it got stopped by the
list patrol because my email address has changed and it thought I wasn't
a member.  I've been waiting for the list owner to send it through but
it looks like it's not gonna happen, so I'll type it again :(

Over a year ago now I had started working on a multitrack timeline
editor for Kino.  However due to work and home getting busy, I hadn't
touched the code for many months.  I was thinking about getting back
into it (actually I've already spent a couple days going through the
code and making lots of modifications based on some new ideas), and I
was wondering if there has been any other attempts at creating a
multitrack editor.  If development has already started, I don't wish to
recreate the wheel.

At the time I had stopped working on it, I had the GUI basics there.  I
could visualize video frames/audio waveforms and move things around, but
one of the reasons I was stalled then was the lack of a multitrack aware
data model.  One of the changes I've been making to my original code
(beside lots of cleanup) is removing any real state to the timeline.  It
is (or will be) entirely dependent on the DOM for any and all data
retrieval or setting.  With that said, it won't be much more than a
single track timeline until I know how I'll be interfacing with the DOM.
Has there been any progress making the DOM multitrack aware?

Thanks,
Jason

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
(Continue reading)

Permalink | Reply | 6 comments |
headers
acanon | 8 Jan 2004 10:20

Feature Request from Polidori: XML Export Log to support downstream tools

Over at Polidori-devel, we're trying to make a GUI front end to DVDAuthor. Kino is the tool of choice for us.
Since DVDAuthor is chapter (scene) oriented, we are impressed that Kino easily deals with multiple video
files using its SMIL project format. Indeed, DVDAuthor also has an XML format. But Kino only uses XML for
its project file format, and that means only DV files, never the MPEG files that all DVD authoring software
must use it *its* front end. Kino produces MPEG files like a dream with its glorious Export facility. But
when you're done you just have a directory full of files.

We would like to see Kino's doExport() facility enhanced to produce an XML-formatted log of its activity
once export commences. If SMIL is suitable that would be fine. The actual format is not important to us, as
one XSLT transform will carry us into any other needed format. I would note that a) other downstream video
processing tools besides Polidori and DVDAuthor might well benefit from this opportunity for ease of
integration, and b) the opportunity to include other useful statistics within the XML format, such as
MPEG statistics, picture dimensions, audio track information, or other debugging output that might be
used to trace a bad file or render.

We would certainly be willing to donate time in introducing an experimental patch to Polidori that could be
tested and shown to provide no deleterious effect to the present behavior of doExport(). Essentially, we
would be examining the debugging facility, and where a useful statistic is currently output to stdout, or
stderr, we would include code to append a named XML text element onto our libxml2 xmlDoc. At the end of the
export process, we simply serialize this xmlDoc to an indicated file. The behavior could be switched on
and off easily, and could also be an configurable option at compile time. My experience with XML suggests
that the very modest-sized XML documents we are likely to produce should produce no significant strain
(especially not to the sorts of platforms on which people are going to tend to process video most of the time
:) And certainly kilobytes on the heap, but not me
 gabytes, and unlike video, not very often. :(

Thanks,

Alan Canon <acanon <at> bellsouth.net>
Polidori Development Team
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Dennedy | 8 Jan 2004 19:46
Favicon

Re: Feature Request from Polidori: XML Export Log to support downstream tools

On Thu, 2004-01-08 at 04:20, acanon <at> bellsouth.net wrote:
> Over at Polidori-devel, we're trying to make a GUI front end to
> DVDAuthor. Kino is the tool of choice for us. Since DVDAuthor is
> chapter (scene) oriented, we are impressed that Kino easily deals with
> multiple video files using its SMIL project format. Indeed, DVDAuthor
> also has an XML format. But Kino only uses XML for its project file
> format, and that means only DV files, never the MPEG files that all
> DVD authoring software must use it *its* front end. Kino produces MPEG
> files like a dream with its glorious Export facility. But when you're
> done you just have a directory full of files.

yep, I and a few others have noted this parallel. In particular, if you
do not split files in Export/MPEG, it would be easy to generate a
dvdauthor XML containing the filename and chapter timecodes.

> We would like to see Kino's doExport() facility enhanced to produce an
> XML-formatted log of its activity once export commences. If SMIL is
> suitable that would be fine. The actual format is not important to us,
> as one XSLT transform will carry us into any other needed format. I
> would note that a) other downstream video processing tools besides
> Polidori and DVDAuthor might well benefit from this opportunity for
> ease of integration, and b) the opportunity to include other useful
> statistics within the XML format, such as MPEG statistics, picture
> dimensions, audio track information, or other debugging output that
> might be used to trace a bad file or render.

That sounds a bit more than I was thinking, but let me tell you about
something else that could be included in the XML output. In Kino CVS and
next release is a new metadata editing feature. The W3C SMIL standard
allows for attributes on seq (our scene): title, copyright, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Dennedy | 8 Jan 2004 20:17
Favicon

Re: multitrack timeline

On Wed, 2004-01-07 at 01:43, The Surprises wrote:
> Hello,
> I sent an email out a few days ago, but it got stopped by the
> list patrol because my email address has changed and it thought I wasn't
> a member.  I've been waiting for the list owner to send it through but
> it looks like it's not gonna happen, so I'll type it again :(

Hi Jason! Yes, we remember your work and are glad to hear from you
again.

> Over a year ago now I had started working on a multitrack timeline
> editor for Kino.  However due to work and home getting busy, I hadn't
> touched the code for many months.  I was thinking about getting back
> into it (actually I've already spent a couple days going through the
> code and making lots of modifications based on some new ideas), and I
> was wondering if there has been any other attempts at creating a
> multitrack editor.  If development has already started, I don't wish to
> recreate the wheel.

No. However, let me make you aware of some recent changes that affect
you. For one, Kino is now GTK2. Also, we are removing GNOME
dependencies. However, GNOME2 now specifically packages the canvas
widget seperately for GTK-only programs.

Next, Charlie and I have a new project for a client, and it will also be
the basis of a replacement media subsystem for Kino. This project (mlt
on SourceForge) is already multitrack aware, and it does not yet
integrate the previously discussed DOM (but it does require an unrelated
business-specific deserialisation method).
(Continue reading)

Permalink | Reply | 5 comments |

Gmane