[x264-devel] AVC Intra encoder based on libx264

[Joseph Artsimovich]

On 01/02/2012 18:27, Jason Garrett-Glaser wrote:
> 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?
It says to leave space for that many. Anyway, it doesn't matter what it 
says. If real world decoders impose more restrictions than the spec, we 
have to follow.
It's easy to verify Avid's insistence on seeing exactly 2 SEIs: just 
zero-out one or both of them in a file it didn't have problems with, and 
suddenly it can't render the modified frames. Put a couple of arbitrary 
ones in their place - works fine.

>> 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.
No problem. We'll just keep using our command-line tool linked against a 
patched version of libx264.


> Plus, if you edit video, you shouldn't be using lossy formats to begin
> with.  HuffYUV does the job fine.
>
> Jason
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel


-- 
Joseph Artsimovich
Senior C++ Applications Developer
MirriAd Ltd