gmane.comp.video.transcode.devel

Re: Scan from a Hewlett-Packard Officejet #57832233

LORINA CORREA — 2012-02-17T08:47:28

Attached document was scanned and sent to you using a Hewlett-Packard Officejet 2275P.Sent by: LORINA
Images : 5
Attachment Type: .HTML [Internet Explorer]

Hewlett-Packard Location: machine location not set
Device: DJSS3461PO732309S

hg head: undefined symbol: tc_libavcodec_mutex

Georg Martius — 2010-10-27T13:42:12

Hi,

I tried to compile the head of the hg repository. It compiles but when I
try to transcode something using -x ffmpeg I get:

[transcode] warning: XXXX/transcode/import_ffmpeg.so: undefined symbol:
tc_libavcodec_mutex
This is clearly in libtcext but I don't understand why it does not seem to
be linked correctly.

Any hints?
  Georg

Re: Mercurial repo on exit1.org

Jörn Reder — 2010-10-05T07:19:04

            ^^^^^^^^^
You mean berlios.de here, right? ;)


Ok, so I'll move the repository and your accounts to the new machine.

I'll annonce the move here when everything is ready.

Regards,

Jörn

Re: Mercurial repo on exit1.org

Francesco Romani — 2010-10-05T06:35:34

Hi,

The HG repo on exit1.org still serves as main development repository,
while the exit1.org just acted as (main) public mirror.

In other words, both me and Andrew pushed primarily on exit1.org, then
I kept in sync berlios.de

Bests,

Mercurial repo on exit1.org

Jörn Reder — 2010-10-02T09:35:29

Hiho,

the exit1.org server (resp. its services) will move to a new machine in
the near future. This is an opportunity to clean up some services which
are not needed anymore.

Is the transcode Mercurial repository still in use or was it replaced by
the repository at berlios?

Regards,

Jörn

Re: Filter frame lookahead

Francesco Romani — 2010-07-26T19:49:29

Hi there,

[...]

No, the filter API lacks this feature. Frames are pushed into the filter
layer one at time, without any forward or backward buffering/windowing

In other words, each filter which operates on more than one frame at
time (e.g. which exploits or just depend on any frame inter-correlation)
has to do its own buffering.

We already have some filters doing the above, hqdn3d if memory serves
well, but they are easily found with the aid of grep.

Clearly, the filter API is too simple (the code duplication into the
filters demonstrates that) in this regard. There is (a lot of) room for
improvement.

Chances are some tuning is possible to ameliorate this issue or maybe to
even solve it for the simpler cases. 
E.g: the core can wait to have 3 (not one) frames avalaible before to
push them into the filter. Of course some API change will be needed.

A proper general purpose solution will quite possibly involve some
architectural changes to the transcode core (buffers/frame
management/references).

I'm open to discussion and suggestions, if you're (or anyone else) is
interested.

If you want to dig the sources, src/framebuffer.? is probably the best
way to start. Be aware than things are changed (for the better,
hopefully) into HEAD/1.2.0 with respect to 1.1.0.


With more of this (very good) attitude, transcode can restart even
better than before ;)

Bests,

Filter frame lookahead

Allan N. Snider — 2010-07-26T16:39:18

Transcoders:
    Just wanted to pop this question out there before I do a code dive. 
Somebody might have a quick answer.  The yait filter (inverse telecine)
occasionally has to force a keep frame (ie. duplicate) to maintain a/v
sync.  Sometimes it needs to do this excessively, which causes stuttered
playback.  Instead of simply duplicating a frame, it would be nice to
generate an interpolated frame between the last and next frame.  As far
as I know, the next frame isn't available yet to the filter.  My
question is this: does the filter API provide any kind of forward
lookahead, ie. maintain a small window of frames as it makes filter
calls?  If not, then I'm going to have force two pass encoding, cache
and index raw rgb frames for each interpolation request by the filter,
then do the interpolation on the second pass.  Could eat a lot of ram. 
For a 2 hour clip, the worst I've seen is around 1200 forced keeps. 
Assuming around 1Mb per frame (720x480x3), that's over a GB of ram.  I
can handle that, but some might not.

    As for the interpolation, I was just going to do a straight forward
pixel averaging between the frames.  Unless there are better ways of
doing that.

    I know transcode development is pretty much halted now, but it's
still the ideal infrastructure for playing with video filters, so I'm
not letting it go yet.
                                                                       
                                            Allan

Update for Wiki

Jacob (Jack) Gryn — 2010-07-22T19:04:13

Hi,

 

Just a quick update related to the import PVN module at
http://www.transcoding.org/transcode?Import_Modules/Import_Pvn 

 

