Help - Search - Members - Calendar
Full Version: h264 reference encoder with AviSynth input!
Hydrogenaudio Forums > Digital Audio/Video > Digital A/V News
JohnV
I've got via an anonymous developer a special modified build of the reference jm 7.3 commandline h264 encoder, which takes an .avs yv12 (DVD-colorspace) input and of course outputs .avi.

I believe Roberto will be hosting the binary of this in Brazil soon.

Usage of this encoder is simple:
CODE
lencod.exe -p InputFile = "video.avs" -p OutputFile = "video.avi"


In encoder.cfg file you can see that by default it retains constant 24 quantizer. By changing this file you can adjust encoder options.

The unmodified build only accpets some raw yuv420 file, so this is a big improvement.
You can do the dvd2avi and avs script build phase in Gordian Knot and then feed the .avs to this commanline encoder.
rjamorim
QUOTE(JohnV @ Nov 25 2003, 09:43 AM)
I believe Roberto will be hosting this binary in Brazil soon.


http://pessoal.onda.com.br/rjamorim/lencod...jm73special.zip
JohnV
Ok, the encoder is still slow. Unfortunately the package doesn't include any decoder.
I happen to have a working h264 dshow decoder in testing, but it's strictly forbidden to share it to anybody.

I tested the VSS h264 beta decoder which is publicly available, but seems it didn't work. Somebody might want to test with their latest beta decoder though if it works.
LordofStars
Perhaps you might be able to share the information about who created the working decoder so we might look forward to and in the proper channels for it.
JohnV
Well.. one thing in the encoder. It currently produces fourcc's a264 and A264 (Edit. it should now produce h264 H264).
Hex edit these to h264 and H264 respectively, and it should work with Mplayer.
http://www.mplayerhq.hu/MPlayer/releases/w...gui-preview.zip

The quality of Mplayer h264 playback totally sucks for some reason. My commercial quality decoder filter gives *hugely* better picture.

Anyway, here are few short demo streams:
http://www.hydrogenaudio.org/extra/H264_q2...q24_600kbps.avi (Reso: 720 x 304)
http://www.hydrogenaudio.org/extra/H264_q2...24_1000kbps.avi (Reso: 704 x 288)

These are both made with constant quantizer 24. The first clip just happens to be about 600kbps and the second about 1000kbps. So these are not really targeted to be these bitrates..rather have constant quality.
idioteque
QUOTE(JohnV @ Nov 25 2003, 10:12 AM)
The quality of Mplayer h264 playback totally sucks for some reason. My commercial quality decoder filter gives *hugely* better picture.

It's possible that MPlayer may be short-cutting or skipping the in-loop deblocking filter to get faster decoding.
danchr
QUOTE(JohnV @ Nov 25 2003, 07:12 PM)
The quality of Mplayer h264 playback totally sucks for some reason. My commercial quality decoder filter gives *hugely* better picture.

I believe the libavcodec implementation of H.264 doesn't support all the techniques used in it, yet. I'd suggest you contact the FFmpeg developers and hand them a sample in the hope they're willing to give it a try smile.gif
bond
JohnV
can you post some screenshots to show the quality plz (perhaps some upsized ones if possible smile.gif )?
JohnV
QUOTE(bond @ Nov 25 2003, 09:09 PM)
JohnV
can you post some screenshots to show the quality plz (perhaps some upsized ones if possible smile.gif )?

I will, if I get the permission, but at the moment I can't. But believe me, the difference is truely *significant*. Considering for example the 600kbps demo stream, the difference is that Mplayer picture has very bad artifacting, while this commercial class dshow decoder's picture is truely great, and I'd probably rate it at least 1000kbps divx/xvid if it was MPEG4.

