View Full Version : DivX H.264 Encoder Beta 2
WorBry
11th November 2009, 05:38
I looked at the output of MKVMerge (2.9.8) and MP4Box (0.4.6 Dev Build 1). In the case of PAFF streams both seem to be interpret field pictures as frames causing them to believe the content is twice as long as it actually is and in the case of MKVMerge giving each field picture a timecode as if it were a frame.
OK, thanks for the explanation. Seems logical.
You could double the frame rate to work around (most) of the issues but your best bet is to stick with MBAFF.
Well, PAFF frame-rate quirk aside, I'd pretty much come to that conclusion. This said, from my comparative tests, I'm afraid I dont find any compelling reason, at this time, to change from x264 despite it's sub-optimal MBAFF implementation (i.e. not being truly macroblock adaptive).
seemees
11th November 2009, 11:57
To Divx developers
HW MUST go ready to decode high and unrestricted levels of AVC, and all old HW devices without x264 support will be blow out from market. Is the CD-players push VHS?
Is the DVD players push CD and VHS? Is the LCD push ELT? Yes. Old and BAD HW devices don't need us. Please stop support for old and ugly devices. Set high level of
request to NEW devices and HW developers.
All we need - is BEST, QUALITY, FUSY, FAST (may be hardware and realtime or FASTER) encoder for x264 and divx264 (if you want).
But quality, quality and once more quality - MAXIMUM quality we need.
With best regards, seemees
WorBry
17th November 2009, 21:37
BTW - It appears that the DivX H264 encoder PAFF is not actually 'adaptive'.
Tested a number of interlaced clips including completely static sequences and some re-encoded reference PAFF samples; in all cases DGAVCIndex reports the Frame Structure as Fields(TFF) for all frames. If truly adaptive, one would expect that the static sequences would be encoded all as Frames, and with mixed content that there would be a mix of Field and Frame encoded frames (as there was in the original reference PAFF samples).
Leads me to wonder whether it is certain that the MBAFF is truly 'macroblock adaptive'?
Dark Shikari
17th November 2009, 21:45
BTW - It appears that the DivX H264 encoder PAFF is not actually 'adaptive'.
Tested a number of interlaced clips including completely static sequences and some re-encoded reference PAFF samples; in all cases DGAVCIndex reports the Frame Type as Fields(TFF) for all frames. If truly adaptive, one would expect that the static sequences would be encoded all as Frames, and with mixed content that there would be a mix of Field and Frame encoded frames (as there was in the original reference PAFF samples).
Leads me to wonder whether it is certain that the MBAFF is truly 'macroblock adaptive'?Most "PAFF" encoders I know of don't actually do any significant adaptation, since if they did, they might as well have done MBAFF instead.
WorBry
17th November 2009, 21:52
Good point, and by the same token it is reasonable to wonder then whether the MBAFF implementation is also non-adaptive ?
Dark Shikari
17th November 2009, 21:55
Good point, and by the same token it is reasonable to wonder then whether the MBAFF implementation is also non-adaptive ?It's rather trivial to test... just grab a copy (trial or whatnot) of Elecard Streameye and open an interlaced file.
WorBry
17th November 2009, 22:03
I'll do that, thanks. Had tried another pro analyzer demo - H.264Vista - but it always crashes with my DivX H264 encodes.
WorBry
18th November 2009, 00:52
Sorry for my ignorance, but which analysis in StreamEye allows you distinguish frame-encoded and field-encoded macroblock pairs in a given frame?
Dark Shikari
18th November 2009, 01:11
Sorry for my ignorance, but which analysis in StreamEye allows you distinguish frame-encoded and field-encoded macroblock pairs in a given frame?Frame MB-pairs don't have a linked icon when MB types are displayed, field MB-pairs do.
WorBry
18th November 2009, 04:15
Frame MB-pairs don't have a linked icon when MB types are displayed, field MB-pairs do.
On that basis, it appears that the DivX H264 encoder MBAFF is not adaptive either.
Edit: In fact, I'm pressed to find a reference clip that does actually demonstrate adaptive MBAFF. None of the MBAFF samples here are:
http://x264.nl/h.264.samples/
And surprised to find that this BBC HDTV MBAFF clip is not adaptive either, since the original source was obviously progressive:
http://mirror05.x264.nl/public/force.php?file=./BBC.HD.Robin.Hood.S01E03.H.264.1080MBAFF.AC3.5.1-BBC.sample.ts
I thought the BBC uses Grass Valley H.264 encoder which, according to their literature, incorporates truly adaptive MBAFF - "Interlace MB Adaptation", as they refer to it.
Anyone have an MBAFF sample that does demonstrate MB adaptation?
stax76
18th November 2009, 16:31
I need to make some changes in StaxRip regarding DivX Plus, does it support AC3? Where can I find the specification?
kieranrk
19th November 2009, 01:59
I thought the BBC uses Grass Valley H.264 encoder which, according to their literature, incorporates truly adaptive MBAFF - "Interlace MB Adaptation", as they refer to it.
Anyone have an MBAFF sample that does demonstrate MB adaptation?
The new BBC encoder does. (And I'm sure the old one did at some point)
http://x264.nl/h.264.samples/force.php?file=./aug.2009/08-08_01-29-47_BBC_HD_(AC3,eng)_Michael_McIntyres_Comedy_Roadshow.ts
I'd assume Ateme does too.
DigitAl56K
19th November 2009, 03:36
Hi Stax,
The recommended audio format for DivX Plus is AAC - support is built into DivX Plus Web Player, DivX Player, and also in our free DirectShow filters. DivX Plus devices support AC3 by decoding or passing it via SPDIF.
BTW, check your PMs :) We're in the process of consolidating information and building out documentation for developers. I was trying to contact you on this front recently.
WorBry
19th November 2009, 18:15
The new BBC encoder does. (And I'm sure the old one did at some point)
http://x264.nl/h.264.samples/force.php?file=./aug.2009/08-08_01-29-47_BBC_HD_(AC3,eng)_Michael_McIntyres_Comedy_Roadshow.ts
I'd assume Ateme does too.
Thanks for the BBC MBAFF clip, but again, according to StreamEye, it looks like it is all 'field MB-pair' encoded i.e. no adaptation.
Sorry to digress, I know this is a DivX H264 encoder thread.
Dark Shikari
19th November 2009, 18:19
Thanks for the BBC MBAFF clip, but again, according to StreamEye, it looks like it is all 'field MB-pair' encoded i.e. no adaptation.
Sorry to digress, I know this is a DivX H264 encoder thread.Look around more carefully. That one is MBAFF.
WorBry
20th November 2009, 02:38
In fact, it appears to be a mix of MBAFF and PAFF. According DGAVCIndex, starts off MBAFF, changes to PAFF (Fields TFF) at frame #87, back to MBAFF around frame #250, and then PAFF again around frame #290.
According to their literature, the Grass Valley Mustang encoder is capable of PAFF, MBAFF and PAFF + MBAFF (i.e. MBAFF when frame coding selected by PAFF) and " is able to compare, in parallel, all solutions, and check the one that provides the optimum bit rate for the best picture quality, approaching RDO (rate distortion optimization) very closely"
http://www.grassvalley.com/docs/WhitePapers/transmission/encoders/CDT-4015M-3.pdf
Foofaraw
30th November 2009, 23:27
Dark Shikari,
I was just thinking the same thing. The maximum IDR interval is limited to 4 seconds because we wanted to improve seeking for consumer electronics devices and through experimental testing our team found that this was a reasonable trade-off to make in terms of the impact on overall efficiency and navigation experience, so our encoder adheres to this recommendation.
Ah, this explains why so many hardware devices appear to seek so badly - its really people encoding with way to large intervals.
juGGaKNot
1st December 2009, 12:44
Next year is coming, when will the encoder be updated ?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.