About B-Frames, cartoon mode and RC4...

[Chainmax]

I recently was told that cartoon mode doesn't work with b-frames in RC4 (i.é: if cartoon mode is selected b-frames are not used). Is that true? If so, what are my options for getting around this issue?

[ObiKenobi]

Originally posted by Chainmax
I recently was told that cartoon mode doesn't work with b-frames in RC4 (i.é: if cartoon mode is selected b-frames are not used). Is that true? If so, what are my options for getting around this issue?

No that isn't true, I've used cartoon mode and b-frames on RC4. BTW, where did you read that?

[Chainmax]

Have you checked any of those encodes to see if B-Frames are actually being used?

[ObiKenobi]

Yeah I watch the status window. And there are B-frames being used. I even just analyzed a few of the files and there are definitely b-frames being used. Once again, where did you read this or who told you?

[Chainmax]

BoNz1 told me that. He wasn't sure of it, though.

[BoNz1]

Once again, where did you read this or who told you?

I did and that wasn't exactly what I said. I never said cartoon mode _doesn't_ work with b-frames; I said I was _unsure_ of whether it worked or not because cartoon mode drops frames. Since this was a problem with builds pre RC4; frame dropping and b-frames no longer were allowed together. Evidently, this must not be the case for cartoon frames from what ObiKenobi said. They must be identified as something else other than N-VOPs. However, cartoon mode seemed to cause the same sort of problem that frame dropping and b-frames did last time I used it with 3ivx mp4 muxer. I haven't tried it since RC2-3.

[ObiKenobi]

Okay that makes alot more sense than the original post. Never actually realized there was supposed to be a problem at all as I've always used cartoon mode and b-frames since it was first added without any problems.

[Chainmax]

BoNz1: I misunderstood you then. My bad :o.

Evidently, this must not be the case for cartoon frames from what ObiKenobi said. However, cartoon mode seemed to cause the same sort of problem that frame dropping and b-frames did last time I used it with 3ivx mp4 muxer.
So, what is this problem you are talking about?

[BoNz1]

Ok the original problem as I understand it began when bond decided to use the frame drop to make vfr files and then mux them into mp4. The dropped frames are identified as N-VOPs. The problem is that b-frames also use N-VOPs as dummy frames and the 3ivx muxer could not tell them apart and just dropped all of them resulting in really bad desync. Therefore, frame dropping and b-frames were not allowed to be used together after RC3. Chainmax sent me a PM about some of his episodes that he was encoding and he was complaining about bad quality. I thought that perhaps the bad quality was because no b-frames were being used because of the frame dropping problem. Cartoon mode seems to drop frames as well so this is why I thought that perhaps b-frames might be disabled too and that this might be the source of the problem. Sorry for any confusion. So it seems b-frames are used with cartoon mode. But I think we still think we need to establish if cartoon mode and b-frames cause problems with the 3ivx muxer. Like I said I had problems before and I had assumed that they were disabled. None of these issues really would affect Chainmax's encode directly I don't think unless he planned to use mp4 and the 3ivx muxer. Hopefully that is more clear. I would appreciate if one of the developers could take a look at this or clarify anything, I would be willing to do some testing with the cartoon mode/b-frames and mp4.

[ObiKenobi]

Thanks for the explanation BoNz1, makes it a whole lot clearer.

[Chainmax]

Yeah, my dumb brain finally understood what you are saying :).

[Shalcker]

Cartoon mode "drops" blocks, not frames.

I think only in case entire frame consists of non-coded blocks it may optionally become an N-VOP, but i guess it doesn't anyway - just look through any stat-file and find places with something like p 2 0 0 1200 159 159 (for 640x480) - that's frames consisting _entirely_ from non-coded blocks as a result of cartoon mode, usually pure black parts. Such frames has size of 159 bytes - N-VOP takes around 1 byte as far as i remember, so they aren't N-VOPs :)

[lordadmira]

Really? So cartoon mode's strategy of lowering the threshold for carrying blocks forward actually works? I was under the impression that it didn't do anything worthwhile yet. Or does it sort of work on best case scenario material and still needs more work...

[shitowax]

Sorry, there is *NO* problem with the 3ivx muxer in this case ... Xvid guys decided to remove true NVop creation when BVop are activated because their encoder created non-compliant bitstream in this case ... Feel free to complement this ansywer, but the 3ivx muxer has no problem to differentiate dummy NVop from real NVop, and it *NEVER* loose sync when the sources are in sync (of course, you can have problems with broken source filters).

