Re-encode mpeg-2 GOPs exceeding a specified bitrate ?

[Music Fan]

Hi,
is there a way to re-encode only the GOPs exceeding a specified bitrate in an mpeg-2 video ?
I have a video recorded on TV with my STB and according to Bitrate Viewer, 3 GOPs are around 16000 kbps, while others are below 10000 kbps and I'd like to avoid a complete re-encoding for dvd compliance.

Mpeg Video Wizard can make smart rendering and modify too long GOPs to get dvd compliant files but it does not change bitrate.
And my file doesn't seem to have too long GOPs because even when I check "GOP size compliance for DVD recording", the exported file is exactly the same than the original (still with the very same size and bitrate).
http://www.womble.com/support/help.dvd5/chap11-5.html

Dvd-Shrink can re-encode files but one can't specify any bitrate, only a percentage of the original file size, which is different.

[Sir Didymus]

Cuttermaran.


It is possible to use encoding mode for frame-accurate editing that will be processed in a reasonable length of time and not eat up gigs of hard drive space for intermediate .avi files. Use it just to make some tiny cuts (about one second’s worth of frames) that include the non-standard start or end frames. This allows one to make the main portions of the cut in standard edit mode. Cuts using encoding mode and standard edit mode can be included together in the same cut list. Just don’t forget to turn off encoding mode before making cuts that don’t require it!

[Music Fan]

That's just smart rendering, as Mpeg Video Wizard does, but that's not exactly what I asked ; I need to re-encode only some GOPs because of their bitrate.

[SeeMoreDigital]

Hi Music Fan,

Is there any particular reason you want to store your MPEG-2 captures onto DVD 'spec' authored disc's?

[Sharc]

You may want to try
DVD-Rebuilder PRO with RB-Opt.
You can redistribute the bitrates on cell basis, processing only those cells (chapters) which include the critical GOPs and leaving the rest intact.

Edit:
or perhaps simpler:
Try HCenc's "Preview/Zones" feature.

[Sir Didymus]

That's just smart rendering, as Mpeg Video Wizard does, but that's not exactly what I asked ; I need to re-encode only some GOPs because of their bitrate.

?!?!?

With Cuttermaran, for instance, if you have a m2v stream which requires only one GOP to be reencoded (let say GOP nr. 100), you may define two cut points, one before and one after the GOP nr. 100. So you have three cut segments (GOP nr. 1-99, GOP 100, GOP 101-end of stream). If you turn off encoding mode for segments 1 and 3, you get only segment 2 to be reencoded, the whole stream is left untouched, except GOP nr. 100, which will be reencoded with the bitrate (end the other encoding parameters) you need.

Is this different respect to what you asked?

Edit. By the way, in order to check for DVD-Video compliance, the bitrate of a single GOP is completely irrelevant (even assuming that the calculations of these "bitrate viewers" are correct, which is not always true). The right tools to use are MPEG2 stream analyzers, and the specific check to perform regarding the video bitrate is that the VBV constraints are obeyed. The alternative (& simple & quick & free) way to make this check is just to go on and mux the stream, together with the audio(s) and subs stream(s) by means of MuxMan; if the authoring session concludes without errors, you may assume for sure that your stream is DVD-Video compliant. :-)

Cheers, SD

[Music Fan]

Is there any particular reason you want to store your MPEG-2 captures onto DVD 'spec' authored disc's?
To be sure I won't have any playing problem.
And I like to specify the correct maximum bitrate in the header with Restream : if I specify 16000 kbps, I'm afraid some players refuse it (and also my authoring software).


Try HCenc's "Preview/Zones" feature.
I tried it but it opens only d2v or avs files, thus I don't believe it can open mpg files and re-encode only some parts.


With Cuttermaran, for instance, if you have a m2v stream which requires only one GOP to be reencoded (let say GOP nr. 100), you may define two cut points, one before and one after the GOP nr. 100. So you have three cut segments (GOP nr. 1-99, GOP 100, GOP 101-end of stream). If you turn off encoding mode for segments 1 and 3, you get only segment 2 to be reencoded, the whole stream is left untouched, except GOP nr. 100, which will be reencoded with the bitrate (end the other encoding parameters) you need.
Ok, I will have a look at this.

Is this different respect to what you asked?
Nearly not, but I hoped to find an automatic process, without having to cut and specify which parts have to be re-encoded.

