MainConcept H.264 bugs

[Toti]

I have been encoding AVC streams in MainConcept. I noticed that both versions have problems V2.0.15 & V2.1.0.

-Both versions can record a AVC preset but does not shows it as available.

-V2.0.15 when encoding MPEG4 High profile VBR it does not respect the Maximum Bitrate set. Even if is set at 13~20Mbps it peeks in up to 30Mbps. Confirmed when playing back the video in PowerDVD 6.5 & Scenarist 4.1 complains "Total Bitrate is TOO High".

-V2.1.0 Gives an error message when setting the 2:3 pulldown flags on a 23.976 fps stream. It forces you to set it at 29.976 fps in order to use the pulldown flags. Video looks choppy because is treating it as a 29.97 with flags.

When encoding in MPEG2 it works great no problems these only occur when encoding to AVC High Profile.

I want to know other people's findings since it is hard for me to think that MainConcept will release a buggy program and nobody to notice it.

Please if anyone can confirm!!

[lazyn00b]

I do know that the pulldown bug has been mentioned by myself and others in the Scenarist 4.1 authoring thread.

Thanks for starting this thread - Mainconcept encoder is somewhat buggy, which is a shame because the encoder produces very good quality at a reasonable speed (IMHO). Other than the pulldown problem, I've also noticed that certain settings don't seem to "stick" after you've set them in the gui. VBV settings seem to mysteriously change, for example.

[Sergey A. Sablin]

Originally Posted by lazyn00b

I do know that the pulldown bug has been mentioned by myself and others in the Scenarist 4.1 authoring thread.

Thanks for starting this thread - Mainconcept encoder is somewhat buggy, which is a shame because the encoder produces very good quality at a reasonable speed (IMHO). Other than the pulldown problem, I've also noticed that certain settings don't seem to "stick" after you've set them in the gui. VBV settings seem to mysteriously change, for example.

please follow this link - http://forum.doom9.org/showthread.ph...057#post951057
read it till the end for detail information about workaround for 3:2 pulldown.
VBV settings has to be set up after bitrate settings, cause changing bitrate will automatically adjust VBV delay and size.

If you know any other settings that don't "stick" - please let me know.

[Sagittaire]

Originally Posted by Toti

-V2.0.15 when encoding MPEG4 High profile VBR it does not respect the Maximum Bitrate set. Even if is set at 13~20Mbps it peeks in up to 30Mbps. Confirmed when playing back the video in PowerDVD 6.5 & Scenarist 4.1 complains "Total Bitrate is TOO High".

-V2.1.0 Gives an error message when setting the 2:3 pulldown flags on a 23.976 fps stream. It forces you to set it at 29.976 fps in order to use the pulldown flags. Video looks choppy because is treating it as a 29.97 with flags.

Well for MC 2.0.15 it's a core codec enginer problem (h264 v 2.0).
The core is old and don't respect vbv parameters.
Anyway the pulldown flag are correct.

for MC 2.1.0 it's a gui problem.
There are no problem with core codec enginer (h264 v 2.1) but gui don't want make pulldown with 23.976 fps source.
Anyway there are no problem with vbv parameters.

If you want good Elecard/Mainconcept gui for HDDVD NTSC 1080p23.976 (with pulldown), you must try Elecard Studio Converter.
http://www.elecard.com/products/prod...verter-studio/
This gui is able to set the complete Elecard/Mainconcept core enginer setting and use the most recent build (h264 v 2.2).
Elecard Studio Converter is simply the most complete gui for the available setting (wpred, bref, pyramid, AQ, complete ME setting, complete RDO setting but not grain optimisation at this time)


[GOP] Use B-frame as reference
[GOP] Enable pyramid coding

[RC] Adaptive quantization mode
[RC] Adaptive quantization strength

[ME] Search range
[ME] Allow out of picture MVs
[ME] Use subblock search
[ME] Enable weighted prediction
[ME] Enable fast sub-block ME
[ME] Enable fast multi-ref ME

