#1 Lumix GH4

You can almost sense when technologies are about to be disrupted.

Take the internal combustion engine used in automobiles.

For about a century the petrol and diesel motors in our cars have experienced incredible improvements, we can talk about 10x increase in energy efficiency, and don’t get me started with reliability, noise and air pollution.

Even in the last 15 years we have seen dramatic changes, like turbocharged diesel engines in sport cars, common rail direct fuel injection, with electronics and firmware keeping the fuel consumption always optimized.

The 1955 Mercedes-Benz 300SL, the first production sports car to use fuel injection, is remembered first and foremost for its gull wing doors.

Diminishing Returns

Yet it seems that reducing fuel consumption further, even a measly 5% or 10%, will require enormous efforts.

In high-end cars we start to see byzantine solutions, like reducing floor clearance at highway speeds to improve aerodynamics, closing partially the front grille to reduce drag while having enough engine cooling, “smart” management of pumps and air conditioning, and so on…

We are clearly in “diminishing returns” phase of the innovation cycle. Actually the engine system itself is already fully optimized; today fuel efficiency improvements come from the rest of car.

We are getting close to the hard limit. Thermodynamic cycle of combustion engines allow for a fuel efficiency of 25% to 30% at most. End of story.

Electric cars, on the other side, will soon be mainstream starting at 80% efficiency. (Producing electricity efficiently is another story, but let’s stay focused on our topic)

The State of Art for H.264 video in DSLR Cameras

I can almost sense that H.264 video encoding is at the same point in its technological cycle as combustion engine.

Today we are pulling almost 100% of its potential.

Just as combustion engine efficiency is limited by the laws of thermodynamics, H.264 encoding efficiency is limited by a standard approved in 2003. It has received amendments over the last decade, but the efficiency of the codec can’t improve significantly unless you redesign it.

First H.264 encoding chips didn’t have all the bells and whistles that Advanced Video Coding standard allows for.
For example, CABAC entropy encoding is about 10% more efficient than CAVLC, but makes chip design more complex.

This improvement in H.264 is the equivalent of common rail direct injection.

Panasonic Lumix GH4
source: ephotozine – Joshua Waller

Then some manufacturers started to use different H.264 encoding settings depending on light, for example 3 possible settings for low light, interior and outdoor.

Canon introduced this optimization in cameras with DIGIC 5+ chip, starting with EOS 5D Mark III in 2012.

It consists in offering 3 different H.264 encoder configurations (called Picture Parameters Sets or PPS), each with a different value for a parameter called pic_init_qp_minus26.

The H.264 specification doesn’t shed too much of a light on what this parameters stands for:

pic_init_qp_minus26 specifies the initial value minus 26 of SliceQPY for each slice. The initial value is modified at the slice layer when a non-zero value of slice_qp_delta is decoded, and is modified further when a non-zero value of mb_qp_delta is decoded at the macroblock layer. The value of pic_init_qp_minus26 shall be in the range of -(26 + QpBdOffsetY ) to +25, inclusive.

In layman terms, this tells the encoder to encode with more detail the shades of color that dominate the picture, and thus avoid color banding: Image quality is slightly improved while keeping same bitrate.

This is like fine tuning the automatic transmission to optimize fuel efficiency.

Lumix GH4 seeking optimal H.264 video encoding

But there’s still a problem: at the time you start recording, the camera has to pick one of the possible H.264 encoding settings and stick with it until you push STOP. This is not optimal if you walk from interior to outdoor while camera is recording!

This is where Panasonic engineers made a smart contribution:
GH4 cameras also use several PPS, but they dynamically change the active PPS frame by frame to always use the settings that will yield optimal image quality.

Not only that: instead of playing with pic_init_qp_minus26, they use a more fine-grained method to get optimal quality called Picture Scaling Matrix.

Picture Scaling Matrix gives you fine-grained control

pic_init_qp_minus26 is more like a dial

Lumix GH4 engineers have used all the tricks in the H.264 encoding playbook to achieve optimal video quality.
There’s no much room for improvement for future H.264 cameras.

The Lumix GH4 is a serious contender to be remembered as a top DSLR camera of the H.264 era, just as the Leica M6 for rangeviewer film cameras.

Disruption Ahead: H.265

HEVC (H.265), the new standard for video encoding, promises a 50% economy in bitrate at constant quality over H.264.
Let’s see how the transition plays out in the next months. The whole industry has yet to start adopting the new standard.

If this is any indication of what is coming, last month we have received our first corrupt H.265 video from a Samsung Gear 360 camera.

Our tools are not yet ready to detect and repair H.265 routinely, but we already have some prototypes running in-house to address such repair requests and we will be ready for when the H.265 deluge starts.