By the way, in order to check for DVD-Video compliance, the bitrate of a single GOP is completely irrelevant
I'm not so sure about that because I know that Tmpg Dvd Author refuses files with too high bitrates (or warn there may be problems), just because of a wrong header, that's why I use Restream.

The right tools to use are MPEG2 stream analyzers, and the specific check to perform regarding the video bitrate is that the VBV constraints are obeyed.
Which software can do this ?

The alternative (& simple & quick & free) way to make this check is just to go on and mux the stream, together with the audio(s) and subs stream(s) by means of MuxMan; if the authoring session concludes without errors, you may assume for sure that your stream is DVD-Video compliant.
I can test it but anyway I will use Tmpg Dvd Author at the end.

edit : that's ok for MuxMan, does it mean it can properly analyze VBV ?
But for the created vob, MediaInfo shows the same bitrate than for the mpg file (15 Mbps, which is always the indicated bitrate in my mpeg-2 SD TV recordings, while none has exactly this bitrate, it's often much lower) while it's supposed to be too high for DVDs, thus I wonder why it's ok for MuxMan.

[SeeMoreDigital]

And I like to specify the correct maximum bitrate in the header with Restream : if I specify 16000 kbps, I'm afraid some players refuse it (and also my authoring software). What type of players?

Unless you have a really old DVD player without a USB input, you should be able to play the (MPEG-2+AC3/MP2).mpg contained file okay. And any Blu-ray player should be able to play your source...

[Sir Didymus]

<<
edit : that's ok for MuxMan, does it mean it can properly analyze VBV ?
>>
Obviously. MuxMan implements a very precise VBV model. Its output, if created without errors, can be digested very linearly by whatever DVD player, and the quality of its authoring is much better than "good".

You 'd better not thrusting too much to the "declarative" information contained in the m2v stream header. Especially regarding the video bitrate, as you have found (and as you are doing with this bad practice of alterating it - however apologies: don't want to comment about your methods and tools). This information is easily "patched" - and screwed up - with tweaking applications such as Restream, or by means of a simple hex editor. MediaInfo can not analyze the whole stream to measure the stream properties and to check if the header information is correct: it just reports the stream header info, that easily becomes (and it is infact) unreliable. The same information, for what it worths, is reported in the VOB files. Why are you surprised? How could it be different? The VOB structure is just a container for the related audio, video and subs assets...

[Sharc]

....
I tried it but it opens only d2v or avs files, thus I don't believe it can open mpg files and re-encode only some parts.
....
- Use DGIndex.exe to create the .d2v from your mpeg-2 source
or
- create a simple avisynth script, like
DirectShowSource("C:\...path....\yourfile.mpg")
Save this codeline with a text editor as yourfile.avs and load it in HCenc.

But I am afraid HCenc will probably re-encode the full file, you would however have full control over the bitrate and VBV.

Edit:
Are you sure that the excessive bitrate peaks are not caused by short GOPs due to scene change ?

[Music Fan]

Probably, but it's too high anyway to be dvd compliant, and I don't want to re-encode the whole file.

Obviously. MuxMan implements a very precise VBV model. Its output, if created without errors, can be digested very linearly by whatever DVD player, and the quality of its authoring is much better than "good".
Good point, but that won't really help me because I won't use it for authoring. I can use it anyway to make verifications.

You 'd better not thrusting too much to the "declarative" information contained in the m2v stream header. Especially regarding the video bitrate, as you have found (and as you are doing with this bad practice of alterating it - however apologies: don't want to comment about your methods and tools). This information is easily "patched" - and screwed up - with tweaking applications such as Restream, or by means of a simple hex editor. MediaInfo can not analyze the whole stream to measure the stream properties and to check if the header information is correct: it just reports the stream header info, that easily becomes (and it is infact) unreliable. The same information, for what it worths, is reported in the VOB files. Why are you surprised? How could it be different? The VOB structure is just a container for the related audio, video and subs assets...
I already know this, that's why I said there were header errors (with TV recordings) that I often have to correct.
Bitrate Viewer detects the real bitrate (I can verify this with my own encodings) and don't care about the header, it's quite reliable.

[pandy]

3 GOPs are around 16000 kbps, while others are below 10000 kbps and I'd like to avoid a complete re-encoding for dvd compliance.

Are you sure? MP@ML is max 15Mbps... how you calculate bitrate?

