Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 22nd August 2008, 21:36   #1  |  Link
DigitAl56K
Registered User
 
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
Project Rémoulade Update: DivX H.264 Encoder Alpha 1 & Tutorial now available

Today we have released as part of Project Rémoulade an alpha version of the DivX H.264 command line encoder at DivX Labs:

Quote:
Originally Posted by DivX Labs
The second package to be released from Project Rémoulade is an alpha version of the DivX H.264 Encoder. Complementing the DivX H.264 Decoder, this multithreaded encoder produces high definition H.264 video bitstreams that are compatible with the draft profile for DivX 7 H.264 HD video. The encoder is a command line utility and accepts input from raw AVI files as well as the AVISynth frame server.
A comprehensive tutorial is provided for anyone who lacks experience with command line tools or certain aspects of AVISynth.

The alpha serves as a starting point for us to discuss the encoder as it stands in this early version and how we can develop it to better serve the needs of the community. A list of known issues and contact information is available at DivX Labs.

The encoder also serves to introduce elements of the draft DivX 7 profile for H.264 HD video and this is something we aim to elaborate on further over the next week to get your feedback.

Last edited by DigitAl56K; 22nd August 2008 at 21:47.
DigitAl56K is offline   Reply With Quote
Old 22nd August 2008, 21:57   #2  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,688
This space reserved for a technical review of the encoder:

1. No adaptive quantization at all.
2. Uses 8x8dct, P-frame weighted prediction (at least the flag is set), and 4 refs in each list (according to the flags).
3. Chroma QP offset of +1.
4. --deblock -1:-1 used.
5. Appears to use spatial B-frame prediction only.
6. Uses Level 4.0, which sounds like a reasonable thing to standardize upon.
7. Uses an I-frame QP offset of -3 and a B-frame QP offset of +1.
8. Its B-frame decision seems to overly bias in favor of 2 B-frames.

This is just a preliminary glance at it, but overall the profile decided upon seems to be quite reasonable: enough bitrate for most sources without being too demanding of hardware, and not making any stupid restrictions like "no 8x8dct".

Actually quality comparisons (and speed) will come later.

Is there documentation on exactly what features are required in the DivX H.264 profile, by the way? I.e. which decisions here (such as spatial B-frames) are encoder decisions, and which are technical decisions in the spec itself. And what about the max of 4 seconds per gop--is that just an encoder limitation, or is there something in the spec about that?

Last edited by Dark Shikari; 22nd August 2008 at 22:25.
Dark Shikari is offline   Reply With Quote
Old 22nd August 2008, 22:12   #3  |  Link
DigitAl56K
Registered User
 
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
Is it really necessary to reserve space to ensure your comments appear immediately under the announcement? That's not really how single-threaded discussion works. Should I reserve space to reply to you? Also, although technical commentary is fine if it's constructive and of course comparisons will be made, a general request I'd make to all contributing is to please avoid turning this thread into DivX vs x264, that is not the goal (start a new thread if you so desire).

Thanks, and eager to hear your thoughts
DigitAl56K is offline   Reply With Quote
Old 22nd August 2008, 22:19   #4  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,688
Quote:
Originally Posted by DigitAl56K View Post
Is it really necessary to reserve space to ensure your comments appear immediately under the announcement? That's not really how single-threaded discussion works. Should I reserve space to reply to you? Also, although technical commentary is fine if it's constructive and of course comparisons will be made, a general request I'd make to all contributing is to please avoid turning this thread into DivX vs x264, that is not the goal (start a new thread if you so desire).

Thanks, and eager to hear your thoughts
I don't intend to do such a thing; the post will not be comparison (that will come later).
Dark Shikari is offline   Reply With Quote
Old 23rd August 2008, 01:31   #5  |  Link
DigitAl56K
Registered User
 
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
Quote:
Originally Posted by Dark Shikari View Post
This space reserved for a technical review of the encoder:

6. Uses Level 4.0, which sounds like a reasonable thing to standardize upon.
Yes, the draft profile is limited to levels 3, 3.1, 3.2, or 4.0.

Quote:
This is just a preliminary glance at it, but overall the profile decided upon seems to be quite reasonable: enough bitrate for most sources without being too demanding of hardware, and not making any stupid restrictions like "no 8x8dct".
There are very few restrictions in the profile that I think will be contentious.

Quote:
Is there documentation on exactly what features are required in the DivX H.264 profile, by the way?
Yes, I plan to cover them next week.

