Login at Kodi Home

fekker · (This post was last modified: 2009-09-17, 22:48 by fekker.)

There was idea about embeding information into the container for video files

As a test I grabbed mkvtoolnix and embeded some attachments as well as a video file into an mkv container. xbmc plays the video (as expected)

Using mkvtoolnix, specifically mkvinfo, i can see the attachments have a file name as well as a description in the mkv container. (as shown below with movie.nfo, folder.jpg, and fanart.jpg).

Code:
(MKVInfo) + EBML head at 0

(MKVInfo) |+ Doc type: matroska at 5

(MKVInfo) |+ Doc type version: 2 at 16

(MKVInfo) |+ Doc type read version: 2 at 20

(MKVInfo) + Segment, size 6429027 at 24

(MKVInfo) |+ Seek head at 36

(MKVInfo) | + Seek entry at 41

(MKVInfo) |  + Seek ID: 0x15 0x49 0xa9 0x66 (KaxInfo) at 44

(MKVInfo) |  + Seek position: 4099 at 51

(MKVInfo) | + Seek entry at 56

(MKVInfo) |  + Seek ID: 0x16 0x54 0xae 0x6b (KaxTracks) at 59

(MKVInfo) |  + Seek position: 4252 at 66

(MKVInfo) | + Seek entry at 71

(MKVInfo) |  + Seek ID: 0x11 0x4d 0x9b 0x74 (KaxSeekHead) at 74

(MKVInfo) |  + Seek position: 6428749 at 81

(MKVInfo) | + Seek entry at 87

(MKVInfo) |  + Seek ID: 0x1c 0x53 0xbb 0x6b (KaxCues) at 90

(MKVInfo) |  + Seek position: 6428729 at 97

(MKVInfo) | + Seek entry at 103

(MKVInfo) |  + Seek ID: 0x19 0x41 0xa4 0x69 (KaxAttachments) at 106

(MKVInfo) |  + Seek position: 5515 at 113

(MKVInfo) |+ EbmlVoid (size: 4014) at 118

(MKVInfo) |+ Segment information at 4135

(MKVInfo) | + Timecode scale: 1000000 at 4141

(MKVInfo) | + Muxing application: libebml v0.7.7 + libmatroska v0.8.1 at 4148

