GNOME Bugzilla – Bug 797111
qtmux: Store video track width/height for closed caption tracks
Last modified: 2018-09-20 08:36:03 UTC
E.g. MOV wants this to be stored and it should also be required for proper layouting of the closed captions in renderers.
Created attachment 373583 [details] [review] video-anc: Store width/height for which Closed Caption data was produced in the meta This is required by some muxers and also for proper rendering.
Created attachment 373584 [details] [review] qtmux: Initialize caption track language code to 0 instead of "und" Without this, Final Cut considers it "non-standard"
Created attachment 373585 [details] [review] qtmux: Store width/height in caption track header This is required by the spec. If we don't have any width/height, we still store 0.
Created attachment 373586 [details] [review] deinterlace: Set width/height in closed caption meta
Created attachment 373587 [details] [review] decklinkvideosrc: Store Closed Caption width/height in the meta
Created attachment 373588 [details] [review] ccextractor: Use gst_caps_new_simple() instead of gst_caps_from_string()
Created attachment 373589 [details] [review] closedcaption: Store Closed Caption width/height in meta and caps
Created attachment 373590 [details] [review] avviddec: Set width/height in closed caption meta
For the meta we don't really need to put it there, you could just use the width/height from the underlying stream (CC meta are on video streams which should have width/height on them). For standalone CC streams I agree that having width/height as (maybe optional) caps would be a good idea.
(In reply to Edward Hervey from comment #9) > For the meta we don't really need to put it there, you could just use the > width/height from the underlying stream (CC meta are on video streams which > should have width/height on them). The problem with that is that the stream could be rescaled but the meta would be passed through as-is > For standalone CC streams I agree that having width/height as (maybe > optional) caps would be a good idea. Not set would be 0 in this case
(Summary of discussion that happened offline) Closed Caption are not "pixel-dependent" systems, therefore the width/height of the underlying video doesn't matter per-se. What matters is: * The *display* resolution (if it's rendered/overlayed) * To a certain extent the aspect-ratio of the original material. The information regarding the aspect-ratio is within the CDP stream (either not specified and it's 16:9, or specified). For raw CEA 608 streams (non-CDP), it's implied to be 4:3. => We don't *need* to store/provide the width/height of the original video stream for a standalone CC stream. So for storing CC in MOV, I would therefore recommend to just store in that CC 'trak' the same width/height as the correlated video stream. (Out of scope, but put here for completion) For display/rendering, we should use the *display* resolution/ratio (unrelated to underlying video stream) and the original-aspect-ratio of the CC stream to figure out the ideal/optimal rendering. But this is a similar problem to efficient rendering of other sub formats.
Created attachment 373690 [details] [review] qtmux: Set Closed Caption track width/height to that of the first video track Otherwise software like Premiere or Final Cut Pro won't like our files.
Attachment 373690 [details] pushed as c6e07a6 - qtmux: Set Closed Caption track width/height to that of the first video track