FFmpeg and WMA v2 - win2k working build exist?

[trodas]

I would like to mention, that I'm using ffmpeg to decode many wma and other audiotracks and other things. Using a 9MB big version ( FFmpeg version SVN-r16573, Copyright (c) 2000-2009 Fabrice Bellard ) I come to wma v2 audio, that this older version can't decode. So I decided to take a look at some more recent build, yet there are a problem each time I try to run almost any version of FFmpeg bilds available to download there:
http://ffmpeg.zeranoe.com/builds/win32/static/

http://s11.postimage.org/x6vxduec3/ffmpeg_win2000_sp4.png

I tried these:
ffmpeg-0.7.1-win32-static.7z
ffmpeg-0.7-rc1-win32-static.7z
ffmpeg-0.8-win32-static.7z
ffmpeg-1.1.1-win32-static.7z
ffmpeg-1.1.3-win32-static.7z
ffmpeg-20130216-git-b9c5448-win32-static.7z
ffmpeg-git-1aeb88b-win32-static.7z
ffmpeg-git-41a097a-win32-static.7z
ffmpeg-git-9d4cb45-32-bit-static.7z
...yet none of them work and all of them display this error I show above, speaking that it cannot find the input connection to the procedure _aligned_free in msvcrt.dll ...

Is this a known bug? Or are there some older version of ffmpeg that will work, and decode wma v2 audio?

Or are there other FFmpeg builds, witch did not require anything over Windows 2000 SP4 that I do have and use (and love)?

[pandy]

search for ffmpeg compiled with GCC - MSVC from version (AFAIR 2008) can give this error (M$ changed API to new - not compatible with older Win NT)

[LoRd_MuldeR]

I'm pretty sure the "zeranoe" FFmpeg builds are done with MinGW/GCC. Support for MSVC has only been added to FFmpeg/libav very recently. And many extra libraries, like x264, still don't support it. Consequently it seems that either recent MinGW/GCC or FFmpeg itself started using API functions that were not available in Windows 2000. And it really isn't surprising that developers don't care about operating systems that have reached their "end of life" many years ago ;)

Even the "extended" support for Windows 2000 has ended almost three years ago! Given the countless critical security vulnerabilities Microsoft has fixed in their Windows operating systems since then (and given that many of those fixes effected all NT-based systems), Windows 2000 now is full of critical security vulnerabilities that are never going to be fixed. Windows XP will meet the same fate in a not too distant future, so it's time to get an up-to-date Windows (I would recommend version 7, as version 8 is a disappointment) now! Either that or switch to an alternative operating system (Linux!?). As a side note, I keep a VM with Windows 2000 for test purposes and I noticed that now you can't even get an up-to-date web-browser for that system (Firefox stopped working long ago, Opera now stopped working too and a recent Flash Player doesn't work either). Same goes with Antivirus software (my old Avira has expired, current Avira won't install). Hopeless, really...

[trodas]

Hmmm, I like my old good OS, so I just have to look for software that work :)
I got suggested to install the M$ C++ files:
http://www.microsoft.com/en-us/download/details.aspx?id=5638
...but the dll in question (msvcrt.dll from 2003) stays the very same. Another msvcrtd.dll is added with more recent creation date (2008), but that is another file name...

[LoRd_MuldeR]

I got suggested to install the M$ C++ files:
http://www.microsoft.com/en-us/download/details.aspx?id=5638
...but the dll in question (msvcrt.dll from 2003) stays the very same. Another msvcrtd.dll is added with more recent creation date (2008), but that is another file name...

Starting with Windows 2000, MSVCRT.DLL (the one without any suffix) is a component of the operating system. It doesn't need to be installed separately. If it is updated, then via Winodws Update. But not for Windows 2000, anymore ;)

The Visual C++ 2005 redistributable package from your link is for the MSVCRT80.DLL and friends (i.e. the runtime DLL's that belong to Visual Studio 2005). This won't help at all, if the application has not been compiled with Visual Studio 2005 and thus doesn't use MSVCRT80.DLL. The same applies to the Visual C++ 2008 redistributable package (MSVCRT90.DLL) or the Visual C++ 2010 redistributable package (MSVCRT100.DLL). MinGW/GCC compiled binaries use MSVCRT.DLL!

Also: MSVCRTD.DLL or MSVCRT??D.DLL are "debug" versions. They are only used/required by debug builds. Completely unrelated with release versions...

Hmmm, I like my old good OS, so I just have to look for software that work :)

