On Mon, 2009-02-02 at 13:24 -0500, Brian Thompson wrote: > Hello all, > > I was recently given the following set of MPEG-2 transport stream > file requirements and recommendations listed below and my goal is > find a hardware-based MPEG-2 encoder with linux support to > be able record and encode such files from a standard analog > composite NTSC + analog stereo audio source in realtime. > > After going through all of the kernel drivers/modules in > /linux-2.6.28/drivers/media/video and comparing them with > their respective IC datasheets, it seems that the only two chips > (or series of chips) that have any hope of working are the > Conexant cx23415/16/18 which there appears to be quite > a bit of support for, or the Philips NXP saa6752 which I > only found one reference to as part of the saa7134 driver.
I can speak to the CX23418 and a little bit to the CX23416. > I should also mention that I'm a novice at MPEG encoding > in general so much of what's listed below is still foreign to me, > but I'm a quick learner... > > My question is - am I on the right track with possibly using > Hauppauge HVR-1600 card(s) for this project? First, the CX23416/8 chips are end consumer devices. Your requirements below really look more like professional broadcast requirements. The CX23418 is a better fit for your requirements than a CX23415/6, but that's not saying that it's a good fit either. > And, if so, is > it possible to accomplish what is needed using existing linux > drivers/software or would it still require some development/ > coding? You would have some audio transcoding and/or TS manipulation in user application software still to do. It may not be trivial either. If you have real professional requirements, and you have some $ to back your needs, and you are still interested in a CX23418 based solution, then you should contact a Conexant sales rep to see if they would be willing to develop firmware to meet your needs or have some other solution. Otherwise you would have to work with the TS the current CX23418 firmware provides, and you have to fix it up in software - that also costs time & money. > Thanks in advance for any info. > > -Brian > > > > Minimum requirements: > 1) The TS file should contain an MPEG-2 fixed rate transport stream (TS) > multiplexed to a final rate of 19.392658 Mbps (+/-54 bps) as required by > ATSC. A fixed rate multiplex is achieved by adding null packets to the > combined audio, video and data table packets as needed to maintain the > constant transport rate. Well, the CX18_CPU_SET_VIDEO_RATE api call in cx23418.h in the linux driver has a parameter to set the mux rate. I've never tested to see if it actually works, nor is there support in the cx2341x module, nor the cx18 driver, (nor the V4L2 API spec?) for setting that control parameter. It would be a change to the linux drivers to be able to set it explicitly. If the firmware doesn't actually perform the function, despite the API definition in the linux cx18 driver, then the cx18 driver or user software would have to perform this metering/stuffing function (something like what's mentioned in the DVB-S2 appendices I guess), > 2) The TS multiplex should contain the desired video and audio programs > encoded as valid MPEG-2 packetized elementary streams (PES) following > the restrictions of ATSC document A/53b. I don't know if it complies with A/53b. You should buy a cx23418 based card (the HVR-1600 and Videomate H900 are avilable and well tested under linux) and inspect the TS you get from the firmware. The CX23415/6 doesn't produce a TS, only a PS. The CX23418 can produce a TS or PS. > 3) Each video access unit should be packaged in a unique PES packet, and > each video access unit should contain a PTS/DTS stamp (A/53b). AFAIK there is only one video PES in a CX23418 capture. PTS and DTS are emitted, IIRC. > 4) The Program Clock Reference (PCR) should be encoded with the video PES. For the CX23418 it is, IIRC. > 5) The Video elementary stream should be encoded in one of the 18 > recommended ATSC frame-rate/resolution formats. It can obviously do at least a subset of them. Remeber, the analog source is a 525 line/60 Hz or 625 line/50 Hz source - CVBS, S-Video, or Tuner CVBS, and, with a lot of driver work, Y/Pr/Pb analog input as well. I default my MythTV setup to a 704 or 720 x 480 line mode for digitzation of NTSC-M. > 6) The Audio elementary stream should be an AC-3 compressed bit-stream > per ATSC document A/52. Right now, the CX23418 only provides MPEG Layer II audio compression. For now, you would have to transcode the audio PES in software from MPEG Layer II to AC-3. > 7) The TS should contain a valid Program Association Table (PAT) > multiplexed at intervals of no more than 100mS from the beginning of the > file to the end. > > 8) As required by MPEG-2, the PAT should have a Table I.D. 0x00 and be > located at packet identifier (PID) 0x00. > > 9) The PAT should contain entries for all Program Map Tables (PMTs) > needed to describe programs in the stream. > > 10) A valid version of each PMT should be multiplexed at intervals of no > more than 400mS from the beginning of the file to the end. > > 11) As required by MPEG-2, the PMT tables should all have a Table I.D. > of 0x02. Well, you'd need to run a capture and feed it to dvbsnoop to see if the TS meets all your requirements. If it doesn't, you'll have to build what you need in a user application and splice them into the TS. > > Recommendations for smooth file transitions: > 1) The video PES should begin with a sequence header and the first GOP > of the file should be CLOSED. IF THE FIRST GOP OF THE TS FILE CANNOT BE > CLOSED, then 2 seconds or (tbd) frames of black should be added to the > beginning and end of the UNCOMPRESSED clip with a smooth fade-in / > fade-out. > > > Recommendations for best playback quality: > 1) If possible, all source clips (before MPEG-2 compression) should be > native HD1080i or 720p and encoded as 1080i or 720p streams. The linux cx18 driver sets up for BT.656 pixel timing at 13.5 Mp/s so for both PAL and NTSC video that's 720 pixels per active region of each line. > 2) The highest quality encoder settings should be used for a given > source clip. This should result in the encoded video using as much of > the available 19.39 Mbps TS capacity as possible (video bit-rate > 15 > Mbps recommended). I've never tried to set the compression to a level that relaxed. It may work and there are already controls and infrastructure to set it that high. Buy a board, give it a try. > 3) Recommended groups of pictures (GOP) structure: > 3.1) Each GOP should begin with an I-frame. > 3.2) GOPs should have M=3. > 3.3) GOP size should be nominally 15 for 30fps source, 12 for 24fps source. Not sure about, M, but the 15 for 30 fps & 12 for 25 fps are driver defaults. You won't find an analog 24 fps source in consumer applications, we can't set the digitizer up for such a thing anyway, and I don't think the firmware supports it. However, I haven't looked for nor tried to enable inverse telecine for the encoder. (IIRC the CX23416 firmwre claimed support for inverse telecine, but never actually performed it.) > 4) All files should begin and end on a whole transport stream packet and > at whole PES packet boundaries. The first byte in the file should be the > sync byte (0x47) of the first packet. The TS starts with 0x47. Don't know about the rest. > 5) Every file must begin with a closed GOP. The first coded picture in > the file must be an I-frame belonging to a closed GOP, but does not have > to be the first byte in the file. (If the first GOP cannot be closed, a > fade-in/out to/from black should be used.) You'd have to fix that in user software. I've actually seen a broadcaster in my area do something like this. On CBS' NCIS program on digital channels, after commericals you can see the end of the upcoming segment spliced onto the front of the next sgement followed by a fade to black. > 6) Each TS file should contain a multiplex of only one MPEG-2 > audio/video program. The audio and video elementary streams should be > present throughout the file. The CX23418 does that. > 7) The single program entry in the PAT should be “Program 1”. > 7.1) The PMT for the single program entry should have a PMT_PID value of > 0x10 (16). > 7.2) The Video_PID value should be 0x11 (17). > 7.3) The Audio_PID value should be 0x14 (20). > > 8) The Program Clock Reference (PCR) should be encoded with the video > PES on PID 0x11 (17). > > 9) Each TS file should have valid place-holders and repetition for the > minimum recommended ATSC PSIP tables, including MGT(required), > TVCT(required), STT, RRT, and four EITs. Consumer equipment relies on > the presence of PSIP to identify and acquire the ATSC channel. You'd have to fix these in software. > 10) If possible, all source clips (before MPEG-2 compression) should be > native HD1080i. At a minimum all files in the same seamless list MUST be > the same ATSC format (1080i, 720p, etc.) – this will ensure that all > sequence headers are identical across the playlist boundaries, otherwise > unpredictable consumer responses can occur at the format change points. For than man years in software development you're going to spend to get a commodity PC capture card to meet your needs, it really seems to me like you want to buy a canned broadcaster solution from a vendor or work with a SoC MPEG encoder vendor (like Conexant or LG or someone else) to get an eval board and development support. Your requirements far exceed what a consumer device is expected to handle. My $0.02 Regards, Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
