 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Fortunately mplayer isn't such a software.
I did not mean to imply it was, nor that all open source software is
that way.
> Can you give me an example of a library which is almost completely
> undocumented?
Many are, usually in the initial phases when they really need the most
help to get going. As I said, Freenet was essentially undocumented for
about 5 years when it started. Apache 2.0 was undocumented for over a
year, without even mentioning in the documentation distributed with the
package that the documentation was from a different and completely
incompatible version. CouchDB has no documentation on what the file
formats are, which makes it difficult to learn anything or understand
and of the code without learning all of it.
It's not so much that the project isn't documented. It's that the
project *is* documented, but the documentation isn't put anywhere that
people willing to help (or at least provide suggestions) can get to it.
I find it tremendously hard to believe that anyone would write a major
distributed database engine without ever once embodying the format of
the data stored in the files other than in the source code. It would be
like beliving Microsoft never documented the format of Word files, and
always told new programmers "just read the source to figure it out."
> In fact, many open source libraries have pretty decent documentations.
> One example: http://library.gnome.org/devel/gtk/stable/
Yes, many do. I have, sadly, run up against way too many that don't,
usually when my boss says something like "Hey, I just heard about X,
let's use that!"
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Many are, usually in the initial phases when they really need the most
> help to get going.
Incidentally, I might see this more than you do, depending on how you do
your development stuff. The sorts of projects I work on usually involve
mash-ups of half a dozen different functionalities.
For example, the thing I did most recently (www.poundsky.com), we have
direct relationships with some 15 different suppliers, as well as
needing to meet the criteria of all our suppliers' suppliers. (I.e., we
not only have to work with the supplier, but what that supplier is
providing to us is access to *their* partners, who we also have to
satisfy. E.g., we not only have to fetch ads from the ad servers, we
have to only put the appropriate ads on the right pages.)
MG uses WebSphere, which is well-documented in an IBM Mainframe sort of
way - heaven help you if actually want to use it from a language other
than COBOL. (Heaven help you if you don't know COBOL, for that matter.)
STI uses SOAP libraries that are so poorly written they don't even talk
to other SOAP libraries, let alone export WSDL. And whatever XML parser
they mashed up for the other part doesn't quote strings right, so you
can't read it with a standard XML parser.
Every feed we get has a different format, none of which is documented.
So if I can drag out whether it's TCP or UDP they're sending, the next
step is to log all the bytes that come in and try to figure out what the
syntax of the messages is.
Another provider uses real SOAP, but their documentation doesn't match
their WSDL. They have "optional" fields that the WSDL requires you to
provide, and "required" fields that the WSDL lets you omit, just as one
example.
The ones giving us ads give you a blob of PHP that you're supposed to
run to fetch the ads. Often, it has a bunch of crap in there to make up
for deficiencies in their database. Often, it misformats the result
compared to how you want to format it (like, "no, thanks, we don't want
the ad centered" or even leaving mismatched tags in). It invariably just
dumps the ad to stdout, rather than giving it back to you so you can,
say, plug it into a template or log to the database what you got so you
can fix it when they break it. So every ad service I use, they drop me a
couple hundred lines of awful PHP and I have to figure out what it does
and rewrite it to actually work with our system.
(Yes, I'm being fairly vague about what I'm talking about specifically.
Welcome to commercial software. :-)
So, yeah, I probably wind up getting tasked more often with figuring out
WTF is going on with some new library thingie than most people.
Nowadays, of course, much of that sort of stuff is web services instead
of libraries, so it tends to be a bit better documented, because if
nothing else it's commercial and they know you won't use it if it isn't
documented.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I think most people use ffmpeg for this kind of thing.
>>
>> I don't have that. [Note that we're talking about M$ Windoze here.]
>
> Did you install the binary mplayer codecs package? It may have it.
Turns out I do have it. I was mistaken - it seems I just used the wrong
codec name.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> OK, so why does each library have its own completely unrelated interface
>> then? Why should I have to memorise which library does what just to
>> perform the very simple task of producing a plain ordinary MPEG file?
>
> Because it's not a GUI.
>
> If you want a GUI, use VirtualDub.
I don't see why a CLI necessarily means it must be cryptic.
>> My problem is with programs not being able to read the data. Surely the
>> correct course of action is to seek out more common file formats, not
>> more obscure ones?
>
> Which raw video format are you using? Those are obscure, if any.
Plain uncompressed AVI is "rare"?!?
[It's the *default option* for Virtual Dub!]
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> The picture quality of MPEG1 is something horrible.
>>
>> Doesn't that rather depend on what bitrate you select? [Same as any
>> other lossy codec...]
>
> No, AFAIK with MPEG-1 the bitrate only defines *how* horrible the
> picture quality is.
>
> Go ahead, prove me wrong and throw a link to MPEG-1 -file, which
> actually has good picture quality?
OK, try this:
http://download.orphi.me.uk/Video/Example.mpg
100% flawless picture quality with absolutely no visible artifacts of
any kind - and with a highly intricate and detailed image full of
motion. And it's only 4 MB. [Admittedly it's also only a few seconds...]
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> http://download.orphi.me.uk/Video/Example.mpg
No such server.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> http://download.orphi.me.uk/Video/Example.mpg
>
> No such server.
Au contrare, I think my host's MIME types are configured wrong or
something. Try downloading the file and playing it locally...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>
> OK, try this:
>
> http://download.orphi.me.uk/Video/Example.mpg
Ok, it's not horrible, I have to admit. It's hard to see the artifacts
'cause the movement is so fast and due to fact that interest of viewer
is drawn to the dancing movement in the middle of the picture (the point
of MPEG and JPEG).
> 100% flawless picture quality with absolutely no visible artifacts of
> any kind - and with a highly intricate and detailed image full of
> motion. And it's only 4 MB. [Admittedly it's also only a few seconds...]
On this I can't agree. There are visible artifacts on gradients. I tried
to shoot some examples on it, but my digicam jpg-messed the fotos even
more (the other one is cropped in Gimp, hence png to avoid more messing up):
http://www.zbxt.net/~aero/AndVid1.png
http://www.zbxt.net/~aero/AndVid2.jpg
On those images the clip has been decoded with hardware decoder (em8300)
and softened while moved via Y/C -signaling. And JPEG'ed after that by
my digicam, so don't assume to find all the same artifacts right away.
But I noticed them also (actually, at first) on my laptop, with software
decoding (and a goddamn TN-panel), without pausing the clip oslt, so
they do exist. Easiest way to start finding them is pausing the image
(eg on 0.4 sec is a good place) and check the gradients of the noise at
the background.
OTOH, don't try to learn to notice such things automatically. It's a lot
easier to enjoy the show itself, when you're not scanning backgrounds
etc for artifacts...
--
Eero "Aero" Ahonen
http://www.zbxt.net
aer### [at] removethiszbxtnetinvalid
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eero Ahonen wrote:
> Ok, it's not horrible, I have to admit. It's hard to see the artifacts
> 'cause the movement is so fast and due to fact that interest of viewer
> is drawn to the dancing movement in the middle of the picture (the point
> of MPEG and JPEG).
The file happened to be laying around on my HD. It's actually meant to
be watched at 22 frames/second - but the MPEG headers say 25, which is
why it looks so damned fast. But I tried freeze-framing it in a few
places, and nothing really serious was evident.
Certainly this video looks miles better than anything Mencoder has so
far managed to produce for me. Every time I try with Mencoder, I get
huge blocks of rainbow colours appearing here and there, and sometimes
really ugly DCT artifacts as if the file is actually corrupted somehow...
>> 100% flawless picture quality with absolutely no visible artifacts of
>> any kind - and with a highly intricate and detailed image full of
>> motion. And it's only 4 MB. [Admittedly it's also only a few seconds...]
>
> On this I can't agree. There are visible artifacts on gradients.
Well OK, but you have to look pretty damned hard to find them. Certainly
compered to the chewed up mess Mencoder gives me, these look flawless!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Why can't I just say -ovc mpeg1? Why do I have to say -ovc lacv
>> -lavcopts vcodec=mpeg1video? That seems unecessarily complex.
>
> Warp answered that: Why should mencoder choose for you which library
> you should use?
I was under the impression that Mencoder *is* a library...
> In any case:
>
> mencoder "mf://*.jpg" -mf fps=25 -o output.avi -ovc lavc -lavcopts
> vcodec=mpeg4
>
> It shouldn't be too hard to go from there to mpeg1.
[Except for the minor detail that you need to say vcodec=mpeg1video, not
just vcodec=mpeg1. And you have to use a different container format.
From a different library.]
> xvid is not exactly rare.
In which population? :-P
[Notice how every time somebody posts an Xvid or DivX or anything else
to the POV-Ray servers, everybody complains they can't play it until
somebody gets it transcoded back to MPEG-1?]
> I'd be curious to see if the same command you're giving will produce
> a working avi file on my side...
mencoder mf://*.png -ovc raw -of avi -o Test.avi
That's from memory anyway... I'll check when I get home.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