(MKVInfo) | + Writing application: mkvmerge v2.9.8 ('C'est le bon') built on Aug 13 2009 12:49:06 at 4186

(MKVInfo) | + Duration: 33.240s (00:00:33.240) at 4251

(MKVInfo) | + Date: Thu Sep 17 18:56:44 2009 UTC at 4258

(MKVInfo) | + Segment UID: 0x9a 0xfc 0xfb 0x89 0xb6 0xec 0xf1 0x6e 0xb9 0x04 0xc5 0x5d 0xd9 0x27 0x17 0x32 at 4269

(MKVInfo) |+ Segment tracks at 4288

(MKVInfo) | + A track at 4294

(MKVInfo) |  + Track number: 1 at 4297

(MKVInfo) |  + Track UID: 3041326251 at 4300

(MKVInfo) |  + Track type: video at 4307

(MKVInfo) |  + Enabled: 1 at 4310

(MKVInfo) |  + Default flag: 1 at 4313

(MKVInfo) |  + Forced flag: 0 at 4316

(MKVInfo) |  + Lacing flag: 0 at 4320

(MKVInfo) |  + MinCache: 1 at 4323

(MKVInfo) |  + Timecode scale: 1 at 4327

(MKVInfo) |  + Max BlockAddition ID: 0 at 4335

(MKVInfo) |  + Codec ID: V_MS/VFW/FOURCC at 4339

(MKVInfo) |  + Codec decode all: 1 at 4356

(MKVInfo) |  + CodecPrivate, length 40 (FourCC: DIV3, 0x33564944) at 4359

(MKVInfo) |  + Default duration: 41.708ms (23.976 fps for a video track) at 4402

(MKVInfo) |  + Language: und at 4410

(MKVInfo) |  + Video track at 4417

(MKVInfo) |   + Pixel width: 640 at 4419

(MKVInfo) |   + Pixel height: 352 at 4423

(MKVInfo) |   + Interlaced: 0 at 4427

(MKVInfo) |   + Display width: 640 at 4430

(MKVInfo) |   + Display height: 352 at 4435

(MKVInfo) | + A track at 4440

(MKVInfo) |  + Track number: 2 at 4442

(MKVInfo) |  + Track UID: 1295843229 at 4445

(MKVInfo) |  + Track type: audio at 4452

(MKVInfo) |  + Enabled: 1 at 4455

(MKVInfo) |  + Default flag: 1 at 4458

(MKVInfo) |  + Forced flag: 0 at 4461

(MKVInfo) |  + Lacing flag: 1 at 4465

(MKVInfo) |  + MinCache: 0 at 4468

(MKVInfo) |  + Timecode scale: 1 at 4472

(MKVInfo) |  + Max BlockAddition ID: 0 at 4480

(MKVInfo) |  + Codec ID: A_MPEG/L3 at 4484

(MKVInfo) |  + Codec decode all: 1 at 4495

(MKVInfo) |  + Default duration: 24.000ms (41.667 fps for a video track) at 4498

(MKVInfo) |  + Language: und at 4506

(MKVInfo) |  + Audio track at 4513

(MKVInfo) |   + Sampling frequency: 48000 at 4515

(MKVInfo) |   + Channels: 2 at 4521

(MKVInfo) |+ EbmlVoid (size: 1024) at 4524

(MKVInfo) |+ Attachments at 5551

(MKVInfo) | + Attached at 5558

(MKVInfo) |  + File name: fanart.jpg at 5563

(MKVInfo) |  + Mime type: image/jpeg at 5576

(MKVInfo) |  + File data, size: 130944 at 5589

(MKVInfo) |  + File UID: 2125069724 at 136538

(MKVInfo) |  + File description: fanart at 136545

(MKVInfo) | + Attached at 136554

(MKVInfo) |  + File name: folder.jpg at 136559

(MKVInfo) |  + Mime type: image/jpeg at 136572

(MKVInfo) |  + File data, size: 228078 at 136585

(MKVInfo) |  + File UID: 150730918 at 364668

(MKVInfo) |  + File description: preview at 364675

(MKVInfo) | + Attached at 364685

(MKVInfo) |  + File name: movie.nfo at 364689

(MKVInfo) |  + Mime type: application/xml at 364701

(MKVInfo) |  + File data, size: 4818 at 364719

(MKVInfo) |  + File UID: 2392821424 at 369541

(MKVInfo) |+ Cluster at 369548

so my question is this
how feasable is it for xbmc to pull the data directly out of the container for the metadata and images

using the xml files that are currently supported (.nfo) as well as the standard naming convention (or an extended version that allows more options) this would be a neat way to keep the data associated with the correct file, and support for many video types seems to be there with no transcoding/decoding etc required for me to inject that data into the file.

the same could be done with music files as well (images, metadata, whatever)

if the current image naming convention was expanded, all associated images could be in the container with the video

Something like this (just threw it together)

Code:
Types of data

mkv metadata

metadata.nfo (xml)

images

prefix(th) = thumbnail size (small image)

prefix(sm) = smaller image

prefix(lg) = full sized image

prefix(sw) = small wideformat 480p (720x480)

prefix(mw) = medium wideformat 720p size (1280x720)

prefix(lw) = large wideformat 1080p size (1920x1080)

mkv image support (video)

thfanart (jpg) 

swfanart (jpg) 

mwfanart (jpg)

lwfanart (jpg) 

thposter (jpg)

smposter (jpg)

lgmposter (jpg)

smwideimage (jpg)

lgwideimage (jpg)

smdisc1 (jpg)

lgdisc1 (jpg)

sminsert (jpg)

lginsert (jpg)

smfront (jpg)

lgfront (jpg)

smback (jpg)

lgback (jpg)

sminlay (jpg)

lginlay (jpg)

to extract the files back out
mkvmerge --identify %fullPathAndName%
regex (or awk/sed) of that result, look for file names on match get ids
mkvextract attachments %fullPathAndName% %id%:%outputPathAndName%

example output from mkvmerge --identify command

Code:
C:\Users\me>mkvmerge --identify C:\Users\me\Videos\test\vsshort.mkv

File 'C:\Users\me\Videos\test\vsshort.mkv': container: Matroska

Track ID 1: video (V_MS/VFW/FOURCC, DIV3)

Track ID 2: audio (A_MPEG/L3)

Attachment ID 1: type 'image/jpeg', size 130944 bytes, description 'fanart', file name 'fanart.jpg'

Attachment ID 2: type 'image/jpeg', size 228078 bytes, description 'preview', file name 'folder.jpg'

Attachment ID 3: type 'application/xml', size 4818 bytes, file name 'movie.nfo'

to get the fanart (either by description or filename), match the text and get it's id, 1 in this case, and save it as extractedfanart.jpg

Code:
mkvextract attachments C:\Users\me\Videos\test\vsshort.mkv 1:C:\Users\me\Videos\test\extractedfanart.jpg

it looks like mkvextract is using two main libs
libmatroska and libebml

I'm not really sure how to get those to work directly in umx, but they are c++ open source. I know I can call mkvextract and mkvmerge, and since those are cross platform, it should work out the same as mediainfo.dll does (just changing the .config for the exe (mono exe) to tell it to use the nix library for that call. (in theory)

mots · 2009-09-17, 21:32

This actually sounds like a great idea Big Grin

pbjr · (This post was last modified: 2009-09-18, 01:32 by pbjr.)

I like this thinking too. Everything contained in the MKV. Very clean.

I'm all MKV these days. Currently, I am using the MKV "Track name" field to store additional media info.

I convert bluray HD audio to flac and keep info on what it was prior to conversion. So for example, I put "DTS-MA" in the audio track name.

I was hoping one day that I could get my XBMC library to use the track name info to show "DTS-MA", "TrueHD", "PCM", etc. instead of "flac".

Thanks

elupus · 2009-09-21, 13:15

Showing the track name aught to be quite simple to add. We've just not updated our code to use libavformat's new metadata API.

jz1276 · (This post was last modified: 2012-06-14, 06:43 by jz1276.)

I just came across this thread after posting the exact same question. Attaching the movie.trailer, movie.tbn, movie-fanart.jpg, and movie.nfo to the mkv file and having XBMC read all that data within the mkv file would be awesome.

anaximandus · 2014-01-02, 16:26

Hi there, what's the status on this one? I'd like to use MKV as a standard container for family videos, and use attachments as "title cards", which I would like XBMC to show as thumbnail.

gaiko · 2014-01-03, 12:48

I'd love this, I've asked around about something like this before (though the origonal poster has a much better technical grasp of it than me). It would be very clean and really help with migration in the future and just seems to make sense to me, if you look at how it works for music with cover art and all the other metadata and how music apps pull that from the files XBMC using it as well would be great. Anyway, it has my vote!

pummi · 2014-01-05, 13:23

I would REALLY like this, too.
In fact, I already add tags, cover images and fanart to my mkv files for quite some time - in the hope that it will be supported by xbmc sometime.

It would be cool, if there was a scraper, which would take this information.

Here is an example how it could look like (but I am happy to change the tags in my files if there is another standard)

Code:
<?xml version="1.0"?>

<!-- <!DOCTYPE Tags SYSTEM "matroskatags.dtd"> -->

<Tags>

  <Tag>

    <Targets>

      <TargetTypeValue>50</TargetTypeValue>

    </Targets>

    <Simple>

      <Name>TITLE</Name>

      <String>Kick-Ass 2</String>

    </Simple>

    <Simple>

      <Name>DATE_RELEASED</Name>

      <String>2013</String>

    </Simple>

    <Simple>

      <Name>SUMMARY</Name>

      <String>After Kick-Ass: insane bravery inspires a new wave of self-made...</String>

    </Simple>

    <Simple>

      <Name>TMDB</Name>

      <String>movie/59859</String>

    </Simple>

    <Simple>

      <Name>IMDB</Name>

      <String>tt1650554</String>

    </Simple>

    <Simple>

      <Name>GENRE</Name>

      <String>Action</String>

    </Simple>

    <Simple>

      <Name>GENRE</Name>

      <String>Comedy</String>

    </Simple>

    <Simple>

      <Name>GENRE</Name>

      <String>Crime</String>

    </Simple>

    <Simple>

      <Name>RATING</Name>

      <String>6.9</String>

    </Simple>

    <Simple>

      <Name>DIRECTOR</Name>

      <String>Jeff Wadlow</String>

    </Simple>

    <Simple>

      <Name>ACTOR</Name>

      <String>Christopher Mintz-Plasse</String>

      <Simple>

        <Name>CHARACTER</Name>

        <String>Chris D'Amico / The Mother F%$$%r</String>

      </Simple>

    </Simple>

    <Simple>

      <Name>ACTOR</Name>

      <String>Lyndsy Fonseca</String>

      <Simple>

        <Name>CHARACTER</Name>

        <String>Katie Deauxma</String>

      </Simple>

    </Simple>

  </Tag>

</Tags>

(This is according to http://matroska.org/technical/specs/tagg...video.html - for a small example, see http://matroska.org/files/tags/dune.xml )

I already looked at the scraper tutorials, but they seem to support only downloading data from the web and parsing it using regexes.

I also add covers as "cover.jpg" (see http://matroska.org/technical/cover_art/index.html ) and fanart as "fanart.jpg, fanart_1.jpg, fanart_2.jpg, ...")

defrost · 2014-01-13, 01:30

While I've read the exact same spec as Pummi is quoting above and agree in principal with the sentiment ....

Forty+ years of chasing digital specs for a plethora of meta data formats for a multitude of implementations telss me ONE thing - K.I.S.S - Keep It Simple !

The Matroska spec DOES NOT have a wide array of examples of meta data tags, it IS NOT mature, etc. etc.

The simplest and most powerful / flexible solution of LEAST SUPPORT is to agree upon a tag such as "XBMC/NFO/VER" and simply attach ( just as you would attach a JPEG or a (ANY FILE)) a standard, already supported xbmc .NFO file.

The parsers for that format already exist, the ongoing support for the format is already there, and it's more of an industry|niche standard for TV|Film|Etc. metadata that *anything* in the Matroska spec.

To build & support requires no more than testing if an .MKV has XBMC.NFO or not, and the ability to attach / replace / detach / extract that file -- all of which already exists with wide support in the Matroska libraries and the MKVToolNix CLI/GUI tools / utils.

pummi · 2014-01-13, 20:17

This would be ok for me too. Smile

Both approaches have advantages.
I think it's up to the person that actually implements the feature to decide.

gregorv · 2014-07-19, 11:23

Yes please, I also would like that. Should not be too complicated to extend the existing part for reading nfo files to also look into the matroska container for retrieving the nfo file from there, if it does not exist as a separate file. As a temporary solution I have written a little php script that retrieves tags & cover from a mkv file and delivers the output for a scraper, but it needs a web server (can be found here: MKV tag scraper).

Seegras · 2015-01-02, 17:57

For anyone searching a solution to incorporate the contents of an .nfo (and the cover-art) into an .mkv file, I just wrote something here as well: http://forum.kodi.tv/showthread.php?tid=199844

I still think the ability to at least _read_ basic information from embedded mkv metadata is a must. In fact, it can't even read the title-tag (the one you can set with mkvpropedit --edit info --set title=), which is not even part of the rather complicated xml-structure-metadata that must be muxed in.

gregorv · 2015-01-02, 18:30

Actually Kodi does extract Matroska meta data from the file but there is no way to get them into the database. So the task to implement this feature would not be huge. See the log extract:

Code:
30:03 T:140414149453568    INFO: ffmpeg[7FB4B77FE700]: Input #0, matroska,webm, from 'smb://VNETMAIN/Movies/Der Schatz der Azteken.mkv':

30:03 T:140414149453568    INFO: ffmpeg[7FB4B77FE700]:   Metadata:

30:03 T:140414149453568    INFO: ffmpeg[7FB4B77FE700]:     creation_time   : 2015-01-02 10:38:59

30:03 T:140414149453568    INFO: ffmpeg[7FB4B77FE700]:     encoder         : libebml v1.3.0 + libmatroska v1.4.1

30:03 T:140414149453568    INFO: ffmpeg[7FB4B77FE700]:     TITLE           : Der Schatz der Azteken

30:03 T:140414149453568    INFO: ffmpeg[7FB4B77FE700]:     ORIGINAL_TITLE  : Der Schatz der Azteken

...
Even custom fields like e.g. IMDBID are seen - but ffmpeg does it not really correct for multiple fields like ACTOR it just takes the last entry only. But this could be solved if the ACTOR field contains a coma separated list.
The MediaBrowser.Naming project sound like something is moving here Wink

.