As the title says
I want to know if there are anything that will help someone to trace the laptop or machine used for encoding the video?
Also is there any trace in image file too? Like I watermark with ffmpeg and my machine code is added into metadata of that image?
With ffmpeg, no. Add -bitexact to be sure.
Depending on the applicatzion you are using, container and codec you are encoding to, this is possible.
For ffmpeg i am not aware that it puts any machine related stuff into any format or codec.
Even when you are using external encoders instead of built-in ones like AMD or NVIDIA stuff, currently the codecs do not allow to put such data into the stream.
Sure, future audio/video codecs might allow such metadata in order to find out if the encoder is licensed correctly, but as by now i am not aware of such stuff.
What cameras do for example to overcome the lack of codecs and formats support for storage of this information is to just write some xml along to the media file where they store serial number and such.
If there was such information contained, analyzer tools like "mediainfo" would show this info. I am not yet affiliated with mediainfo Sarl.
Related
I am trying to find available DirectShow video encoders, using following code:
ICreateDevEnumPtr pEnm(CLSID_SystemDeviceEnum,NULL,CLSCTX_INPROC_SERVER);
// Video Compressor
if(pEnm!= NULL)
{
IEnumMonikerPtr pEnumMoniker;
hr = pEnm->CreateClassEnumerator(CLSID_VideoCompressorCategory,&pEnumMoniker,0);
//......
}
However, some video compressors installed in the system (Windows 10 x64) have different category.
For example "Microsoft MPEG-2 Encoder" and "VisioForge H264 Encoder" have category {083863F1-70DE-11d0-BD40-00A0C911CE86} - CLSID_LegacyAmFilterCategory
If I use CLSID_LegacyAmFilterCategory instead of CLSID_VideoCompressorCategory in my code, I get a lot of irrelevant objects.
Can you suggest the proper way to enumerate the DirectShow video compressors installed in the system ?
There is no better way and most likely you don't need any other way. You need this enumeration to eventually check availability of specific codec of interest and instantiate it. It is hard to imagine that you are building an application capable to pick some arbitrary installed codec and be able to use it, you normally deal with compression codecs you are well familiar with, esp. H.264 video compression codecs which have certain specific configuration methods etc. For the codecs you are familiar with you would want to have codec specific instantiation and configuration ways, one might need a discovery through enumeration, another would be available for instantiation via CLSID directly.
I want record screen (by capturing 15 screenshots per second). This part I know how to do. But I don't know how to write this to some popular video format. Best option which I found is write frames to separated PNG files and use commandline Mencoder which can convert them to many output formats. But maybe someone have another idea?
Requirements:
Must be multi-platform solutions (I'm using Free Pascal / Lazarus). Windows, Linux, MacOS
Exists some librarys for that?
Could be complex commandline application which record screen for me too, but I must have possibility to edit frames before converting whole raw data to popular video format
All materials which could give me some idea are appreciated. API, librarys, anything even in other languages than FPC (I would try rewrite it or find some equivalent)
I considered also writting frames to video RAW format and then use Mencoder (he can handle it) or other solution, but can't find any API/doc for video RAW data
Regards
Argalatyr mentioned ffmpeg already.
There are two ways that you can get that to work:
By spawning an new process. All you have to do is prepare the right input (could be a series of jpeg images for example), and the right commandline parameters. After that you just call ffmpeg.exe and wait for it to finish.
ffmpeg makes use of some dll's that do the actual work. You can use those dll's directly from within your Delphi application. It's a bit more work, because it's more low-level, but in the end it'll give you a finer control over what happens, and what you show the user while you're processing.
Here are some solutions to check out:
FFVCL Commercial. Actually looks quite good, but I was too greedy to spend money on this.
Open Source Delphi headers for FFMpeg. I've tried it, but I never managed to get it to work.
I ended up pulling the DLL wrappers from an open source karaoke program (UltraStar Deluxe). I had to remove some dependencies, but in the end it worked like a charm. The relevant (pascal) code can be found here:
http://ultrastardx.svn.sourceforge.net/viewvc/ultrastardx/trunk/src/lib/ffmpeg-0.10/
There was some earlier discussion with a Delphi component here. It's a very simple component that sometimes generates some weird movies. Maybe a start.
I really stucked with that problem, because I haven't seen enough information in the internet regarding video encoding in iOS, however we can observe plenty of apps that deal with the problem of video streaming successfully (skype, qik, justin.tv, etc.)
I'm going to develop an application, that should send video frames obtained from camera and encoded in h.263 (h.264 or MPEG-4 it is under decision) to a web-server. For this, I need some video encoding library. Obviously, ffmpeg can deal with that task, but it is under LGPL license, which could probably lead to some problems in submitting the app in the AppStore. On the other hand, there are some applications, which are seemed to use ffmpeg library, but only Timelapser clearly states this fact in app description. Does this mean, that other apps are not using ffmpeg or just hiding this information?
Please, share your thoughts and experience in this topic. I'm open for dicsussion.
After googling and making some research in this area, I found this one library http://www.foxitsolutions.com/iphone_h264_sdk.html. They really use hardware encoding. I've examined demo example with instruments, and they showed me that while encoding, ~12% cpu is used and syscall read() constantly called. From that I can conclude, that their library uses standard AVFoundation's AVAssetWriter to write into the temporary file, and (most probably) concurrent thread is used to read this temp file for retrieving encoded frames.
Also, take a look at http://www.videolan.org/developers/x264.html. It is under GPL, but still can be useful.
I was planning to use the vlc library to decode an H.264 based RTSP stream and extract each frame from it (convert vlc picture to IplImage). I have done a bit of exploration of the vlc code and concluded that there is a function called libvlc_video_take_snapshot which does a similar thing. However the captured frame in this case is saved on the hard disk which I wish to avoid due to the real time nature of my application. What would be the best way to do this? Would it be possible without modifying the vlc source (I want to avoid recompilation if possible). I have heard of vmem etc but could not really figure out what it does and how to use it.
The picture_t structure is internal to the library, how can we get an access to the same.
Awaiting your response.
P.S. Earlier I tried doing this using FFMPEG, however the ffmpeg library has a lot of issues while decoding an H.264 based RTSP stream on windows and hence I had to switch to VLC.
Regards,
Saurabh Gandhi
My software encodes videos using the standard Windows AVIFile functionality. That means, it can use all the DirectShow Codecs that are installed.
I recommend my users to download the XVid Codec themselves, but that's inconvenient.
I cannot bundle XVid since my software is not GPL. Is there any good direct-show-compatible video codec that can be redistributed with a commercial application? Requirement: The videos must look great on YouTube.
If not, I could switch from AViFile to another library (e.g. FFMpeg). But I'd like to avoid that if possible.
Thanks! :-)
Edit: The videos are computer animation with very sharp details (explosions and sparks). The video should be high-bitrate.
Theora is an excellent open source codec with very good DirectShow support. You also might consider google's newer WebM codecs. You dont say what kind of video you are distributing (from a camcorder, animation/computer rendered graphics, etc), so some of the choice of codec may depend on the exact nature of your video.