[RDO] Enable RD optimization
[RDO] Enable Hadamard SATD
[RDO] Enable fast RD optimization
[RDO] Enable fast inter decision
[RDO] Enable fast intra decision
[RDO] Quantization mode

[IP] Enable I_16x16 mode in intra slices
[IP] Enable I_8x8 mode in intra slices
[IP] Enable I_4x4 mode in intra slices
[IP] Enable I_16x16 mode in inter slices
[IP] Enable I_8x8 mode in inter slices
[IP] Enable I_4x4 mode in inter slices

[Clown shoes]

I would just like to say that the Mainconcept encoder is working brilliantly for me. Yes there are a few little bugs, but nothing that is that hard to workaround (thanks to Sergey's tips using avisynth) Unlike many of the other encoders, the mainconcept one appears to use all my processors (dual, quadcore xeon machine) although it seems to peak at around 50%, windows performance tab shows all 8 processors in use. I did a two pass encode of a 2 hour 1080p feature in 11 hours and that's at only 50% usage.

Yes the Elecard encoder may be slightly more ironed out right now, but the Elecard encoder HD version retails for about £4000 whereas the Mainconcept encoder does the same job with a bit of tweaking for about £600. For me as a consumer, it is a no brainer.

@Sergey, are you with Elecard or Mainconcept now

I have a couple of little questions if you have the time. (I did try to contact Mainconcept's end user support department with my issues last time, but unfortunately it was a month before I heard back, whereby the problem was solved) Do you have any idea when the next update will be released that may fix some of these minor issues and secondly do you have any idea why all my processors appear to be in use, however they do not appear to go over 50% usage.

Thanks again for your time


Oh, I almost forgot, @Toti

The bitrate limit is definately a VBV issue. I found that setting the buffer to 750,000 seems to work perfectly for me when encoding for HD-DVD. Feel free to correct me if I am wrong here Sergey, but it definately works for me.

[Toti]

Thank guys for the feedback. For the record:

In Version 2.1.0

-There is a bug with the pulldown flag that there is a workaround via Avisynth.
You must assumefps(29.97) then set pulldown 3:2 in MainConcept. (Sergey solution)

-The bug where The Maximum bit rate goes above the set is addressed by changing
The buffer to the correct size. AVC = 750,000 & MPEG2 = 150,000
You must put the value of your Average & Maximum Bitrate first, then changing
the buffer size. (Clown solution)

Preliminary tests, video looks PERFECT and bitrate is right where it should be (AVC encodes).

Also, I noticed ANOTHER BUG, on both versions the file size calculation is WRONG. However, I noticed that the expected file size differs from the actual size by a factor of 28% (close but not exactly). When calculating I do:

Desired file size MB
------------------------ = Actual File Size
1.28

I’ll post the results after I try it out several times.

Thank you SERGEY & CLOWN SHOES.

[Clown shoes]

Hi Toti,

the filesize (and running time if you notice) issue is caused by the avisynth fix. The footage is being reported to the encoder as 29.97fps when in fact it is 23.976fps. When the pulldown flags are applied the framerate is fixed but the encoder still reports the running time as if it was 29.97fps. Hence my 2 hour film is recognised as being about 1 hour 30 something. This is really only a very small issue which is easily fixed by using a good bitrate calculator to work out what average you need. The important thing to check is that the encoder reports the same number of frames as the source.

[Sagittaire]

Originally Posted by Toti

Also, I noticed ANOTHER BUG, on both versions the file size calculation is WRONG. However, I noticed that the expected file size differs from the actual size by a factor of 28% (close but not exactly). When calculating I do:

Desired file size MB
------------------------ = Actual File Size
1.28

I’ll post the results after I try it out several times.

Thank you SERGEY & CLOWN SHOES.

In fact it's not exactly a bug. The problem come from framerate pulldown convertion 24@30 Hz. You must set the bitrate with 24/30 scalling.

[Sergey A. Sablin]

Originally Posted by Clown shoes

I would just like to say that the Mainconcept encoder is working brilliantly for me. Yes there are a few little bugs, but nothing that is that hard to workaround (thanks to Sergey's tips using avisynth) Unlike many of the other encoders, the mainconcept one appears to use all my processors (dual, quadcore xeon machine) although it seems to peak at around 50%, windows performance tab shows all 8 processors in use. I did a two pass encode of a 2 hour 1080p feature in 11 hours and that's at only 50% usage.

thanks for kind words firstly.

Originally Posted by Clown shoes

@Sergey, are you with Elecard or Mainconcept now

well, till tomorrow I'm unemployed

Originally Posted by Clown shoes

I have a couple of little questions if you have the time. (I did try to contact Mainconcept's end user support department with my issues last time, but unfortunately it was a month before I heard back, whereby the problem was solved) Do you have any idea when the next update will be released that may fix some of these minor issues and secondly do you have any idea why all my processors appear to be in use, however they do not appear to go over 50% usage.

afaik, MainConcept prepares updated soon, but I don't know exact timeline, sorry.
version 2.2 has some restrictions/problems with loading more then 4 CPUs. Upcoming 2.3 will do work much better (I've tested 4 dual core Opterons and it was 75-90% loading) and it will be upto 1.3 - 1.5 faster for highest quality settings (even on single CPU).

Originally Posted by Clown shoes

Oh, I almost forgot, @Toti

The bitrate limit is definately a VBV issue. I found that setting the buffer to 750,000 seems to work perfectly for me when encoding for HD-DVD. Feel free to correct me if I am wrong here Sergey, but it definately works for me.

VBV of course limits bitrate variation, but I don't know any restriction on maximum peak bitrate.
The settings which appears in GUI as "maximum bitrate" is in fact hypotetical stream scheduler (HSS) rate - the rate at which decoder will receive data (or the rate at which VBV buffer is filled). So this settings isn't exactly maximum peak rate, which is unrestricted by AVC spec - restrictions are came from HSS rate and VBV buffer size (so reducing any of them will result in peak rate reduction apparently)

[Clown shoes]

Originally Posted by Sergey A. Sablin

version 2.2 has some restrictions/problems with loading more then 4 CPUs. Upcoming 2.3 will do work much better (I've tested 4 dual core Opterons and it was 75-90% loading) and it will be upto 1.3 - 1.5 faster for highest quality settings (even on single CPU).

Well that explains my processors peaking at about 50%. The speed enhancements in the newer versions are very exciting news. I can't wait to test it out.

You mention versions 2.2 and 2.3. Is that a typo or have I missed a version somewhere along the line

[Toti]

After some testing I have encoded a video that is perfectly encoded and in sync with audio. I need people to confirm this.

I encoded video with MainConcept v 2.1.0 using Sergey solution and I kept having a video that didn’t have enough frames. Video was shorter than the audio and will get out of sync quickly within 5 minutes of video.

Then tried MainConcept v 2.0.15 with Clown Shoes solution, it was the same way but not that shorter than with the other method. This made me believe that v 2.0.15 was the right way but when using pulldown 3:2. MainConcept is doing a lot more than just turning on flags…like changing the framerate (another BUG).

If anyone knows on another simple application to set the pulldown flags on an .avc format please let me know. Just like the PULLDOWN.EXE we have for the MPEG2.

I encoded a few videos and noticed that video every time is shorter by the same factor.

Anyway, I added the following to the avs script and now the video has the same frames as the audio (give or take 1~2 frames).

changefps(24.00)
assumefps(23.976)

When checking for the amount of frames I use Scenarist 4.1. Drop the video and the audio and click to select then browse to the property box to check the attributes of each.

If I don’t use the above I get both video and audio the same length time wise but different frame wise. MainConcept tells you the amount of frames but after the encode it’s a different amount of frames (Another BUG?).

Anyway, I mux the project play it back on PowerDVD 6.5 and everything is beautiful, no out of sync, no shuttering just perfect.

[Sergey A. Sablin]

Originally Posted by Clown shoes

Well that explains my processors peaking at about 50%. The speed enhancements in the newer versions are very exciting news. I can't wait to test it out.

You mention versions 2.2 and 2.3. Is that a typo or have I missed a version somewhere along the line

I've meant AVC encoder engine versions, not application (which usually behind engine for some time because of testing, bug fixing, addition of minor features).

[Clown shoes]

Hi Toti,

I don't know what your source material is but if like me you are testing VC1 material demuxed from HD DVDs, I may know what the problem you are experiencing is. Sonics Cinemaster Decoder pack 4.2 is having issues correctly reading the number of frames from VC1s. I think it may have something to do with the pulldown flags on the VC1. I will investigate and report back.

[Toti]

Hi Clown,

In the past two days I have encoded five different movies. My source is DirecTV HD. Here is my complete script:

LoadPlugin("C:\Program Files\AviSynth 2.5.7\plugins\DGDecode.dll")

LoadPlugin("C:\Program Files\AviSynth 2.5.7\plugins\Decomb521.dll")

mpeg2source("C:\Test\The Transporter 2.d2v", upConv=1)

Telecide(1,guide=1,vthresh=25)

Decimate(cycle=5)

FieldDeinterlace(Full=False,threshold=15,dthreshold=9)

Crop(4,4,-4,-2)

BilinearResize(1280,1080)

changefps(23.986)

assumefps(23.976)

I have an HD-DVD rip that I'll be testing once I get DirecTV HD encodes working.

Remember, I am using MainConcept v2.0.15 That "changefps" makes the video longer and aligns it with the audio but this is only good for the first 40~50mins after that the difference it starts to be noticeable.

This changefps is NOT the solution since it varies with each video. It is a problem with the pulldown in MainConcept, it is doing a lot more than just setting the flags, it is changing the framerate.

If we could encode the video and leave it at 23.976 fps then have another application to set the pulldown flags. I think it should work. Does anyone knows of such application????

I have given up on MainConcept since it makes it nearly impossible to work around the BUGS! I'll be testing CineVision 1.1 & 1.2 if it works I'll open a CineVision Thread to post the results.

[Clown shoes]

That's strange Toti, I use mainconcept 2.1 with a 23.976 source using assume 29.97 at the end of my script. I am then able to apply pulldown correctly. The encoder incorrectly displays the running time as it has been tricked into thinking the source is 29.97fps however the number of frames is correct. The file that is output is the correct running time and plays smoothly and flawlesley. Therefore I think there may be something else going on at your end as this is definately a working solution with the Mainconcept encoder.

[Toti]

Clown, Please post your script to see what else you are doing. If it works for you then I'll give it another try.

When you check for the number of frames and time is inside Scenarist HD? Do me a favor, after the encode drop both files .ac3 and the .avc in Scenarist HD. Select the file then look at the property box to see if they both have the same amount of frames.

By the way, both ways with MainConcept 2.0.15 & 2.1.0 produce a smooth video that looks good. Its that Scenarist HD tells me that both audio and video have different frames and after the project is finished. Video starts out fine but within 10 minutes the sync starts to be noticeable.

Have you mux your project and played it back? I use PowerDVD 6.5 HDDVD version. What do you use to playback you video since I have other versions of PowerDVD as well.

I really appreciate your help.

[Clown shoes]

Hi Toti, the framecounts for my output video are identical to the source framecounts that I put into the encoder. So far I have only been working with demuxed HD-DVD material but I have some other HD transport streams similar to what you are working with that I can test. I must confess that I have not produced any fully muxed HD-DVDs yet as I have been working on perfecting the video quality and the ability to transcode DD+ streams has only just become a possibility. However if my video streams are smooth and exactly the same length as the source I see no reason why this might be a problem.

I have a question for you though. Why does your script contain a changefps (which adds in additional frames) of 23.986 and then an assumefps (which slows down the framerate) back to 23.976? Surely that would cause a gradual desync. Not a rapid one as the framerate difference is quite small, but overtime I would imagine your video and audio would definately move apart. What is the reason for following changefps with assumefps in your script?

I will be away this weekend, so I probably won't be able to do any tests until Monday evening. I will get back to you asap

[Toti]

Hello Clown,

Yes, I know what you are saying. Theoretically, it should be perfect when you assumefps(29.97) in MainConcept 2.1.0 when set the flags. However, is another thing when you actually drop the files inside Scenarist HD and author your DVD. To test don't create a menu all the features just drop the video and the audio then create one VTS with just the video.

You will noticed that your video will start getting out of sync slowly. How slow? well, so slowly that you must encode at least 25 minutes to notice the difference. If you don't want to wait set a track at 20 mins and playback.

That's when you realize that Mainconcept is doing something with the framerate because the .avs file is perfect. Actually, when you encode MPEG2 with MainConcept and set the flags the video is GREAT. Meaning, its a bug with AVC not MPEG2.......what makes things so bizzar is that if you read documentations of CineVision 1.2 go to "Known Issues" it tells you In future CineVision versions you will be able to encode AVC 23.976p to 29.97 with the correct pulldown flags. Ala!, aren't they using MainConcept Engine? NO WONDER.

Again, PLEASE!! if anyone knows of an application that will set the pulldown flags for an AVC file let me know!!!

[Toti]

Guys LOOK

[HTML]http://www.elecard.ru/forum/viewtopic.php?t=1598&sid=c9f516598ac86945c0471afbf20bd452[/HTML]

[Toti]

Found solution its called Sonic CineVision 1.2 encoding in VC1. No more dealing with AVC's BUGS!. By the way, you think AVC is good? wait till you try VC1!!! Let me not screw up your WOW! when you encode your own VC1 files. Read more at this other thread.

http://forum.doom9.org/showthread.php?t=123569

[Clown shoes]

Hi Toti, can you compare the frame count and frame rate of your source and the frame count and frame rate of you encoded file. Are they definately different and if so by how much. Maybe we can work out what is going wrong for you.

[Toti]

Hello Clown,

I haven't used MainConcept again. If you want I'll encode a few minutes but honestly If you want trouble free encoder try CineVision 1.2 in VC1 MODE ONLY and in 1280X720 or 1920X1080. I haven't tried SD resolutions but I'll be testing them later.

Anyway, do your encodes in MainConcept then author the HD-DVD and you will see what I am talking about. Ofcourse, let the video run for about 20 mins at 30 minutes the video is so out of sync is horrible.

To answer you question, yes video and audio frames are different but again drop your files in Scenarist HD. When you drop the audio on the video you will see that the time line for the audio is longer than with the video. Even though that Scenarist has a feature to use the timecode to align both they still get out of sync.

Conclusion is that MainConcept does change the framerate of the video when you use the pulldown flags on both versions 2.0.15 & 2.1.0.

Let me know if you need any other help. I still want to use AVC for my DirecTV HD encodes since HD-DVD does support 1280X1080 in AVC ONLY which is exactly the same res that DirecTV HD gives me.

As soon as MainConcept releases a new version I'll be using it again or if CineVision comes with a new version I'll try the AVC.

[Sagittaire]

Anyway, do your encodes in MainConcept then author the HD-DVD and you will see what I am talking about. Ofcourse, let the video run for about 20 mins at 30 minutes the video is so out of sync is horrible.

It's not a Codec problem (Cinevision, Mainconcept H264 encoder or Elecard Studio Converter) but a scenarist problem.

[Clown shoes]

Is that confirmed sagittaire? And if so can you tell me what the problem is? I have several projects waiting to go right now.

[Crisidelm]

Sorry if this is a little off-topic, but does anyone have a certain date for the publication of Mainconcept H.264 codec Demo? The one mentioned here: http://www.mainconcept.com/site/index.php?id=17754 ?
It's been ages that this page advertises the downloadable demo appearing soon...

[Sagittaire]

Originally Posted by Clown shoes

Is that confirmed sagittaire? And if so can you tell me what the problem is? I have several projects waiting to go right now.

It's a resolved issue in Scenarist HD 4.2 ... the file duration for AVC ES with pulldown is not correct in scenarist HD 4.1.

DTS HD, DD TrueHD, DD+ work correctly too with Scenarist HD 4.2.

[Toti]

Thanks for the input, I'll be looking for that 4.2 version. I am currently using 4.1 and I found the Sonic Scenarist Pro v4.1.25a.

Although I can't verify that I do can tell you that when you encode AVC inside CineVision you can preview the video before you "finalize" and it does play fine inside CineVision.

I'll keep my eyes open for Scenarist 4.2 but I'll be testing it on Scenarist 4.1.25a. If not, well its going have to be VC1 for now till I find the solution. Anyway, VC1 works great for anything else that is not 1280X1080 (most people). That I know of only DirecTV HD gives you that. Some people call this HD-Lite.

Do you have Scenarist 4.2 or you read the fix somewhere?

[guada2]

@Sagitairre

Scenarist HD 4.2.

What is the real version "4.2.1" or "4.2.2", can you confirm ?

[Clown shoes]

real version??

[Toti]

Tested and re-tested. Mainconcept has BUGS when encoding in H.264 with pulldown. Cinevision produces a video with no pulldown problems.

[Clown shoes]

Can you elaborate on the "Bugs"

[Trahald]

Originally Posted by Toti

If we could encode the video and leave it at 23.976 fps then have another application to set the pulldown flags. I think it should work. Does anyone knows of such application????

https://sourceforge.net/projects/batchccews/ under download .. the app is called h264info. still alpha but seems to work well.

[Sergey A. Sablin]

Originally Posted by Trahald

https://sourceforge.net/projects/batchccews/ under download .. the app is called h264info. still alpha but seems to work well.

does it care about HRD state or just change picture timing even without buffering periods SEI? I just wondering - should we expect next rants about HRD errors after using this nifty tool...

[Sagittaire]

Originally Posted by Sergey A. Sablin

does it care about HRD state or just change picture timing even without buffering periods SEI? I just wondering - should we expect next rants about HRD errors after using this nifty tool...

H264info seem rewrite completely HRD and SEI. Mux work good in scenarist and hardware/software playback too.

[Sergey A. Sablin]

Originally Posted by Sagittaire

H264info seem rewrite completely HRD and SEI. Mux work good in scenarist and hardware/software playback too.

I see "seem" in each post regarding this tool...
Am I correct to suppose that the tool re-calculates buffering period SEI messages and checks that no one buffer error has been added after changing picture timing according to the spec? If no, then I'd say another "seem" - sorry, but it seems it doesn't care about HRD then.

[Trahald]

When developing the tool i made reference encodes.. from mainconcept, and also cinevision... (some sagittaire provided) to see the difference in hypothetical reference decoder model values between flat 23.976fps and 29.97(23.976+pulldown). i mirrored what i saw in this model.

in the reference streams all data in buffering sei was unchanged. so my tool mirrors that and doesnt change the data. the data that is vital is the sei_pic_timing.(all other data stays unchanged) i did alot of reading in the jvt data information for hrd and avc. for cpb_removal_delay i calc previous numclock_ts (in code order) and add to value. this mirrors what im seeing in reference encodes. dpb_output_delay in h264info i hard code to values i saw in ref streams. (dpb_output_delay effectively is diff from read time to display time in fields) i calulate the value more purely in my x264 patch. h264info uses hard values so if b frames > 2 (should never be the case however if you are making complaint gops) may get wrong values. i'll update h264 info to calculate the values in the same manner as my x264 patch at a later time.

i dont recommend h264info with a stream that doesnt already have hrd values in it as the values for buffertiming are taken from a reference encode. (i'll try to add real calcs for next release) . i made it originally as an addon to x264+hrd patch. so its made to give correct values based on source that already has hrd, just not pulldown and corrected pic timing.

the 'seems' you are hearing are in light of the fact this is an alpha tool and while im confident in its output, i am admitting there is a possibilty its not perfect

[Sagittaire]

Originally Posted by Sergey A. Sablin

I see "seem" in each post regarding this tool...
Am I correct to suppose that the tool re-calculates buffering period SEI messages and checks that no one buffer error has been added after changing picture timing according to the spec? If no, then I'd say another "seem" - sorry, but it seems it doesn't care about HRD then.

Well source for h264info are available here
https://sourceforge.net/project/show...ease_id=493468

Like I say mux for scenarist work (scenarist scan HRD compliance I think) and most important for me hardware/software playback work good too.

[Trahald]

as an addendum.. remember that pulldown does not alter how fast data enters and leaves the buffer. but since the cpb_removal_delay and dpb_removal_delay are based on a larger time scale they have to be adjusted.

[Sergey A. Sablin]

Originally Posted by Trahald

as an addendum.. remember that pulldown does not alter how fast data enters and leaves the buffer. but since the cpb_removal_delay and dpb_removal_delay are based on a larger time scale they have to be adjusted.

If this was said to me then I should say that I know a bit about pulldown and HRD, and even more about encoders used for generation of these reference streams.

If you'll read spec once again you'll probably find that pulldown flags change at least the number of bits written into Picture Timing SEI - mind clock_timestamp_flag. So pulldown change the rate of data - by small amount but every picture, so after several hundreds of pictures you'll have at least several hundreds bits mismatch.

It's just a luck that you didn't experienced buffer errors yet.

[Trahald]

@sergey
i dont doubt your knowledge..

while it is definately true that data is added to the stream. (up to 6.5 bits per frame for x264 stream which has pic_struct_present_flag=0 and 1.5 bits per frame for streams that do have pic_struct_present_flag=1 ).. so for.. lets say.. worst case.. 3 hour movie would be TOTAL 226.8kb of which on dvd-5 is against 4gb worth of data.. ... so 4000000000 vs 226000 = % 0.000567 impact on the buffer... (even smaller for dvd-9 or hddvd blank).. that could be bad if buffer were managed that tight of tolerance. ( i actually did a 4 hour movie w/out buffer errors. )

but again.. i do concede you are correct and i may (but probably not) factor that in in the future... thats why i have released the app as alpha

[Sergey A. Sablin]

Originally Posted by Trahald

@sergey
i dont doubt your knowledge..

while it is definately true that data is added to the stream. (up to 6.5 bits per frame for x264 stream which has pic_struct_present_flag=0 and 1.5 bits per frame for streams that do have pic_struct_present_flag=1 ).. so for.. lets say.. worst case.. 3 hour movie would be TOTAL 226.8kb of which on dvd-5 is against 4gb worth of data.. ... so 4000000000 vs 226000 = % 0.000567 impact on the buffer... (even smaller for dvd-9 or hddvd blank).. that could be bad if buffer were managed that tight of tolerance. ( i actually did a 4 hour movie w/out buffer errors. )

but again.. i do concede you are correct and i may (but probably not) factor that in in the future... thats why i have released the app as alpha

ok that's clear, I just thought you missed that.
btw - don't you forget about the time stamps? MC encoder writes them and they're at least 60 or 63 bits per each clock. Do you handle them?

[Trahald]

at first i did write them. but i found that they are not necessary for import to scenarist so i dropped them.

[Trahald]

another source of expansion would be increase in size of the 2 delay lengths. this has impact of 0 bits->22bits per frame depending on the sources allocation. this still is pretty small.. i will redo the calc for this and try to change this value as little as possible (some cases it isnt changed or made smaller as some encoders are over generous) for the next release.

[Toti]

Very nice tool, this could be the tool I need to start using MainConcept again. Thanks for the link.

I'll give it a try later on and post my results.

[Toti]

Originally Posted by Trahald

https://sourceforge.net/projects/batchccews/ under download .. the app is called h264info. still alpha but seems to work well.

@ TRAHALD, wow, this tool works perfectly. I can now use Mainconcept again. I'll try it again on larger files.

Why is this tool not available under Doom9.org -> Download?

Someone should let doom9 know!!