VITC in a Container

[Dave1024]

Hello,

I wrote this query for understanding the container formats. For the same i choose mxf [Material Exchange format] and the mpeg - 2 stream as the essence.

Here i face a difficulty. I know the time code information sometimes will embedded in each frame data,[In some top lines of the frame].

I would like to know what information the mxf encoder added as a meta data in the headers present in the mxf file structure for an indication of time code in the frame data.

Thanks In Advance.
Dave

[Mug Funky]

typically the VITC is captured as is, and the container metadate is blind to whether it's there or not.

the best indicator i've found is whether the frame has enough height to contain the VITC (for example, 512 line NTSC is likely to have VITC, but 486 is not).

the only foolproof way to find it is probably a VITC reader.

[Dave1024]

Hello, Thanks to your replay.

After reading Ur answer i have one doubt. VITC is part of VBI data. In Mxf file container the VBI data decoding is possible or not.?

Dave

[Blue_MiSfit]

I'm not an expert in MXF by any means. I've been taking a (literal) crash course recently though... :)

If you're talking about (for example) SMPTE D10 / IMX wrapped in an MXF container, then the VBI data is encoded into the video (720x512 pixels for NTSC).

As Mug Funky says, if your video is 720x512, it probably has VITC :) This can be decoded.

Derek

[Dave1024]

Hello,

Thanks to your post. I am also in the class room for MXF understanding :)
The VBI data consists the information about the VITC, LTC, Close Caption etc. So a decoder is required for decode the info.
Any body provide some information for a VITC and LTC decoder and the starts codes used to differentiate these two different forms.

Dave

[Blue_MiSfit]

I know about Rhozet Carbon Coder, which can (at the very least) extract closed caption data from the VBI. I believe it can do the same for VITC data in the VBI.

Furthermore, I think it can modulate this data into VBI when encoding formats like D10/IMX as I mentioned above.

I think Telestream Flip Factory and other "pro" tools can do this kind of thing as well. I'm not familiar with any free/open source solutions.

Derek

[Ghitulescu]

Is your question directed to reading the VITC off a source (probably analogue), or to write it on a destination (again probably analogue)?
Why analogue? Because the digital formats and their containers have their own TC system, so I assume you want VITC for compatibility reasons with mostly analog systems.

[Dave1024]

Hi,

I am thinking in a decoder side. Already i have a encoded VBI information. I want to decode the information from the top lines of a video frame.

For mxf

Is this 720x512 only have VITC or 720x608 also have VITC information?
Does the display height and stored height difference in an mxf container info[meta data] is an indicator of VBI data presence ?

Please replay.

Thanks
Dave

[jmac698]

608 has VITC from what I can tell

Blackmagic have told me on the phone that their SDK supports capture at 720×608 for retention of VITC.
http://www.blackmagic-design.com/support/detail/?sid=3945&pid=4013&os=linux&leg=0

From http://stream0.org/category/video/blackmagic-design/

Anyhow, it's easy to decode cc.
For one thing, cc is recording in mpeg2 with the pvr250 capture card. It can be extracted with ccextractor.
http://ccextractor.sourceforge.net/

More detailed help here, especially for the programmer:
http://www.theneitherworld.com/mcpoodle/SCC_TOOLS/DOCS/SCC_TOOLS.HTML

And if you can see the flickering white lines in your video, you can extract them directly:
http://www.theneitherworld.com/mcpoodle/Tools/DumpPixelValues.html

This is useful with some upconverted shows on HDTV; they forgot to mask the top lines and you can actually see the CC data in the image.

There's some other weird data too; graphics and ads were sent, XDS data has program title and short program guide; there was some URLs embedded in commercials for an intel initiative (you still see them pop up in re-runs.. like hidden data).. and so on.
Also Oprah has spanish CC on channel 2.

[Dave1024]

:goodpost:

Please correct if a stream with VBI data is skip from the given pseudo code

