why 2.6.0 file is larger than 2.5.6

[feihuit]

version 2.6.0  generic larger file size than 2.5.6 with the same v/a codec and output format,why

[Jan Gruuthuse]

When using x264? The constant rate factor settings (single pass) are not the same: 2.5.# = 25 <> 2.6.# = 20.
If not using x264. Something similar could be the case, compare the settings with the GUI 2.5.# <> 2.6.#

[TCmullet]

This may be the same problem or maybe not.  I just ran a 4-hr M2TS file (captured from my Hauppauge Colossus) through AviD using "Mpeg TS Muxer (ff)" as the Output Format.  My new file was bigger.

Old file:  7,960,236 KB
New file: 8,381,936 KB

Why would it grow??  I'd say the duration is the same, but the new is actually 1/10 sec. shorter (losing the last few frames) due to a bug that Mr. Mean knows about but hasn't fixed yet.  But as those 2 numbers are round, the bug does not affect my point.  Where did the extra 421,700 KB come from??

[Jan Gruuthuse]

Probably not. When going back to ts the missing 0 packet(s) filler are reconstituted. My understanding of what is going on?

[TCmullet]

Probably not. When going back to ts the missing 0 packet(s) filler are reconstituted. My understanding of what is going on?

I don't know what you mean by "going back to ts".  I'm not.  I'm going m2ts to m2ts.  And what does "missing 0 packets" mean?  You make it sound like ts has something that m2ts doesn't.  It's the other way around... m2ts has something that ts doesn't.  But I'm going m2ts to m2ts anyway, so nothing should change.  Hence the mystery.

[Jan Gruuthuse]

I just ran a 4-hr M2TS file (captured from my Hauppauge Colossus) through AviD using "Mpeg TS Muxer (ff)" as the Output Format.

This becomes very hard to follow your issues running over several threads. Obviously there is some issues with m2ts provided by your hauppage board.
Null Packet are used to keep a stream constant. Working with these files: you are working/editing/cutting the stream. Video stream <> Video clip (with frames).

[TCmullet]

It makes sense to me to try to keep different topics in different threads.  If anything, I feel I may be guilty of putting *multiple* (too many) topics within *one* thread.  So I looked for some other thread that may have covered the new topic, and this one seemed like it might be related (rather than starting another new thread).

I didn't do any cutting or editing of the stream in question.  I was led to believe I should use the "Mpeg TS Muxer" option for .m2ts files.  Have I erred in some way?

I'll have to check what the HD captures do...   Just did so with a 1-hr HD capture, totally unedited.

Old file: 4,804,443 KB
New file: 4,805,158 KB

Difference (increase) of only 715 KB.  Small by comparison, and I thought it to be insignificant.  But still, I guess I should wonder why the extra 715 KB would be there, even though less than 1 MB.

"Obviously there is some issues with m2ts provided by your hauppage board."  If that's the case, then if we solve them for me, we solve them for ALL users of this fine card.

Hey, I just noticed something.  There appears to be only one muxer output option for BOTH .ts and .m2ts, namely, "Mpeg TS Muxer (ff)".  I was under the impression that one could change what container you have by simply using a different muxer.  Is that incorrect?  So how would I convert a .m2ts into a .ts by muxing??

[Jan Gruuthuse]

Save your videograbber output as .ts and not .m2ts. Both mpeg-ts stream slightly different format. If you don't re-encode (copy for both video/audio) the file size increase has nothing to do with constant rate factor settings.

[TCmullet]

The Colossus does have both .m2ts and .ts capabilities.  Yes, they are slightly different formats.  And yes, I'm not reencoding, but cutting at the GOP points like you are.  So if I don't reencode, and the file size increase has nothing to do with whatever you said, then what is causing it?  It makes sense to ask the AviDemux forum, as it is AviDemux that is increasing the size, mysteriously.

And I don't understand why you are pushing me to abandon .m2ts and embrace .ts.  Both formats should work.

[Jan Gruuthuse]

You're continuously jumping from one point to another.
m2ts is apparently not working. You did not even reply if .ts was working for you in that situation. You see only video = frame and it should work. Stream is not equal to video with frame.
Sorry for you, I'm out of here, spend enough time trying to help you, what you obviously don't want. Keep discussing in the forum. Bye.

[TCmullet]

Whether you reply or not (and I'm sorry I've irritated you), I will try .ts again.  But the .m2ts files created by the Colossus (at least the HD ones) cannot be doubted as being good, as their card is well established in the market.  All 3 of their capture formats work (.ts, .m2ts, .mp4).  Whether a freeware program can be made to work with it, is another matter.  I do appreciate what Mr. Mean has done in creating this, and to him and all others who try to provide help.

[Jan Gruuthuse]

But the .m2ts files created by the Colossus (at least the HD ones) cannot be doubted as being good

Jan, when you asked if I could try recording in .ts vs .m2ts, I failed to see that you said "AVCHD".  I'm not recording HD, but SD.  The HDs have worked fine.

Sorry even more contradictions. Hope for you developer(s) are even willing to look at your .m2ts problem. I work now for over 1 1/2 years with different mpeg-ts sd/hd streams from different hardware sources/manufacturers. Strangely enough these don't have this/cause issues with this nice freeware kit.