Saturday, February 6, 2010

AVCHD timecode update

After this post I got some infos from a cat, which helped me to understand the AVCHD metadata format much better. This post summarizes, what I currently know.

AVCHD metadata are stored in an SEI message of type 5 (user data unregistered). These messages start with a GUID (indicating the type of the data). The rest is not specified in the H.264 spec. For AVCHD metadata the data structure is as follows:

1. The 16 byte GUID, which consists of the bytes

0x17 0xee 0x8c 0x60 0xf8 0x4d 0x11 0xd9 0x8c 0xd6 0x08 0x00 0x20 0x0c 0x9a 0x66

2. 4 bytes

0x4d 0x44 0x50 0x4d

which are "MDPM" in ASCII.

3. One byte, which specifies the number of tags to follow

4. Each tag begins with one byte specifying the tag type followed by 4 bytes of data.

The date and time are stored in tags 0x18 and 0x19.

Tag 0x18 starts with an unknown byte. I saw values between 0x02 and 0xff in various files. It seems however that it has a constant value for all frames in a file. The 3 remaining bytes are the year and the month in BCD coding (0x20 0x09 0x08 means August 2009).

The 4 bytes in tag 0x19 are the day, hour, minute and second (also BCD coded).

There are more informations stored in this SEI message, check here for a list.

If you want to make further research on this, you can download gmerlin-avdecoder from CVS, open the file lib/parse_h264.c and uncomment the following line (at the very beginning):

// #define DUMP_AVCHD_SEI

Then you can use bgavdump on your files. It will decode the first 10 frames from the file. If you want to decode e.g. 100 frames, use

bgavdump -nf 100 your_file.mts

21 comments:

Lord Pancreas said...

Thanks for this! I was not looking for timecode, but this points me in the right direction of what I *am* looking for, which is xvYCC color information.

I have the Panasonic HDC-SD9, which shoots AVCHD in 24p or 60i. In 24p mode, it is locked into "Digital Cinema Color", Panny's name for xvYCC color, or extended gamut YCbCr, which uses a color value range of 0-255 rather than 16-235. But this can only be taken advantage of by Digital Cinema Color-compliant devices. The same is true of Sony's "x.v.Color", etc.

