Leaderboard

The IFEND works in all versions. LEGACYIFEND ON only makes XE4+ accept only IFEND, too. That might be helpful to write code compatible with versions before XE4 when written and tested with newer versions only. So it is more like a safeguard for the developer, but code written like before XE4 will also compile in XE4+ without that LEGACYIFEND directive.

For the same reason they have ridiculous NDAs and don't have public betas; They are so stuck in the 90s that they think anyone still gives a damn.n They never understood how to build a community.

Please stop using VERxxx. It's been possible to do {$if CompilerVersion >= XX} since Delphi 6 or 7. It's so annoying having to edit the .inc files of various 3rd party libraries with each new version of Delphi because they're designed as if the latest version = the last version. Graphics.32 uses {$LIBSUFFIX AUTO} for the D11+ packages. The earlier packages are manually maintained by using a diff tool to keep them synchronized with a master. The master usually comes from the latest supported Delphi version. There's no way I'm wasting disk space on old versions of Delphi just to maintain the package files. I have the latest version, and the few versions required by my job, and that's it.

I have worked on a port of my Bitmaps2Video-encoder to using Windows Media Foundation instead of ffmpeg, since I wanted to get rid of having to use all those dll's. Now, before posting it on GitHub, I'd like to run it by the community because of my limited testing possibilies. I also hope that there are people out there having more experience with MF and could give some suggestions on the problems remaining (see below). Learning how to use media foundation certainly almost drove me nuts several times, because of the poor quality of the documentation and the lack of examples. What is does: Encodes a series of bitmaps to video with the user interface only requiring basic knowledge about videos. Can do 2 kinds of transitions between bitmaps as an example of how to add more. Supports file formats .mp4 with encoders H264 or H265, or .wmv with encoder WMV3. Does hardware encoding, if your GPU supports it, falls back to software encoding otherwise. Uses parallel routines wherever that makes sense. Experimental routine to mux in mp3-audio. Only works for H264 and WMV3 right now. Requirements: VCL-based. Needs the excellent MF headers available at https://github.com/FactoryXCode/MfPack. Add the src-folder of MFPack to the library path, no need to install a package. Needs to run on Windows10 or higher to make use of all features. Not sure about Delphi-version required, guess XE3 and up is required for sure. Problems remaining: I'm not too thrilled about the encoding quality. Might be a problem with my nVidia-card. The audio-muxer should work for H265, because it works when I use ffmpeg. But with my present routine the result just plays the audio and shows no video. I haven't yet figured out how to insert video clips. Major problem I see is adjusting the frame rate. Renate Bitmaps2VideoWMF.zip

Yikes. Nobody touches my screen! Not even myself. Besides touch screens add cost and complexity.

I also use {$LEGACYIFEND ON} in Indy for XE4+ versions. Helps the code remain backwards compatible with earlier versions by forcing the compiler to not accept {$ENDIF} to close {$IF}. The compiler can run into issues when you have nested {$IF} and {$IFDEF} blocks but don't use {$IFEND} consistently, which can trigger error E2029, as mentioned in the {$LEGACYIFEND} documentation (and I've run into it before).

I don't remember the specific version, but I know there was a time when the compiler had problems with the evaluation order of {$IF} and {$IFDEF}, I think that was around the early Kylix days, so would have probably been around Delphi 6-8. But that is just a guess...

That's normal. Each memory block is guarded by additional data to detect overrun and under-run. madExcept is not intended to be delivered with the released product. Pay attention that memory allocated with Delphi memory manager comes from virtual memory and is sub-allocated. In this sub-allocation, you get also fragmentation. Actual behavior is entirely dependent on the memory manager you use (You said FastMM4). If you app consume memory but has no leak, then you have fragmentation.

From what I read, the 32-bit version of Matlab has issues under W11ARM, while the 64-bit supposedly works. IMO - making a general statement that 32-bit and 64-bit intel apps doesn't work on ARM, is a far cry away from specifying some specific apps that don't work.

I think I know what you mean, I'll play around with it some. Problem is that I really need to have a well defined video-frame-rate, otherwise the user can't time the input. I have meanwhile figured out the audio-sample-duration for given sample-rate and use it for the amount of audio-samples to be read ahead. Audio-sync is now acceptable to me. Problem is now, that some decoders are sloppyly implemented in Windows, like .mpg. I'm not sure I even have control over that. Isn't the encoder just using everything that is in the leaky bucket to write the segments in what it thinks is the right way? Why can't you compile the code? I think your feedback would be very valuable to me. Did you try the latest version on GitHub? https://github.com/rmesch/Bitmaps2Video-for-Media-Foundation (there's one silly bit of code still in there that I need to take out, but it usually doesn't hurt anything) I was hoping to have eliminated some code that prevented it to run on versions earlier than 11.3. Or have you meanwhile developed an aversion against the MF-headers? 🙂

