Have ValidatingNalUnitConsumer do something
Optimise: don't parse all H264 data all the time

We only switch on H264 parsing periodically to check that our calculated
relationship between PCR values and SEI pic_timing values is still correct.

H264 parsing is a relatively expensive part of the protocol stack, so this
makes a fair difference to the overall cost when chunking higher bitrate
video.
Fix typo in package name
Better test shows more poorly handled edge cases

The test previously relied on Mockito verification, but because
the API under test is complex, the assertions that could be made
where limited.  Now, a hand-crafted mock is used which makes the
test code look better, be less sensitive to irrelevant implementation
changes, and better able to assert that code under test makes proper
use of the mocked API.
Better 'snickersnack' command line interface
Supress potentially noisy debug output
A few more comments explaining the implementation
While we continue to log this, note the source
Make the chunk dir configurable
Use 24-hour timestamp format. 12-hour was a typo
Optimise writes by gathering multiple packets.

We previously wrote one transport stream packet at a time to disk.
By collecting several sequential packets into a CompositeByteBuf,
we are not actually copying data in memory, but we are able to
send all the pieces to the kernel in one gathering write operation
(e.g. writev() on linux).

This change takes processing time for a benchmark file I tested with
from ~13 seconds to ~6 seconds.
Show nannos rather than millis in timestamp
Increased verbosity on timestamp wraparound
Don't log on every chunk
Switch to from NIO to older java.net multicast API

It seems the older MulticastSocket API handles filtering so that
the application sees only multicast which it explicitly asked
for (rather than all multicast groups the interface has joined
on the given port, e.g. due to another process attempting to
listen to another stream).