Also the 1000kbps H264 looks very blocky and bad quality for this bitrate with MPlayer, but it's very nice with this better decoder.
Bonzi
JohnV, probably you are encoding with inloop filtering which is why it looks better on the commercial decoder than mplayer. Mplayer does not support inloop filtering so it can look really bad if it is used. They should look about the same though if inloop filtering is turned off because the decoder in mplayer I think is largely based on reference code. BTW, this makes me very very happy since all of my testing with h.264 has involved converting to yuy2 and then encoding this. I am a little concerned though about how this is stored in avi though since I don't think there is any standard way to do this, all the other encoders that I know only output the raw h.264 bitstream except hdot264 and vss. So definitely people don't archive stuff to this codec but it is definitely free game to do lots of testing!
JohnV
QUOTE(Bonzi @ Nov 26 2003, 03:59 AM)
JohnV, probably you are encoding with inloop filtering which is why it looks better on the commercial decoder than mplayer.  Mplayer does not support inloop filtering so it can look really bad if it is used.

Indeed, yeah.
I had this in encoder.cfg
CODE

LoopFilterDisable  = 0  # Disable loop filter in slice header (0=Filter, 1=No Filter)


I'll soon encode something with In-Loop Filter disabled and see what is the difference then. Well, it's said here, that in-loop filtering reduces bitrate 5-10%, so at least file size will increase a little with constant quantizer.
JohnV
QUOTE(Bonzi @ Nov 26 2003, 03:59 AM)
So definitely people don't archive stuff to this codec but it is definitely free game to do lots of testing!

I don't think anybody archives anything with this. With 3Ghz P4 encoding about 2 hour movie takes about 15 days, if I calculated correctly. Though maybe changing some of the encoder options makes it faster. Currently it takes about 7-8 sec per frame...

I was thinking maybe someone like Frank Klemm who has experience on encoder speed optimizations and now says is infact more interested in video, would like to start tweaking a h264 encoder. wink.gif
I'm at least going to email him. smile.gif
Bonzi
QUOTE
I don't think anybody archives anything with this. With 3Ghz P4 encoding about 2 hour movie takes about 15 days, if I calculated correctly. Though maybe changing some of the encoder options makes it faster. Currently it takes about 7-8 sec per frame...

Lol, well, you never know but I would hope that nobody would try to. Certainly it would be great if frank or anyone else could make a fast high quality encoder or even tweak this one so it is faster. But, personally I hope someone will write an encoder from scratch. Clearly, this would be no small task. The interest in h.264 is building quickly, there are many people including some very talented developers that I know of who are interested. I even heard that certain persons already have been developing an encoder which now is approximately the same speed as VSS h.264 implementation but much better quality of course. I haven't seen it yet so we will just see what happens...
JohnV
I just contacted ffdshow developer Milan Cutka, and if everything goes alright, we should see ffdshow support for h264 avis pretty soon. smile.gif
He had problems creating streams working with libavcodec using hdot264 and vssh264, but hopefully this will work. At least the files work with Mplayer which should use libavcodec for h264 decoding.
I'm also soon finishing an encode with in-loop filtering disabled. I'll upload it also.

Someone might wonder why b-frames don't work. [edit] see my next message.
slav!x
Hi, because not eveybody have 3ghz pc , this config should be pretty fast

CODE

# New Input File Format is as follows
# <ParameterName> = <ParameterValue> # Comment
#
# See configfile.h for a list of supported ParameterNames


##########################################################################################
# Files
##########################################################################################
InputFile             = ""     # Input sequence, YUV 4:2:0
InputHeaderLength     = 0      # If the inputfile has a header, state it's length in byte here
FramesToBeEncoded     = 299    # Number of frames to be coded
SourceWidth           = 352    # Image width in Pels, must be multiple of 16
SourceHeight          = 288    # Image height in Pels, must be multiple of 16
TraceFile             = ""
ReconFile             = ""
OutputFile            = "res.avi"


##########################################################################################
# Encoder Control
##########################################################################################

