summaryrefslogtreecommitdiffstats
path: root/core/xmp_parser.cpp
AgeCommit message (Collapse)Author
2020-05-01cleanup: move declaration of utc_mk* functions to new subsurface-time.h headerGravatar Berthold Stoeger
No point in slurping in all of dive.h for translation units that only want to do some time manipulation without ever touching a dive. Don't call the header "time.h", because we don't want to end up in a confusion with the system header of the same name. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2019-10-28Cleanup: use helper to avoid NULL dereferenceGravatar Dirk Hohndel
We have these helper functions for exactly this purpose. Found by Coverity. Fixes CID 350129 Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-03-18Desktop: fix yet another variable name conflictGravatar Robert C. Helling
Addresses LGTM.com issue. Signed-off-by: Robert C. Helling <helling@atdotde.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2018-09-25Metadata: rudimentary support for XMP metadataa in MP4-based videosGravatar Berthold Stoeger
XMP is a media-metadata standard based on XML which may be used across a variety of media formats. Some video-processing software writes XMP data without updating the native metadata fields. Therefore, we should aim at reading XMP metadata and give priority of XMP data over native fields. Pros: - Support for *all* common media formats. Cons: - XML (complex, verbose, chaotic). - Does not even come close to fulfilling its promise of being well defined (see below). Implement a simple XMP-parser using libxml2. Connect the XMP-parser to the existing Quicktime/MP4 parser. First problem encountered: According to the spec, XMP data supposed to be put in the 'XMP_' atom. But for example exiftools instead writes an 'uuid' atom with a special 16-byte uid. Implement both, more options will probably follow. Second problem: two versions of recording the creation date were found 1) The content of a <exif:DateTimeOriginal> tag. 2) The xmp::CreateDate attribute of a <rdf:Description> tag. Here too, more versions are expected to surface and will have to be supported in due course (with an obvious priority problem). Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>