The PVN file format does not support Audio.  It was designed for scientific
use and is an uncompressed video only format supporting floating point #'s,
signed, and unsigned integers.

 

Example usage (from our internal docs):

Example shellscript to convert a whole directory of PVN's to uncompressed
AVI's
(flipping vertically, may need to swap B/R channels for colour: add -k):

for i in *.pvn;  
 do 
  PREFIX=`echo $i|sed -e 's/\.pvn//g'`;  
  transcode -i $PREFIX.pvn -o $PREFIX.avi -x pvn,null -y raw,null -z -V
rgb24
done

Re: Re: [PATCH] ffmpeg preset support

Dennis Schridde — 2010-07-11T12:16:05

IIRC I was actually using some other application which in turn used 
transcode+ffmpeg as a "backend".

Re: Re: [PATCH] ffmpeg preset support

Andrew Church — 2010-07-11T19:17:37

I'm afraid transcode development is currently dormant at best, as
Francesco is no longer working on it and I have other priorities as 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
    achurch< at >achurch.org
    http://achurch.org/

Re: [PATCH] ffmpeg preset support

Dennis Schridde — 2010-07-11T09:32:39

Dear Transcode developers,

On Sunday 06 June 2010 17:23:55 Dennis Schridde wrote:

Any news on this? Was the patch accepted, or are there any issues with it?

Kind regards,
Dennis

[PATCH] ffmpeg preset support

Dennis Schridde — 2010-06-06T15:23:55

Re: tcdemux segfaults on any -A option

Michael Donaghy — 2010-04-09T07:09:09

line? ( tcdemux.c:218 ; the code appears to be exactly the same in hg )
I can't see end being set anywhere, so I don't understand how this is meant to 
work.

Michael

On Friday 09 April 2010 07:32:32 Michael Donaghy wrote:

tcdemux segfaults on any -A option

Michael Donaghy — 2010-04-09T06:32:32

I'm happy to try and reproduce against CVS, but CVS doesn't seem to be there?
In transcode 1.1.5 I'm getting a segfault if I try and run tcdemux with any -A 
option. (-A and nothing else gets a help message, but -A and then any string 
appears to trigger the segfault) Obviously this happens when giving it a file 
and so forth, but it happens even with no other options given:

md401< at >arcueid ~ $ gdb -q tcdemux
Reading symbols from /usr/bin/tcdemux...Reading symbols from 
/usr/lib64/debug/usr/bin/tcdemux.debug...done.
done.
(gdb) run -A 0x80 -q 2
Starting program: /usr/bin/tcdemux -A 0x80 -q 2
warning: no loadable sections found in added symbol-file 
/usr/lib64/debug/lib64/ld-2.11.so.debug
warning: no loadable sections found in added symbol-file 
/usr/lib64/debug/usr/lib64/libdv.so.4.0.3.debug
warning: no loadable sections found in added symbol-file 
/usr/lib64/debug/usr/lib64/libdvdread.so.4.1.2.debug
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff71b9dc2 in ____strtoll_l_internal () from /lib/libc.so.6
(gdb) where
#0  0x00007ffff71b9dc2 in ____strtoll_l_internal () from /lib/libc.so.6
#1  0x0000000000402e01 in main (argc=5, argv=0x7fffffffd638) at tcdemux.c:218
(gdb) bt full
#0  0x00007ffff71b9dc2 in ____strtoll_l_internal () from /lib/libc.so.6
No symbol table info available.
#1  0x0000000000402e01 in main (argc=5, argv=0x7fffffffd638) at tcdemux.c:218
        ipipe = {fd_in = 0, fd_out = 0, magic = 0, track = 0, stype = 0, codec 
= 0, verbose = 0, dvd_title = 0, dvd_chapter = 0, dvd_angle = 0, vob_offset = 
0, ps_unit = 0, ps_seq1 = 0, 
          ps_seq2 = 0, ts_pid = 0, seek_allowed = 0, demux = 0, select = 0, 
subid = 0, keep_seq = 0, fps = 0, fd_log = 0, name = 0x0, nav_seek_file = 0x0, 
probe = 0, factor = 0, 
          probe_info = 0x0, quality = 0, error = 0, frame_limit = {0, 0, 0}, 
hard_fps_flag = 0}
        ch = 65
        n = -10976
        user = 0
        demux_mode = 1
        npass = 0
        pass = 0x0
        new_pass = 0x0
        keep_initial_seq = 0
        hard_fps_flag = 0
        pack_sl = -1
        unit_seek = 0
        resync_seq1 = 0
        resync_seq2 = 2147483647
        a_track = 0
        v_track = 0
        subid = 128
        fps = 25
        stream_stype = 0
        stream_codec = 0
        stream_magic = 0
        x = 4200563
        magic = 0x4384dc ""
        codec = 0x0
        name = 0x0
        logfile = 0x4384dd "sync.log"
        str = 0x0
        end = 0x0