For the moment, H.265 is only present in specialized markets (surveillance, IP cameras) and in new Samsung products (Gear 360, NX series).

#2 DJI drones

During this 2015 we did a lot of drone footage repairs. A lot. Different drone models, brands, settings, but all of them share some common points. A worried customer and some non working files.
Crashed Drone
Back in 2013 and 2014, when all the drones fever started, we used to receive a lot of repair requests with, more or less, same content. Rude flight footage ending with a hard landing.

Fortunately, seems that our 5 Tips to Avoid Crashing your Copter on the First Day were taking into account and the skills of all of those pilots improved during this time.

But not only man skills were improved, but also the drone capabilities (Worry-free autopilot, Built-in practice flight simulator, etc). Now the copters are able to flight longer, faster, higher, farther and, what’s more interesting, they’re able to broadcast the live footage that is being recorded (Live HD view).

[UPDATE]: Seems DJI removed human pilot skills from the equation in their latest released model, the DJI Phantom 4.
Those factors changed our view about the drone’s damaged files. From a basic repair approach we evolved to a recovery one. Now the customer finds that sometimes their files are simply gone. Only a blank, usually mistakenly, formatted card is left behind. Data should be found and afterwards repaired.

That’s where our magic begins…

What could be done when a whole card, containing the aerial takes of your Thailand trip, is formatted before all clips had been backed up on your computer’s hard drive? Reshoot seems not an option but thanks to Treasured and it’s DeepMediaScan feature we can bring back the footage.

Thailand Aerial View

This particular case was involving a DJI Phantom 3 drone and 1080p at 50 fps video only (no Audio track). Despite DeepMediaScan results were promising, there was something weird within the data that caused any Video player closes when trying to play the clips. Seemed clear we must go the extra mile.

After some data struggling, we finally find the clue. There were some blocks of alien data (garbage data from any other source but not the footage we’re trying to repair) of 0x100000 bytes each every 4 seconds of Video.

That required a custom tailored cleaner to accurately remove them and, finally, repair the real footage data. Those blocks of data, as after some more study revealed, were in fact, parts of the proxy video that is being broadcasted from the drone to the remote control.

Looks similar to the good known Kayak problem with the GoPro cameras, but this time, those blocks of data are formatted in raw H264 instead of LRV (Low Resolution Video). Lesson learnt and repair flow updated.

Nothing compares with the satisfaction of the positive feedback from the customers when they get back their clips repaired. That make us feel that the effort put in every request is worthy.

Please fly your drone in the safest way possible, improve your pilot skills, and use top quality memory cards to record your footage. And obviously, have fun!

When everything else fails, we’ll be here ready to help you.

#3 XAVC-S

Thanks to the success of Sony A7 series and Sony AX series, XAVC-S is today one of the most common format that we are requested to repair, and so it deserves its number 3 ranking in my list of Tops and Flops of 2015.

In Sony XAVC family, the “S” flavor is the mainstream one, used by a wide range of devices, from DSLR cameras to cheap consumer camcorders.

In its novel “The Leopard”, Tandredi has the famous quote:

If we want things to stay as they are, things will have to change.

This illustrates perfectly what XAVC-S is in essence: A new name for our usual suspect, AVC/H.264

Back in 2013 when XAVC was unveiled, there wasn’t a lot of choice as far as video compression is concerned:
Once discarded the future technology (HAVC/H.265) that wasn’t ready, Sony could only pick either 20-years old MPEG-2 or 10-years old AVC/H.264.

H.264 scales to 4K, has better compression and quality, so the technical decision was easy.
But the marketing guys were not happy with that, because

you know, everybody else is doing H.264, we are Sony and for our new 4K products we need differentiation. We will use H.264 but it must be with another fancy new name.

OK let’s call it XAVC.

And the marketing guy to add: “and we need different brand names for cinematography-grade, professional and consumer H.264” and so were invented the names XAVC-I, XAVC-L and XAVC-S.

Therefore, XAVC-S is nothing more than regular AVC/H.264 wrapped in a standard MP4 container.

Change Management

Let me tell you my first contact with XAVC-S in spring 2014.
Ironically, this was a corrupt recording of a conference on “Change Management”…

I was expecting this to be business as usual, a boring video (change management, anybody?) recorded in standard H.264 in MP4 container.
Apparently nothing new under the sun.. but I was wrong.

What first grabbed my attention was Treasured insistence in reporting “MXF”. In a video allegedly wrapped in MP4, the last thing you expect to detect is precisely MXF.