Well, good luck then. I will send you a PM when I find an up-to-date FFmpeg that runs on my old C64 :p

But seriously, even if the developers still did care about Windows 2000 (and the usually they don't), it will become more and more difficult to target that platform, when even the development tools (compilers, etc) drop support for Windows 2000. For example, the last Visual Studio that could target Windows 2000 was VS2008. And with VS2012 they even dropped support for Windows XP (was only re-added with "Update-1" after massive protest from the community).

BTW: The Dependency Walker (http://www.dependencywalker.com/) is extremely helpful to track down DLL dependency issues...

[pandy]

And it really isn't surprising that developers don't care about operating systems that have reached their "end of life" many years ago ;)

Even the "extended" support for Windows 2000 has ended almost three years ago! Given the countless critical security vulnerabilities Microsoft has fixed in their Windows operating systems since then (and given that many of those fixes effected all NT-based systems), Windows 2000 now is full of critical security vulnerabilities that are never going to be fixed. Windows XP will meet the same fate in a not too distant future, so it's time to get an up-to-date Windows
---
Hopeless, really...

There large amount various devices not connected to network some with Embedded version of Windows 2k and to be honest this system was sufficient more than enough (i don't see anything new in XP when compared to 2k) but i understand why M$ behave like this.

[LoRd_MuldeR]

I think you really can't complain about the support policy for Windows. Windows 2000 got support for ~10 years, Windows XP even for ~13 years. Compare that to Mac OS X, where generally only the current version plus the direct predecessor are supported. With their release cycle of 1-2 years, you get ~3 years of support. Not to mention that newer Mac OS X versions often require new hardware, while an up-to-date Windows 7 still runs on an 10-years-old Pentium III (not necessarily smooth, but it does).

[JEEB]

Whether or not the binary works on Windows 2000 most probably depends on the version of mingw, as well as the version of mingw headers used (and naturally on the needs of the piece of software itself).

The old, original mingw project used to not have any dependencies that would limit the binary for WinXP+, but unfortunately that project in general as of late has gone more or less downhill. Zeranoe, and many others, including me, use the fork of mingw that is quite active, called mingw-w64. This fork, as far as I know, has not only started further fixing and developing the for-windows toolchain system, but also taken use of things only available on XP and newer Windows versions. Support for pre-XP Windows systems was thrown away quite some time ago as far as I know.

In any case, if you would want to build a Windows 2000 compatible ffmpeg, it might still be possible if you use a toolchain based on the original mingw project, but you might have to put some effort into it :) . That is, if the ffmpeg project itself hasn't decided that it wants to use features found in currently supported Windows versions by default. In that case you'd either have to disable that functionality, work around it, or just see when that change was incorporated, and revert to the commit previous to that.

[trodas]

LoRd_MuldeR - the application has not been compiled with Visual Studio 2005 and thus doesn't use MSVCRT80.DLL ...same applies to the Visual C++ 2008 redistributable package and the Visual C++ 2010

Thanks for showing up well the reason why it won't work after the proposed update "solution"...

MSVCRTD.DLL or MSVCRT??D.DLL are "debug" versions

That means, that they are not necessary to have, because I'm not a programmer and therefore never ever need them? Because no debug will ever take a place, they never get used?

Is that right?

I will send you a PM when I find an up-to-date FFmpeg that runs on my old C64

Now you are getting sarkastic and there is not need to. C64 is a 8bit computer that cannot access even the required amount of memory, FFmpeg need. Last builds have 25MB big executable...
C64 is with 64kBy of ram...

On the other hand, Fabrice Bellard says that "it's quite simple to change ffmpeg source code to make it work again in win2k" so I can hope it will make it work again ;)
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1048

development tools (compilers, etc) drop support for Windows 2000

Then probably it is time to not update the tools, if they drop the support. Because there is no crucial difference between W2k and WinXP, it have no sense to drop the support - other that to push people towards bloatware and very restricting "OSes" like Vista, Win7 or even Win8...

