Discussion of alternative approach for JPEG parsing
[Continuing the discussion from the lobby....](https://gitter.im/kaitai_struct/Lobby?at=5ac3a38ee4ff28713aa32cc5)

Here's a snippet from my current whack at the KSY:
```yaml
types:
  record:
    -my-record-kind: internal
    seq:
    - doc: Code for the format of the payload
      enum: rec_types
      id: type
      type: u1
    - doc: Length of the payload (does not include the header or trailer).
      id: length
      type: u1
    - id: payload
      size: '((type == rec_types::separator and length == 0x30) or (type == rec_types::jpeg and length == 0xD8)) ? 1 : length'
      type: payload
    - doc: For normal records (i.e., not separators or JPEGs), marks the end of the record, value 0xFF
      id: trailer
      type: u1
      if: type != rec_types::jpeg
```
So, it's a typical TLV record, with a trailer byte, plus a couple of twists.  There's a weird case which I call a "separator" (which I finesse by referencing a special-case type containing just a padding byte), and there's the other special case of a JPEG record.  For the JPEG case, we recognize the record from the first two bytes (read as `type` and `length`, even though that's not what they are), we omit the trailer byte, and we fake the rest.

Once I've recognized a JPEG record, I can either read the stream manually, looking for the two-byte terminator, or I can read the following record:
```yaml
  jpeg_segment:
    -my-record-kind: internal
    seq:
    - id: start_byte
      type: u1
    - id: additional_bytes
      terminator: 0xff
      if: start_byte != 0xd9
  jpeg:
    -my-record-kind: hand-coded
    doc: >
      This is a JPEG thubnail image.  It appears as a record in the record
      stream, but it has no type or length field.  We've already read the first
      byte, 0xff, as though it were the record type and the second byte, 0xd8,
      as though it were the payload length.  Once we recognize the record as a
      JPEG, we read it manually, since we have to find a two-byte terminator
      and it's not obvious how to do that in KS.
    seq:
    - id: segments
      type: jpeg_segment
      repeat: until
      repeat-until: _.start_byte == 0xd9
```
This yields an array of pointers to `jpeg_segments`.  My code could then take the original "type" and "length" bytes, and append to them each of the segments, thereby building up a single blob representing the image.

But, I think that's much more effort and complexity than simply reading the image and looking for the terminator myself.

However, if there were some trick for getting KS to return the segments as a single byte array instead of an array of pointers, that might tip the balance the other way.  :-)

Thanks!