[Music Fan]

Already written, I see it in Bitrate Viewer (which does not care about header).

[raffriff42]

I've been looking into the ffmpeg segment (https://ffmpeg.org/ffmpeg-all.html#segment_002c-stream_005fsegment_002c-ssegment) command lately for other reasons, and I think it can help with this problem:

You can easily split a file on GOP boundaries withffmpeg
-i "INPUT.mp4"
-codec copy
-f segment
-reset_timestamps
-segment_list_type "ffconcat"
-segment_list "segments.concat"
-segment_start_number 1000
"segment--%d.mp4"(the above should all be on a single line; line breaks were added for readability)

Next, generate a per-segment (and per-GOP) bitrate report with this batch script (save as "segment-report.bat"):@echo off
@echo Segment report: > segment-report.txt
@echo. >> segment-report.txt

for %%f in (segment--*.*) do call :SUBR %%f >> segment-report.txt
goto :EOF

:SUBR
@echo %1
ffprobe "%1" 2>&1| find ", bitrate:"
@echo.
goto :EOFThe batch script creates a file called "segment-report.txt", that looks like this:Segment report:

segment--1000.mp4
Duration: 00:00:04.18, start: 0.000000, bitrate: 16896 kb/s

segment--1001.mp4
Duration: 00:00:02.01, start: 0.000000, bitrate: 18635 kb/s

segment--1002.mp4
Duration: 00:00:03.33, start: 0.000000, bitrate: 13567 kb/s

...