if(Profile == "MPEG-2 422" && Level == "ML" && width == 720 && (height == 608 || height == 512))
{
//Processing for VBI + MPEG-2 Processing
}
else
{
// MPEG-2 Processing
}

[Blue_MiSfit]

Looks good to me.. You don't technically have to use MPEG-4 422@ML to make a VBI encoded video... you do if you're making something that's IMX compatible though, so I would say your pseudo code is valid.

Derek

[Dave1024]

Hi,
:goodpost:
Now i am searching for the meaning of a "container time code".
Here in container different time code type [formats] apart from the elementary stream. Out of this which version 'promoted' as container time code.

Thanks
Dave

[jmac698]

http://en.wikipedia.org/wiki/Vertical_interval_timecode

[Dave1024]

Hi,

Thanks for the reference.
Here i have one more doubt. How can differentiate Linear Time Code and Vertical Interval Time Code.
and where i get the info about VITC and LTC in a frame of MPEG-2

Thanks
Dave

[Ghitulescu]

AFAIK you can't have LTC in an MPEG-2 frame. LTC is physically recorded on an additional track thus the name. For the purpose of MPEG-2 and other compression schemes the LTC is replaced by the TC specific of the container (for MPEG-2 either PS or TS, in extenso the TC of MKV).
You still failed to mention the real purpose of your quest for knowledge.

[Dave1024]

Hi,

I strongly disagree with your answer.AFAIK In MPEG-2 picture user data, there is scope to send Linear Time Code. can u agree with this ?. I don't know which standard confirms it.

Thanks
Dave

[Ghitulescu]

Well, LTC has a precise meaning, the one I mentioned it (SMPTE 12M). MPEG-2 doesn't have to rely on LTC as defined before, but on other schemes that encode a time code.
All tape formats I know of (including audio like DAT) have somehow embedded TC. Some of them may be converted on-the-fly to VITC (for instance MiniDV) or LTC if needed for compatibility reasons, if needed. Digital formats don't need VITC and/or LTC anymore, unless used in real-time editing (also called linear) for compatibility reasons. The containers in which they reside set the TC (or better said time stamp).
Without you being too specific I can't go in deeper details.

Try read the recommendation of EBU R 122 for a better understanding of time codes and time stamps for an MXF container.

[jmac698]

There's some stuff here
http://ingex.sourceforge.net/
They have an open-source program for archiving of video tapes, including all time codes.
With a little searching, I've found that LTC is just an audio track, but can be made into a video line with VITC.
Please try google for your answers; it's a good skill to develop.

[Dave1024]

:goodpost:

