Hi,
It's about time for a new status report.
First and foremost, some small maintainership notes:
I'm alive and kicking, I'm just overwhelmed by real-life work, and this
happens quite often recently. As personal policy, when the time for
transcode runs below the guard limit, I focus on the coding side only.
I FULLY ACKNOWLEDGE that code isn't the only nor the most important
piece of an opensource project, but that's the best I can do given the
circumstances.
In other words, the best indicator of the project progress is the commit
log. :)
+++
About the 1.2.0 status.
The development is undergoing on a private repo on my box. The reason
for going private is I broke^Wchanged a lot of things, but I honestly
believe that all changes are improvements[1].
The significant changes are the following:
1. Real, explicit extradata handling:
configure (in/out), open (in/out) (see below for open).
2. split multiplex() operation into write_{audio,video}.
3. split demultiplex() operation into read_{audio,video}.
4. new explicit flush() operation.
5. new explicit open() operation, formerly implicitely done
in configure() when needed.
6. new explicit close() operation, formerly implicitely done
in stop() when needed.
7. there is now codec compatibility list for audio and video.
A short rationale follows for each of the above.
#1 that's the easy one: previously we just don't have a real extradata
API/policy/whatever, just an outrageous hack. So, this is the real
starting point.
#2, #3 this was driven by the need to avoid to replicate the frame
ordering decision in every muxer. This means: given a pair of frames,
which one should to be written first into the on-disk stream? When I
discovered myself writting (roughly) the same decision code for ogg and
lavf muxer, I thought this decision should be taken on the upper layer.
However, I'm very open to discussion on this topic.
#4, #5, #6 those are easy too: just fixed some aknowledged former API
deficiencies.
#7 fixes an error of the previous API. There is no valid reason to mix
audio and video codecID on the same list.
The port of the codebase to the new API is almost ready, and currently
the test is in progress. The existing unit tests (testsuite/*) passes,
more unit tests are coming.
The push into the mainline will happen as soon as the very basic use
case work; I want to merge as soon as is possible.
Some other changes to the codebase are been pulled in by the 1.2.0/NMS
export layer work, so expect more messages describing them in the next
few days.
Discussion welcome.
+++
[1] this can sound kind of heretic, but after some work experiences I
started to appreciate the value of ABI and API stability.
This of course doesn't change the fact that bad APIs SHOULD be changed
soon or later, and I still firmly believe that refuse the change is a
mistake too. The key point is that every change should carefully
evaluated, and that isn't always true into the opensource world, and
most important that wasn't true in my early transcode days :)
Bests,
--
Francesco Romani // Ikitt
http://fromani.exit1.org ::: transcode homepage
http://tcforge.berlios.de ::: transcode experimental forge