IntraPeriod           = 300 # Period of I-Frames (0=only first)
QPFirstFrame          = 24  # Quant. param for first frame (intra) (0-51)
QPRemainingFrame      = 24  # Quant. param for remaining frames (0-51)
FrameSkip             =  0  # Number of frames to be skipped in input (e.g 2 will code every third frame)
UseHadamard           =  1  # Hadamard transform (0=not used, 1=used)
SearchRange           =  8  # Max search range
NumberReferenceFrames =  1  # Number of previous frames used for inter motion search (1-5)
MbLineIntraUpdate     =  0  # Error robustness(extra intra macro block updates)(0=off, N: One GOB every N frames are intra coded)
RandomIntraMBRefresh  =  0  # Forced intra MBs per picture
InterSearch16x16      =  1  # Inter block search 16x16 (0=disable, 1=enable)
InterSearch16x8       =  1  # Inter block search 16x8  (0=disable, 1=enable)
InterSearch8x16       =  1  # Inter block search  8x16 (0=disable, 1=enable)
InterSearch8x8        =  1  # Inter block search  8x8  (0=disable, 1=enable)
InterSearch8x4        =  1  # Inter block search  8x4  (0=disable, 1=enable)
InterSearch4x8        =  0  # Inter block search  4x8  (0=disable, 1=enable)
InterSearch4x4        =  0  # Inter block search  4x4  (0=disable, 1=enable)

##########################################################################################
# Error Resilience / Slices
##########################################################################################

SliceMode             =  0   # Slice mode (0=off 1=fixed #mb in slice 2=fixed #bytes in slice 3=use callback 4=FMO)
SliceArgument         = 50   # Slice argument (Arguments to modes 1 and 2 above)
num_slice_groups_minus1 = 0  # Number of Slice Groups Minus 1, 0 == no FMO, 1 == two slice groups, etc.
FmoType               =  0   # 0:  Slice interleave, 1: Scatter, 2: fully flexible, data in FmoConfigFileName,
                            # 3:  rectangle defined by FmoTopLeftMB and FmoBottomRightMB,
                            #     (only one rectangular slice group supported currently, i.e. FmoNumSliceGroups = 1)
                            # 4-6:evolving slice groups, FmoNumSliceGroups = 1, the evolving method is defined by
                            #     FmoChangeDirection and FmoChangeRate.
FmoTopLeftMB          = 24   # the top left MB of the rectangular shape for slice groups, MB counted in raster scan order
FmoBottomRightMB      = 74   # the bottom right MB of the rectangular shape for slice groups
FmoChangeDirection    = 1    # 0: box-out clockwise, raster scan or wipe right,
                            # 1: box-out counter clockwise, reverse raster scan or wipe left
FmoChangeRate         = 4    # SLICE_GROUP_CHANGE_RATE minus 1

FmoConfigFileName     = "fmoconf.cfg"   # not yet used, for future fully flexible MBAmaps

UseRedundantSlice     = 0    # 0: not used, 1: one redundant slice used for each slice (other modes not supported yet)

##########################################################################################
# B Frames
##########################################################################################

NumberBFrames         =  0  # Number of B frames inserted (0=not used)  
QPBPicture            =  30 # Quant. param for B frames (0-51)
DirectModeType        =  0  # Direct Mode Type (0:Temporal 1:Spatial)

##########################################################################################
# SP Frames
##########################################################################################

SPPicturePeriodicity  =  0  # SP-Picture Periodicity (0=not used)
QPSPPicture           = 28  # Quant. param of SP-Pictures for Prediction Error (0-51)
QPSP2Picture          = 27  # Quant. param of SP-Pictures for Predicted Blocks (0-51)


##########################################################################################
# Output Control, NALs
##########################################################################################

SymbolMode             =  0  # Symbol mode (Entropy coding method: 0=UVLC, 1=CABAC)
OutFileMode            =  0  # Output file mode, 0:Annex B, 1:RTP
PartitionMode          =  0  # Partition Mode, 0: no DP, 1: 3 Partitions per Slice

##########################################################################################
# Search Range Restriction / RD Optimization
##########################################################################################

RestrictSearchRange  =  0  # restriction for (0: blocks and ref, 1: ref, 2: no restrictions)
RDOptimization       =  0  # rd-optimized mode decision (0:off, 1:on, 2: with losses)
LossRateA            = 10  # expected packet loss rate of the channel for the first partition, only valid if RDOptimization = 2
LossRateB            =  0  # expected packet loss rate of the channel for the second partition, only valid if RDOptimization = 2
LossRateC            =  0  # expected packet loss rate of the channel for the third partition, only valid if RDOptimization = 2
NumberOfDecoders     = 30  # Numbers of decoders used to simulate the channel, only valid if RDOptimization = 2
RestrictRefFrames    =  0  # Doesnt allow reference to areas that have been intra updated in a later frame.

