Recherche avancée

Sur d’autres sites (10224)

• Setup FFMpegCore in Visual Studio 2019

  27 juillet 2022, par DsiakMondala

  I am confused on the basics of using a library. I understand that there is a library called FFMpeg and a wrapper called FFMpegCore so we can use FFMpeg with C#, correct ? I downloaded both FFMpeg and FFMpegCore and I have them in my project's folder. Although I didn't perceive any class named FFMpegOptions in either of the file's folders.
I am stuck on how to actually set it up so I can use it in my little project, I never downloaded someone's library before. Can somebody please walk me though the motions of connecting the three of them together ?

  


  So far I experimented with :

  


  

  • Add a reference to my project, but there doesn't seem to be any .dll, .tlb, .olb, .ocx or .exe files to add

  


  • Add an existing project to my solution. There is a project called FFMpegCore.csproj but adding it raises a missing SDK error. Weirdly enough, opening the same project as a standalone doesn't raise any issues which makes me thing the operation I am trying is inadequate.

  


  


  I am sure this is a silly and easy setup to perform but I just don't know enough to find a solution.

  


• Unable to build solution in Visual Studio 2019 : The BaseOutputPath/OutputPath property is not set for project

  23 juillet 2022, par mhadi

  In an effort to integrate FFmpeg with Unity, I have been trying to build a solution file in Visual Studio 2019. However, I am currently unable to resolve the following error when I try to build in Visual Studio :

  


  


  The BaseOutputPath/OutputPath property is not set for project
'FFmpegUnityInterop.vcxproj'. Please check to make sure that you have
specified a valid combination of Configuration and Platform for this
project. Configuration='Release' Platform='x64'. This error may
also appear if some other project is trying to follow a
project-to-project reference to this project, this project has been
unloaded or is not included in the solution, and the referencing
project does not build using the same or an equivalent Configuration
or Platform.

  


  


  I have tried a number of solutions, including :

  


  

  1. Manually adding the OutputPath in 'FFmpegUnityInterop.vcxproj'
<outputpath>bin/Build/</outputpath>.

  


  2. In the FFmpegUnityInterop.vcxproj file, moving the ProjectProperty with my preferred configuration and platform combination to the very top of the list of ProjectProperties (there are 8 of them).

  


  3. Building with different configuration and platforms.

  


  4. Trying to build from VS Dev Command prompt using the following command :
MSbuild.exe "FFmpegUnityInterop.sln" /p:Configuration=Release /p:Platform="x64", as well as from the Visual Studio IDE.

  


  5. Tried setting the OutputPath in the command line command
(>MSbuild.exe FFmpegUnityInterop.sln /p:Configuration=Release /p:Platform="AnyCPU" /p:OutputPath = bin\Debug), only to have
MSbuild throw error MSB1008 (MSBUILD : error MSB1008 : Only one
project can be specified.)

  


  6. Setting the configuration and platform manually in the Configuration Manager GUI in
Visual Studio.

  


  


  I may have missed an attempted solution or two above, but I've tried most of the suggestions I found online, only to get the error pasted above. Part of me suspects that my compilation of FFmpeg libraries didn't execute fully, but I unfortunately do not have enough experience to verify that. Any suggestions to resolve this would be much appreciated.

  


  PS. The project was developed privately by a private entity that is currently unreachable

  


• Trouble with CoCCA Registry

  7 octobre 2012, par Multimedia Mike — General

  I’ve been rather despondent all week. People who see me daily could readily identify this fact. Unfortunately, the exact reason was difficult to adequately explain. The problems that nerds deal with…

  When A Domain Expires
  As a few people noticed, the multimedia.cx domain and all of it’s subdomains didn’t work this last week. The problem started on Monday, October 1. Whose fault ? Well, fundamentally, I neglected to renew the domain name in time. However, I prefer to place the blame on the .cx domain registrar, CoCCA Registry. You see, they have never developed the technology to email a domain holder with a notice that their domain is about to expire or has already expired.

  This domain is the only one I have ever held so I don’t have a lot of experience in this matter. I wondered if I was crazy for thinking it would be normal for a registrar to send an email or 2 with status updates about your domain. I get the impression from speaking with others that this is indeed normal. I have 3 different email addresses listed under my account at the registrar– 2 at multimedia.cx and a backup gmail account. I checked spam folders after this incident. Then I remembered that I have never received any email notifications from them (although password reset emails show up, so that part thankfully works). Also, their support emails are black holes.

  So, I guess the moral is : be wary of dealing with CoCCA Registry. However, they seem to be the only way to register domains under a wide variety of uncommon country codes.

  By Friday, the domain appeared to have been reinstated, even through the status was officially listed as “renewal-pending” according to the web-based management console. Eventually, as cached DNS results started to time out throughout the day, I started seeing subdomains come back. I excitedly used the ‘dig’ command to count down the seconds until gamemusic.multimedia.cx was accessible on the network I was on (the number after the domain name is the time-to-live or ‘TTL’ value) :

  $ dig +nocmd gamemusic.multimedia.cx +noall +answer
  gamemusic.multimedia.cx. 3      IN      A       174.143.152.251
  $ dig +nocmd gamemusic.multimedia.cx +noall +answer
  gamemusic.multimedia.cx. 2      IN      A       174.143.152.251
  $ dig +nocmd gamemusic.multimedia.cx +noall +answer
  gamemusic.multimedia.cx. 1      IN      A       174.143.152.251
  $ dig +nocmd gamemusic.multimedia.cx +noall +answer
  gamemusic.multimedia.cx. 12962  IN      A       207.45.186.114
  

  Finally, today (Saturday), I received a receipt confirming that the domain has been renewed.

  8 Years Old
  Incidentally, happy eighth birthday to multimedia.cx. It was September, 2004 when I decided to branch out from a simple ISP-based web presence.

  People often ask why I went with the .cx TLD. When I decided I wanted a proper domain name 8 years ago, I found that multimedia.X was already taken for just about every TLD value of X. .cx was a notable exception and was distinctive enough (speaking of .X, though, I see that multimedia.xxx is still up for grabs as of this writing ; I imagine that would come with a whole other set of problems).

  It’s funny that tech nerds often rail against outsourcing too much — email, storage, computing power, web hosting — all to some type of cloud provider under the premise that it could easily be taken away. But this episode teaches me that even having your own domain name is no guarantee of a solid online presence.

  Meanwhile, I have taken proactive steps to avert this same situation from arising again :

  
  
  

  Barring a lack of automated emails from the registrar, I hope a Google Calendar reminder set up a month ahead of expiration will do the trick.