Does anyone know of an open source H.264 encoder in C# (or any other managed language)? I might be able to make do with a python implementation as well.
The libraries that I’ve found (e.g. x264) are written in pretty low level c (procedural with lots of macros) and assembly. Tweaking them is turning out to be far more complex than I'd thought. My project has no concern for performance or compatibility. We just want to test how some ideas will impact the perception of the outputted video.
We’d be willing to pay for or license the code if need be.
Thanks in advance!
Edit - Some important points:
I don't care about performance (e.g. real time encoding) at all. It could take 10 days to encode for all I care.
A wrapper isn't helpful since I want to actually modify the encoder itself.
No one would likely spend the time to develop the codec in those languages because they would be hopelessly slow for actual encoding. However, the reference implementation should be less optimized and more useful to you. It is still in C.
http://iphome.hhi.de/suehring/tml/download/
I don't think there is already such a port you need - you'll find wrappers for any langugae but a pure implementation does not have the critical mass. I'd recommend to port it yourself, document your port well and then start tweakening it.
If you'd want to port some encoder to C#, this should be easier to start with - about 8k LOC: http://sourceforge.net/projects/fevh264/
How about http://www.ffmpeg-csharp.com/?
Related
I have a bit of an unorthodox question. I am trying to do a little pet project purely out of interest and willingness to mess around for fun and giggles.
I want to read data (bytes, bits or whatever I can) from my rocksmith cable(usb cable attached to a guitar), and just go whack at it in some c# code. I actually have no idea if this is even possible. I have been playing around with libraries such as SharpUsb and LibUsbDotNet, but they don't seem to pick it up as a device, which kindof makes sense.
I also tried using System.IO.Ports.SerialPort, just to see if I can pick up anything but it does not.
So smarter genius people out there. Is this possible ? Any advice/ideas of what I can try ?
Any advice or ideas will be very much appreciated! For me this is purely an out of interest project for fun.
Thanks in advance!
Since the rocksmith Realtone cable is a usb to guitar cable, all you should need the dll file for that piece of hardware and import it into your project / call the proper methods associated with it.
More than likely the code will be in C++, so you will need to use DLLImport function as well.
Any further than that, I'm sure you could figure out where to go from there. You could possibly use XNA and use the microphone class if you have that usb device set as your default microphone, although, that is just a random thought.
I have a problem that I think is very common among low-level developers whose start working with high-level languages. I made some research but didn't find a suitable solution to my problem.
I have a client-server application and I want to re-create all the client, from "scratch" using C# but as I want to keep the server as it is, the "new" updated client have to follow the actual protocols of sending and receiving data packets.
If the packets just contains unmanaged types (byte, int, etc) it should be ok, but my problem comes up when I have to work with strings between the managed client in C# and the unmanaged server in C/C++.
I already have found some solutions for this problem, but I really don't know which is the best or if there is a better solution that i didn't notice.
The first approach is use the fixed keyword to create structs that represents each packet of the application and doing this the C# allows me to easily and with very low cost (I guess) do my pointer casts (from byte* to packet_structure* and vice-versa) without worry about all the marshaling and other expensive methods. I think this approach is particular bad because forces me to use a sbyte data type on the buffers where should be a string in the packet and then make a cast to bring these bytes to the managed world to be properly processed.
The other approach I have made was to declare the struct of each packet as managed but marked with MarshalAs attributes to make use of the Marshal's methods for converting the data. This approach I think is more expensive, considering that the application is a game and the client, which I'm doing, is a real-time application. I think that make extensive use of marshaling on each packet can be very much expensive for the application.
Is there any simple and beautiful solution which I could follow something like C style or any other solution that my inexperience is denying me? In C a very simple pointer cast should be enough to free me the problems.
I'm in love with C# but I'm veeeery afraid I couldn't do this with this platform :(
Anyone could please shed me some light? :/
Thanks very much for your time, any kind of help will be VERY appreciated.
I have prototyped a library with some image-processing algorithms in Python/Numpy/Scipy, and now I want to port the code to C# and WPF.
I have realized that, although the input files are images (photographs), conceptually what matters to my domain problem is that they are bidimensional arrays of floats, and the operations I perform (grayscale conversion, blur, blob detection, skeletonization), and even persistence, are best performed in floating-point "space", rather than in integer space (which means bytes - uint8 -, usually).
So, I took a look at .NET namespaces, and there are a lot of "Drawing" this, "Imaging" that, "Media" something, and I am utterly confused.
So, the question is: Which .NET class is the most obvious and commonly used "image data container" for floating point image processing.
I know about AForge, but since I am learning C# and my image-processing needs are not so heavy at this point, I'd like to give native .NET a chance (but that could be a bad idea anyway, so please let me know if it is).
Based on what you already have, why not looking for the same libraries you used in Python but for C#/.NET? for example, for numeric calculations look at:
Project:
http://numerics.mathdotnet.com/
Examples: https://github.com/mathnet/mathnet-numerics/tree/master/src/Examples
And for examples of image processing, maybe looking at the source code of Paint.NET (its latest open sourced version - openpdn Fork of Paint.NET 3.36.7) may give you an idea of what libraries to use for images:
http://code.google.com/p/openpdn/source/browse/#hg%2Fsrc
Both libraries are in C#.
I want to convert Writablebitmap to Jpeg stream, and it looks like there is no platform support as well as I can see a bunch of opensource Encoder libraries on web, I want to get your opinion on which is the recommended one in terms of performance and reliability.
I made good experience with FJCore.
I also blogged about it a while ago http://kodierer.blogspot.com/2009/11/convert-encode-and-decode-silverlight.html
I've spent quite a bit of time with both FJCore and LibJpeg.Net. FJCore is easier to use, since it was ported over from Java, and has an object model that vaguely resembles what you'd expect to see in C#. However, LibJpeg.NET is by far the more complete library (it's based on the informally canonical libjpeg), and it's significantly faster as well. To give one example, FJCore uses a naive implementation of an inverse discrete cosine transform that involves something like 1024 multiplications and an additional 1024 additions for each 8x8 block. In contrast, LibJpeg.NET uses the high performance AAN algorithm which only takes 144 multiplications and 464 additions (see http://datasheets.chipdb.org/Intel/x86/MMX/MMX/AP528.HTM#AAN Algorithm). In addition, FJCore is fairly inefficient in how it uses memory, constantly recreating objects that could easily be re-used. At the same time, because FJCore has fewer optimizations, it's significantly easier to hack.
For my current project (which involves writing a video codec for Silverlight), I used FJCore as a starting point, fixed a whole bunch of its inefficiencies, replaced its IDCT algorithm with the one from LibJpeg.NET, and ended up with something that gave me about 10x the original performance.
Ken why don't you submit your updated code to the FJCore source?
http://code.google.com/p/fjcore/
I've finished my current "part-time" project and am looking for something new.
I've decided to have a crack at writing my own compression / decompression utility. I'm not planning on selling it or anything - it's more for my own interest.
Preferably, it will be be in C# but Java or C is OK.
Can anyone suggest some good sources on compression / decompression techniques that I can study. Hopefully, some that don't involve maths at a doctorate level!
A good book on this topic is The Data Compression Book. It starts off with the basics and ends up with JPEG and fractal image compression algorithms.
I worked through this whole book years ago (the first edition, I think) and I still remember it as a really rewarding experience.
I find that Wikipedia is a pretty good source in this respect. See, for example, Huffman coding, LZW and Deflate for some common lossless general-purpose data compression algorithms.
If you want to do something more specific, the article on JPEG is also really good.
This competition gives a good idea of the current state of the art for text compression, and something to aim for if you come up with something good!
I've found this a useful survey of lossless image compression.
If you read only one academic paper on the subject, make it C.E. Shannon's "A Mathematical Theory of Communication". The ideas there are absolutely fundamental to compression.
This is completely not an answer, but....Compression and Decompression, for me, have never really been of high interest. There are compression classes in System.IO.Compression, and those things take care of it for me. What more do I need to know? If the built-in classes are not sufficient, there are third-party class libs.
(Actually, the DeflateStream and GZipStream classes in .NET exhibit anomalous behavior with previously-compressed data : they can actually increase the size of the data they are asked to compress. Whoops! It's been reported as a problem but the shot was deflected off of the Borg's shield: Connect.
Kudos to Microsoft for soliciting public bug reports; Bados on Microsoft for simply Closing bugs they didn't feel like fixing. )