>Hiho,
>
>I just realized that this mail should NOT go to the mailing list and
>changed all passwords mentioned publically here...
I was wondering about that ;)
I tried the new passwords you sent, but they don't work either -- same
error about cookies.
--Andrew Church
http://achurch.org/
n I set the AdminPass to: Apagirima721
The preferences page won't accept that either -- I get the same error
about cookies.
It looks like Bitbucket allows you to associate wikis with repositories,
so as a last-ditch option I guess I could migrate the wiki content there.
Let me know if you want
the "CVS access" chapter is
>rather outdated as well ;)
Hmm, I can't seem to find where I saved the wiki admin password so I
can't edit it at the moment. If you send me the password I'll get that
updated.
--Andrew Church
http://achurch.org/
Hi Jörn,
I still have the HG repository here (including a few occasional fixes I've
made more recently, like support for newer FFmpeg versions). I can upload
that to Bitbucket if you like.
--Andrew Church
http://achurch.org/
>
>Hi David,
>
>thanks for your response.
well.
With regard to this particular issue, however, transcode does have a
native x264 interface (use e.g. -y x264,lame,avi -N h264,mp3) so there's
no need to go through ffmpeg.
--Andrew Church
achu...@achurch.org
http://achurch.org/
I wish I could say I'll pick up where you're leaving off, but I'm afraid
I'm in much the same boat. But I'll also keep on committing changes from
time to time as well (I'm working on cleaning up HEAD a bit right now).
Take care!
--Andrew Church
achu...@achu
o zap the repository and re-clone it anyway, just to be
safe. I guess we could always think about moving to SourceForge or
Google Code if you're worried about a repeat...
--Andrew Church
achu...@achurch.org
http://achurch.org/
hat (or at least
>it doesn't complain loudly).
>No symbol clash, no complains, no warning, anything.
There's actually a good reason why this works--but I'd hate to spoil
the fun of figuring it out for yourself. Or else I'm just too lazy to
write it up at the moment. :)
--
27;t work, we can always go to shared libraries
as a fallback.
I ought to try and find some time to figure out what state my own local
repository is in so I can actually make use of it...
--Andrew Church
achu...@achurch.org
http://achurch.org/
er's
filesystem with unnecessary shared objects.
With respect to "just doesn't work", granted I haven't actually tried it
myself (: but why doesn't it work? Is there some weird symbol
dereferencing or some such that causes problems if -lavi/-lwav is added
to each module that requires them, instead of to the core?
--Andrew Church
achu...@achurch.org
http://achurch.org/
d the tc* programs link to them
>will save a fair number of headaches and annoyances (at least to me).
Out of curiosity, what annoyances have you had with them? I've never
run into any trouble.
--Andrew Church
achu...@achurch.org
http://achurch.org/
I'll take care of this; sorry about the delay.
--Andrew Church
achu...@achurch.org
http://achurch.org/
>I've made a bug report about this issue, but it has not been touched in months
>now, and I wasn't sure what to do. I was trying to update the FreeBSD port of
wasn't aware of the special -W usage, and
while one could make an argument for using a different option instead of
hacked parameters, we shouldn't break things in 1.1 either way. (:
--Andrew Church
achu...@achurch.org
http://achurch.org/
ay
to support e.g. installations where transcode is used as a backend to
something else).
--Andrew Church
achu...@achurch.org
http://achurch.org/
>Hi.
>
>As per $SUBJECT. We need an official GUI bundled with the official
>package, as mplayer or handbrake (www.handbrake.fr) do.
>I'd like to propose this key:
>
>[+] new feature
>[*] changement/improvement (not bugfix)
>[!] bugfix
>[-] feature dropped
>
>(More will be added if needed)
Looks good to me!
--Andrew Church
achu...@achurch.org
http://achurch.org/
l in the date when we release, like with the transcode-0.6
entries in the current ChangeLog. What would you think about that? (We
could also have explicit lists of additions/changes/removals instead of
the +/*/- marking if you think that'd be better.)
--Andrew Church
achu...@achurch.org
http://achurch.org/
er we need to save every single change there is another
issue; it might be better to make a more concise list of changes per
version instead, like what was done for the early 0.6.x versions.
--Andrew Church
achu...@achurch.org
http://achurch.org/
is (: but do you have any
ideas what's going on here?
--Andrew Church
achu...@achurch.org
http://achurch.org/
tory locally I had problems with push/pull missing some of the
changesets... Anyway, I'll let you know what the result is shortly.
--Andrew Church
achu...@achurch.org
http://achurch.org/
ked out.
If you believe this is in error, please contact your system administrator.
Can you look into this? Alternatively, if you can download the repository
from http://achurch.org/transcode.tar.bz2 and extract it on the server,
that'd be fine too.
Thanks again!
--Andrew Church
achu...@achurch.org
http://achurch.org/
FYI, I'm starting the Mercurial adjustments now, so don't commit anything
new to the exit1.org repository for the moment.
--Andrew Church
achu...@achurch.org
http://achurch.org/
>As for forwarding changes to berlios, I've no strong opionions yet.
>*Perhaps* is better to start pushing manually.
That'd be fine with me, and yeah, probably a good idea until we're used
to the new setup. (Though it should only be a matter of adding commit
and incoming hooks to push the changes out.)
--Andrew Church
achu...@achurch.org
http://achurch.org/
here you want to put the final repository),
so just let me know your thoughts and I'll get started on it.
--Andrew Church
achu...@achurch.org
http://achurch.org/
it almost
perfect (I just had to tweak a couple of branch merges, IIRC).
--Andrew Church
achu...@achurch.org
http://achurch.org/
>Plus, a new topic:
>
>* switch to graphicksmagic (http://www.graphicsmagick.org/)
Good find! I have no argument with that whatsoever. (:
--Andrew Church
achu...@achurch.org
http://achurch.org/
hread_3:encode_audio) --> ...
i.e. thread 1 pulls from thread 2 and thread 3 at the same time, so it
only has to wait for max(wait_2,wait_3), not (wait_2 + wait_3).
Admittedly I'm not sure how well this will work in practice, since the
demux stage will be single-threaded and not (ye
declare
(dynamically, since e.g. DVDs can have any number of streams) what inputs
and outputs it uses.
>(and don't be afraid to say "you still don't get it!" if it's the
>case ;))
No, I think you got it this time. (: Your method is similar, anyway, and
in fact I think I like it better than the one I proposed.
--Andrew Church
achu...@achurch.org
http://achurch.org/
>On Wed, 2009-01-07 at 19:48 +0100, Francesco Romani wrote:
>> On Wed, 2009-01-07 at 10:39 +0000, Andrew Church wrote:
>> > >What we essentially need is a safe way for a filter _plugin_ (while I
>> > >was referring to the core part handling the filtering) to deliv
making each filter copy frames to a distinct output buffer will
help enforce this idea of having unconnected input and output streams,
I think. (And now that I think of it, most filters end up doing
something or other to the entire frame anyway, so not doing zero copy
won't make much differ
I'm more concerned about the possibility of
resource leakage in general. As a rule, I prefer a mechanism that's
robust against leakage (e.g. by having a single free() call that applies
to every module) over one which relies on multiple modules to all do the
right thing (e.g. call free
ff for the moment if
it looks like it'll complicate things, and come back to it later once
the basic model is functioning.
--Andrew Church
achu...@achurch.org
http://achurch.org/
outputs. This would mean we can't do zero copy processing,
but for a first implementation I don't think we should try and stretch
that far. (And it wouldn't be that hard to implement anyway; it'd
probably suffice to add a reference counter to each frame buffer and let
the filter call fr
;The only drawback is until the sliding window code gets committed, HEAD
>will be broken. But reverting the framebuffer code in HEAD is not an
>option for me.
Agreed. I haven't played around with the (old) framebuffer code much
myself, but from my few peeks at it I have to say I wasn
the
moment, it should just be a matter of assigning a frame number and "ready"
flag to each buffer; then the export layer can just wait for each frame's
"ready" flag in sequence, while the core delegates out frames to the
individual filter threads as they become idle.
--Andrew Church
achu...@achurch.org
http://achurch.org/
imagine encoders could make better use of multiple threads than
filters could anyway.
--Andrew Church
achu...@achurch.org
http://achurch.org/
ady.
>While we're on topic, what do you think about moving enterely to
>berlios.de ?
I don't see a problem with that. It looks like developer.berlios.de is
basically a SourceForge clone? As long as it doesn't try to get in my
way with weird JavaScript tricks or annoying F
offline. You do have to
learn to deal with revision numbers varying by repository, but I don't
think we're making much use of CVS version numbers as it is, so I doubt
that'd be much of a problem.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
r output and changing --use_rgb to
-V rgb24). Can you check again and see if the problem still occurs?
If it does, please mention:
- Which version of transcode you tried
- Whether or not it happens with no "--accel" flag, with "--accel C",
and with "--accel a
ptions will be obsolete in later
x264 versions.)
P.S. Yes, I'm still alive -- I just had an 11-month-long non-maskable
interrupt from work to deal with. (:
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
hould go much, much faster. That said,
NMS could probably use a seek_to_frame() method for demultiplexors that
could do an instant seek if the input source and file format supported it.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
functionality, save perhaps for transcode's
difficulty dealing with pipes (one of the things scheduled to be fixed in
the new module system). I also don't see what the maintainedness of an
external library has to do with anything; code doesn't rot away just
because it's not constantly being changed.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
transcode aims to be a _utility_, not a _library_
like libav* (and the "ffmpeg" executable doesn't count; it's not much
more than a wrapper).
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
t system,
please test and let me know if there are any problems.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
Happy New Year! I hope everyone is enjoying / has enjoyed their holiday
season of preference. (:
A quick question for Francesco: Did you have any issues with the revised
patch I suggested to fix the type problems in the NUV importer? If not,
I'll go ahead and commit that to HEAD.
--A
treams on hand to test with.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
---
Index: import/nuv/README.rtjpeg
===
RCS file: /cvstc/transcode
you had a patch
along those lines in the works; is that the case? If not, I'll see what
I can put together.
(*) The _proper_ solution would be to get rid of it entirely and link it
in from an external library, but I seem to recall failing to find
such a library last time I looked.
thin air... oh well. ;)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
to
look into a few issues on CVS HEAD if need be.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
= latest version at all times (even after a .0 release), and only
branch the old version when I want to start making changes toward a new
version (that won't be included in the stable release).
Then again, given my, uh, minimal contributions lately, what I think may
not be relevant. (:
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
. (Now if
only I can get faad2 to compile...)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
. I agree that PVM should be
disabled for the moment; maybe change the configure script to output a
warning if --enable-pvm3 is given?
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
ntrivial to port; many have tried but none have yet
>succeeded.
Oh well, it was worth a thought. I suppose we'll have to use --disable-mmx
on OSX Intel until Apple sees fit to get with the rest of the world...
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
ar.gz
cd binutils-2.17
./configure --prefix=/usr
make
make install
;)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
e
use of .balign rather than .align here would avoid such potential trouble,
and I'll look into making that change on CVS HEAD when I have a chance.)
Note that you can disable assembler code entirely by passing --disable-mmx
to ./configure (but this can slow transcode down considerably depe
s.
>If noone object, I'll go ahead quickly
Looks fine to me. Besides, the history will still be there if for whatever
reason we still need it (it just won't be in the same place).
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
>I just added a snapshot of 1.1.0 to the tree as well.
>
>Thanks guys! :)
Thanks to you as well. (: Now I just need to find three minutes together
to actually do something with transcode these days...
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
>I've seen filter part mostly (not the tcyait tool), and the code itself
>looks good. I've no problem for inclusion (Andrew?).
Just for the record, I have no complaints. I also have no spare time
to take a detailed look, sorry... ;)
--Andrew Church
[EMAIL PRO
cessing rules that virtually every other
Unixy program obeys. Not that those rules don't have their own
difficulties, as demonstrated here, but if we're going to break them I'd
much rather break them all at once...)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
to choke.
Fixed in CVS (both single and double quotes work). However, note that
the shell also processes quotes, so in order to use -x like this you need
to write:
transcode -x mplayer='"-vf eq2=0.9,pp=dr"',mplayer
or
transcode -x mplayer="'-vf eq2=0.9,pp=dr'",mplayer
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
>Attached patch address both issues outlined above. Feel free to comment.
This looks fine to me.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
le headers from the second and subsequent
files and concatenating them, e.g. something like:
$ (cat file1.nuv; tail -c+73 file2.nuv file3.nuv) >all.nuv
$ transcode -i all.nuv [other options]
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
t;this. It works for me, though I've only had occasion to use it once or
>twice.
There are a few issues with the patch itself (no static variables are
allowed in shared objects, for one), but the logic looks sound, so I'll
commit a similar patch shortly. Thanks for the report!
>As I said: we could use autotools and cmake in parallel, so we could test
>cmake without drawbacks.
Hmm. Well, if you're willing to put together a cmake build
environment, I'd certainly be interested in at least taking a look at it
(well, when I have more time on my han
command-line use is considered deprecated. In any case, I
would be nervous about using a tool that rewrites user-edited files like
this; as complex as the autotools suite is, it does follow the standard
input-file-to-output-file process, so it's easy to track the effects of
changes.
heir ASCII equivalents in CVS HEAD.
>
>Why to not use UTF-8 character instead ?
For exactly the same reasons: they won't show in non-supporting
environments (such as mine).
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
ch", the character before "streich" is an
O-umlaut, which probably doesn't show on the reporter's terminal (as it
didn't on mine), and all such non-ASCII characters have been converted to
their ASCII equivalents in CVS HEAD.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
cker to hack little changes into something that already works, more or
less, than to redo the whole thing from scratch. Maybe one of these days
I'll see if I can get any use out of my IRC Services configure script
instead...
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
gh to be honest,
part of the problem is that autoconf doesn't make it easy to do things like
command-line checks cleanly--you end up having to split code for processing
options into multiple parts.)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
>If you try and run ./conf
e'. 'Make' went
>through all the directories and did nothing! Did I miss something?
Nope, I goofed. Found and fixed, thanks for the report. (Make sure
you rerun autoreconf -f -i after updating from CVS, and if you have a patch
for import_nuv.c, please send it along.)
--A
gi-bin/transcode?Download
crystal:/usr/local/src/cvs/transcode> cat .cvsignore
Makefile
Makefile.in
aclocal.m4
autom4te.cache
autotools
config.log
config.status
config.h
config.h.in
configure
[...]
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
input or output that it happened on, but I think my gut feeling was that
mplayer was broken). Quick things off the top of my head: What command
line did you use? Does adding --export_asr 2 (for 4:3) or --export_asr 3
(for 16:9) help?
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
ne was deleted quite a while ago. Have you regenerated
filter/Makefile.in since your last cvs update? (autoreconf -f -i)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
ead against it, far be it from me to
stop you. (: I would suggest, however, that you limit any changes to
fixing bugs in the current code, rather than trying a redesign that would
just have to be changed again later (and might hamper our subsequent
efforts to complete NMS).
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
point of a wrapper like
>pwrite which continues on meaningless errors (EINTR) but stops on
>larger errors.
That would be my own take as well (and is how I've written similar
routines in some of my personal projects), but as I'm sure you realize
after going through the transco
e a write() that doesn't return EINTR: i.e., if an
error occurs after writing some data out, it should return the number of
bytes successfully written, not -1.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
e/close on a regular file? some ioctl()s are involved?
Presumably one would do something like the opposite of dvgrab/kino,
using libiec61883 and whatever else, but again this is not something we
should be thinking about right now. We need to get NMS finished before
trying to add yet more functionality.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
ink about having to match up stream parameters between each input
file. I think we ought to drop directory mode entirely for 1.1.0 and
reintroduce it after we get the import system working under NMS, which
should make things much easier.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
option, but I'd rather avoid a routine like the import_write() you
suggest that exits on error, and instead have the check and bail at the
point where fwrite() is called; that'll make it easier to go through and
just replace all the import_exit() calls with error returns later.
ce everything into a single pass until
we can rethink transcode's command line entirely (which is _definitely_
not happening for 1.1).
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
abile to control log colorized output.
>Maybe a little less clean but effective.
>
>I like b) most even here.
That seems reasonable to me as well.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
Francesco, do you have any idea on this? I don't do much (well,
anything) with -x vob, and I don't really have the time to look into it
in detail at the moment.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
>Hi,
>
>I'm just wondering if the VO
>OK, I'm adding flush hooks on encoder core (src/encoder.c) following
>approximatively this model. Hopefully code will hit CVS in a few days.
>Please bug me if I start being late.
Thanks, and don't worry--I'm awful busy at the moment myself...
--Andrew Church
[E
the user has.
I figure that as long as transcode is still in CVS, we can assume
up-to-date versions of other libraries (though a configure check is
probably in order). Once 1.1.0 is released, then the code will start
getting messy, I imagine.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
e fact that I'm on a dual-core system?
I've left --threads at default, so it _should_ still be 1...
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
in English.
Does anyone object if I just get rid of the entire directory? Speak now,
as in before the next time I ls /usr/local/src/cvs/transcode, or forever
hold your peace ;)
docs/ needs to be cleaned up too, but that's a slightly more
cumbersome undertaking...
--Andrew Church
[
a quick look at tcmodule*.h, but it doesn't
look like they're in the structures yet. Actually, since we already have a
stop(), it might be simpler to let stop() handle file closing and add a
start() method for file opening--that way we can also redefine configure()
so that it's only for configuring and doesn't act like a start() as well.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
is that a bug in x264
(a missing EMMS instruction somewhere) can cause bizarre floating-point
errors in transcode. Either disable acceleration with --accel C (slow!)
or apply the patch I posted to the x264-devel list:
http://www.via.ecp.fr/via/ml/x264-devel/2006-10/msg00044.html
until the bug is
Right now I think we only need to worry about module interface
functions--local stuff can do whatever it wants, and the main code doesn't
need to worry about it.
And now I need to get to sleep before the sun comes up again ;)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
Sorry, I didn't realize that was you ;) I though TC_EXPORT_* were
part of OMS and therefore going away. If we're going to use constants, we
should probably pick better names. (Maybe just TC_OK and TC_ERROR?)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
ed as -v -f, and -v
causes transcode to print its version and exit immediately. If there's
any hang going on, it would be a program/script expecting transcode to
output something and not properly handling cases when it doesn't.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
>I accidentally typed:
>
>-vf pp=ha/va/dr \
>
>instead of:
>
>-J pp=ha/va/dr \
>
>and produced a nasty lockup with hung children.
I can't reproduce this. What was the full command line?
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
I hope we can get done. But after 1.1.0,
as you say--it's not critical (as long as people don't use huge -u values).
>I defintively must figure out how to live without sleeping :^)
You and me both ;)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
scode to allocate only as much space as was actually
needed for processing, but there's currently no way to propogate size
changes through the processing pipeline, so that'll have to wait for a
future version.)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
;)
>
>But 51.16.0 is okay, right?
Yup, sorry if that was confusing. I was trying to test the -m
problem after upgrading FFmpeg yesterday (the version at that time being
51.15.0), and all of a sudden transcode was crashing left and right.
Nearly sent me into a panic before I noticed
audio file. It's fixed now, thanks for
the report.
> libavcodec version: 51.16.0
While I'm here, let me mention that 51.15.0 will make transcode
crash and burn, just in case anyone else recently upgraded FFmpeg and
discovered that all of a sudden they couldn't transcode an
27;m looking into a workaround, but
the immediate solution is to upgrade to GCC 4.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
und in comments in most
source files, is now an Oe). Will Unicode eventually make it as a
worldwide text encoding standard? Only time will tell...
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
ree' field is the index of buffer that DOES NOT have the 'real'
>video frame data in the pair of buffers that vframe_list_t
>carries (so it has 0/1 possible values).
Sounds like that's the problem. (: Yes, ptr->free should indicate
which buffer is _not_ being us
about what it was supposed to do, but
since libtc didn't pay it any attention it wasn't really meaningful. ;)
It might still be a good idea to implement a switch like that, but that
can be re-added after the code to handle it is in place, rather than
trying to drag around old code that wasn't designed for it.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
be any
regressions at first glance. If something does pop up, comment out the
#define NEW_CMDLINE_CODE
line in src/transcode.c to re-enable the original processing code. The
new code will still get compiled in, but (aside from the moved variables)
won't get used.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
1 - 100 of 129 matches
Mail list logo
