Just a quick conclusion of a previous thread.
I can confirm that the order of how one sets the bitrate is important depending
on the previous values.
It is never possible to (during a change) have inconsistence in the peak/average
levels so one has to do it in different orders depending on the previous values
and the new values
An example will clarify this. If the current bitrates are, say:
Video bitrate: 3.5 Mbps
Video peak bitrate: 4.2 Mbsp
Depending on the new values there will be two cases two consider
1) Case 1 : The new bitrate is larger than the existing peak (or the new peak is
larger than the old peak)
NEW Video bitrate: 4.3
NEW Video peak bitrate: 4.7
Order: Set Peak bitrate, Set Video vitrate
2) Case 2: The new peak is lower than the existing average (or the old peak is
lower than the new peak)
NEW Video bitrate: 2.5
NEW Video peak bitrate: 3.1
Order: Set Video bitrate, Set Peak bitrate
Seems obvious in retrorespect but not something I thought of when writing the
code. So perhaps this might be helpful for some other.
Rgds
Johan
On the 2009-12-09 you wrote:
>
> Thanks for the tip. Hadn't thought about that. That could possible be the
>
> reason since when my server switches between recording profiles I set the
>
> video rate first and then the max rate, i.e.
>
>
>
> <snip>
>
> int ret = video_set_controlbyid(fd,V4L2_CID_MPEG_VIDEO_BITRATE,
>
> bitrate);
>
> if( ret != 0 ) {
>
> logmsg(LOG_ERR,"Can not set video bitrate ( %d : %s )",errno,
>
> strerror(errno));
>
> return -1;
>
> }
>
> ret = video_set_controlbyid(fd,V4L2_CID_MPEG_VIDEO_BITRATE_PEAK,
>
> peak_bitrate);
>
> if( ret != 0 ) {
>
> logmsg(LOG_ERR,"Can not set video bitrate ( %d : %s )",errno,
>
> strerror(errno));
>
> return -1;
>
> }
>
> </snip>
>
>
>
> I'll update the code to always check the old value and do as you suggest
>
> so that logically it is always true that
>
> video rate < max video rate
>
>
>
> I'll report back on this thread once I verified this.
>
>
>
> /Johan
>
>
>
> On Wed, 09 Dec 2009 02:52:54 -0500, faginbagin <mythtv@hbuus.com> wrote:
>
> > Johan Persson wrote:
>
> >> I was wondering if someone could give some more detailed explanation of
>
> >> why a
>
> >> Hauppauge 150 (or 350/500) driver/chip combo refuses some ordinary
>
> >> video
>
> >> encoding bitrates while other work just fine.
>
> >>
>
> >> For example setting
>
> >>
>
> >> "Video Bitrate" 4 500 000
>
> >>
>
> >> gives an error while
>
> >>
>
> >> "Video Bitrate" 4 600 000
>
> >>
>
> >> works fine. Is there (for example) some "multiple" of a base value that
>
> >> whould
>
> >> be used ?
>
> >>
>
> >> (I would like to try to include some checking in my program to avoid
>
> >> this error
>
> >> message in case the end user have selected an "illegal" bit rate)
>
> >>
>
> >> Johan
>
> >
>
> > Could it be that when you first tried setting the video bitrate to
>
> > 4,500,000, the maximum bitrate was less than that? I've found that the
>
> > order in which you set these two parameters is important. If you want to
>
> > adjust both values up, you must first set the maximum, then set the
>
> video
>
> > bitrate. If you want to lower both, you must first set the video
>
> bitrate,
>
> > then the maximum bitrate. So, before changing both values, you should
>
> query
>
> > the current maximum so you know which value to change first.
>
> >
>
> > HTH,
>
> > Helen
>
> >
>
> > _______________________________________________
>
> > ivtv-users mailing list
>
> > ivtv-users@ivtvdriver.org
>
> > http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users