Re: ANNOUNCE: ivtv alpha release
Marcus Metzler [EMAIL PROTECTED] writes:
since we are not experts concerning the variuos MPEG settings and did
/me too.
So if this is going to be done for V4L2, maybe we could start on this
list. A good start for a parameter list would probably be the .par
files for mpegenc.
videodev2.h has some dummy stuff in right now, see below. I'm waiting
for someone which knows more about mpeg than me to come with something
reasonable (hint, hint).
Gerd
/*
* C O M P R E S S I O N P A R A M E T E R S
*/
#if 0
/* ### generic compression settings don't work, there is too much
* ### codec-specific stuff. Maybe reuse that for MPEG codec settings
* ### later ... */
struct v4l2_compression
{
__u32 quality;
__u32 keyframerate;
__u32 pframerate;
__u32 reserved[5];
};
#endif
[ ... ]
#if 0
#define VIDIOC_G_COMP _IOR ('V', 6, struct v4l2_compression)
#define VIDIOC_S_COMP _IOW ('V', 7, struct v4l2_compression)
#endif
--
video4linux-list mailing list
Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: MPEG encoder API notes (Re: ANNOUNCE: ivtv alpha release)
Forgot that some encoders also support MPEG-1. And also most MPEG encoders do have a from of noise reduction, but this is very encoder specific. Gert system stream: - type: elementary stream(ES), packatised elementary stream(s) (PES) program stream(PS), transport stream(TS) (MPEG-1 systems stream ~ MPEG-2 program stream, TS not supported by MPEG-1 systems) - system bitrate - PS packet size (DVD: 2048 bytes, VCD: 2324 bytes) - TS video PID - TS audio PID - TS PCR PID - TS system information tables (PAT, PMT, CAT, NIT and SIT) audio: - type: MPEG, AC-3, LPCM - bitrate - sampling frequency (DVD: 48 Khz, VCD: 44.1 KHz) video: - noise reduction, parameters encoder specific? - picturesize (SIF, 1/2 D1, 2/3 D1, D1) and PAL/NTSC norm can be set through excisting V4L2 controls - MPEG video version: MPEG-1, MPEG-2 - GOP (Group Of Pictures) definition: - N: number of frames per GOP - M: distance between reference (I,P) frames - open/closed GOP - quantiser matrix: inter Q matrix (64 bytes) and intra Q matrix (64 bytes) - quantiser scale: linear or logarithmic - scanning: alternate or zigzag - bitrate mode: CBR (constant bitrate) or VBR (variable bitrate). - target video bitrate for CBR - target video bitrate for VBR - maximum video bitrate for VBR - min. quantiser value for VBR - max. quantiser value for VBR - adaptive quantisation value - return the number of bytes per GOP or bitrate for bitrate monitoring -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: ANNOUNCE: ivtv alpha release
Hi Gerd,
On Sat, 2003-02-08 at 12:22, Gerd Knorr wrote:
struct v4l2_compression
[..]
#define VIDIOC_G_COMP _IOR ('V', 6, struct v4l2_compression)
#define VIDIOC_S_COMP _IOW ('V', 7, struct v4l2_compression)
when you're actually going to use, it might be a good idea to rename
this to VIDIOC_[GS]_MPEGCOMP and v4l2_mpegcompression, to make clear
that it's MPEG-specific and not something 'generic-compression' like
(and to make the clear distinction w.r.t. jpegcompression-stuff).
Ronald
--
Ronald Bultje [EMAIL PROTECTED]
Linux Video/Multimedia developer
--
video4linux-list mailing list
Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: MPEG encoder API notes (Re: ANNOUNCE: ivtv alpha release)
On Fri, 7 Feb 2003, Gert Vervoort wrote: It is also very likely that not all of these settings are supported by other MPEG encoders or that other MPEG encoders have also other parameters available. In practice some parameters can also be fixed, depening on a type of system stream or picture size. I'm not real familiar with the MPEG specs either, but most of what you enumerated here (and your next message) looks supportable by the iTVC15. I don't remember any settings for the quantizer, but that may be a register/mmio level operation which I don't have docs for. Perhaps we use this as the baseline, and the driver can reply with an UNSUPPORTED message to any that it doesn't handle. For the properties that tend to be card specific (noise reduction), those can be handled by userspace tweak utilites. audio: - type: MPEG, AC-3, LPCM Layer I,II,III (iTVC15 does 1 2 but not 3) Our chip can support AC3, but the card hardware isn't wired to support it as far as I can tell. - bitrate - sampling frequency (DVD: 48 Khz, VCD: 44.1 KHz) 32KHz Trick Modes? (ff, rew) Copyright Inverse Telecine John -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: MPEG encoder API notes (Re: ANNOUNCE: ivtv alpha release)
PlasmaJohn wrote: I'm not real familiar with the MPEG specs either, but most of what you enumerated here (and your next message) looks supportable by the iTVC15. I don't remember any settings for the quantizer, but that may be a register/mmio level operation which I don't have docs for. The qmin/qmax settings I mention are specific for the VBR bitrate control of the SAA6752. Also the adaptive quantisation is specific for this IC. Other encoder might or might not use these kinds parameters, but I'm sure they have a slightly different meaning then. The inter/intra quantiser matrices I mentioned are part of the MPEG video standard. The standard describes default matrices, but also custom matrices might be used. An encoder could implement fixed (default or custom) Q matrices or give make it programmable. Perhaps we use this as the baseline, and the driver can reply with an UNSUPPORTED message to any that it doesn't handle. For the properties that tend to be card specific (noise reduction), those can be handled by userspace tweak utilites. Proberbly a custom ioctl could be used. audio: - type: MPEG, AC-3, LPCM Layer I,II,III (iTVC15 does 1 2 but not 3) For SAA6752 the MPEG audio is fixed to MPEG1 layer 2. Our chip can support AC3, but the card hardware isn't wired to support it as far as I can tell. - bitrate - sampling frequency (DVD: 48 Khz, VCD: 44.1 KHz) 32KHz This also a valid value. (althoug not support by SAA6752, which is fixed to 48kHz). Trick Modes? (ff, rew) Trick modes are a decoder issue. Does iTVC15 also have a MPEG decoder? This raises a different topic, as my list was encoding specific. MPEG encoding and decoding are very different issues, so a MPEG decoder will probarbly using a completely different API from an MPEG encoder. There is a MPEG decoder API for the Stradis MPEG decoder card in V4L (ioctl: VIDIOCSWRITEMODE, VIDIOCSPLAYMODE), might be a starting point for a MPEG decoder API. Copyright This could also be set, I saw that SAA6752 has also a field original. Inverse Telecine As far as I know not supported by SAA6752, but this is very usefull setting for 60 Hz contries. Gert -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: MPEG encoder API notes (Re: ANNOUNCE: ivtv alpha release)
Gert Vervoort writes: PlasmaJohn wrote: This also a valid value. (althoug not support by SAA6752, which is fixed to 48kHz). Trick Modes? (ff, rew) Trick modes are a decoder issue. Does iTVC15 also have a MPEG decoder? This raises a different topic, as my list was encoding specific. MPEG encoding and decoding are very different issues, so a MPEG decoder will probarbly using a completely different API from an MPEG encoder. There is a MPEG decoder API for the Stradis MPEG decoder card in V4L (ioctl: VIDIOCSWRITEMODE, VIDIOCSPLAYMODE), might be a starting point for a MPEG decoder API. Have a look at the DVB API for playback. There are two playback devices supported (more or less) by GPL drivers, namely the full featured DVB cards based on the Technotrend design and the margi dvd pcmcia card. There is also a driver for the em8400 chip, but it's not publicly available. I also started to write a wrapper for the em8300 driver, but did not have the time to finish it. Marcus -- /\ | Dr. Marcus O.C. Metzler| | ||---| | [EMAIL PROTECTED]| http://www.metzlerbros.de/| \/ -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: MPEG encoder API notes (Re: ANNOUNCE: ivtv alpha release)
On Sat, 8 Feb 2003, Gert Vervoort wrote: Trick Modes? (ff, rew) Trick modes are a decoder issue. Does iTVC15 also have a MPEG decoder? Yes, it does, but the trick modes API call is in the encoder section not sure why. (BTW, the '16 is encode only) Gert John -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: MPEG encoder API notes (Re: ANNOUNCE: ivtv alpha release)
On Sat, 8 Feb 2003, Marcus Metzler wrote: There is also a driver for the em8400 chip, but it's not publicly available. Will it be? I hear good things about the X-Card, particularly compared to the dxr3. While the combo encode/decode card is interesting I'd much prefer seperated functions (one capture machine, multiple playback remotes). Thanks, John -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: MPEG encoder API notes (Re: ANNOUNCE: ivtv alpha release)
PlasmaJohn writes: On Sat, 8 Feb 2003, Marcus Metzler wrote: There is also a driver for the em8400 chip, but it's not publicly available. Will it be? I hear good things about the X-Card, particularly compared to the dxr3. While the combo encode/decode card is interesting I'd much prefer seperated functions (one capture machine, multiple playback remotes). Thanks, John You have to ask convergence (www.convergence.de) and they probably have to ask sigma designs. Considering sigmas problems with open source that may be a problem. They will probably point to their closed source user space drivers, which are not very efficient and not very stable, the last time I cecked. Marcus -- /\ | Dr. Marcus O.C. Metzler| | ||---| | [EMAIL PROTECTED]| http://www.metzlerbros.de/| \/ -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
RE: MPEG encoder API notes (Re: ANNOUNCE: ivtv alpha release)
] From: [EMAIL PROTECTED] ] [mailto:[EMAIL PROTECTED]] On Behalf Of Gert Vervoort ] Forgot that some encoders also support MPEG-1. ] And also most MPEG encoders do have a from of noise ] reduction, but this ] is very encoder specific. Don't leave out other encoding formats too. Here is a reference board from Sigma Designs. http://www.sigmadesigns.com/products/rhapsody.htm - MPEG-1, MPEG-2 MP@ML, MPEG-4 Advanced Simple Profile Level 5* video decoding (Sigma Designs EM8475) - MPEG-1, MPEG-2 MP@ML, MPEG-4 Simple Profile, Level 3 (extended to 720 x 480i or 720 x 576i resolution) video encoding (Vweb VW 2005) - DolbyR Digital, MPEG-1 Layers 1 and 2, MPEG-4 Low Complexity AAC, and CD-DA audio decoding (Sigma Designs EM8475) - MPEG-1 Layers 1, 2 and 3, MPEG-2 Layers 1 and 2, Dolby Digital 2.0 and AAC 2.0 audio encoding (Vweb VW 2005) (Haven't found any commercial products using this chip yet.) A chip from Cirrus Logic can encode in MPEG2 (and integrates seamlessly with the saa7134): http://www-test.cirrus.com/en/products/pro/detail/P951.html - Supports real-time MPEG-1, MPEG-2 MP@ML, SP@ML, and MP@LL - Support for constant/one-pass variable bit rate - IPB-pictures, CBR, or VBR to 15Mbps - I-pictures only to 30Mbps - Supports Transport, Program, and Elementary streams - Support for real time, 2-channel, encoding/decoding of digital audio of either Dolby Digital or MPEG audio (Layer I, II, and III - MP3) - 8-bit OSD support (2-b text, 2-b to 8-b graphics) - 8 MB memory for full D1 (720) NTSC/PAL pictures Commercially available in http://www.kworld.com.tw/products/pro2/kw-capure-version.htm Whatever interface is devised it needs to be extensible (for both audio and video). -Greg -- -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: ANNOUNCE: ivtv alpha release
On Fri, 7 Feb 2003, Marcus Metzler wrote: PlasmaJohn writes: Can the cards produce MPEG transport streams, and if so are you planning to support the Linux DVB API? Although the support of the DVB API may not be important for recording it can be very helpful for playback, especially for transport streams that need demmuxing which would typically come from DVB cards without their own MPEG decoder. Yes, I think it can do TS. There are also indications that the card can transfer a raw (uncompressed) stream, but we haven't worked out the details on that. As far as framework goes, we're aware of DVB and I looked very briefly at it but none of us have any implementation experience with either ( volunteers welcome! ;) that or V4L2. I did notice that V4L2 will need some work to deal with an MPEG compressed stream. Thanks, John -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: ANNOUNCE: ivtv alpha release
As far as framework goes, we're aware of DVB and I looked very briefly at it but none of us have any implementation experience with either ( volunteers welcome! ;) that or V4L2. I did notice that V4L2 will need some work to deal with an MPEG compressed stream. V4L2 can deal perfectly with a MPEG compressed stream. At work I have a prototype board running with a SAA7134 PCI bridge/video decoder and a SAA6752 MPEG-2 encoder. It uses the SAA7134 driver: http://bytesex.org/saa7134/ . I initialise the MPEG encoder via the I2C user space device and then I can read a transport stream from the card, by just simply reading from a V4L2 device: cat /dev/video1 | mpeg2dec -t 0x100 And this is exactly what a kernel space driver should do; just pass a compressed stream to user space. The DVB API adds mux/demux functionality to kernel space, but this is clearly a user space issue instead of a kernel space issue. Gert -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: ANNOUNCE: ivtv alpha release
On Fri, 2003-02-07 at 17:16, Gert Vervoort wrote: As far as framework goes, we're aware of DVB and I looked very briefly at it but none of us have any implementation experience with either ( volunteers welcome! ;) that or V4L2. I did notice that V4L2 will need some work to deal with an MPEG compressed stream. V4L2 can deal perfectly with a MPEG compressed stream. At work I have a prototype board running with a SAA7134 PCI bridge/video decoder and a SAA6752 MPEG-2 encoder. It uses the SAA7134 driver: So is the documentation for the SAA6752 available? Or is there ane open source driver in the works? -- Torgeir Veimo [EMAIL PROTECTED] -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: ANNOUNCE: ivtv alpha release
Gert Vervoort writes: As far as framework goes, we're aware of DVB and I looked very briefly at it but none of us have any implementation experience with either ( volunteers welcome! ;) that or V4L2. I did notice that V4L2 will need some work to deal with an MPEG compressed stream. V4L2 can deal perfectly with a MPEG compressed stream. At work I have a prototype board running with a SAA7134 PCI bridge/video decoder and a SAA6752 MPEG-2 encoder. It uses the SAA7134 driver: http://bytesex.org/saa7134/ . I initialise the MPEG encoder via the I2C user space device and then I can read a transport stream from the card, by just simply reading from a V4L2 device: cat /dev/video1 | mpeg2dec -t 0x100 And this is exactly what a kernel space driver should do; just pass a compressed stream to user space. The DVB API adds mux/demux functionality to kernel space, but this is clearly a user space issue instead of a kernel space issue. Not if the demux is in hardware. As I said the DVB API makes more sense for the decoder part of the pvr 350. Although you need more for encoding than supporting open and read. If your encoder card has the ability to provide more than one cmpressed format and bitrate (and whatever other parameters you have to set for MPEG encoding) you need an API (i.e. some ioctls) that let you control these features, in my opinion user space I2C is not suitable for that because that would limit you to one particular hardware and would limit the user to root or give to much ability to mess up the system. Marcus -- /\ | Dr. Marcus O.C. Metzler| | ||---| | [EMAIL PROTECTED]| http://www.metzlerbros.de/| \/ -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: ANNOUNCE: ivtv alpha release
Marcus Metzler wrote: Not if the demux is in hardware. As I said the DVB API makes more sense for the decoder part of the pvr 350. Although you need more for encoding than supporting open and read. If your encoder card has the ability to provide more than one cmpressed format and bitrate (and whatever other parameters you have to set for MPEG encoding) you need an API (i.e. some ioctls) that let you control these features, in my opinion user space I2C is not suitable for that because that would limit you to one particular hardware and would limit the user to root or give to much ability to mess up the system. Yes this true, there should actually be an V4L2 extension for MPEG encoding. For me the I2C user space solution is perfect, as I can also use my userspace program to control standalone SAA6752 application boards. But, this is indeed not suitable for regular users. I considered adding a V4L2 MPEG encoder extension, but I did not find the time to do it. And making a good generic API for MPEG encoders is quite difficult, although most encoder have a lot of settings in common (features which can be found in MPEG standard), there also important settings which are quite different between encoder implementations (e.g. variable bitrate control settings). And at the time I added the SAA6752 support to the SAA7134 driver, such a board was (as far as I know) not available outside of Philips and I was the only one running it under Linux, so it did not make much sense for me to add this. Setting these kind of settings to the hardware, certainly belongs to kernel space. But to my opion, the compressed stream should be passed as is to user space and then a user space program/library should demux/mux/convert this stream to something which can be used be used by other programs (e.g. cat /dev/video1 | ./convert_to_mpeg_ts | mpeg2dec -t 0x100). It looks strange to me that a demux (/usr/src/linux-2.5.x/drivers/media/dvb/dvb-core) was added to kernel space for the DVB driver. What is the reason for doing this in the kernel, instead of a user space solution? Gert -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: ANNOUNCE: ivtv alpha release
Ralph Metzler wrote: The problem is that you then would have to implement the DVB network device in userspace. Possible, but more complicated and it adds unnecessary overhead if the DVB card can filter in hardware. It is similar to the situtation with network cards where some have many hardware multicast filters and others where you might have to use promiscuous mode and software filters. I didn't realise that DVB cards also have a network device, this does indeed complicate a user space solution. Gert -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: ANNOUNCE: ivtv alpha release
Torgeir Veimo wrote: Are there any consumer level cards with this chipset available yet? Don't know if there are currently any available, unfortunatly I haven't seen any yet. I heard that there are companies working on such a board, but I don't know the details. If such a board becomes available, then I imediatly replace the bttv card in my PC at home ;-) Gert -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: ANNOUNCE: ivtv alpha release
Gert Vervoort writes: I considered adding a V4L2 MPEG encoder extension, but I did not find the time to do it. And making a good generic API for MPEG encoders is quite difficult, although most encoder have a lot of settings in common (features which can be found in MPEG standard), there also important settings which are quite different between encoder implementations (e.g. variable bitrate control settings). That's true. We had the same problem with the kfir card which still has no API for the settings. We did tried to motivate people on the mpeg mailing list at linuxtv.org (http://www.linuxtv.org/mailinglists/mpeg2/) to give some suggestions since we are not experts concerning the variuos MPEG settings and did have other things to work on, but it never came to actually defining an API. So if this is going to be done for V4L2, maybe we could start on this list. A good start for a parameter list would probably be the .par files for mpegenc. Setting these kind of settings to the hardware, certainly belongs to kernel space. But to my opion, the compressed stream should be passed as is to user space and then a user space program/library should demux/mux/convert this stream to something which can be used be used by other programs (e.g. cat /dev/video1 | ./convert_to_mpeg_ts | mpeg2dec -t 0x100). It looks strange to me that a demux (/usr/src/linux-2.5.x/drivers/media/dvb/dvb-core) was added to kernel space for the DVB driver. What is the reason for doing this in the kernel, instead of a user space solution? Various cards have hardware demuxes and there is a kernel internal demux that allows you to e.g. write network drivers that use the stream from the DVB cards and demux it to feed it to the IP stack. You could also imagine using the demux to directly pipe the incoming data to a separate MPEG decoder card. Furthermore, the software demux does not create a lot of overhead (not like decoding MPEG or converting yuv-rgb) and keeps the API consistant for the applications. If you dont want to use it and the hardware allows it you can still get the complete TS and demux it in userspace. Marcus -- /\ | Dr. Marcus O.C. Metzler| | ||---| | [EMAIL PROTECTED]| http://www.metzlerbros.de/| \/ -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
Re: ANNOUNCE: ivtv alpha release
Marcus Metzler wrote: That's true. We had the same problem with the kfir card which still has no API for the settings. We did tried to motivate people on the mpeg mailing list at linuxtv.org (http://www.linuxtv.org/mailinglists/mpeg2/) to give some suggestions since we are not experts concerning the variuos MPEG settings and did have other things to work on, but it never came to actually defining an API. So if this is going to be done for V4L2, maybe we could start on this list. A good start for a parameter list would probably be the .par files for mpegenc. I still have a list somewhere of possible parameters for MPEG encoder API. It's mostly based on my experiences with the SAA6750/SAA6752, so most parameters could also be found back in the SAA6752 datasheet. It also contains some paramters missing from this encoder. When I've cleanup this list a bit, I will post it to the video4linux list. Combined with experiences of other people with MPEG encoder parameters, this might be start for a (V4L2) MPEG encoder API. Gert -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
MPEG encoder API notes (Re: ANNOUNCE: ivtv alpha release)
So if this is going to be done for V4L2, maybe we could start on this list. A good start for a parameter list would probably be the .par files for mpegenc. Below there is a list of parameters I wrote down a while ago, it was intended to be a start for a V4L2 MPEG encoder API. But, I never finished it. Most of the parameters are based on my experiences with the SAA6752 MPEG-2 encoder, so most of these parameters could also be found back in the datasheet of this IC (http://www.semiconductors.philips.com/pip/SAA6752HS_V101.html). I also added VCD related settings, although these are not supported by this encoder. It is also very likely that not all of these settings are supported by other MPEG encoders or that other MPEG encoders have also other parameters available. In practice some parameters can also be fixed, depening on a type of system stream or picture size. Gert system stream: - type: elementary stream(ES), packatised elementary stream(s) (PES) program stream(PS), transport stream(TS) - system bitrate - PS packet size (DVD: 2048 bytes, VCD: 2324 bytes) - TS video PID - TS audio PID - TS PCR PID - TS system information tables (PAT, PMT, CAT, NIT and SIT) audio: - type: MPEG, AC-3, LPCM - bitrate - sampling frequency (DVD: 48 Khz, VCD: 44.1 KHz) video: - picturesize (SIF, 1/2 D1, 2/3 D1, D1) and PAL/NTSC norm can be set through excisting V4L2 controls - GOP (Group Of Pictures) definition: - N: number of frames per GOP - M: distance between reference (I,P) frames - open/closed GOP - quantiser matrix: inter Q matrix (64 bytes) and intra Q matrix (64 bytes) - quantiser scale: linear or logarithmic - scanning: alternate or zigzag - bitrate mode: CBR (constant bitrate) or VBR (variable bitrate). - target video bitrate for CBR - target video bitrate for VBR - maximum video bitrate for VBR - min. quantiser value for VBR - max. quantiser value for VBR - adaptive quantisation value - return the number of bytes per GOP or bitrate for bitrate monitoring -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/video4linux-list