##########################################################################################
# Additional Stuff
#########################################################################################

UseConstrainedIntraPred  =  0  # If 1, Inter pixels are not used for Intra macroblock prediction.
LastFrameNumber          =  0  # Last frame number that have to be coded (0: no effect)
ChangeQPP                = 16  # QP (P-frame) for second part of sequence (0-51)
ChangeQPB                = 18  # QP (B-frame) for second part of sequence (0-51)
ChangeQPStart            =  0  # Frame no. for second part of sequence (0: no second part)
AdditionalReferenceFrame =  0  # Additional ref. frame to check (news_a: 16; news_b,c: 24)

NumberofLeakyBuckets     =  8                      # Number of Leaky Bucket values
LeakyBucketRateFile      =  ""  # File from which encoder derives rate values
LeakyBucketParamFile     =  "" # File where encoder stores leakybucketparams

InterlaceCodingOption    =  0  # (0: frame coding, 1: adaptive frame/field coding, 2:field coding, 3:mb adaptive f/f)

NumberFramesInEnhancementLayerSubSequence  = 0  # number of frames in the Enhanced Scalability Layer(0: no Enhanced Layer)
NumberOfFrameInSecondIGOP                  = 0  # Number of frames to be coded in the second IGOP

WeightedPrediction    = 0   # P picture Weighted Prediction (0=off, 1=explicit mode)  
WeightedBiprediction  = 0   # B picture Weighted Prediciton (0=off, 1=explicit mode,  2=implicit mode)  
StoredBPictures    = 0   # Stored B pictures (0=off, 1=on)

SparePictureOption = 0         # (0: no spare picture info, 1: spare picture available)
SparePictureDetectionThr = 6   # Threshold for spare reference pictures detection
SparePicturePercentageThr = 92    # Threshold for the spare macroblock percentage

PicOrderCntType = 0       # (0: POC mode 0, 1: POC mode 1, 2: POC mode 2)

##########################################################################################
# Loop filter parameters
##########################################################################################
LoopFilterParametersFlag = 0  # Configure loop filter (0=parameter below ingored, 1=parameters sent)
LoopFilterDisable        = 0  # Disable loop filter in slice header (0=Filter, 1=No Filter)
LoopFilterAlphaC0Offset  = -2  # Alpha & C0 offset div. 2, {-6, -5, ... 0, +1, .. +6}
LoopFilterBetaOffset     = -1  # Beta offset div. 2, {-6, -5, ... 0, +1, .. +6}



##########################################################################################
# CABAC context initialization
##########################################################################################
ContextInitMethod   = 0   # Context init (0: fixed, 1: adaptive)
FixedModelNumber    = 0   # model number for fixed decision for inter slices ( 0, 1, or 2 )


btw, setting RDOptimization = 1 , can decrease bitrate by few percents, and slow down at least twice ph34r.gif
JohnV
QUOTE(JohnV @ Nov 26 2003, 03:47 PM)
Someone might wonder why b-frames don't work. This is most probably because the encoder currently only supports baseline h264 profile, which means no b-frames.

Umm, according to new info I got this was wrong information. The encoder should be able to encode b-frames as well. For example encoding with 1 consequtive b-frame, edit the encoder.cfg values:
CODE

FrameSkip             =  1  # Number of frames to be skipped in input (e.g 2 will code every third frame)
NumberBFrames         =  1  # Number of B frames inserted (0=not used)

The skip parameter should be applicable for i/p frames only and "skipped" frame will be encoded as b-frame.
This is not 100% confirmed information, and I haven't yet tested this.
Also I don't know if any decoder supports b-frames yet. My dshow decoder doesn't support those yet.

ANyway, this is something which should be tested..
idioteque
QUOTE(JohnV @ Nov 26 2003, 09:51 AM)
Also I don't know if any decoder supports b-frames yet. My dshow decoder doesn't support those yet.