However thanks for the DependancyWalker idea. There is the result:
http://s9.postimage.org/fcdqco2bv/FFmpeg_Dependancy_Walker.jpg (http://postimage.org/image/fcdqco2bv/)

pandy - some with Embedded version of Windows 2k and to be honest this system was sufficient more than enough

Exactly my point. And I do undersntad M$, but I'm very strictly opposed to it. I simply not see any reason at all, why change trusty good working OS to some bloatware crap. Not to mention the hardware requirments. Since my main PC was stolen, I have to use pure crap, a JetWay V266B with KT266A chipset and 150x12.5 AXP (at least with Barton core) CPU. And FX5200... Now come on, try to run a Win7 on that. No way in hell. With only 1G of ram, W2k run pretty nicely, albeit they put all important devices to IRQ7, witch is insane (Graphic, sound, net and USB, all on IRQ7, while there is 5 free IRQs anyway).

LoRd_MuldeR - perhaps that is why not much people use MacOS novadays? OS is not something that is changed like a dirty socks each second day or so...
On PIII run pretty slow even W2k anyway. I have DellOptiPley GX110 with 1GHz PIII, upgraded ram to 512MB (100MHz SDRAM) and 80G Seagate upgraded HDD. With all optimalizations I can think of and throw at the OS, stripped down everything... still even using old Firefox v3.0.14 the web browsing is a pain in the a$$... Yea, Win7 can run on it, I seen that on YewTube video too. But they just start, that it is. You never see browsing or YewTube video playback in the vid anyway. The oboard GFX use separate 4MB of ram, but did not support ever overlay, so the video is dead slow and enlagre it to fullscreen = once per 2 or so seconds the screen get updated, lol.
Yea, a PCI Radion 7000-9100 passive would change that, but where to get it?
Installing the Win7 would be impossible w/o changing the CDrom in this thing to DVD rom anyway. And wher to get some trusty NEC 3200 or so nowadays, huh?

Could be fun, but it will be pretty slow I would bet.

