Re: Fwd: [Cellar] Depth offsets for subtitles in case of 3D MVC tracks in MKV files

On Mon, Feb 29, 2016 at 10:14 AM, madshi via Matroska-devel
<[email protected]> wrote:
> 2016-02-29 10:04 GMT+01:00 Moritz Bunkus via Matroska-devel
> <[email protected]>:
>>> CodecState is per Cluster, though, not per Track,
>>
>> This is wrong. CodecState is a child element of BlockGroup. It's effect
>> as it's been meant to be understood so far is to replace CodecPrivate
>> for that track from that BlockGroup onwards (until another BlockGroup
>> with CodecState comes along). So it _could_ be used for changing Z-depth
>> values for individual subtitle frames. However, as it's supposed to
>> replace CodecPrivate I don't think it would be a good fit for Z-depth
>> data as Z-depth data is additional data that changes on a frame-by-frame
>> basis; it doesn't invalidate the existing CodecPrivate data.
>>
>> CodecState was meant for situations in which e.g. a whole new set of
>> SEIs/PPSs come along.
>>
>> I'd prefer new elements, or maybe BlockAddition.
>
> Ok, thanks.
>
> I think the key thing that needs to be decided first is which of the two
> following approaches we want to use:
>
> 1) Do we want to store *ALL* 3D subtitle depth information we need
> into the MKV header structures? If we do that, we need to be able
> to store (up to) one depth information per subtitle track per video frame.

This is the problem that occured to me just now as well - there is
typically more depth information than subtitle frames.
BDs store the depth information based on video frames, not subtitle
frames, so any subtitle frame can change its depth for each video
frame to react to changes in the video.

Which means that storing such information inside the subtitle track is
probably going to be rather problematic.

>
> 2) Do we want to make use of the SEI 3D depth information? In that
> case all we need to store in addition to that is one "int" per subtitle
> track, for the whole MKV file!
>

This would certainly be the easier option, but it is highly specific
to H264 MVC SEI's, so I can see how they might be reluctant to do
that.

-  Hendrik
_______________________________________________
Matroska-devel mailing list
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel