Francesco:
Yes, I was a little distraught when I read that. I thought you had
to die to get out of maintainer roles? Wasn't that a life time
contract? ;-) It would be a shame if transcode dies. Of all the
encoding tools, I use transcode about 95% of the time. For anyone who
wants a nice playground for experimenting with video/audio filters,
transcode is the way to go. On the other hand, transcode lags a bit
(IMHO) when it comes to recent codec improvements. Like the ffmpeg.cfg
H264 headache. But I digress...
I have a yait patch update for v1.1.5. Patches attached. Forcing
the frame rates and hard frame dropping within the filter was a bad
idea. Let the user specify what he wants on the command line. It turns
out that the yait filter does a much better job when using soft frame
dropping anyway because of the large tolerance and window for missing or
extra frame duplicates. (Far less forced frame keeps and drops,
producing a smoother video). The tcyait tool patch adds an option to
drop a fixed frame within a telecined group. (This was useful when 3:2
pulldown wasn't used but simply an extra (interpolated) frame was added
for each group of five).
I suppose I really need to write a Wiki on this if I expect people
to try it out. I'll do that eventually. For variable fps NTCS
telecined video I still get the best results using yait. I've encoded
over 500 films using it and in the majority of cases was able to
reproduce the 24 fps original progressive frames for the entire film,
(with no frame blending). However, it always involves tweaking the
parameters of the analysis tool, so I'm still hesitant to incorporate it
into the filter itself as opposed to a stand alone tool. (Separate
discussion topic). Eventually I would want to see some kind of yait
interface within DVD::Rip.
I've attached the nextsub filter patch again. I sent this quite
some time ago pending review for inclusion but it's still not in.
Again, this was an enhancement to the extsub filter allowing zooming,
aliasing, opacity, forced subtitles, and better color and positioning
control. I think it was mostly NMS compliant, but really was just a
copy of the old extsub code and hacked. (There is still a very old
DVD::Rip thread to be pursued here).
The patches should apply cleanly to v1.1.5 (as built by gentoo).
Let me know if they don't.
When you have the time... Cheers.
Allan
Francesco Romani wrote:
> On Fri, 2010-02-05 at 10:27 +0100, Georg Martius wrote:
>
>
>> It would be great if you can stay available for consulting purposes for
>> further developments.
>>
>
> 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 am in fear that transcode is slowly going to die.
>>
>
> 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.
>
>
>> How many "active" developers are there at the moment?
>>
>
> 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.
>
>
>> How long would you thing it takes to get familiar with the code for a new
>> maintainer?
>>
>
> 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...
>
>
>> And a last question: How much time did you roughly spend on the project?
>>
>
> In the ol' good, funny, days, about 8-10 hours per week.
>
> Bests,
>
>
>
filter_yait_v2.patch.gz
Description: application/gzip
tcyait_fixeddrop.patch.gz
Description: application/gzip
filter_nextsub.patch.gz
Description: application/gzip