Now after you replace any problematic segments, you can reassemble them with ffmpeg concat (https://ffmpeg.org/ffmpeg-all.html#concat-1):ffmpeg -f concat -i "segments.concat" -c copy "OUTPUT.mp4"


This idea has only tested with a couple of short .mp4's. Hopefully it works for you.

Keep the commands unchanged except for the input & output filenames (in blue).

[Music Fan]

Thanks, does it work too with mpeg-2 in mpg container ?
When you say "replace any problematic segments", do you mean I still have to re-encode manually these GOPs with another tool ?

[raffriff42]

I think it will work, but have not tested it.
Yes, you do have to re-encode the "bad" segments.

[manolito]

@Music Fan

Which bitrate viewer are you using? I am asking because there are different methods to calculate the maximum bitrate.

Konran's Bitrate Viewer always calculates higher bitrates than the old Teco Bitrate Viewer. And in Konran's program you can specify four different methods to calculate the bitrate (Seconds based, Raw GOP based, Enhanced GOP based and Frame based). Each of those methods results in very different avg and max bitrates.


To just reencodes GOPs with bitrates above the DVD specs I agree with Sir Didymus, Cuttermaran can do this. It is even much easier than the method suggested by SD, it can be done without making any manual cuts.

How?
Cuttermaran has an encoding option "Create DVD compliant Output". (For this option to work you must install an MPEG2 encoder in Cuttermaran. CuttyEnc and HCenc are supported.)

If this option is checked, Cuttermaran determines the GOP length and the bitrate of each GOP. If one of them exceeds DVD specs, the corresponding GOP will be reencoded. The reencoding bitrate can be set to "Auto" (takes the bitrate from neighboring GOPs), or a specific bitrate can be set. I always use a fixed value between 7000 or 8000 kbps.

To process your source (must be elementary streams) you just load the source into Cuttermaran, then select the whole clip and add it to the time line. With the above option ticked you will end up with DVD compliant elementary streams.


Cheers
manolito

[Music Fan]

Great, that's what I need, I'm gonna try this.:thanks:

I use Bitrate Viewer 2.3 by Konran in "GOP based" mode ; the maximum bitrate detected in this mode corresponds to the maximum bitrate I specify in my mpeg-2 encoder. The same bitrate is also detected by MediaInfo and Tmpg Dvd Author 2.

I found an interessant trick about Mpeg Video Wizard : it makes smart rendering with mpeg-2 and re-encodes only the modified parts (for transitions, titles, fade), but as it uses the maximum bitrate detected in the header as reference, the re-encoded parts have a too high bitrate if this header is wrong (I verified with Bitrate Viewer), which is always the case with my SD TV recordings (15 Mbps in the header while it's always less, except some rare GOPs).
Therefore I first modify the header with Restream : if I specify for example 9500000 bps (= 9500 kbps for Mpeg Video Wizard), the re-encoded parts won't exceed 9500 kbps (also verified with Bitrate Viewer), even if some GOPs already present in the original video have actually a higher bitrate. :)
But it doesn't re-encode these high bitrate GOPs if they are in non-modified parts.
Thus the header is only used for the parts modified by Mpeg Video Wizard, not for all GOPs.

That's why I will use Cuttermaran for the final step, except if it's not really needed, I will test my video on several standalone players. I guess it will work because it was ok for MuxMan.

[Ghitulescu]

I have a video recorded on TV with my STB and according to Bitrate Viewer, 3 GOPs are around 16000 kbps, while others are below 10000 kbps and I'd like to avoid a complete re-encoding for dvd compliance.

It's very rare that a DVB stream with DVD-like MPEG-2 video goes beyond what the DVD accepts. So rare that I haven't found any since 2004 when I started doing this. What I have found is that many of them do not correctly fill in the header (also DVD recorders do this), so a 3Mbps can incorrectly be flagged as a 15Mbps one.

Secondly - 3 GOPs are not a problem - the DVD specs are so that any unit can read out CONTINUOUSLY at max. bitrate. DVDR and RW are "slower" in this respect, but still can provide 16000 for short period of times (bursts).

I would not care about it... it will only complicate your life with no evident benefit.
PS: DVDs are somehow stoneage now. Have you thought of reauthoring them into a BD - in SD mode they accept DVD-like streams and the BDR provide better bitrates.

[Music Fan]

Yes but sometimes I still need dvds.

[burfadel]

You can cut the MPEG2 file into sections, the first section, the oversized section, and so forth for the remaining. You can then re-encode just the oversized sections, and rejoin back together.

[pandy]

What I have found is that many of them do not correctly fill in the header (also DVD recorders do this), so a 3Mbps can incorrectly be flagged as a 15Mbps one.

This is common practice in professional encoders - they set in header maximum allowed bitrate i.e. 15Mbps but real bitrate is usually variable and substantially lower.


Secondly - 3 GOPs are not a problem - the DVD specs are so that any unit can read out CONTINUOUSLY at max. bitrate. DVDR and RW are "slower" in this respect, but still can provide 16000 for short period of times (bursts).

Well - this depend from decoder - do not forget that decoder works under strict constraints and it may be not capable to satisfy going above system limitations - this is not about bitrate from/to storage - this is about number of cycles that decoder is able to receive from system bus when memory is shared between various components - mostly any HD capable decoder will be able to deal with such peaks but pure SD decoders can be unable to cope with such peaks.


I would not care about it... it will only complicate your life with no evident benefit.
PS: DVDs are somehow stoneage now. Have you thought of reauthoring them into a BD - in SD mode they accept DVD-like streams and the BDR provide better bitrates.

I would care - as SoC may have many limitations - do not forget that DVD and MPEG-2 are from first half of the 90's - 4-8MB RAM was in those time huge amount of memory.

Encoder that produce such spikes is simply not MPEG-2 compliant.

You can cut the MPEG2 file into sections, the first section, the oversized section, and so forth for the remaining. You can then re-encode just the oversized sections, and rejoin back together.
It may be not possible when stream is Open GOP style - then serious bitstream work is required (you need to do all things at DTS/PTS) - from practical perspective it may be better to re-encode faulty encoded (by not MPEG-2 compliant encoder) video.

[Music Fan]

Which bitrate viewer are you using? I am asking because there are different methods to calculate the maximum bitrate.

Konran's Bitrate Viewer always calculates higher bitrates than the old Teco Bitrate Viewer. And in Konran's program you can specify four different methods to calculate the bitrate (Seconds based, Raw GOP based, Enhanced GOP based and Frame based). Each of those methods results in very different avg and max bitrates.
I'm a little bit confused now because I realize that the maximum bitrate of my file in GOP based (16757 k) is not the same than in GOP enhanced (9878 k), what's the difference between these modes ?
But for the mpeg-2 files I encoded myself, there are no differences between these 2 modes, the maximum bitrate is exactly the same :confused:

[Sharc]

I'm a little bit confused now because I realize that the maximum bitrate of my file in GOP based (16757 k) is not the same than in GOP enhanced (9878 k), what's the difference between these modes ?
But for the mpeg-2 files I encoded myself, there are no differences between these 2 modes, the maximum bitrate is exactly the same :confused:
From the doc:
GOP based:
a bitrate peak value is generated after each GOP (Group of Pictures) processed. A GOP usually consists of 12 ... 15 frames on PAL systems and 15 ... 18 frames on NTSC systems. So the measurement interval is approx. half a second. But files that are using scene change detection or rudimentary cut-edited can have shorter GOP's than the standard size specified to the MPEG encoder. Consider having a GOP with only one I-frame then you'll get very high bitrate values that increase the average value and dominate the peak detection. Use Ctrl-G to activate this from any other setting.

Enhanced GOP based:
This is a similar method as the GOP based setting. The difference is a weighted algorithm that counts the frames each GOP has and shifts a GOP that is less than half the standard GOP size into the next cycle of calculation. This gives a more harmonized result than the raw GOP based method. Use Ctrl-X to activate this from any other setting

Kind of smoothing/filtering of GOPs of unequal length as I understand it. This may happen due to scene changes. Or perhaps open GOPs vs closed GOPs.....

[Music Fan]

Thanks, finally I don't which one I have to care about.

[Sharc]

I think at the end it all boils down to buffer control (VBV) issues which must be compliant for DVD.

[Music Fan]

Yes, but apart the mux with MuxMan, I don't know any simple method (avoiding a mux would be faster) to know if VBV is ok.

[Sharc]

It's the task of the encoder to handle VBV properly.
I am not aware of a free tool (other than MuxMan) for mpeg2 VBV verification. For AVC/mpeg4 there is Donald Graft's VBV checker b.t.w.
HCenc GUI has a control bar which you can activate to visualize VBV during encoding.

[manolito]

It's the task of the encoder to handle VBV properly.
HCenc GUI has a control bar which you can activate to visualize VBV during encoding.

It is even better: By default HCenc controls the VBV buffer during encoding to avoid any buffer problems. The option can be disabled with the *NOVBV command in the HC.ini file.

NOVBV

This command disables the VBV (Video Buffer Verifier) checking.
VBV checking is enabled by default. This command should not be used for DVD creation.


My own experience using QuEnc, CCE SP and HCenc is that the absolute peak bitrate does not say anything about the VBV buffer. Whenever QuEnc created peaks above 10000 kbps there was a good chance that MuxMan would reject the file (Imago and Mplex would accept it, but causing stuttering in some players).

The same peak bitrates created by CCE and HCenc would not cause any problems with MuxMan. Not sure how the current FFmpeg versions behave, but I believe that VBV buffer handling has improved a lot compared to QuEnc.


Cheers
manolito

[Music Fan]

It's the task of the encoder to handle VBV properly.
Ok, we can guess that the files we encode ourselves are ok but we don't know what are the encoders and settings used by TV channels and the TV norm is not the same than Dvd (GOP size, bitrate, resolution).

[pandy]

but we don't know what are the encoders and settings used by TV channels and the TV norm is not the same than Dvd (GOP size, bitrate, resolution).


It is easy, TV broadcast use usually twice lower bitrate than max in DVD (around 4 - 5Mbps) rest is very similar with exception that TV broadcasters usually to improve efficiency allowing for longer GOP's (sometimes also variable structure) and some of the broadcasters even able to operate with progressive/interlace flag to improve compressibility even further (AFAIR TF1 use such feature). But TV and DVD overlapping in large area (for H.262 practices).

[Music Fan]

Yes, but I have seen some strange resolutions on TV, CNN here is in 544.576 (with 16/9 DAR).

[Ghitulescu]

It doesn't matter - many DVD recorders may use such widths if the chosen bitrate falls below a certain limit.

I repeat (noticing however that pandy is right) that you should try first to put the stream on a DVD. Many DVD players have no issue playing unusual DVB streams.

[pandy]

Yes, but I have seen some strange resolutions on TV, CNN here is in 544.576 (with 16/9 DAR).

This is strange - as EBU nad DVB specify for 16/9 704/720 only.
544 and 576 are allowed for 4/3 and they offer luminance resolution comparable to analog RF channel bandwidth (5 - 5.5MHz).

[Music Fan]

And CNBC is in 480.576, also with 16/9 DAR.

[manolito]

Broadcasters do not care for the DVD specs (and they don't have to). They do care to meet the MPEG2 TS specs.

Ghitulescu is right, most DVD players will play these unusual resolutions. You just have to find an authoring application which accepts these streams (MuxMan will not, but DVDAuthor will, at least for 480 x 480/576 SVCD resolution).

If you are determined to meet the DVD specs, there is no way except resizing to a standard DVD resolution (Full D1, Half D1 and VCD).

Cheers
manolito

[Ghitulescu]

You just have to find an authoring application which accepts these streams (MuxMan will not, but DVDAuthor will, at least for 480 x 480/576 SVCD resolution).

Back in theose days when I put DVB onto DVDs, I think I could trick out any muxer, if I would have patched the very first header with DVD-compliant values, then revert to original values (not that the DVD player would care - it is not required to)

[filler56789]

.......
You just have to find an authoring application which accepts these streams (MuxMan will not, but DVDAuthor will, at least for 480 x 480/576 SVCD resolution).

DVD-lab Pro accepts any resolution between 320x240 and 720x576.
Years ago, I created several DVDs with "non-compliant" frame dimensions (400x480, 640x480, 544x480, and even 320x240 :D ).

[Sharc]

And CNBC is in 480.576, also with 16/9 DAR.
Which is standard SVCD resolution.

DVD players which are tolerant to non-standard resolutions were mostly introduced by "divx-certification", as I remember.

[Ghitulescu]

I believe that all DVD players can play whatever unusual framesizes that are allowed by the MPEG-2 standard and also are VCD compatible (with few restrictions). DAR was not an issue regardless of framesizes.

I don't think I had a DivX-compatible DVD player at that time when I tested first whether the DVB DVD-non-standard streams can be played or not, and yes they could have been played back on those. Nevertheless, the only variance was the GOP-size and the width, but not the height, which was always 576 (PAL).


One of those strange players was a JVC that blocked the S-VCD mode. I could get rid of this limitation by authoring the S-VCD streams as VCDs. Those discs however could not be played elsewhere.



I know that bending the rules is dangerous and the resulting DVD may not be played.
However I would take this risk. I would use a DVD-RW for the tests first.
And I remember that many authoring houses, although using all types of certifying and testing tools - thus ensuring a 100% compliant DVD, still had an armada of various DVD-players to test the DVDs upon them.

[Music Fan]

I didn't burn this video on dvd yet but here is an observation about the mux to vob with MuxMan 0.16.8 :
-original video demuxed with TSmuxer : OK, the VOB still has 15 Mbps in its header, MuxMan doesn't change it
-video non edited but with modified header (9500 kbps instead of 15000) : OK, the VOB still has 9500 kbps in its header
-video edited by Mpeg Video Wizard with original header : KO, "muxed failed probably because of excessive bitrate", it began but stopped after a few seconds
-video edited by Mpeg Video Wizard with modified header (I put 9500 kbps with ReStream before editing with Mpeg Video Wizard) : OK

This confirms that my trick with ReStream is useful when editing with smart rendering is needed, at least for Mpeg Video Wizard.

[Music Fan]

That's OK for the 3 titles muxed by MuxMan on 3 dvd players (actually 1 dvd player & 2 Blu-ray/dvd players).
I gathered the 3 titles in 1 project with Dvd-Shrink and burnt it on a dvd+rw.

[pandy]

This confirms that my trick with ReStream is useful when editing with smart rendering is needed, at least for Mpeg Video Wizard.

I usually place average bitrate (calculated manually) in ReStream - it works for dumb ts muxers (such as adherent/tektronix).

[Music Fan]

Normally it's for maximum bitrate, not average bitrate.

[Ghitulescu]

Can one confirm (or not) whether the VBV is the same for DVB and DVD models, all other things equal? I assume DVB is stricter, for the channel is less reliable, but I do not know for sure...

[Sharc]

Can one confirm (or not) whether the VBV is the same for DVB and DVD models, all other things equal? I assume DVB is stricter, for the channel is less reliable, but I do not know for sure...
You find possibly the answer here:
http://forum.doom9.org/showthread.php?t=168073
and here:
http://www.etsi.org/deliver/etsi_ts/101100_101199/101154/01.11.01_60/ts_101154v011101p.pdf

[pandy]

Normally it's for maximum bitrate, not average bitrate.

That's why i said that this is workaround for retarded TS muxer which is part of Tektronix suite (worth 40k+ $) - muxer will feed packets with max header bitrate inside TS even if average bitrate is way lower - Manzanita is free from this issue.