JEEB - I can only hope that the developers reconsider that way of doing things :( XP is not different that W2k afterall, so a little change won't hurt, will it?

[Kurtnoise]

You should try to find a FFmpeg build within --enable-memalign-hack as config parameter...

From Zeranoe website, the current builds are compilated within this :
This FFmpeg build was configured with:
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avisynth
--enable-bzlib
--enable-fontconfig
--enable-frei0r
--enable-gnutls
--enable-libass
--enable-libbluray
--enable-libcaca
--enable-libfreetype
--enable-libgsm
--enable-libilbc
--enable-libmp3lame
--enable-libopencore-amrnb
--enable-libopencore-amrwb
--enable-libopenjpeg
--enable-libopus
--enable-librtmp
--enable-libschroedinger
--enable-libsoxr
--enable-libspeex
--enable-libtheora
--enable-libtwolame
--enable-libvo-aacenc
--enable-libvo-amrwbenc
--enable-libvorbis
--enable-libvpx
--enable-libx264
--enable-libxavs
--enable-libxvid
--enable-zlib

[JEEB]

You should try to find a FFmpeg build within --enable-memalign-hack as config parameter...
Care to explain why? Other than to get builds from early 2011, as in the middle or so of '11 memalign-hack was made to be automatically set (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9bbd6a4cd89da4bfc9fd36fea5777a539a542b40) in the configure script on architectures that need it (which is why it has almost completely vanished from the compilation options that people use).

Not to mention that as long as the builds were made with a new enough mingw-w64, that parameter wouldn't help at all to make those unsupported imports suddenly work.

edit: OK, I see it. It's not needed by mingw (at least any of the modern mingw-w64 ones), but if it isn't enabled you end up using _aligned_free() in libavutil/mem.c, which is one of those functions he seemingly doesn't have in the CRT... (and instead you will be using hacked code that kind of tries to do the same thing)

edit2: With my old (non-mingw-w64) mingw memalign-hack gets automatically enabled, whereas with mingw-w64 there is support for both atomics in win32 threads as well as support for proper aligned malloc/free, so it doesn't get enabled as it isn't explicitly needed (except in this case where we are dealing with a lolold CRT from a lolold OS).

That said, I could also see him lacking something in ws32 as well in that dependency walker screenshot. We won't be much wiser until we get a full list of APIs his OS doesn't have, and see if those are being used by mingw-w64 itself, or by ffmpeg.

edit3: Tested a mingw-w64 toolchain (version 2.x, stable branch) + --enable-memalign-hack ffmpeg in a Windows 2000 SP4 VM I created as I was bored :V Now it wants _vscprintf, as that is supported in mingw-w64 as well. So no, --enable-memalign-hack will not make current ffmpeg work.

XP is not different that W2k afterall, so a little change won't hurt, will it?
<sarcasm>Yes, because neither XP or XP SP2 added any new APIs, right?</sarcasm>

If there are APIs that are worth it to be used by default, and the last OS that didn't have them was EOL'd a few years ago, why not use it by default if it leads to a better result and/or simpler code? If the system gives you something that works fine, why redo the wheel just to support something that is no longer supported by its creator (for free, at least)?

You are seemingly in some imaginary world where Windows 2000 equals Windows XP SP2 or newer API-wise, or one where everyone should implement everything themselves because of a "We must keep compatibility with NT3.5!" mentality :P .

The latter is of course a noble goal in a way, but I really, really wouldn't do it unless I got paid to recreate all the wheels for the users of such operating systems. In a way, the same can be said for Windows 2000 users. They create extra work, so if they want their unsupported-by-maker OS to be supported, they should be ready to compensate the creators for it.

Anyways, I have told you that you could build ffmpeg with an older mingw cross-toolchain. It has its own share of bugs and so forth that were fixed with mingw-w64, but it would most probably create Win2000-compatible binaries (thus the only things that you would have to poke around would be ffmpeg itself).

I also tried with an old komisar's mingw toolchain from circa 2010 (cross-mingw.gcc444.generic.20100506); memalign hack got enabled automatically as the proper Windows aligned memory APIs aren't available in it, but win32 threads got enabled -- even while the headers do not support atomics, which ffmpeg now needs (compilation stopped at the threading code). Disabling threading made it build, and probably if I had pthreads around in this mingw setup it might help to attain threading support. I also happened to be bored and made a Windows 2000 SP4 virtual machine, the binary (http://x264.fushizen.eu/builds/ffmpeg-N-50880-gc3bb2f7-cross-mingw.gcc444.generic.20100506.7z) worked on it.

Edit: Checked the lib folder of that old 4.4.4 mingw, the pthreads library was there but it seems like ffmpeg wouldn't pick it up by default (with --enable-pthreads). Didn't check config.log, but I would just guess it wasn't enough (or the file name just wasn't right for it for whatever reason?). Getting the thing built with mingw-w64 would be much better, but it seems like with all of the things that try to make stuff work correctly on Windows basing on XP+ capabilities... I really wouldn't want to hack too much around it to be honest :P

Edit2: Tested with TDM's mingw, seems to work too (http://x264.fushizen.eu/builds/ffmpeg-N-50880-gc3bb2f7-tdm471-1.7z), as long as you configure with "--disable-w32threads". Leads me to think that as long as you use mingw, and not mingw-w64 you should indeed be able to compile Win2000-compatible binaries (albeit without threading support). That said, original mingw is quite untested in ffmpeg/libav by now. Doesn't mean nothing will work, but you're most probably going to end up being "out there" support-wise. Set yourself a msys/mingw setup with mingw-get-inst (http://sourceforge.net/projects/mingw/), and try building by yourself :P

[trodas]

JEEB - wow... thanks a lot, dear friend! Both versions seems to work just great on Win2k SP4 Czech (truth to be spoken, heavily modified) !

I just did not understand, why these seemingly uncompressed executableas are "just" around 10MB in size, where the Zeranoe FFmpeg is close to 25MB in size...
WTF?

The great irony is, that what I hoped the new version of FFmpeg will help me with, does not work at all. To cut long story short, from this wmv video:
Re: Moon Hoax Not (http://www.moonfaker.com/videos4mirror/Re_Moon_Hoax_Not.wmv.zip)
I, using latest VirtualDub, exported the audio (save wav or extract raw audio) and since the VD reported that this is a wma v2 audio, I hoped the FFmpeg will convert it to wav, so I can work with it (eg. normalize it, because it sounds just awfull)...

Now FFmpeg complain that there are errors, so it cannot do the job... :( Great irony. So much work and so little result...

D:\Tools\Lame>ffmpeg -i x.wma -vn -f wav x.wav
ffmpeg version N-50880-gc3bb2f7 Copyright (c) 2000-2013 the FFmpeg developers
built on Mar 13 2013 17:56:41 with gcc 4.4.4 (GCC) (x86.generic.Komisar)
configuration: --disable-w32threads
libavutil 52. 19.100 / 52. 19.100
libavcodec 55. 0.100 / 55. 0.100
libavformat 55. 0.100 / 55. 0.100
libavdevice 54. 4.100 / 54. 4.100
libavfilter 3. 45.101 / 3. 45.101
libswscale 2. 2.100 / 2. 2.100
libswresample 0. 17.102 / 0. 17.102
[wav @ 0191f380] no 'data' tag found
x.wma: Invalid data found when processing input

D:\Tools\Lame>ffmpeg -i x.bin -vn -f wav x.wav
ffmpeg version N-50880-gc3bb2f7 Copyright (c) 2000-2013 the FFmpeg developers
built on Mar 13 2013 17:56:41 with gcc 4.4.4 (GCC) (x86.generic.Komisar)
configuration: --disable-w32threads
libavutil 52. 19.100 / 52. 19.100
libavcodec 55. 0.100 / 55. 0.100
libavformat 55. 0.100 / 55. 0.100
libavdevice 54. 4.100 / 54. 4.100
libavfilter 3. 45.101 / 3. 45.101
libswscale 2. 2.100 / 2. 2.100
libswresample 0. 17.102 / 0. 17.102
[NULL @ 01946380] Picture size 1280x917072 is invalid
[NULL @ 01946380] Ignoring invalid width/height values
[bintext @ 01946380] Warning: not compiled with thread support, using thread emu
lation
[bintext @ 01946380] [IMGUTILS @ 0022f234] Picture size 0x0 is invalid
[bintext @ 01946380] video_get_buffer: image parameters invalid
[bintext @ 01946380] get_buffer() failed
[bin @ 0191f3a0] Stream #0: not enough frames to estimate rate; consider increas
ing probesize
[bin @ 0191f3a0] decoding for stream 0 failed
[bin @ 0191f3a0] Could not find codec parameters for stream 0 (Video: bintext, p
al8): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[bin @ 0191f3a0] Estimating duration from bitrate, this may be inaccurate
x.bin: could not find codec parameters

D:\Tools\Lame>


PS. as far, as hacking the OS goes, I just use few "Innocent" inf files that are based on the work of Fred Vorck, and their purpose if to remove completely IE, Outlook and few of unimportant stuff from W2k. Also I disable most of the services running and made some changes to in Autoruns, uninstall some not need devices and stuff. Better include these inf files + registry tweaks:
http://ulozto.cz/xxgXFFX/win2k-fixes-zip
http://www.sendspace.com/file/7t64ho

There are the Autoruns optimalizations:
[img]http://s12.postimage.org/noa9i4909/autoruns_optimizing.jpg (http://postimage.org/image/noa9i4909/)

What else? My graphic changes to the Win GUI did not have any effect on apps, but for fun, there are basically shown there:
http://trodas.wz.cz/index.php?act=ST&f=14&t=454


How to do the full list of API's that my OS does not support you mention?


PS. tested the FFmpeg in "action" and it can decode the audio right of the wmv, so, things only did not work when using combination of VirtualDub export and FFmpeg to docode the resulting data. Interesting. However the messages about the missing thread support, using thread emulation are sort of ughly:
D:\Tools\Lame>ffmpeg -i x.wmv x.wav
ffmpeg version N-50880-gc3bb2f7 Copyright (c) 2000-2013 the FFmpeg developers
built on Mar 13 2013 17:56:41 with gcc 4.4.4 (GCC) (x86.generic.Komisar)
configuration: --disable-w32threads
libavutil 52. 19.100 / 52. 19.100
libavcodec 55. 0.100 / 55. 0.100
libavformat 55. 0.100 / 55. 0.100
libavdevice 54. 4.100 / 54. 4.100
libavfilter 3. 45.101 / 3. 45.101
libswscale 2. 2.100 / 2. 2.100
libswresample 0. 17.102 / 0. 17.102
[wmav2 @ 0196c9a0] Warning: not compiled with thread support, using thread emula
tion
[wmv3 @ 0196d460] Warning: not compiled with thread support, using thread emulat
ion
[wmv3 @ 0196d460] Extra data: 8 bits left, value: 0
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, asf, from 'x.wmv':
Metadata:
SfOriginalFPS : 300000
WMFSDKVersion : 12.0.7601.17514
WMFSDKNeeded : 0.0.0.0000
IsVBR : 0
DeviceConformanceTemplate: MP@ML
Duration: 00:25:27.87, start: 0.000000, bitrate: 1286 kb/s
Stream #0:0(eng): Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, stereo, fltp
, 96 kb/s
Stream #0:1(eng): Video: wmv3 (Main) (WMV3 / 0x33564D57), yuv420p, 640x480,
3049 kb/s, 30 tbr, 1k tbn, 1k tbc
[pcm_s16le @ 01996160] Warning: not compiled with thread support, using thread e
mulation
[wmav2 @ 0196c9a0] Warning: not compiled with thread support, using thread emula
tion
Output #0, wav, to 'x.wav':
Metadata:
SfOriginalFPS : 300000...

Any chance to getting bored again and look out at the thread support? At first I would think that this is good only for multicore CPU's, but obviously I was wrong. It is more about what the program intelnal threads communicate with themselves...

[vhs.d9]

Try using vlc. I think last version that works on windows 2000 is 1.1.x http://sourceforge.net/projects/vlc/files/1.1.11/win32/

Menu-> convert(ctrl+r), add file(s), click convert , choose destination file(dont forget right extension), from profile choose audio cd(if you want wav)


vlc should work if you have sp4 and all hotfixes... http://forum.videolan.org/viewtopic.php?f=14&t=76295

[JEEB]

How to do the full list of API's that my OS does not support you mention?
No idea, but you should be able to create a full list with a mingw-w64-built ffmpeg like zeranoe's with whatever tool. I have no real interest in trying to find exactly how much Win2000 sucks regarding basic C APIs you can use.

Meanwhile just from the brief look we've had upon trying to compile ffmpeg for the system, we've found out that:

Old mingw doesn't support atomics in Windows threads. It's possible that this is actually a limitation of Windows 2000 and older, but it could also be a problem with ye olde mingw (it doesn't provide the functions needed in its headers). I just don't know/care to look further into it :P .
Aligned memory stuff isn't in Win2000's CRT (in order to allocate and free etc. memory at an alignment of, say, 16 or 32 bytes).
No support for _vsnprintf(), which is used to emulate a proper snprintf() and vsnprintf() in ffmpeg.


PS. tested the FFmpeg in "action" and it can decode the audio right of the wmv, so, things only did not work when using combination of VirtualDub export and FFmpeg to docode the resulting data. Interesting. However the messages about the missing thread support, using thread emulation are sort of ughly:

Any chance to getting bored again and look out at the thread support? At first I would think that this is good only for multicore CPU's, but obviously I was wrong. It is more about what the program intelnal threads communicate with themselves...
No. Update to an OS that can use the Windows threading APIs that mingw-w64 lets one use, and that doesn't need memalign-hack to work.

Or since you really like hacking Win2000 so much, hack the support for these into the CRT? :P

(Also I did leave you a note on how to compile ffmpeg yourself, if you really want to see if you can get the old implementation of pthreads on Windows work with current ffmpeg. I have no such interest. Windows 2000 and Windows XP are not the same things, and current version of XP provides many new APIs in the C runtime that are actually useful. Let developers use them now that Windows 2000 has been dead for almost three years.)

I just did not understand, why these seemingly uncompressed executableas are "just" around 10MB in size, where the Zeranoe FFmpeg is close to 25MB in size...
WTF?
I only built ffmpeg itself in a basic configuration, Zeranoe builds ffmpeg with a lot of libraries to enable, say, H.264, MP3 and proper Vorbis encoding. The full list of libraries built with is at the bottom of his page :P

[filler56789]

@ JEEB —

— many :thanks: for your useful :goodpost: :goodpost: in this thread :)