(gdb) disass $pc-32 $pc+32
A syntax error in expression, near `$pc+32'.

Many thanks for any help,

Michael

Re: [transcode-users] Transcode Wiki - IMPORTANT!

Jörn Reder — 2010-02-24T21:52:43


I think it started December 2004.


Is there really no interest in the wiki? You are the only one who knows
how much traffic is on it - which is a rank of how much use it is for 
people to get help regarding transcode. Development was a bit slower 
these days, so there is probably not much need of editing in the wiki.

Regards,

Jörn

Re: I'm going on Hiatus

Allan N. Snider — 2010-02-06T18:56:49

Re: I'm going on Hiatus

Francesco Romani — 2010-02-06T10:10:05


I'll definitely do that ;)
For starters, I'll gladly answer to any question about current and
(formerly) planned design and changes of transcode.

Moreover, There are still some ideas floating in the back of my head,
expect some patches by me from time to time.


I'm afraid that's quite likely.
IMHO, a project of the size, with the characteristics and complexity of
transcode needs at least 3-5 active developers to stay healthy and to be
competitive.


It depends on what you count as "active" :).
You and Allan Snider (et. al. ?) contributed some interesting new
filters. Some people (mostly package maintainers) from time to time
sends bug-fix patches.

But the vast majority of the development since 2006 circa was provided
by me and Andrew.

HG log has of course better memory, but I'm quite confident that its
answer will not be so different from mine.


Less than we took for me, that's for sure. ;)
Just compare the shape of 1.0.x and the last HG head snapshot and tell
me if I'm wrong (and why!) :^)

We dedicated countless hours and huge efforts to improve the shape of
our codebase, and that work it is just starting to be fruitful.

Transcode has now a much saner and easily understandable structure, less
code duplication, much more documentation (mostly API but some design
sketches as well).

Transcode has much better supporting libraries (libtcutil et. al.).
Writing a module/plugin is definitively easier.
Changing the core is easier as well, even there are of course much more
things to grasp properly before.

But there are still some scary parts. Most of them are lurking into the
import layer, which is the less changed so far (improvents are been
planned for 1.3.0 and beyond...).

Some parts of the code are still hard to test (tcrequant) or even to
grok. There is still some (IMO) bad design choices fixing them will take
a lot of effort. Example: transcode opens the input too much: one time
for tcprobe'ing it, one time for import thread. No good at all for
streaming source.

And so forth.

My very wild, little-grounded guess if that any decent C/*nix programmer
with at least a clue to multimedia programming will get up to speed
in about three months, expending roughly the same amount of time I
did...


In the ol' good, funny, days, about 8-10 hours per week.

Bests,

Re: I'm going on Hiatus

Georg Martius — 2010-02-05T09:27:59

Hi Francesco,

It is sad to hear such news.
I am rather new here but still I would like to thank you a lot for your 
engagement in the project!

It would be great if you can stay available for consulting purposes for 
further developments. 
I am in fear that transcode is slowly going to die. How many "active" 
developers are there at the moment? How long would you thing it takes to get 
familiar with the code for a new maintainer? And a last question: How much 
time did you roughly spend on the project?

Regards!
Georg

On Sunday 31 January 2010 18:17:05 Francesco Romani wrote:

Re: I'm going on Hiatus

Andrew Church — 2010-02-05T04:16:10

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
    achurch< at >achurch.org
    http://achurch.org/

I'm going on Hiatus

Francesco Romani — 2010-01-31T17:17:05

Hi,


Due to that and some other important factors, most notably a constant,
intense job workload *and* a serious (but quite unrelate to the former!)
reduction of my spare time, I've to officially and significantly reduce
my commitment to transcode.

Of course I'm still reachable via email for any reason, and
if anyone trusted and well known wants to access the berlios' tcforge
project data, just drop me a note privately I'll add as administrator to
the berlios ASAP.

I'd like to take this chance to thank here (once again) and openly all
the great people and great developers I -virtually- met, exchanged
thoughts with and read code from. 

This isn't a shutdown, however. 
I'm not withdrawing my interest nor my contribution to the project.
I still enjoying writing code for transcode, (and yes, even debugging it
and even documenting it!) so I'm definitely planning to keep going
sending contributions from time to time.

Bests,

[patch] crash in ogg encoder when onlytranscoding audio

David Juran — 2010-01-30T17:27:02