Subject: [Cellar] Codec ID for rewrapped TIFF in Matroska

From: Kieran O Leary <[email-masked]>
Date: Sat, 8 Dec 2018 12:25:33 +0000

Hi,

Currently FFmpeg uses a codecID of V_QUICKTIME when rewrapping TIFF to
Matroska.
I asked about this on FFmpeg-user and Carl Eugen Hoyos was wondering if
there was a spec for the correct handling of these kind of files. I thought
ye might know?
http://ffmpeg.org/pipermail/ffmpeg-user/2018-December/042273.html

Does V_QUICKTIME sound correct?

In my original email to ffmpeg-user, I mistakingly thought that DPX also
had the same issue, but that was my mistake. FFmpeg uses V_MS/VFW/FOURCC /
dpx
The reason why I am investigating this, even though it might seem a bit odd
is:

It seems that rewrapping DPX/TIFF to Matroska (or QuickTime it seems) via
ffmpeg is reversible, producing the same wholefile checksum values when
returning from MKV to the original format. With TIFF or DPX you just need
to be careful to use the correct compression algorithm and pix_fmt.

This is pretty interesting because while FFV1 compresses very well for film
scans, I found with some limited tests that the compression ratio for born
digital DCDM sequences is quite poor. I don't have figures at the moment,
but from what I saw the value of encoding time vs file size reduction was
not worth it. I am going to proceed with further tests and perhaps my
sample suite was too small, so I think this is still worth investigating.

With DCDM, reversibility is essential as all of our DCDM are deposits or
donations. So I was thinking about ZIP as the most likely option, but it
would be pretty cool to be able to rewrap to Matroska and to be able to
reverse back to the original files. As this is just a stream copy, the
process is very fast.

Best,

Kieran O'Leary
Irish FIlm Insitute.

---

From: Dave Rice <[email-masked]>
Date: Fri, 14 Dec 2018 10:25:30 -0500

Hi,

> On Dec 8, 2018, at 7:25 AM, Kieran O Leary <[email-masked]> wrote:
> 
> Hi,
> 
> Currently FFmpeg uses a codecID of V_QUICKTIME when rewrapping TIFF to Matroska.
> I asked about this on FFmpeg-user and Carl Eugen Hoyos was wondering if there was a spec for the correct handling of these kind of files. I thought ye might know? http://ffmpeg.org/pipermail/ffmpeg-user/2018-December/042273.html <http://ffmpeg.org/pipermail/ffmpeg-user/2018-December/042273.html>
> 

In this case, Matroska is storing what the QuickTime stsd would be. For data from TIFF and DPX, using V_QUICKTIME seems like an odd fit. I’d suggest making an issue at https://github.com/Matroska-Org/matroska-specification/issues/new so that we remember this.

> In my original email to ffmpeg-user, I mistakingly thought that DPX also had the same issue, but that was my mistake. FFmpeg uses V_MS/VFW/FOURCC / dpx 
> The reason why I am investigating this, even though it might seem a bit odd is:

V_MS/VFW/FOURCC is a common fallback for storing encodings in Matroska where there is no dedicated codec mapping yet defined.

> It seems that rewrapping DPX/TIFF to Matroska (or QuickTime it seems) via ffmpeg is reversible, producing the same wholefile checksum values when returning from MKV to the original format. With TIFF or DPX you just need to be careful to use the correct compression algorithm and pix_fmt.
> 
> This is pretty interesting because while FFV1 compresses very well for film scans, I found with some limited tests that the compression ratio for born digital DCDM sequences is quite poor. I don't have figures at the moment, but from what I saw the value of encoding time vs file size reduction was not worth it. I am going to proceed with further tests and perhaps my sample suite was too small, so I think this is still worth investigating.
> 
> With DCDM, reversibility is essential as all of our DCDM are deposits or donations. So I was thinking about ZIP as the most likely option, but it would be pretty cool to be able to rewrap to Matroska and to be able to reverse back to the original files. As this is just a stream copy, the process is very fast. 
> 
> Best,
> 
> Kieran O'Leary
> Irish FIlm Insitute.
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 18 Dec 2018 18:10:18 +0100

On 08/12/2018 13:25, Kieran O Leary wrote:
> I asked about this on FFmpeg-user and Carl Eugen Hoyos was wondering 
> if there was a spec for the correct handling of these kind of files. I 
> thought ye might know? 

"matroska is not a useful container for rawvideo because it is not well 
defined, use nut instead."

As everyone knows, nut is well defined...

> Does V_QUICKTIME sound correct?

I does not to me. Isn't TIFF a picture container ? Looking at this 
https://en.wikipedia.org/wiki/TIFF it seems there are a lot of specific 
things. Some of the "compression schemes" are supported in Matroska like 
deflate (although it says Adobe variant)  JPEG (via MJPEG).