Quote:
And what about the max of 4 seconds per gop--is that just an encoder limitation, or is there something in the spec about that?
The draft profile has a limitation of 4 seconds for the IDR interval. The goal is to enable a nice trick-play experience on lower powered decoders. We had requests for even shorter intervals but after some rounds of testing where we measured the effects of various maximum periods on quality and bitrate we settled upon this as a good trade off. If you would also like to do some testing of your own that would be welcome
DigitAl56K is offline   Reply With Quote
Old 23rd August 2008, 02:27   #6  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
Quote:
Originally Posted by DigitAl56K View Post
The draft profile has a limitation of 4 seconds for the IDR interval. The goal is to enable a nice trick-play experience on lower powered decoders.
Amen, Bro'. And it's not just lower-end decoders. Having to decode 300 HD frames just for a frame seek is really silly.

I would have made it one second, although I can see that would be too short if targeting a small bitrate.

Last edited by Guest; 23rd August 2008 at 05:32.
Guest is offline   Reply With Quote
Old 23rd August 2008, 03:04   #7  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,688
I've finished a preliminary evaluation of the encoder; overall I'd say its roughly on par with the Mainconcept encoder (the cynic inside me says its a modified Mainconcept due to DivX's acquisition, but I'll trust you if you say it isn't...). This isn't competitive at all with x264, but a pretty damn good accomplishment for the first alpha release.

Last edited by Guest; 23rd August 2008 at 05:31.
Dark Shikari is offline   Reply With Quote
Old 23rd August 2008, 04:27   #8  |  Link
DigitAl56K
Registered User
 
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
Thanks Dark Shikari,

The encoder is based around the MC engine, but I'd like to stress again that we should really stop thinking about which pieces of code come from where because over time this becomes irrelevant - both teams work together now and the best of any previously separate works will become fused together in future software. In fact this is already happening as part of this project

In my opinion the main difference you'll see is that DivX will be more focused on working directly with the video community to create a high quality media experience and bridge the consumer electronics gap - which is why I'm working on Project Rémoulade!
DigitAl56K is offline   Reply With Quote
Old 23rd August 2008, 05:21   #9  |  Link
ChronoCross
Does it really matter?
 
ChronoCross's Avatar
 
Join Date: Jun 2004
Location: Chicago, IL
Posts: 1,542
Anyway I think 1 second is too little and would be detrimental to quality. It's just like making it too big might give the encoder more freedom quality wise but at the cost of seeking time. 4 is a decent compromise.

The Cli is easy to use and isn't as complex as Ateme's beta was when i did testing with that. Granted this encoder has few quality control options and is definitely an alpha but appears to be a good start. I can't really say much about the multithreading as I have a single core processor but the inclusion of direct AVISYNTH support is welcome.

Do you plan on including anything else in terms of input support? I see AVI is on the list but the known bugs state it's not currently working.

I don't have any interlaced sources but I wanted to ask if anyone had tried it out yet?

Last edited by Guest; 23rd August 2008 at 05:52. Reason: thread cleanup
ChronoCross is offline   Reply With Quote
Old 23rd August 2008, 04:50   #10  |  Link
DigitAl56K
Registered User
 
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
Just to add to the IDR interval discussion it is worth considering the value of a given maximum IDR to the trick-play experience. If you have a max. IDR of 4 seconds and during trick play you display each IDR for 0.5 seconds you have time scaling of 8:1. If you display each IDR for 0.25 seconds you have timeline compression for 16:1. But if your max IDR is every 1 second then even if you're displaying each trick frame for only 0.25 seconds that's only timeline compression of 4:1.

You would get max 30:1 compression with max IDR = 1 second due to the frame rate if you did not skip IDR's, and max 120:1 compression with max IDR = 4, but I'm not exactly sure how easy that would be to navigate!

Just posing an alternative way to look at it. Nothing in the draft profile prevents shorter IDR interval btw.

If anyone is interested, it's possible to simulate the experience using AVISynth's SelectEvery() filter as an IDR skip and using AssumeFPS() to set the rate that the display is updated.

Code:
IDRInterval = 4 # IDR max period
UpdateRate = 4  # IDR's shown per second during trickplay
MySource=AVISource("SomeFile.avi")
Return SelectEvery(MySource, int(MySource.FrameRate() * IDRInterval), 0).AssumeFPS(UpdateRate, 1)

Last edited by DigitAl56K; 23rd August 2008 at 05:02.
DigitAl56K is offline   Reply With Quote
Old 23rd August 2008, 22:21   #11  |  Link
bobololo
Registered User
 
Join Date: May 2003
Posts: 328
Quote:
Originally Posted by DigitAl56K View Post
Just to add to the IDR interval discussion it is worth considering the value of a given maximum IDR to the trick-play experience. If you have a max.

[...]
Speaking of IDR in your profile specification, please do me a favor and try to avoid the common mistake that assumes that a random access point is an IDR access unit. Indeed, while an IDR has actually the properties of an random access point, it also has many other charateristics like flushing the DPB which prevents the use of open GOP for instance (that can hurt encoder efficiency).

H.264 standard provides a syntax to signal random access point. It relies on the recovery_point SEI message that tell from which point in the bitstream you can start decoding and after how many frames, you're guaranteed to have recovered a proper video.
bobololo is offline   Reply With Quote
Old 24th August 2008, 03:39   #12  |  Link
komarovsky
Registered User
 
Join Date: Jul 2008
Posts: 15
Quote:
Our goal will rather be to create a spec that enables widespread interoperability of content across CE devices, ensuring that media created on certified encoder devices is guaranteed to play well on any certified decoder device.
very worthy goal many users are fine with knowing what settings to use to get compatibility with something, like the apple tv. They know about all of the options in the encoder and what they are compatible with... But then there are other people who just want to know "if I encode my video with this, it will be able to play on this. good."
komarovsky is offline   Reply With Quote
Old 24th August 2008, 14:58   #13  |  Link
squid_80
Registered User
 
Join Date: Dec 2004
Location: Melbourne, AU
Posts: 1,963
Is interlaced encoding (via -tff or -bff) meant to be working? I always get an error stating "Width, height or frame rate outside profile (interlace) specification" followed by the width x height@framerate of my input clip (which is kind of pointless; I already know what they are, but I don't what profile specifications I've supposedly exceeded). I've tried various resolution and framerate combos right down to 320x240x23.975fps.
squid_80 is offline   Reply With Quote
Old 24th August 2008, 17:19   #14  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
I've moved the IDR versus editing discussion here:

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

I'm interested in further discussion of it over there. Thank you.
Guest is offline   Reply With Quote
Old 23rd August 2008, 22:18   #15  |  Link
Ranguvar
Registered User
 
Ranguvar's Avatar
 
Join Date: Feb 2007
Location: ::1
Posts: 1,236
Please do let use know when you have a finalized or near-finalized spec for max encode settings (number of refs, b-frames, level, b-pyramid, etc.).

I believe a lot of us here, including me, are mostly just interested in creating DivX 7-compatible encodes with x264 Not dissing DivX, just a fact
Ranguvar is offline   Reply With Quote
Old 24th August 2008, 18:07   #16  |  Link
stax76
Registered User
 
Join Date: Jun 2002
Posts: 6,480
Are there plans for a PAR option?
stax76 is offline   Reply With Quote
Old 24th August 2008, 19:06   #17  |  Link
crypto
@DVBPortal
 
crypto's Avatar
 
Join Date: Feb 2004
Posts: 434
Yes, a PAR option would be great, although the same can be accomplished with a MP4 transformation matrix. I would also be happy to target the Main Profile. All other options are a well done, not to much, but powerful enough.
crypto is offline   Reply With Quote
Old 26th August 2008, 02:38   #18  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 962
could i ask what is happening regarding divx certification on games consoles, is it mandatory for them to update to each new version? As i'm hoping that the ps3 and 360 add divx 7 so that they will be able to play .mkv files as we currently have to demux them and put them in a .mp4 container which is a choir. Will the 360 and ps3 HAVE to allow divx7 file playback and therefore x264 .mkv files as there are loads of x264 videos on the internet, would be great to play them on consoles.
hajj_3 is offline   Reply With Quote
Old 26th August 2008, 19:45   #19  |  Link
DigitAl56K
Registered User
 
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
hajj_3: It's not mandatory, but we also hope to see these consoles playing the new format.
DigitAl56K is offline   Reply With Quote
Old 26th August 2008, 20:02   #20  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 962
doh Are you able to tell us if MS or Sony have discussed adding divx7 support to next update or if they are already adding .mkv support for h264? They added xvid surely .mkv would make sense too, they'd sell quite alot more consoles i reckon.
hajj_3 is offline   Reply With Quote
Reply

Tags
cli, divx, encoder, h.264, tutorial

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:38.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.