So, in non-xvYCC workflows (which is pretty much everybody's), the image looks noticeably duller than that produced by the inbuilt LCD screen when shooting, because you're only reproducing the 16-235 subset of the recorded range of colors.

According to my research, the way this works is through a proprietary extension to AVC via the HDMI spec called "Gamut Boundary Description metadata" that instructs compliant devices to utilize the extra color information, but is ignored by everything else.

I want to overcome that by extracting the full range values and intelligently mapping them to the limited range with a custom colorspace conversion algorithm.

But, I have no idea in which files these values are stored or what bytes to even look for in the hex. Do you have any advice or insight on how I might go about this? Thank you.

burkhard said...

Can you upload a sample file somewhere?

Lord Pancreas said...

Sure. Here's an MTS file (44.8 MiB): http://www.nospoon.tv/test/avchd/00001.MTS. Let me know if you need anything else; I have whole directory structures.

burkhard said...

The AVCHD SEI message (MDPM)
of your file looks like:

Tag: 0x18, Data: ff 20 09 04
Tag: 0x19, Data: 26 19 06 41
Tag: 0x70, Data: c7 12 3f ff
Tag: 0x71, Data: ff 7f ff ff
Tag: 0x7f, Data: 00 00 03 82
Tag: 0xe0, Data: 01 03 03 10
Tag: 0xe1, Data: 83 ff ff ff
Tag: 0xe2, Data: ff ff 80 15
Tag: 0xe3, Data: ff c0 1f ff
Tag: 0xe4, Data: ff ff ff ff
Tag: 0xe5, Data: ff ff ff ff
Tag: 0xe8, Data: 81 00 00 50
Tag: 0xe9, Data: 20 00 00 a4
Tag: 0xea, Data: 00 ff ff ff
Tag: 0xeb, Data: 12 0a 92 00

But there is another SEI type 5 message:

GUID:
a7 46 02 bb f8 a1 4c c0 a9 36 48 e3 91 dc e7 61

Then 4 bytes "CLID"

Then 12 bytes:
92 9b 52 f4 8d 72 96 8c c2 92 00 00

This could be where the color information is stored.

Lord Pancreas said...

Thank you very much! I'll let you know if I find anything.

Unknown said...

You might like to look at this:
http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-8.10/lib/Image/ExifTool/H264.pm - it gives a good explanation of the use of the byte you say is 'unknown'. The byte is used for time zone data and the values seem to check OK in files I downloaded from my Canon HF10. There is also info about other tags.

Unknown said...

I have been trying to compile gmerlin-avdecoder following this post: http://hirntier.blogspot.com/2010/02/avchd-timecode-update.html.
I'm looking for converter that will take an avchd stream and convert the metadata in it (time, date, shutter info, geotags) into text, preferably an SRT subtitle file.
The program bgavdump.c in the suite seems to be a good starting point to create this converter.

However, after significant effort I've not been able to compile it successfully yet. Please help.

I'm using Ubuntu 9.10 clean install, used the package manager to get all sorts of apps and libs in (g++, Xfree, Doxygen, and a couple more). I started with the all-dependencies bundle, but did not manage to complete to the end. Then focussed on gmerlin-avdecoder only. I've had to edit the configure file because it complained about HAVE_VDPAU not having been set, and am not completely sure about whether I made the right choice there to bypass. At the end, I've just tried to compile & link bgavdump.c and it gave up as per below. Seems close though.

Any help appreciated.

bin/bash ../libtool --tag=CC --mode=link gcc -D_REENTRANT -D_FILE_OFFSET_BITS=64 -I/usr/local/include -Wall -Wmissing-declarations -Wdeclaration-after-statement -Wl,--rpath -Wl,/opt/gmerlin/lib -o bgavdump bgavdump.o ../lib/libgmerlin_avdec.la -lz -lpthread -L/usr/local/lib -lgavl
libtool: link: gcc -D_REENTRANT -D_FILE_OFFSET_BITS=64 -I/usr/local/include -Wall -Wmissing-declarations -Wdeclaration-after-statement -Wl,--rpath -Wl,/opt/gmerlin/lib -o .libs/bgavdump bgavdump.o ../lib/.libs/libgmerlin_avdec.so -lz -lpthread -L/usr/local/lib /usr/local/lib/libgavl.so
../lib/.libs/libgmerlin_avdec.so: undefined reference to `XOpenDisplay'
../lib/.libs/libgmerlin_avdec.so: undefined reference to `XCloseDisplay'
../lib/.libs/libgmerlin_avdec.so: undefined reference to `vdp_device_create_x11'
collect2: ld returned 1 exit status
make: *** [bgavdump] Error 1

burkhard said...

I cannot help fixing compilation errors after the configure script got hacked. One should find out why it failed in the first place. In this case I need the output compiler output and the config.log file.

Also you should use the latest (ideally CVS) version. For bugreports, the gmerlin-general mailinglist (low traffic and spam free) is the official channel.

Unknown said...

Great. I'm using a clean Ubuntu 9.10 (from the live CD) virtual machine under VMWare Player 3.0.1 and the latest gmerlin 20100918 all-in-one and dependencies. Should be easy to reproduce. I'll recreate the problem and report as requested. May take a while....

Unknown said...

Managed to compile bgavdump successfully now. Does someone know how tag B4 is interpreted? In my case for instance, the data says
"Tag: 0xb4, Data: c4 ea 03 e8"
and this should translate to 50.41. I must be missing the trick.

burkhard said...

Just play around a little:
50410 in Hex is 0xc4ea (your first 2 bytes).

Unknown said...

Just to let you know: this is what I created so far, using all the learnings: http://forum.videohelp.com/threads/316229-Export-AVCHD-frame-specific-metadata-to-subtitles

Does anyone know how exiftool figures out the time zone info in the H264 data stream?

Unknown said...

Found it. It's the "unknown byte" that 0x18 starts with. 5 bits are counting the half hours difference from GMT and bit six is the sign.

On Sony, that is. Panasonic seems to use constant 0xff at that spot.

Unknown said...

I would just like to say thanks, a complete newbie to timecode. lol...

Unknown said...

Tag 0x18 starts with an unknown byte. I saw values between 0x02 and 0xff in various files. It seems however that it has a constant value for all frames in a file. The 3 remaining bytes are the year and the month in BCD coding (0x20 0x09 0x08 means August 2009). free mkv avi converter

Unknown said...

MPEG-4AVC/H.264 way is more than 2 times higher than the MPEG-2 and MPEG-4 efficiency high efficiency compressed recording mode, there is a great market potential for development. With [AVCHD] specification, high-definition digital high-definition images shot with a high-definition digital video camera can also be recorded in a compact 8-cm DVD discs.
i have ever played the MPEG-4AVC/H.264. but made ​​little achievements,and you can play how to convert avi to mp4

Unknown said...

[AVCHD] specification is a highly efficient compression technology, the 1080-line interlaced or 720-line progressive scan HD signal recorded on 8 cm DVD discs, high-definition digital video camera specifications.The image compression to adopt MPEG-4AVC/H.264 way sound with Digital Dolby Pro Logic AV-3 ways, or linear PCM mode.This specification is to make high-definition digital video camera can be at the same time maintaining a smaller volume, high quality and high sound quality.
Hope useful to you.or study avi to iTunes .

Unknown said...

Great post.Really appreciate your work.http://www.convert-avitomp4.com/product.html

cheney said...

This week, Rise of the Planet of the Apes has been released, to be honest, I got this movie and I don't know how to convert Rise of the Planet of the Apes AVCHD to MP4 HD for watching.

Fortunately, I got Aunsoft iMedia Converter for Mac. It's really remarkable and I am so fond of it!

Jim K said...

Thank you for this information. Just went to Windows 10 64-bit, and learned that the ImageMixer software that came with my Canon camera probably won't work. I hadn't realized that this software was extracting the date and time from the video files and changing the file name during the import to my computer to YYYYMMDDHHMMSS.M2TS (from an unhelpful sequential numbering scheme on the camera). Using the information above, I've written a windows forms program to rename the files in bulk after copying from the camera.

Unknown said...

Compared time codes calculated using the above method and those generated by the Transfer Utility application bundled with my Canon camcorder and found in most cases they're the same. Interestingly the application seems to get time codes from the 2nd frame for the most of the time except for 2 out of 996 files.