Which was is a PITA as it makes inc files just a tad more complicated than they would be otherwise. I usually have something like this so I can have one inc file that supports versions before and after XE4 {$IF CompilerVersion > 24.0 } //XE4 or later {$LEGACYIFEND ON} {$IFEND}

Some problems !, one might call WMF the mother of all problems that can encode and decode. I remember trying use the encoder in real time for live video chat, and dropped it later and never looked back. Anyway, i can't compile and run TBitmapEncoderWMF, but i looked at the source and found this the following line This to my experience with the whole Windows Media Foundation that approach is a problem, and most likely a core problem in your encoder. The problem in such calculation with that your are not using audio sample rate and the ability to divide the audio sample right, so my suggestion is to to round that fSampleDuration to what audio sample allow you and will be acceptable to the encoder and of course to the decoder in later stage. To understand the problem and forgive my English and inconsistent phrases, you have to know why the standard of the audio sample rate for many many years was 44100 hz, why this number and from where it came, please read this https://en.wikipedia.org/wiki/44%2C100_Hz and see its there for compatibility with PAL at 50 fps and NTSC at 60 fps, so to make it right in your encoder you should choose fSampleDuration according to acceptable/right audio sample rate, that will add to exact (real exact like 44100) audio sample rate per second. Also you should make sure that audio sample rate and the sample rate buffer have the right channels, you can't have audio sample rate with 2 channels and feed the encoder an odd number of samples !, same goes for 5.1 channels or 7.1, just food for thoughts, if and most likely you are doing 2 channels (Strereo) then the audio sample per frame should always be even number. By the way, it is beautiful code what you did there !

Works for me:

@Juan C.Cilleruelo I've run - RAD Studio (32-bit) and Windows apps (32 and 64-bit) made with it - Visual Studio 17.4 (64-bit) and .NET apps made with it. - GitKraken (Electron) - VS Code (Electron) under Windows 11 for ARM in Parallells on my MacBook Pro M1. Windows 11 for ARM emulates x86 and x64 apps pretty darn good - there is no need to have a native ARM app. Considering my projects compiles faster in RAD Studio under Windows 11 for ARM in Parallells under MacOS, than on my one year old Lenovo P16 i7. I am not sure what went wrong for you.

That would make it harder to detect breaches of the NDA and start arguments about where the limits are. It's much easier to forbid any mention.

A TCheckBox with AllowGrayed set to true has three possible states; checked, unchecked, and grayed according to : http://www.delphigroups.info/2/6/245597.html I thought TRzCheckbox might have more, but the thread seems to think not... Edit: here's the VCL documentation on it: https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.StdCtrls.TCustomCheckBox.AllowGrayed

It is no secret that many or most components developers are beta testers under NDA, how else are all their components ready for each new release, or in the olde days on the component companion CD included with the final release. This benefits everyone involved, because new versions of Delphi can be used for old projects immediately, rather than waiting weeks for developers to buy the new version, etc. What has changed in recent years is beta testing being offered openly for paying customers, rather than by invitation only, and blogging about the next release, so it is now all more obvious. Angus

This probably means that there is no memory leak but memory fragmentation. You have 118MB memory split into thousands of block separated by small free blocks. @PizzaProgram if fragmentation then this can be solved by running as 64 bit. Are you not using 4 GB? {$SetPEFlags $0020} // Winapi.Windows.IMAGE_FILE_LARGE_ADDRESS_AWARE { App can handle >2gb addresses } Or better try 64 bit if possible.

A HTTP GET doesn't use a body. If you want to pass a body use POST or if supported QUERY (preferred as it is supposed to be idempotent where POST may not be).

Added a quick blog post on inline variables: https://www.ideasawakened.com/post/newly-discovered-hidden-benefits-of-inline-variables-in-delphi

That is only an issue for library authors that need to target a range of past versions which is the vast minority of Delphi users. Most migrate to a new version, start using that and never have to run their code through previous versions. Type inference for inline variables is a really nice thing - no need to explicitly decare the type just to tell the compiler (yes, if you name your variable properly the type is irrelevant for understanding the code, ask programmers from other languages that have this feature for a long time). Also often enough you have to add units to a uses clause just to declare a variable of a type that is the return of a method of some other type being used - with type inference that becomes unnecessary.