The JM7.3 decoder supports B Frames. B Frames have been supported in the JM encoder and decoder at least since 6.1d, if not longer. (6.1d is as far back as I've tested)

I'm curious if anyone has ever gotten the interlace options to work:

CODE
InterlaceCodingOption    =  0  # (0: frame coding, 1: adaptive frame/field coding, 2:field coding, 3:mb adaptive f/f)
JohnV
QUOTE(idioteque @ Nov 26 2003, 07:56 PM)
The JM7.3 decoder supports B Frames. B Frames have been supported in the JM encoder and decoder at least since 6.1d, if not longer. (6.1d is as far back as I've tested)

Right, I was more referring to some more "useful" decoders like libavcodec, which are used by players or dshow.
slav!x
JohnV can you test, if that your mystical cool.gif decoder supports cabac, it's one of best h264 features
JohnV
QUOTE(slav!x @ Nov 26 2003, 08:43 PM)
JohnV can you test, if that your mystical  cool.gif decoder supports cabac, it's one of best h264 features

Well.. it's a decoder in development. My version doesn't support h264 main profile features quite yet.
JohnV
QUOTE
This package contains the official H.264 / AVC Reference Software
encoder (JM 7.5b) with some quick'n'dirty hacks in the input/output
modules so that it can use AVI files as input and output.

The input AVI file must be in YUV 420 format (FOURCC = IYUV, I420 or YV12).

For the output, the hack is very basic, it considers that each frame is
contained in a single slice and therefore embedded in a single nal unit.
This latter is put in a AVI sample.

The parameters nal units are preppended to each IDR frame and sent to the
AVI file in the same sample.

The FOURCC used for the output AVI is A264, since it is what we're using
for our decoder. Feel free to change it to whatever you want.

Please consider this modification as a very quick prototyping tweak and
should not be considered as a reference for carrying H.264/AVC stream in AVI
files. And of course, you're welcome to improve this stuff.


bobololo@h-cube.net

Source download here.
plonk420
how does it compare to VP6? i've been mildly impressed with VP6 to say the least, not to mention On2 had some glowing things to say about their encoder on their site...

"In our internal testing, VP6 beat H.264, Windows Media 9 and Real Networks 9 in PSNR comparisons using the standard set of MPEG-2 test clips. The codec looks better than Windows Media 9, shows far fewer motion artifacts than Windows Media 9, and maintains more texture and detail than Real 9 or H.264."
JohnV
QUOTE(plonk420 @ Nov 30 2003, 02:50 AM)
how does it compare to VP6? i've been mildly impressed with VP6 to say the least, not to mention On2 had some glowing things to say about their encoder on their site...

"In our internal testing, VP6 beat H.264, Windows Media 9 and Real Networks 9 in PSNR comparisons using the standard set of MPEG-2 test clips. The codec looks better than Windows Media 9, shows far fewer motion artifacts than Windows Media 9, and maintains more texture and detail than Real 9 or H.264."

Umm.. first of all, I don't think they have had any really commercial quality h264 codec, mainly because those are just beginning to develope. So to say at this point already something about "h264-quality" is pretty much the same if someone talked about "mp3 quality" when Xing-old was new...
Further more PSNR comparison is pretty much unreliable..
plonk420
i'm posting a few tests i did (didn't mess too much with the default settings, altho i finally figured out how to do multipass vbr) to alt.binaries.pictures.leek, if any of you are into newsgroups... vp6+aac/aac-he in the MKV container

i was pretty skeptical when i first downloaded it, but was pretty impressed as it put out better results than i ever got with XVID/Divx5 (or what little i knew of those technologies)
JohnV
I got permission to post some pics from the commercial h264 decoder output, so I will do so soon.

Also Milan Cutka (ffdshow developer) emailed me that he got h264 decoding working in ffdshow. smile.gif
JohnV
QUOTE(plonk420 @ Nov 30 2003, 04:13 AM)
i was pretty skeptical when i first downloaded it, but was pretty impressed as it put out better results than i ever got with XVID/Divx5 (or what little i knew of those technologies)

Well, according to On2 tech, their 2-pass encoding is a bit broken at the moment, and they are gonna release an update. I'll test it when they have fixed their 2-pass mode.
Bonzi
Lol, I expect future vp6 releases to be better than the first release. Their whole vfw is completely b0rked, not only the 2-pass but also keyframe intervals and I wouldn't be surprised if there is something weird going on with vbr in general since quality mode doesn't seem to work well either. Anyway, back to h.264, I wouldn't be surprised at all if the reference encoder gives pretty nice quality. Generally, it is the case that mpeg reference encoders will output reasonably good quality with little to no regard for speed. Which makes sense, I mean you want to see what the codec is really capable of right? smile.gif Speed can come later. Good to see that milan got h.264 working in ffdshow smile.gif if only I could build the thing sad.gif. /me runs off to bug athos for new ffdshow compile wink.gif
JohnV
QUOTE(Bonzi @ Nov 30 2003, 09:19 AM)
Anyway, back to h.264, I wouldn't be surprised at all if the reference encoder gives pretty nice quality.  Generally, it is the case that mpeg reference encoders will output reasonably good quality with little to no regard for speed.  Which makes sense, I mean you want to see what the codec is really capable of right? smile.gif Speed can come later. 

Well, actually I think this is not actually the MPEG h264 "reference encoder", this is reference as "ISO reference source".
Latexxx
What is that cabac feature about which somebody asked earlier?
rjamorim
CABAC is an arithmetic coding scheme used in the main profile. CAVLC is a VLC coding scheme used in the baseline profile.
Latexxx
QUOTE(rjamorim @ Dec 1 2003, 10:18 AM)
CABAC is an arithmetic coding scheme used in the main profile. CAVLC is a VLC coding scheme used in the baseline profile.

Are there any easy to understand descriptions of these methods available in the Internet? And what are the other new inventions in h.264 and are there any good general information sites about h.264? Don't bother to point me to some technical oriented reference documents because I don't understand them. tongue.gif
idioteque
QUOTE(Latexxx @ Dec 1 2003, 12:04 PM)
Are there any easy to understand descriptions of these methods available in the Internet...


These documents may help:
From Thomas Wiegand's Publication page.

Overview of the H.264/AVC Video Coding Standard [pdf]

Context-Based Adaptive Binary Arithmetic Coding in the H.264/AVC Video Compression Standard [pdf]
Tommy Carrot
I still don't get what's the reason behind the 2 profiles, it just makes everything more complex. Baseline profile is completely unnecessary, since they decided it wont be free (as they originally intended).
Latexxx
Thanks for those links.

JohnV, when are you going to upload those samples you promised? I'd like to see some real quality of this thing instead of watching those video clips using mplayer.
i4004
one more vote for seeing some screenshots that would increase folks' interest in this...

also,if inloop processing is disabled (in decoder and encoder) does this mean they both run lot faster,or this inloop thing si really what differentiates "normal" mpeg's from h264..(let me tell ya,i hate blur... biggrin.gif )

would milan be able to include this (encoder) into ffvfw if he already put decoding support into ffdshow?
how about YUY2 support for capturing people...?

lot of wishes anyhow..heh...

vp6?
very poor stuff....
[ http://i4004.0catch.com/ffvfw-mpeg1-vp6.htm ]
use rv9 instead....
Latexxx
QUOTE(i4004 @ Dec 7 2003, 01:16 PM)

how about YUY2 support for capturing people...?

It might work if you have a 50 GHz processor.
wkwai
QUOTE(Latexxx @ Dec 7 2003, 05:09 AM)
how about YUY2 support for capturing people...?

What is YUY2 ? blink.gif
Latexxx
QUOTE(wkwai @ Dec 7 2003, 03:21 PM)
QUOTE(Latexxx @ Dec 7 2003, 05:09 AM)
how about YUY2 support for capturing people...?

What is YUY2 ? blink.gif

It's a colour format like RGB, CMYK and YV12.
i4004
QUOTE(Latexxx @ Dec 7 2003, 05:09 AM)
QUOTE(i4004 @ Dec 7 2003, 01:16 PM)

how about YUY2 support for capturing people...?

It might work if you have a 50 GHz processor.

latex,you misunderstood;i didn't ment h264 as a capturing codec (i'll never use YV12 "lossless" capture codec's,let alone the end codec's such as mpeg's) but YUY2 support in an encoder (so encoder accepts YUY2 avi's....at the start of this tthread it says it's YV12 only....and that's cheap and dvd-ripish... biggrin.gif )

i imagine this shouldn't be hard thing to do;avs already has working "->yv12" convertors etc.
(although that also means that one can feed the encoder with avs script which has "converttoyv12" at the end..heh)
idioteque
QUOTE(i4004 @ Dec 7 2003, 01:27 PM)
latex,you misunderstood;i didn't ment h264 as a capturing codec (i'll never use YV12 "lossless" capture codec's,let alone the end codec's such as mpeg's) but YUY2 support in an encoder (so encoder accepts YUY2 avi's....at the start of this tthread it says it's YV12 only....and that's cheap and dvd-ripish... biggrin.gif  )