Well, I read EBU R122[I got a PDF from Google source http://tech.ebu.ch/docs/r/r122.pdf]. I struck in between some sections of EBU R122. I will share my conflicting points here.Source time code = {VITC,LTC,ATC,Application,Preset} in MXF.Such that EBU R122 said source time code is present with essence streams - (SMPTE 328M MPEG ES editing info or VITC) - After reading this i disagree to your previous posts - MPEG-2 doesn't have to rely on LTC as defined before-Is source time codes like LTC, VITC and ATC will be part of MPEG-2 header?

What is preset timecode? - AFAIK it is a user-wish time code during the time of encoding?

Thanks
Dave

[Ghitulescu]

Apparently you're still in the confusion of what time codes are. It's like saying AVI is DivX or vice-versa.

Time codes are values, samples of time, when a frame has been recorded. VITC, LTC and many others, are material recordings of a time code, for instance LTC is nothing else than a highly pitched audio (remember the first personal computers, Commodore, Amiga, Spectrum and their tapes?) recorded on an supplementary longitudinal (thus the name linear) track on the tape, or for instance, VITC is a recording of a time code in the VBI, like the videotext/teletext is. Both of them encode, for compatibility reasons, values for time codes as defined in the SMPTE 12M. MiniDV doesn't have LTC nor VITC, yet compatible signals are regenerated from the internal TC (also following SMPTE convention), for an easier integration of DV/MiniDV gear into the production chain. DAT has its own TC format (still using the numerical format of SMPTE) that is recorded before the audio part, and may be overwritten anytime.
The time code was invented to help synchronising audio and video parts, which normally are[/were?] separately processed in a studio using linear editing.

The digital formats don't need this archaic formats anylonger, they rely instead on time stamps. TC might be present for compatibility reasons (film production), but only as values according to SMPTE, not as VITC/LTC/CPS/CTL/VISS/etc/etc/etc. There is no way LTC being embedded into an MPEG multiplex/elementary stream, and unless the encoder chose to encode the whole videoframe (ie all 576 lines), there will be no VITC either. And even if the whole frame was encoded, the VITC is nothing else than a part of the image, like burned subtitles are, meaning that one has to decode the full frame/GOP to extract the TC therefrom, which defeats the purpose of having TC for such streams. :) Read the function of time stamps to understand why.

[Dave1024]

Thanks
:goodpost:

Well, let me list out the points that i observe from the discussion.

1. LTC coming in with container or ATC packets.
2. VITC is coming in VBI lines or with ATC packets

The time code information which is coming with MPEG-2 picture user data comes under which category? [LTC or VITC or ATC]?

I would like to know the presence of ATC and VITC time code in VBI lines. How can i detect this presence?

For a stream with MPEG-2 4:2:2 @ML 720x608.
The first 32 lines have VBI lines. The size of the VBI data is 720*32 = 23040 bytes. Once i go through the bytes will i get the presence of the time codes in this data ?

Thanks
Dave

[Ghitulescu]

There is no way that LTC comes with the container nor within ATC packets, because LTC is analogue. You may want to say time code. The information both VITC and LTC carry is identical on the formats that allow both.

How is the time code (not LTC) embedded into ASC, this is defined in former SMPTE RP 188-1999 (now renamed as SMPTE 12M-2). This is a copyrighted commercial document so you have to buy it yourself.
VITC for digital formats is described in (again commercial) SMPTE 266M.
code.
If you need info about HD Timecodes, read SMPTE 291M-1998. For HANC please read SMPTE RP196-1997.

Buy them, read them and be happy.
Remember, it's not a requirement that all videos must carry a TC, or that the TC info must carry valid data, in particular for consumer applications.

[Ghitulescu]

Maybe I should add this to clarify some misunderstandings.
LTC and VITC, as they are called in several standards, are called this way for compatibility reasons. That is, the info that is stored in ATC_VITC must be output in VBI (for compatibility reasons if a digital gear is used together with analog gear or in an older linear editing suite) and that of LTC_ASC must be output as it were the old analog LTC (BNC, RS422 after transcoding etc etc).
Since LTC counts frames whereas VITC has the possibility to count fields, there might be a problem if the user chooses to edit based on fields, most editing suites still use frames so they'll have no problem. Various producers assign both fields of a frame the same VITC code, to avoid any issues.
Remember that all SMPTE standards were designed for real interfaces, real gear, real stuff. In the computer world, the things are different, and time codes of any kind become simply time codes, mostly based on a system clock rather than on a real time clock. If VITC were so important to computer video (or DVD for that matter) then the frame size would have been 525/625 and not 480/576.

[Dave1024]

:goodpost:

Thanks for your guidance.

According to earlier discussion i will conclude the following points. and few of my observations added along with my points...

1.The LTC and VITC is comes under analogue domain. and for digital domain, conversion is required. The content of ATC_LTC and ATC_VITC are equal always even if its packing is different.

2. To convert the analogue value to digital value there is a mapping mechanism are available - (eg :: Digital VITC)

Here i have one question, In a digital domain only two values ie: Zero and One. But in analogue domain the values are continuous in nature. So how the via smooth transition is possible ?

3.In VBI lines i can expect 2 types of time code - ATC packets and VITC packets - Does both of this simultaneously come in one frame ?

4. In VBI data i can see the time code value with in some unique header -(Digital data along with the frame)?

5. There is no impact of LTC and VITC in audio data?

Reference :: EBU R122.

Thanks
Dave

[Ghitulescu]

The notation has been kept for digital domain, as to suggest that no conversion has to be made, the TC format still represent HH:MM:SS:FF irrespective of the writing format. The analogy is like cassette <-> CD, both have the same music but differently stored. What has to be changed is the physical format that has to be compatible with the medium, eg LTC is modulated audio in one longitudinal linear track, VITC embedds the same HH:MM:SS:FF in VBI and so on. Each player/recorder is more or less free to implement whatever scheme the manufacturer wants (if no standards apply!!!! see Sony and its Video8/Hi8 babilony) as long as it provides interfaces that input/output SMPTE signals (BNC/AES, RS422, SDI etc.) for interconectivity reasons. What is important is that any frame must be unique identified (if two or more systems are used, say LTC and VITC, then both should have the same SMPTE TC for that particular frame).

For digital containers I think there are people much better informed than me.

[Ghitulescu]

5. There is no impact of LTC and VITC in audio data?

Unfortunately yes.
The time code was primary directed to video, thus the SMPTE notation. With the advent of digital audio, it happened many times that a video frame could not fit an integer number of audio frames, in particular for NTSC.

[jmac698]

Ghitulescu,
Great knowledge! I actually have a question now, since I've managed to capture VBI data, I want to know how to create my own, thus how does one put CC data into an MPEG?
I have found http://www.theneitherworld.com/mcpoodle/SCC_TOOLS/DOCS/SCC_TOOLS.HTML#cc_mux which lets me mux the "USER DATA" into the stream, but then I'm supposed to feed this complete mpg to a dvd author program which will take it unmodified, finally to open the .ifo files in IFOEDIT, but that step isn't working - ifo edit sets a flag to indicate that CC data is present, but those boxes are always greyed out.

So I'm looking for alternate tools. I've never seen any other muxer/authoring program which handles CC data.

[jmac698]

I found some specs
The Consumer Electronics Association publishes CEA-608-C Line 21 Data Service that details data formats for closed captioning services and extended data (including CGMS and APS). The CEA publishes CEA-708-B Digital Television Closed Captioning that details usage of a 9600 bps closed channel (ten times the bandwidth of the original channel). The Advanced Television Systems Committee Inc (ATSC) publishes the Digital Television Standard A/53 specification that details a format for adding line 21 data to user_data of an MPEG-2 stream. The International Organization for Standardization (ISO) publishes the ISO/IEC 13818-2 MPEG video standard that details the inclusion of user_data in compressed video streams. The Society of Cable and Telecommunications Engineers (SCTE) publishes the ANSI/SCTE 20 2004 Methods for Carriage of Closed Captions and Non real-time Sampled Video and ANSI/SCTE 21 2001 Standard for Carriage of NTSC VBI Data in Cable Digital Transport Streams specification that defines additional VBI services.

[Blue_MiSfit]

a payware app that does this very well is MacCaption / CaptionMaker. Take a peek.

[Dave1024]

Hi,

"Using one OMAP 3 Beagle board and decode a stream with VBI information. Before each frame write in to output uncompressed file (yuv format) i need to remove the VBI lines and store the VITC time code and the modified resolution and native codec info as a separate header".

well, to do VITC analysis i require some explanation.

VITC data packets consider as 90 bit from the start of a line - True/False ?

or

Consider first two sync bits from the starting of line (90 bits buffer - initially), The sync bits not found in the starting position. Then the 90 bits buffer removes the first 10 bits (group 1 of 9 ten bit group) and add 10 more bits like a circular queue/ it flush all the 90 bits and go to 91st bit in the stream.

Please share the info's relate to VITC.

:thanks:
Dave

[Ghitulescu]

See SMPTE 12M section 9.

[Dave1024]

Well,

I agree with you.
In VITC 9 pair of sync words present. Did each group of 10 bits coming in different places[bit positions] of a line or it is spotted continuously[eg :: 000000h to 00005Ah]?

Thanks
Dave

[Dave1024]

Hi,

I have some doubts relate to VITC. For a PAL stream with 32 lines VBI data, which line hold the information about VITC.?
Is there any offset value required to find out the position of vitc in a line.?

Thanks
Dave

[Ghitulescu]

I don't have the standards but this is taken out from an almost authorised source
VITC timecode must be on line 14 and/or 277 for NTSC (SMPTE RP 164-1996) and 19 and/or 332 for PAL (EBU Tech Std N14-1998)

EDIT: The PAL reference is here -> http://www.ebu.ch/CMSimages/fr/tec_text_n14-1998_tcm7-4661.pdf .

[Dave1024]

:goodpost:

Hi,

I am little bit confused with line logic. Since in my resolution of 720x608, initial 32 lines contribute vbi data. In this scenario how can i look for the time code information as given by the following picture.

http://en.wikipedia.org/wiki/Vertical_interval_timecode

Thanks
Dave

[Ghitulescu]

I don't know. If you'd have the 720x625 I could have told you.

[Dave1024]

Hi,

So let me conclude, In a D10 std 720x608 MPEG-2 422 @ML clip have no VITC/DVITC data in its VBI line.
But may have ATC packets. With in this packet may VITC will come;

Thanks
Dave

[Ghitulescu]

I'll check tomorrow to see if I have the SMPTE 356M which describe the D10 (IMX) format.
I'm still confused about what you're after. If you work with D10 (IMX, MXF) then you should at least be in the possession of the relevant standards. Any of them costs less than a D10 cassette ;)