Treasured sometimes has “false positives”, so I fired my hex editor to check what was going on.
Upon searching for the MXF header (060e 2b34), I quickly found lots of matches inside the file.


00000c0: 0008 0100 00ad 034b 060e 2b34 0253 0101 .......K..+4.S..
00000d0: 0c02 0101 0101 0000 8300 000c 8000 0002 ................
00000e0: b3e3 8001 0002 51ad 060e 2b34 0253 0101 ......Q...+4.S..
00000f0: 0c02 0101 0201 0000 8300 0036 8100 0010 ...........6....
0000100: 060e 2b34 0401 010b 0510 0101 0101 0000 ..+4............
0000110: 8101 0001 0181 0900 0800 0000 0100 0000 ................
0000120: 6481 0a00 0200 0081 0c00 0200 6481 0d00 d...........d...
0000130: 0101 060e 2b34 0253 0101 0c02 0101 7f01 ....+4.S........
0000140: 0000 8300 002f e000 0010 9669 0800 4678 ...../.....i..Fx
0000150: 031c 2051 0000 f0c0 1181 e300 0001 00e3 .. Q............
0000160: 0200 0100 e303 0001 ffe3 0400 0844 2015 .............D .
0000170: 0625 0321 5100 0000 0000 0000 0000 0000 .%.!Q...........

Obviously Treasured was right, the Sony engineers had inserted MXF stuff inside their XAVC-S MP4 file. WTF?

I asked Mike (my “Change Management” customer) to send me a playable XAVC-S file, so I could investigate this in depth.

What were they smoking?

What I discovered was even more puzzling: MXF data is indeed part of a bigger, more byzantine thing.

The bits of MXF are inside samples of a real time metadata track of the MP4.
To every video frame corresponds one of such metadata sample of 1024 bytes.

Metadata samples look like the diagram below, and are padded with 00 bytes until filling the 1024 bytes size.
Others samples also include a mysterious a “kkad” atom at the end (more on this below).

Header was easy to understand:
0008 0100 00ad 034b
It reports the length in bytes of the components of the sample:

  • 8 bytes for the header itself
  • 0xAD bytes for the MXF KLV (Key Length Value)
  • 0x34B bytes for padding or kkad data.

And of course, the sum is 1024.

MXF KLV itself contains several items, but most are encoded in a proprietary format, and I haven’t managed to understand everything.
In any case, it is not very important and I can prove it:

This metadata is not even necessary.
For two years, I have been repairing XAVC-S without bothering to include the metadata inside the repaired videos, and no customer has reported any problem!

Therefore, Sony engineers have managed a real tour de force:
They have created a video format whose unique “new” feature (besides the shiny XAVC-S name) is to stuff some metadata that is not even being used!

To really appreciate the feat, let’s take a look at this mysterious kkad stuff:

“kkad” blocks include tables with addresses, lengths, and time code information of every video sample.

And with this we close the circle of stupidity:
This information would be useful if it wasn’t already included in the standard MP4 video track.

Yes, Sony engineers have added a metadata track with a proprietary and byzantine format that not only isn’t used, but contains information already present elsewhere in the MP4 container.

And there’s more strange stuff throughout our XAVC-S file…
For example, inside the H.264 stream we have NAL objects of type 6 with more metadata “smoke”.
Or the unnecessary file header below:


0000000: 0000 001c 6674 7970 5841 5643 0100 1fff ....ftypXAVC....
0000010: 5841 5643 6d70 3432 6973 6f32 0000 0094 XAVCmp42iso2....
0000020: 7575 6964 5052 4f46 21d2 4fce bb88 695c uuidPROF!.O...i\
0000030: fac9 c740 0000 0000 0000 0003 0000 0014 ...@............
0000040: 4650 5246 0000 0000 2000 0000 0000 0000 FPRF.... .......
0000050: 0000 002c 4150 5246 0000 0000 0000 0002 ...,APRF........
0000060: 7477 6f73 0000 0000 0000 0000 0000 0600 twos............
0000070: 0000 0600 0000 bb80 0000 0002 0000 0034 ...............4
0000080: 5650 5246 0000 0000 0000 0001 6176 6331 VPRF........avc1
0000090: 0164 002a 0003 0002 0000 c350 0000 c350 .d.*.......P...P
00000a0: 0032 0000 0032 0000 0780 0438 0001 0001 .2...2.....8....

Besides the funny “XAVC”, we have here a description of the tracks:
Audio “twos” at 48000Hz (0xbb80)
Video “avc1” with resolution 1920 x 720 (0x780 0x438)

Again, all this information was already present in the MP4 tracks, so why duplicate it in other places?

XAVC-S: Engineered with love by Sony