h.264 only supports 4:2:0, which for its intended applications makes perfect sense.
Mike Giacomelli
QUOTE(idioteque @ Dec 7 2003, 03:39 PM)
QUOTE(i4004 @ Dec 7 2003, 01:27 PM)

latex,you misunderstood;i didn't ment h264 as a capturing codec (i'll never use YV12 "lossless" capture codec's,let alone the end codec's such as mpeg's) but YUY2 support in an encoder (so encoder accepts YUY2 avi's....at the start of this tthread it says it's YV12 only....and that's cheap and dvd-ripish... biggrin.gif  )



h.264 only supports 4:2:0, which for its intended applications makes perfect sense.

What do you mean by 4:2:0, the aspect ratio? blink.gif
rjamorim
QUOTE(Mike Giacomelli @ Dec 7 2003, 10:17 PM)
What do you mean by 4:2:0, the aspect ratio? blink.gif

Sampling.
i4004
idioteque,i know mpeg's use 4:2:0 (all of them),but one can feed RGB or YUY2 to almost any mpeg1,2,4 encoder....

i hope it's clear now....intended application of a codec is a video,and not YV12 only sources....

nevermind this;as i said avs can convert to yv12 so it's not a big problem....
Diocletian
QUOTE(Mike Giacomelli @ Dec 8 2003, 01:17 AM)
QUOTE(idioteque @ Dec 7 2003, 03:39 PM)
QUOTE(i4004 @ Dec 7 2003, 01:27 PM)