No, I don't have it.

[redshift90]

Ghitulescu,
Great knowledge! I actually have a question now, since I've managed to capture VBI data, I want to know how to create my own, thus how does one put CC data into an MPEG?
I have found http://www.theneitherworld.com/mcpoodle/SCC_TOOLS/DOCS/SCC_TOOLS.HTML#cc_mux which lets me mux the "USER DATA" into the stream, but then I'm supposed to feed this complete mpg to a dvd author program which will take it unmodified, finally to open the .ifo files in IFOEDIT, but that step isn't working - ifo edit sets a flag to indicate that CC data is present, but those boxes are always greyed out.

So I'm looking for alternate tools. I've never seen any other muxer/authoring program which handles CC data.

I have code that will insert userdata into a mpeg that works similar to cc_mux but is fast.

[mpucoder]

Just about all authoring programs handle CC embedded into the video stream. Try the freeware version of MuxMan.

[jmac698]

I did, it has no specific support for muxing in a CC stream. I need the tool to mux it in. Even then, there's a flag that needs to be set on a dvd to enable CC, and this option was greyed out in ifoedit. However, I'll do some new tests soon.

[Sir Didymus]

Jmac, in the case under discussion, as already pointed out elsewhere, the support of the CC from the side of the DVD authoring tool is implicit: if you feed MuxMan with a video asset including CC information, then it should detect this situation, accept your video, mux it properly, and set the CC flag in the resulting IFO files.

In order to prepare a suitable video asset, (Inserting Captions into MPEG Files), you may want to use - for instance - the CC_MUX tool, which is included in the SCC Tools package.

[jmac698]

Sir,
Thanks for the clarification! I had no idea muxman had that feature, as part of it's simple dvd authoring feature. I'm still stuck, however, with a very simple DVD output. It would be nice if I could use, say, dvdstyler (a simple, opensource and easy dvd authoring tool), and be able to support CC as well.
I think I'll try it now with the two methods pointed out to me.

[Ghitulescu]

Since CC info is part of the MPEG stream, any muxer (that does DVD, of course) will include them into the final VOB. Since I'm from a PAL country and never tried other muxer than muxman (well, long time ago IfoEdit and Scenarist SD) I cannot be 100% sure, but nothing seems to contradict my impression. Even DVDshrink, as long as it doesn't compress the video, passes the CC streams unaltered to the source.

PS: I convert sometimes the CCs into subtitles; the European TVs, despite being NTSC-compatible, cannot display CCs, and most DVDs do not have subtitles if they feature CCs. That is my whole experience with CCs but I hope it helped.