Originally posted by BoNz1
Ok the original problem as I understand it began when bond decided to use the frame drop to make vfr files and then mux them into mp4. The dropped frames are identified as N-VOPs. The problem is that b-frames also use N-VOPs as dummy frames and the 3ivx muxer could not tell them apart and just dropped all of them resulting in really bad desync. Therefore, frame dropping and b-frames were not allowed to be used together after RC3. Chainmax sent me a PM about some of his episodes that he was encoding and he was complaining about bad quality. I thought that perhaps the bad quality was because no b-frames were being used because of the frame dropping problem. Cartoon mode seems to drop frames as well so this is why I thought that perhaps b-frames might be disabled too and that this might be the source of the problem. Sorry for any confusion. So it seems b-frames are used with cartoon mode. But I think we still think we need to establish if cartoon mode and b-frames cause problems with the 3ivx muxer. Like I said I had problems before and I had assumed that they were disabled. None of these issues really would affect Chainmax's encode directly I don't think unless he planned to use mp4 and the 3ivx muxer. Hopefully that is more clear. I would appreciate if one of the developers could take a look at this or clarify anything, I would be willing to do some testing with the cartoon mode/b-frames and mp4.

[bond]

there is a little bit confusion of what i said, so plz read up the whole original story here (http://forum.doom9.org/showthread.php?s=&threadid=73633)

basically the most important parts:
note that during my testings i found that the frame drop ratio option was broken in the current release candidates (koepis rc3). syskin now fixed some bugs but it seems that there are still "unfixable" problems when using framedrop with b-frames
therefore the frame drop option in xvid will only work without b-frames from now on until this problem is fixed1) xvid (tested rc4, till rc3 no n-vops were created with the default settings (framedrop ratio on 0)!!)
- when b-frames are disabled xvid will create n-vops even if the framedrop ratio is set to 0 (which means it only drops frames that are 100% the same) a higher value will lead to that even frames which are not 100% the same can be dropped
- with b-frames enabled it doesnt output n-vopsso basically there is nothing wrong with the 3ivx mp4 muxer, the problem was that xvids framedrop ratio option (outputting n-vops) doesnt work together with b-frames atm (rc4)


Originally posted by BoNz1
I would be willing to do some testing with the cartoon mode/b-frames and mp4.yep would be great
try enabling cartoon mode and b-frames, and mux with 3ivx into .mp4 (with n-vop compression enabled)
than plz report back what framerate the .mp4 has (can be checked when opening the file in mp4ui for example)

[bond]

ok i now tested it myself with an extreme sample (totally black, heavily smoothed to force n-vops whereever possible) - pal 25 fps

here are my results with xvid 1.0 rc4:
i always encoded in vdm (default settings with 2b frames, framedrop ratio always on 0) -> remuxed with 3ivx to mp4 (with n-vop compression enabled) -> analysed the framerate with mp4ui

1) no cm, no b -> 17.273 fps
2) no cm, with b, with pb -> 25 fps
3) no cm, with b, no pb -> 25 fps

4) with cm, no b -> 15.682 fps
5) with cm, with b, with pb -> 24.773 fps
6) with cm, with b, no pb -> 25 fps

b = b-vops, pb = packed bitstream, cm = cartoonmodeso from my point of view cartoonmode uses a framedrop ratio higher than 0 (compare 1 and 4)
5 shows a bug maybe caused by the 3ivx muxer, which outputs the last frame at double duration when unpacking packed bitstreams (which causes the 24.773 fps)

so to sum things up:
- cartoon mode with b-frames enabled doesnt output framedrop n-vops
- with b-frames disabled it does output n-vops (and uses a framedrop ratio above 0)

[BoNz1]

Originally posted by shitowax
Sorry, there is *NO* problem with the 3ivx muxer in this case ... Xvid guys decided to remove true NVop creation when BVop are activated because their encoder created non-compliant bitstream in this case ... Feel free to complement this ansywer, but the 3ivx muxer has no problem to differentiate dummy NVop from real NVop, and it *NEVER* loose sync when the sources are in sync (of course, you can have problems with broken source filters).

Yes, I understand and sorry if I made it look this way. Thanks for the clarification, like I said I was a little sketchy on the details myself.

Originally posted by bond

5 shows a bug maybe caused by the 3ivx muxer, which outputs the last frame at double duration when unpacking packed bitstreams (which causes the 24.773 fps)

Ok so there may be a problem. I would like to do some more testing too myself. However, I will not be able to get to it today. I have finals and I really must study.