Mailing List Archive: cx18 mpeg-2 transport stream encoding question

cx18 mpeg-2 transport stream encoding question

Feb 2, 2009, 10:24 AM

Post #1 of 4 (3437 views)

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 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? And, if so, is
it possible to accomplish what is needed using existing linux
drivers/software or would it still require some development/
coding?

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.

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.

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).

4) The Program Clock Reference (PCR) should be encoded with the video PES.

5) The Video elementary stream should be encoded in one of the 18
recommended ATSC frame-rate/resolution formats.

6) The Audio elementary stream should be an AC-3 compressed bit-stream
per ATSC document A/52.

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.

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.

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).

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.

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.

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.)

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.

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.

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.

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18 mpeg-2 transport stream encoding question [ In reply to ]

awalls at radix

Feb 2, 2009, 2:15 PM

Post #2 of 4 (3162 views)

Permalink

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
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18 mpeg-2 transport stream encoding question [ In reply to ]

brian at eng

Feb 2, 2009, 6:06 PM

Post #3 of 4 (3150 views)

Permalink

Andy Walls wrote:
> 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
>
>

Andy, I really appreciate all of your detailed feedback. It's very
helpful and informative.

In our particular situation I'll only need to build (at most) six of
these encoder boxes and unfortunately there's not a whole lot of
money behind it since they're just for internal use here at the university
where I work (ATSC content distribution via coax/fiber through
several buildings for what in the retail industry would be considered
digital signage).

I do have the go-ahead though to put some time into the project
and it sounds like there is some hope, so I'll definitely pick up
one of the cx23418 cards and see what can be done.

Thanks again,
Brian

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18 mpeg-2 transport stream encoding question [ In reply to ]

awalls at radix

Feb 3, 2009, 3:44 AM

Post #4 of 4 (3127 views)

Permalink

On Mon, 2009-02-02 at 21:06 -0500, Brian Thompson wrote:
> Andy Walls wrote:
> > On Mon, 2009-02-02 at 13:24 -0500, Brian Thompson wrote:

>
> Andy, I really appreciate all of your detailed feedback. It's very
> helpful and informative.
>
> In our particular situation I'll only need to build (at most) six of
> these encoder boxes and unfortunately there's not a whole lot of
> money behind it since they're just for internal use here at the university
> where I work (ATSC content distribution via coax/fiber through
> several buildings for what in the retail industry would be considered
> digital signage).
>
> I do have the go-ahead though to put some time into the project
> and it sounds like there is some hope, so I'll definitely pick up
> one of the cx23418 cards and see what can be done.

No problem.

Since you probabaly have to do so much manipulation of the MPEG stream
(like audio transcoding) in user software, it may be best to start with
a PS from the hardware, estraxt the PES's and work from there to build
up a TS to meet your needs. In that case either a CX23416 or CX23418
base board may meet your needs.

Conexant did ask if I could add an AC-3 support in the linux cx18
driver, which I did; but the current firmware doesn't support it. Maybe
one day there will be an updated firmware that supports AC-3, but I
wouldn't hold my breath.

Regards,
Andy

> Thanks again,
> Brian

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel