[x264-devel] AVC Intra encoder based on libx264

[Jason Garrett-Glaser]

On Wed, Feb 1, 2012 at 12:47 AM, Joseph Artsimovich <joseph at mirriad.com> wrote:
> On 31/01/2012 18:51, Jason Garrett-Glaser wrote:
>>
>> On Tue, Jan 31, 2012 at 2:00 AM, Joseph Artsimovich<joseph at mirriad.com>
>>  wrote:
>>>
>>> On 31/01/2012 00:42, Jason Garrett-Glaser wrote:
>>>>
>>>> ...
>>>>
>>>> I've written my own full
>>>> implementation, which can be found on my github
>>>> (https://github.com/DarkShikari/x264-devel).
>>>>
>>>> Testing welcome.
>>>
>>> Will do.  One thing I noticed being missing are custom scaling matrices
>>> and
>>> i_chroma_qp_offset = 3
>>
>> Where in the spec does it list anything about those parameters?
>
> In SMPTE 2027:2011, nowere. Maybe in Panasonic's confidential spec, but I
> don't have access to that. Avid decoder seems to have those hardcoded
> though. Without them, the colours are off in Avid and macroblock boundaries
> are clearly visible. I extracted those from h264 streams encoded with
> Panasonic's encoder.
>
>
>>> * Need to get rid of a SEI with x264 version info.
>>
>> Where in the spec does it prohibit this?  In fact, the spec explicitly
>> states that arbitrary SEIs are okay.
>
> The spec doesn't prohibit it. Avid insists on seeing exactly two SEIs
> though.

But the spec says exactly 10 or exactly 18!  How do you know it
insists on that; did you disassemble the decoder?

> If you want my personal opinion, SMPTE 2027:2011 is a joke. Even Panasonic's
> own encoder violates it at one point. Specifically, the spec says "Each
> individual SEI message that may be present shall be a multiple of 512
> bytes.", while the first SEI produced by Panasonic's encoder is shorter than
> that. In fact, if they didn't put a filler NAL in front of it and let the
> SEI start where the filler starts, it would have been exactly 512 bytes.
>
>
>>> * Frame size is wrong. For 50i, you generate frames of 546000 bytes. It
>>> should instead be 559104 + 512*19 =  568832. See my code in
>>> avci_encoder.cpp
>>> for more details.
>>
>> 1.  As far as I can tell from the spec, the 512 SEI bytes are
>> *included* in the frame size.  The frame size should be 559,104.
>
> SMPTE 2027:2011 doesn't say if it's included or not, so it's logical to
> assume it is. However, Panasonic's encoder produces frames of 568832 bytes,
> which indicates it's not.
>
>
>> 2.  The code requests a frame size of 559,104, not 546,000.  If you
>> can show me a case where it generates the wrong frame size, please do
>> so, but I tested a number of resolution/fps combinations and they
>> worked correctly.
>
> Sorry, got it wrong. Your frames are indeed 559104 bytes. That's still not
> what Panasonic's (and all other) encoders are producing.

This is absurd.  We can't commit support for a nonexistent video
format defined only as "what a particular decoder happens to do",
doubly so when different decoders do different things.  If Panasonic
cared about people adopting their format, they would release a spec
for it.

Plus, if you edit video, you shouldn't be using lossy formats to begin
with.  HuffYUV does the job fine.

Jason