It seems that a remuxing would miss some of the specifics of TIFF. 
Converting is always an option for lossless sources without losing anything.

>
> In my original email to ffmpeg-user, I mistakingly thought that DPX 
> also had the same issue, but that was my mistake. FFmpeg uses 
> V_MS/VFW/FOURCC / dpx
> It seems that rewrapping DPX/TIFF to Matroska (or QuickTime it seems) 
> via ffmpeg is reversible, producing the same wholefile checksum values 
> when returning from MKV to the original format. With TIFF or DPX you 
> just need to be careful to use the correct compression algorithm and 
> pix_fmt.

What variant of TIFF is this ? And what "codec" is used when stored in 
Matroska ? FFV1 ?

>
> This is pretty interesting because while FFV1 compresses very well for 
> film scans, I found with some limited tests that the compression ratio 
> for born digital DCDM sequences is quite poor. I don't have figures at 
> the moment, but from what I saw the value of encoding time vs file 
> size reduction was not worth it. I am going to proceed with further 
> tests and perhaps my sample suite was too small, so I think this is 
> still worth investigating.
>
> With DCDM, reversibility is essential as all of our DCDM are deposits 
> or donations. So I was thinking about ZIP as the most likely option, 
> but it would be pretty cool to be able to rewrap to Matroska and to be 
> able to reverse back to the original files. As this is just a stream 
> copy, the process is very fast.
>
> Best,
>
> Kieran O'Leary
> Irish FIlm Insitute.
>

---

From: Jerome Martinez <[email-masked]>
Date: Tue, 18 Dec 2018 18:24:26 +0100

On 18/12/2018 18:10, Steve Lhomme wrote:
> I does not to me.

It is in that case for the moment, as QuickTime method supports TIFF, 
and there is no direct mapping of TIFF to Matroska.

> Isn't TIFF a picture container ? Looking at this 
> https://en.wikipedia.org/wiki/TIFF it seems there are a lot of 
> specific things. Some of the "compression schemes" are supported in 
> Matroska like deflate (although it says Adobe variant)  JPEG (via MJPEG).
>

You lose DPX or TIFF metadata. you lose the easy Matroska support by 
tool already supporting TIFF and DPX. You lose a simple remux without 
having to map pixel to another raw pixel format if you don't want to use 
a compression format for speed issues (which one? using again AVI or 
QuickTime wrapping?)

> What variant of TIFF is this ? And what "codec" is used when stored in 

In my opinion, this is going too far here, storing DPX or TIFF in 
Matroska would be just storing raw DPX or TIFF files as is, without any 
change to the input files.
So there is no "variant" to check, the decoder is in charge to handle 
the format as it is, issue is in DPX or TIFF.
As we don't provide any specific metadata to AVC saying if CABAC is used 
or any AVC specific stuff (we just transport the AVC stream, 
CodecPrivate is init used by the decoder and not by the container).

In short, in my opinion the need is just to remove AVI or QuickTime 
overhead and map V_DPX to DPX format and V_TIFF to TIFF format as AVI 
and QuickTime do.

Jérôme

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 18 Dec 2018 18:28:51 +0100

On 18/12/2018 18:24, Jerome Martinez wrote:
> having to map pixel to another raw pixel format if you don't want to 
> use a compression format for speed issues (which one? using again AVI 
> or QuickTime wrapping?)
>
>
>> What variant of TIFF is this ? And what "codec" is used when stored 
>> in Matroska ? FFV1 ?
>
> Matroska would be just storing raw DPX or TIFF files as is, without 
> any change to the input files.

So a TIFF file would become a Matroska frame ? There's no metadata to 
extract ?
If there's a mapping to do it should at least extract some of them like 
the pixel sizes. Does it vary between TIFF variants ? Or there's a 
common header ?

> As we don't provide any specific metadata to AVC saying if CABAC is 
> used or any AVC specific stuff (we just transport the AVC stream,

---

From: Jerome Martinez <[email-masked]>
Date: Tue, 18 Dec 2018 18:44:14 +0100

On 18/12/2018 18:28, Steve Lhomme wrote:
>
> So a TIFF file would become a Matroska frame ?

As in other containers (AVI or MOV) and/or other image formats e.g. JPEG 
or JPEG 2000 in other containers, this is the idea.

> There's no metadata to extract ?
> If there's a mapping to do it should at least extract some of them 
> like the pixel sizes. Does it vary between TIFF variants ? Or there's 
> a common header ?

I wanted to mean that there is no specific metadata to add e.g. 
compression and so on, this is for the DPX or TIFF decoder as it 
currently does for single images on disk.
For the mandatory video related metadata (width, height), this is as 
other formats, the muxer needs to probe it, but it is really easy and 
does not depends on "variants" (standards fields).

Jérôme