Jason Garrett-Glaser | 1 Apr 07:29 2012

Re: [PATCH] Add Level 5.2 support

On Sat, Mar 31, 2012 at 5:55 AM, Harfe Leier <astrataro <at> gmail.com> wrote:
> Follow T-REC-H.264-201106-S!!PDF-E.

Locally committed.

Jason
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

aviad rozenhek | 4 Apr 19:26 2012
Picon

Re: x264 Development Newsletter: Vol. 28


On Wed, Mar 7, 2012 at 05:19, Jason Garrett-Glaser <jason <at> x264.com> wrote:
This is the twenty-eighth x264 development newsletter. This is a
[..]
 
Upcoming:

Google Code-In is done, but a bunch of NEON assembly still needs review.

x262 is under development: a best-in-class MPEG-2 encoder built using
the x264 framework.  It works well enough to be vaguely usable now,
but is still highly experimental and needs more work -- developers
welcome!

Jason Garrett-Glaser

The x264 Team

<shamelss_flattery>
Dear developers of the best h264 codec in the world,
</shamelss_flattery>

its been a month since your last x264 development newsletter, the mailing list hardly contains information regarding future and current developments anymore ... :-(
would you entertain a few questions to spark discussion?

1. is x264 likely to (significantly) improve in terms of bits/quality efficiency?

2. is x264 likely to get (noticeably) faster for existing intel desktop processors like Bloomfield or Lynnfield?

3. adaptive bitrate has become very important, and with it, synchronized GOPs across encodes in different bitrates.
this is currently supported in x264 by using fixed sized GOPs. what are your thoughts regarding a more content-aware approach?

4. what are you thoughts regarding the upcoming HEVC/H265 standard, and will there be an x265?

Regards,
A.

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Jason Garrett-Glaser | 4 Apr 19:30 2012

Re: x264 Development Newsletter: Vol. 28

On Wed, Apr 4, 2012 at 10:26 AM, aviad rozenhek <aviadr1 <at> gmail.com> wrote:
>
> On Wed, Mar 7, 2012 at 05:19, Jason Garrett-Glaser <jason <at> x264.com> wrote:
>>
>> This is the twenty-eighth x264 development newsletter. This is a
>> [..]
>
>
>>
>> Upcoming:
>>
>> Google Code-In is done, but a bunch of NEON assembly still needs review.
>>
>> x262 is under development: a best-in-class MPEG-2 encoder built using
>> the x264 framework.  It works well enough to be vaguely usable now,
>> but is still highly experimental and needs more work -- developers
>> welcome!
>>
>> Jason Garrett-Glaser
>>
>> The x264 Team
>
>
> <shamelss_flattery>
> Dear developers of the best h264 codec in the world,
> </shamelss_flattery>
>
> its been a month since your last x264 development newsletter, the mailing
> list hardly contains information regarding future and current developments
> anymore ... :-(

That's because discussion has pretty much always been on #x264dev IRC, not here.

> would you entertain a few questions to spark discussion?
>
> 1. is x264 likely to (significantly) improve in terms of bits/quality
> efficiency?

If someone comes up with good enough new ideas!  But it's a lot harder
than it used to be and a lot of the improvements in the pipeline are
not so general-purpose (e.g. OpenCL lookahead).

> 2. is x264 likely to get (noticeably) faster for existing intel desktop
> processors like Bloomfield or Lynnfield?

Unlikely, but I said that before Loren optimized trellis too.

> 3. adaptive bitrate has become very important, and with it, synchronized
> GOPs across encodes in different bitrates.
> this is currently supported in x264 by using fixed sized GOPs. what are your
> thoughts regarding a more content-aware approach?

x264 supports this with adaptive GOP too; all encodes with the same
lookahead settings and the same source will give the same distribution
of frame types, no matter what the bitrate.

> 4. what are you thoughts regarding the upcoming HEVC/H265 standard, and will
> there be an x265?

I don't know, are you offering to write one? =P

Jason
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

aviad rozenhek | 5 Apr 13:24 2012
Picon

Re: x264 Development Newsletter: Vol. 28

On Wed, Apr 4, 2012 at 20:30, Jason Garrett-Glaser <jason <at> x264.com> wrote:
> its been a month since your last x264 development newsletter, the mailing
> list hardly contains information regarding future and current developments
> anymore ... :-(

That's because discussion has pretty much always been on #x264dev IRC, not here.

> would you entertain a few questions to spark discussion?
>
> 1. is x264 likely to (significantly) improve in terms of bits/quality
> efficiency?

If someone comes up with good enough new ideas!  But it's a lot harder
than it used to be and a lot of the improvements in the pipeline are
not so general-purpose (e.g. OpenCL lookahead).

> 2. is x264 likely to get (noticeably) faster for existing intel desktop
> processors like Bloomfield or Lynnfield?

Unlikely, but I said that before Loren optimized trellis too.

does the integration of the GPU into the CPU itself, like in AMD's APUs or Intel's HD3000 make it more feasible to offload parts of the encode to the GPU?
 

> 3. adaptive bitrate has become very important, and with it, synchronized
> GOPs across encodes in different bitrates.
> this is currently supported in x264 by using fixed sized GOPs. what are your
> thoughts regarding a more content-aware approach?

x264 supports this with adaptive GOP too; all encodes with the same
lookahead settings and the same source will give the same distribution
of frame types, no matter what the bitrate.

that's very interesting, I didn't know that. 
I guess it only works when encoding to the same resolution, though ...
would it make sense to encode to one resolution [lets call it the master resolution] using adaptive GOP settings, and then encode all other bitrates/resolutions using the GOP boundaries of the master resolution?

 

> 4. what are you thoughts regarding the upcoming HEVC/H265 standard, and will
> there be an x265?

I don't know, are you offering to write one? =P

if wishes were horses ;-)
 

Jason
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel



--
Aviad Rozenhek
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Jason Garrett-Glaser | 5 Apr 13:42 2012

Re: x264 Development Newsletter: Vol. 28

On Thu, Apr 5, 2012 at 4:24 AM, aviad rozenhek <aviadr1 <at> gmail.com> wrote:
> On Wed, Apr 4, 2012 at 20:30, Jason Garrett-Glaser <jason <at> x264.com> wrote:
>>
>> > its been a month since your last x264 development newsletter, the
>> > mailing
>> > list hardly contains information regarding future and current
>> > developments
>> > anymore ... :-(
>>
>> That's because discussion has pretty much always been on #x264dev IRC, not
>> here.
>>
>> > would you entertain a few questions to spark discussion?
>> >
>> > 1. is x264 likely to (significantly) improve in terms of bits/quality
>> > efficiency?
>>
>> If someone comes up with good enough new ideas!  But it's a lot harder
>> than it used to be and a lot of the improvements in the pipeline are
>> not so general-purpose (e.g. OpenCL lookahead).
>>
>>
>> > 2. is x264 likely to get (noticeably) faster for existing intel desktop
>> > processors like Bloomfield or Lynnfield?
>>
>> Unlikely, but I said that before Loren optimized trellis too.
>
>
> does the integration of the GPU into the CPU itself, like in AMD's APUs or
> Intel's HD3000 make it more feasible to offload parts of the encode to the
> GPU?

In theory.  For example, offloading main-encoder motion estimation
(NOT lookahead) to the GPU would require relatively fine-grained
synchronization (on the order of 10s of microseconds of latency,
basically).  While putting it on the same die is nearly required for
this sort of latency, it doesn't magically get you it either, and even
with AMD's Fusion, I imagine this would be quite a ways off.

> that's very interesting, I didn't know that.
> I guess it only works when encoding to the same resolution, though ...
> would it make sense to encode to one resolution [lets call it the master
> resolution] using adaptive GOP settings, and then encode all other
> bitrates/resolutions using the GOP boundaries of the master resolution?

You could do that.

Jason
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

Alex Giladi | 6 Apr 16:24 2012
Picon

Re: x264 Development Newsletter: Vol. 28

On Thu, Apr 5, 2012 at 7:24 AM, aviad rozenhek <aviadr1 <at> gmail.com> wrote:
> On Wed, Apr 4, 2012 at 20:30, Jason Garrett-Glaser <jason <at> x264.com> wrote:
>>
...
>> > 3. adaptive bitrate has become very important, and with it, synchronized
>> > GOPs across encodes in different bitrates.
>> > this is currently supported in x264 by using fixed sized GOPs. what are
>> > your
>> > thoughts regarding a more content-aware approach?
>>
>> x264 supports this with adaptive GOP too; all encodes with the same
>> lookahead settings and the same source will give the same distribution
>> of frame types, no matter what the bitrate.
>
>
> that's very interesting, I didn't know that.
> I guess it only works when encoding to the same resolution, though ...
> would it make sense to encode to one resolution [lets call it the master
> resolution] using adaptive GOP settings, and then encode all other
> bitrates/resolutions using the GOP boundaries of the master resolution?
>
You can "borrow" the frame types (either programmatically, or using
the stats file) and reuse either IDR's or all frame types.
You end up having essentially a 2-pass encode, with one "master", and
N-1 "slaves", and all N have same segmentation properties.
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

Dan Jordan | 12 Apr 20:15 2012

Internship opportunity at Johnson Space Center

College students interested in x264, VideoLAN, GStreamer, or any streaming video development, we have an internship available, working at NASA in Houston this summer!

Here is a link if you are interested: http://www.metecs.com/careers-job-descriptions.php




--
Dan Jordan
METECS

dan.jordan <at> metecs.com
daniel.d.jordan <at> nasa.gov
(713) 489-2751 [Rings my computer]
<at> JSC: (281) 244-8068
<at> METECS: (832) 224-4726

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Jason Garrett-Glaser | 13 Apr 18:16 2012

Re: some questions about "x264_is_regular_file" & "x264_is_regular_file_path" in file "common\osdep.h"

On Fri, Mar 30, 2012 at 9:57 AM, zxfishhack <zxfishhack <at> 126.com> wrote:
> There is some problem that using a pipe for input stream of x264.exe on
> Window Platform, I think the problem is the two functions I mention.
> I think it's check the return value in wrong way.
>
> In the function mention in the topic, I found the code below:
>
>     if( fstat( fileno( filehandle ), &file_stat ) )
>         return -1;
>
>     if( stat( filename, &file_stat ) )
>         return -1;
>
> but when I check for fstat & stat in MSDN and Linux man page  <at> linux.die.net
> , I found the return value is defined below:
> fstat - Linux man page(link: http://linux.die.net/man/2/fstat)

I'm not sure exactly what the problem is?  The descriptions you posted
say "-1 is error, 0 is no error", which the current code works
correctly with.

Jason
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

Edward Richards | 13 Apr 19:30 2012

Re: some questions about "x264_is_regular_file" & "x264_is_regular_file_path" in file "common\osdep.h"


Using Windows Named Pipes (\\.\pipe\_THE_NAME_ ) is more complicated than
that.
You can't seek a pipe... which is one of the reasons that
"x264_is_regular_file" & "x264_is_regular_file_path" exist to test for such
things.

It turns out that you have to modify libav or ffmpeg's lavf to get it to
work with raw inputs like i420, i444 etc.

I have that code working but have not made a patch for submission.

It's not a x264 problem and it has nothing to do with the return codes from
the mentioned functions.

Edward

-----Original Message-----
From: x264-devel-bounces <at> videolan.org
[mailto:x264-devel-bounces <at> videolan.org] On Behalf Of Jason Garrett-Glaser
Sent: Friday, April 13, 2012 9:17 AM
To: Mailing list for x264 developers
Subject: Re: [x264-devel] some questions about "x264_is_regular_file" &
"x264_is_regular_file_path" in file "common\osdep.h"

On Fri, Mar 30, 2012 at 9:57 AM, zxfishhack <zxfishhack <at> 126.com> wrote:
> There is some problem that using a pipe for input stream of x264.exe 
> on Window Platform, I think the problem is the two functions I mention.
> I think it's check the return value in wrong way.
>
> In the function mention in the topic, I found the code below:
>
>     if( fstat( fileno( filehandle ), &file_stat ) )
>         return -1;
>
>     if( stat( filename, &file_stat ) )
>         return -1;
>
> but when I check for fstat & stat in MSDN and Linux man page 
>  <at> linux.die.net , I found the return value is defined below:
> fstat - Linux man page(link: http://linux.die.net/man/2/fstat)

I'm not sure exactly what the problem is?  The descriptions you posted say
"-1 is error, 0 is no error", which the current code works correctly with.

Jason
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

Alex Giladi | 14 Apr 01:45 2012
Picon

Re: Internship opportunity at Johnson Space Center

Same at Huawei, in either NJ or CA

On Thu, Apr 12, 2012 at 2:15 PM, Dan Jordan <dan.jordan <at> metecs.com> wrote:
> College students interested in x264, VideoLAN, GStreamer, or any streaming
> video development, we have an internship available, working at NASA in
> Houston this summer!
>
> Here is a link if you are interested:
> http://www.metecs.com/careers-job-descriptions.php
>
>
>
>
> --
> Dan Jordan
> METECS
>
> dan.jordan <at> metecs.com
> daniel.d.jordan <at> nasa.gov
> (713) 489-2751 [Rings my computer]
>  <at>  JSC: (281) 244-8068
>  <at>  METECS: (832) 224-4726
>
>
> _______________________________________________
> x264-devel mailing list
> x264-devel <at> videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel


Gmane