If you are in software or firmware development and you have been working in a large organization, the reasons behind all this oddity should now be clear to you.

This is what I call “Frankenstein Engineering”, and it works like this:

  • Marketing decides that a new product with features A, B and C shall be developed
  • Management green lights the project, and gives the R&D departments a short schedule and a low budget
  • Every department has no choice but picking existing, off-the-shelf components and shoe-horn them into the product
  • Extra points if the different departments are spread across continents, have incompatible road maps, and don’t talk to each other anyway
  • When you put hardware, electronics, firmware and software together it’s a disaster, but it can be fixed
  • Eventually the company manages to ship a decent product, but internally the scar tissue is still visible

Therefore, all the odd things I have discovered inside those XAVC-S files was just that:

Scar tissue of the rushed development.

But let’s give credit to Sony: XAVC-S is very successful, and it delivers what Sony promised despite being a Frankenstein monster made with parts that barely fit together and ignore each others.

And the last word about odd XAVC-S again to Tancredi: “A house of which one knew every room wasn’t worth living in.”

#4 Sony XAVC

XAVC comes at #4 and #3 in my list of Tops and Flops of 2015.

You already know that XAVC has 3 variants: (bonus: wiki link for those who want a refresher)


XAVC-I is intra-frame, the highest quality variant
XAVC-L is long GOP variant
XAVC-S is consumer-oriented and will be the subject of next post: #3 Sony XAVC-S

But did you know that’s there a fourth variant and Sony is not even aware of it?

“XAVC Mark II” by Canon…

A few weeks ago, I have received a repair request for a format that Treasured could not detect.
So I parsed the damaged clip manually, and quickly convinced myself that it was a new kind of XAVC-I:
Same MXF container, same data layout, same H.264/MPEG-4 AVC video and Linear PCM audio channels.

And I also found an explanation for Treasured not detecting it as XAVC-I: H.264 encoding settings were slightly different than those I had trained Treasured for.

I thought it was just another flavor of XAVC-I, but found strange that after two years of dealing with XAVC-I, new flavors would still appear.
Nevermind, I did some tweaks to an existing XAVC-I repair kit, and I could repair the sample.

When I sent the XAVC-I preview to the customer, to my surprise he answered that preview was great, but that I got the format wrong: It was not XAVC-I, but rather Canon XF-AVC from the new C300 Mark II.

Rebuttal, the hard way.

What? I could hardly believe it, but evidence was damning:

  1. Google: Canon XF-AVC is the new 4K format in town and everybody is talking about the Canon C300 Mk II. How I had missed that remains a mystery.
  2. A quick MXFDump on the damaged file was saying it loud and clear:
  3. [ K = MXFIdentification ( 0000000000000a10 )
      [ k = CompanyName
      3c.01, l =    10 (000a) ]
           0  00 43 00 41 00 4e 00 4f 00 4e                      .C.A.N.O.N
      [ k = ProductName
      3c.02, l =    64 (0040) ]
           0  00 45 00 4f 00 53 00 20 00 43 00 33 00 30 00 30    .E.O.S. .C.3.0.0
          10  00 20 00 4d 00 61 00 72 00 6b 00 20 00 49 00 49    . .M.a.r.k. .I.I
    

    and the final nail in the coffin:

  4. X-Rays on the first 20 MB shows clear differences (left is Sony XAVC-I, right Canon XF-AVC)


X-Rays is an internal tool using space-filling curves to visualize remarkable structures inside damaged video files.

So what is actually going on?
On one side, Canon XF-AVC uses that exact same ingredients as Sony XAVC for its new 4K format, on the other side there are small implementation differences that make the two formats distinguishable if you have the right tools.

Technical false twins, if you will.

The XAVC Marketing Stunt

Canon has pulled exactly the same marketing stunt as did Sony two years ago:
Rebrand H.264/AVC as Canon XF-AVC to address 4K with a “new” format.

And there’s a good reason Canon did the same: because it worked so well for Sony with XAVC!

The advantages of coining a nice format name are manifold:

  • “New” is a magic word. Every marketer knows that.
  • Under XAVC umbrella you can encompass a variety of specs that otherwise would create confusion:
  • XAVC-S for H.264 in MP4 container
    XAVC-I for raw H.264 in MXF container, intra frame level 5.2
    and future variants can also use the XAVC branding

  • It is easier to communicate on XAVC compatibility, to certify or license XAVC third-party solutions, than to communicate on complicated H.264/AVC profiles and specifications.

The XAVC marketing trick has given a two years head start to Sony over Canon in the 4K transition.
In next post, we will explore a few interesting properties of XAVC and how Canon XF-AVC approach tends to differ.