Where in an mp4 file is the covr atom located? Or where is its location specified, ISO 14496-1?
It is typically located in moov.udta.meta.ilst.covr, see e.g. this implementation of a cover-art-box locator.
The location or existence of the covr atom is not specified by ISO14496 but a non standard extension as explained by this project's wiki.
Related
I am writing a VSCode C++ extension. I would add an include instruction to the current file (which uses the type).
It is like an import instruction in JS.
How can I get the file path of the file where the type is defined?
Is there a way to get the file of goToTypeDefinition or goToDefinition?
you can get the path of the current file with
vscode.window.activeTextEditor.document.uri
How can i include a pre-built binary file into buildroot generated image?
I have tried to include the binary file into appropriate folder in build_dir but every time i try to do make the image is being created without the file.
You can use a root filesystem overlay.
See chapter Project-specific customization in the Buildroot manual.
Just in case someone is looking for a easy fix you can add the files to buildroot-dir/files folder. The file should match the exact directory structure. For example you want to put the file in /usr/bin in the image then keep the file in buildroot-dir/files/usr/bin and rebuild the image.
I've looked for descriptions of the files that go into a Nuget Package (.nupkg), but I have yet to find a definitive guide, most everything assumes you have to use Nuget Explorer, or the Nuget.exe -- but well, let's just say I'm obstinate.
Using the Nuget Explorer to create a package produces a directory with files that I'd like to create using a script or some other tool (besides Nuget.exe). So, given this simple directory layout generated by Nuget Explorer, I'm looking for definition of the .psmdcp file, the .rels file, the [Content_Types.xml] file, and of course the ProjectX.nuspec file.
I can find some details, or deduce them, for [Content_Typex.xml] and the .nuspec file. I tried making a package with just the lib/ dir, it's content, and a nuspec file, but apparently that isn't enough, and I get Package does not contain a manifest -- which I suspect means that the .nuspec alone isn't the full manifest.
lib/
ProjectX.dll
ProjectX.pdb
package/
package/services/metadata/core-properties/____hash____.psmdcp
_rel/
.rels
[Content_Types.xml]
ProjectX.nuspec
Is there no guide for making a .nupkg by hand? Is it really that complicated a process?
.nuspec defines properties about your package (the metadata) as well as a list of files to include in the package. There are plenty of descriptions of this around, so the bits that needs to be addressed are the files that are added by the tools:
.nupkg files follow the Open Packaging Convention. As you have figured out, it is really a .zip file with some predefined files. The _rels directory contain relationships between "parts". Think of a Word document containing images and Excel spreadsheet tables to get an intuition of "parts".
Packages mostly contain only one part; the package itself (but can probably contain sub-packages for modules). The _rels/.rels file defines the relationship for the main, top-level package. A relationship has an ID, a url that describes the kind of relationship and a target, which is the file which has this relationship to the package. Most packages has a relationship to the .nuspec file, which is of kind "manifest", and to the .psmdcp file, which is of kind "core-properties". The IDs of these relationships only need to be unique within the package, so they could be simply strings such as "R1", "R2", but for some reason they are "R" + 16 first bytes of GUID, in choco.
The core-properties seems to be mostly a rehash of the manifest file, dressed in Dublin Core tags instead of the nuspec; I guess in theory other programs could present the package based on these (if you embed it in a Word-document!). Probably psmdcp is an abbreviation of "Package Services Metadata Dublin Core Properties". Checking NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs we see that the name of the file is a simply a GUID with "N" format (just digits). The lastModifiedBy property is the version information of the "choco" assembly itself; I guess you can really put anything there if you create the files yourself.
[Content Types.xml] defines the file format of extensions, in the form of MIME types. This is mostly boiler-plate.
So, in conclusion: Based on the .nuspec you can generate all the other missing files and put together the .nupkg yourself, even in a Powershell script.
I've written a blog post about how you could use the NuGet XSD:
http://www.xavierdecoster.com/post/2012/03/08/Hidden-gem-the-NuGet-package-manifest-XSD.aspx
Also, take a look at the NuGet package conventions in the docs:
http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#Package_Conventions
If you need more detailed hands-on, there's also a Pro NuGet book that goes in-depth into various scenarios:
http://www.amazon.com/NuGet-Professional-Apress-Maarten-Balliauw/dp/1430241918
I generate a doxygen documentation. In one of my "page" I have a link to a pdf file:
<b>Overview</b>
This file is in my project in another directory. The documentation ends up in folder called "html".
How do I tell doxygen to copy the pdf file into html ?
There is a doxygen configuration option HTML_EXTRA_FILES that allows extra files to be copied to the root of the html documentation. You should be able to specify the following to copy the file:
HTML_EXTRA_FILES = ../documents/xxx.pdf
This will place xxx.pdf in the root of your HTML documentation, so you will likely need to change your link to:
<b>Overview</b>
In SPSS 11 it was possible to specify relative paths. Example:
FILE HANDLE myfile='..\..\data\current.txt' /LRECL=533.
DATA LIST FILE=myfile /
...
This worked because apparently, SPSS 11 set the working folder to the path where the source .SPS file is saved. It seems that SPSS 18 always sets it's working folder to the installation folder of SPSS itself. Which is not at all the same thing.
Is there an option to change this behaviour? Or am I stuck with changing everything to absolute filenames?
Instead of a relative path, you could define a directory path and use it inside other file handle declarations to save typing:
FILE HANDLE directoryPath /NAME='C:\Directory\Path\' .
FILE HANDLE myFile /NAME='directoryPath/fileName.xyz' .
GET FILE='myFile' .
This will get the file: C:\Directory\Path\fileName.xyz.
The direction of the slashes may be important.
(Works in version 17)
If you use the INSERT command to run an sps file, it has an option to change the working directory to that location.
You could use the HOST command to SUBST a drive letter (on PCs) and reference everything through that.
You could define a FILE HANDLE to the common root location and use that in file references.
You could use Python programmability to find the path to the active syntax window and issue an SPSS CD command to set the backend working directory appropriately.
HTH,
Jon Peck
With Python, you can get the full path of the current syntax window (or any other one) and get its path. Using that you can issue an SPSS cd command to change the backend working directory accordingly.
If you define an environment variable, though, you can use that in file specifications within SPSS.
p.s. SPSS has an extensive set of apis and helper modules for Python (as well as for R and .NET languages). You can get information about this from SPSS Developer Central, www.spss.com/devcentral. All the language extensions are free once you have the base SPSS Statistics product.
Regards,
Jon Peck
Or use "CD" command to change your default working directory. See also:
http://www.spss-tutorials.com/change-your-working-directory/
For example, if your default directory is C:\project, then GET FILE 'data\data_file.sav'. will open data_file.sav from C:\project\data.
And then, a few minutes later, i came across this little python script from jignesh-sutar (see here: SPSS syntax - use path of the file.
With his python code you can use the path of the syntax file as starting point for all the paths in your syntax.