latex,you misunderstood;i didn't ment h264 as a capturing codec (i'll never use YV12 "lossless" capture codec's,let alone the end codec's such as mpeg's) but YUY2 support in an encoder (so encoder accepts YUY2 avi's....at the start of this tthread it says it's YV12 only....and that's cheap and dvd-ripish... biggrin.gif  )



h.264 only supports 4:2:0, which for its intended applications makes perfect sense.

What do you mean by 4:2:0, the aspect ratio? blink.gif

Color subsampling

4:4:4 => horz. 1:1, vertical: 1:1 (8 bit per component end up with 24 bit per pixel)
4:2:2 => horz. 1:2, vertical: 1:1 (8 bit per component end up with 16 bit per pixel)
4:1:1 => horz. 1:4, vertical: 1:1 (8 bit per component end up with 12 bit per pixel)
4:2:0 => horz. 1:2, vertical: 1:2 (8 bit per component end up with 12 bit per pixel)
4:1:0 => horz. 1:4, vertical: 1:2 (8 bit per component end up with 10 bit per pixel)
Latexxx
Sorry to bring this thread out of death, but somedy is looking for the sources of this program to integrate it with jm90 at http://forum.doom9.org/showthread.php?s=&threadid=84305 . If anybody happens to have a copy of the sources anymore, it would be nice to help him/her.
rjamorim
Dcoder used to send me these binaries to be hosted at RareWares. Maybe he still has the sources.
p0l1m0rph1c
Oh, damnit. I don't have much availability to do that now. Anyway, when i can (maybe next weekend), i'll put jm90 binary + sources online, for those who want it.

EDIT: Hmm, i see the guy already has sources...oh well.
rjamorim
Hello.

I uploaded jm90 binaries to RareWares, kindly provided by Dcoder/p0l1m0rph1c.

I did some limited testing and it worked well. No guarantees though...
http://pessoal.onda.com.br/rjamorim/lencod_jm90-avi.zip

Best regards;

Roberto.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.