Do you have one huge buffer that is continuously playing, and you like to insert data at-position-'now' whenever there is data?

You could use double-buffer and always insert data in the middle, then you get half the latency, but risk missing the start of a sound :)

@tboeckel

Ok, so that is the actual solution to the problem. I suspected that is what I have to do, and that's great. Thanks.

I got the impression that the "hidden implementation" also had a set of varargs, but maybe it actually doesn't. Varargs *only* exist in the API and are translated by the stub/glue code.

It's a bit sad that C make varargs even needed... In E one would use an inline list or struct, or list of struct which makes varargs unneeded and also allows typechecking.

@LiveForIt

Right, that explains SMTube. But does it mean it will still play videos, but not download them?

@LiveForIt

Thanks, but not exactly what I needed. I need to relay varargs, not use them.

See this example:

@zzd10h

They are different bounties, just under the same team: "AmigaOs4.1". Besides, the feanor code is going into the work of this bounty so if there is a link between them, it is just logical. It is still a separate bounty.

About SMTube: How do we know that SMTube is not using the YouTube v3 API already?

Hi

I need to make a stub for a varargsfunction, but how on earth do I relay the arguments??!

In a macro you can receive the args with '...' and send them on using __VA_ARGS__ but that doesn't work in a funciton.

Help.

Now, let's make sure we announce this bounty properly!!

Amigaworld.net is a must, and other sites as well I suppose.

How do we know SMTube doesn't already use the v3 API? It has probably been around for quite some time.

@tommysammy

Please remove AmiUpdate from the bounty! It's a waste of LiveForIt's time and our money because someone else can do it instead. That someone else will also do the install script at the same time. That's the only thing that makes sense.

I would also like to get the priorities straight:
1. New feanor ffmpeg integration (money has been payed to get this into our mplayer so it should be done first)
2. p96_pip fixes
3. Implementing menus in mplayer
4. 64Bit fix
5. Drag and Drop
6. Adding Screenshotdir and EXTPATTERN

What is the point of candy (menu, DnD, screenshot, file patterns) if mplayer isn't even working properly?

Merging code and get the codecs to work has to be done first. It would be nice to see a beta-release after each step. Then stuff that isn't really necessary to play videos, like menu, dnd etc can be implemented.

Install+AmiUpdate someone else should do in parallel.

@samo79

Right, this was about the p96_pip driver. Kind of missed that part... Haven't use that in a couple of years since the RadeonHD cards haven't had overlay.

@samo79

"OSD-non-working-at-all" is usually a path/font problem. OSD works for me in LiveForIt's mplayer.

Use Snoopy to see where it tries to load its config from. A preview version of MPlayer-GUI used wrong home-dir parameters when starting mplayer so it couldn't find its files.

@tommysammy

I think AmiUpdate should also be dropped form the bounty. LiveForIt said he'll do it for free, which means it doesn't have to be in the bounty. besides, if he decides he doesn't have time, someone else can do it and the bounty would still be valid.

AmiUpdate is not important also since it isn't updated very often.

Everything not essential to the mplayer code should not be in the bounty to prevent extra delays.

@ddni and all

It's important IMO to not burden LiveForIt with trivial things that does not require the build environment for mplayer.

Things like AmiUpdate and install script, anyone can do. You don't need to compile mplayer to do this, therefore someone else should do it instead of adding to the bounty, slowing down the important work, which is to make the codecs and video driver to work.

@BSzili

I think I had a quick look at some transmission code once. IIRC there was a problem with multi-threading and sockets mixed with Amiga signals, or something like that.

@broadblues

Yes, and what's most important, is to bring the new speed to existing apps. Then we need to update the datatype.

@xenic

Can't find any ref to openjpeg at a500.org. Do you mean the JpegTools? I already have the JpegTools compiled for Altivec.

Edit: Ok, found it. It's the Jpeg2000. Maybe... Jpeg2000 is incompatible with normal jpeg but perhaps I could link with both libs so it supports both :)

That's why you use the library and not the lib

Anyway, I've started reinventing the wheel, if nothing else then for my own use. But a datatype would be more useful than the library.

@tommysammy

Quote:

Issue 26, 27, half 34 already in MPlayer-GUI. If you want GUI-functionality, use MPlayer-GUI.

@samo79

Quote:

50,51: How/who could test p96_pip?
53: Too slow. Use composition or p96_pip.

47,49: Of course it should NEVER crash. Better to disable a feature if it can't be fixed.

@BSzili

Without reading the entire thread, I'd like Transmission Qt (or something similar)

@broadblues

I have now read the jpeg API more closely, and the changelog for libjpeg from 6a to 9a. I see nothing that would make this incompadible in any way.

Sure 9a has some new switches that can increase lossless compression at the expense of total jpeg incompatibility etc. But that are special switches, not the default mode. The jpeg.library API have no access to these switches.

It's not that major. It's not totally incompatible at all, it just needs some tweaks, and there are new features, if one care to explore... I won't. But I really don't want to reimplement the library Total waste of time.

The big bonus here is libjpeg-turbo with full Altivec-acceleration! With a datatype built on this (WarpDT is already at 9a, just not the turbo version I assume) we could be flipping through digicam picture like a tablet