y262

[rwill]

So over the last four X-Mas when I was on PTO I wrote an mpeg2 encoder.

It was mostly finished last year but I have added some small features in the last few days like pulldown and pipe support.

It would be nice if some people check it out and give feedback.

I have run some limited tests myself and picture quality appears to be good - but the encoder is somewhat slow as it currently lacks multithreading.

*edit 1
Its now up on github. I still do not provide binaries.

https://github.com/rwillenbacher/y262/

[hank315]

A first test using y262.
Test is a progressive PAL 3200 frames clip (720x576) using low bitrate and 2 passes.
For testing I added the next matrix:

8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 37
19 22 26 27 29 34 34 38
22 22 26 27 29 34 37 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 58
26 27 29 34 38 46 56 69
27 29 35 38 46 56 69 83

16 17 18 19 20 21 22 23
17 18 19 20 21 22 23 24
18 19 20 21 22 23 24 25
19 20 21 22 23 24 26 27
20 21 22 23 25 26 27 28
21 22 23 24 26 27 28 30
22 23 24 26 27 28 30 31
23 24 25 27 28 30 31 33




Adaptive Quantisation works fine.
Ratecontrol is good.
Intra/inter decision for MacroBlocks in P and B frames seems OK.
MacroBlock skipping in P and B frames works OK if there's real content but doesn't work in black bars.

Video quality is good, major drawback it's slow.
Metrics (PSNR and SSIM) for this test are high, for this low bitrate encoding metrics beat all commercial encoders I know.

For now it sure looks promising.

[Emulgator]

A build, a build, a kingdom for a build....

[hank315]

I will upload one soon, also some files I used for testing.

Here is an exe and some files used for testing. (https://www.mediafire.com/?tiqoraukzb51x3h)
The matrices used can be activated with -mpeg (see run.bat)
A raw intermediate file is used, pipes are also possible but I didn't try that.
Success and thanks to rwill.

[rwill]

Thank you hank315 for trying out my encoder :)

Ok, regarding the failure of the encoder to use skip mode in unicolour macroblocks: lambda was 0 for quant = 1 so the bit count of the macroblock was not taken into account when determining modes. -Fixed in SVN. Black bars should be skip now.

I also added the ability to specify text files containing 64 values as Intra or Inter Quantization Matrices to the application so there is no need to make changes in the source code anymore when trying QMats out.

[Sparktank]

Just when I thought there wasn't any more toys, Christmas kicks in. :)

[hank315]

@rwill
If input is 1920x1080, output is 1920x1088 in the sequence header and 1920x1080 in the sequence display extension.
IMO in the sequence header, height should also be 1080 using 8 black lines in the lower MacroBlocks, see also here (http://www.atsc.org/cms/standards/a53/a_53-Part-4-2009.pdf), table 6.2.

[rwill]

I just added slice threading. Sadly it does not scale linear.

[hank315]

I also tried that but the thread overhead is pretty large so no linear scaling.
I ended up with frame threading which is almost linear.
Maybe input and lookahead can be threaded?

[rwill]

@hank315

I fixed that vertical size signaling.

Lookahead is threaded. Problem is that different parts of pictures take a different amount of time :)

*edit* Regarding frame threading, I am scared of the bitrate control when its set to CBR.

[hank315]

@rwill
Threads.c and threads.h seem to be missing in SVN repository?

[rwill]

Whoops, they are there now.

[hank315]

New build, threading gives an average speed boost factor of 2.5 on my quad core.
You will need at least SSE2 for this one.
The new avs2yuv will pipe raw data into y262app, so no intermediate raw file is needed.
See readme.txt and example pipe.bat.

Download link (http://www.mediafire.com/download/8w4zv4hww8shqd1/y262_21-12-2014.zip)


EDIT:
Package updated (http://www.mediafire.com/download/zuj26m2i956idu2/y262_22-12-2014.zip), should work also with XP now.

[Emulgator]

Wow, not bad for this low version count. Potential.

[rwill]

y262 is now on github:
https://github.com/rwillenbacher/y262

Not much changed but I added Mpeg-1 support, fixed some bugs and switched to cmake as a build system.

[Blue_MiSfit]

Cool, good to have more MPEG-2 encoders in the world :) Maybe start a new thread? This one is 7 years old

[FranceBB]

Since we're talking about MPEG-2: can it encode compliant XDCAM-50 files?

[rwill]

Cool, good to have more MPEG-2 encoders in the world :) Maybe start a new thread? This one is 7 years old

Thanks for making me feel old.


Since we're talking about MPEG-2: can it encode compliant XDCAM-50 files?

Maybe, i don't know the attributes and constraints a XDCAM-50 file has. Can ffmpeg or x262 generate XDCAM-50 files ? If yes, can someone post a respective commandline here ?

[FranceBB]

Sure, there you go:

avs2yuv.exe "Z:\AVS Script.avs" -csp AUTO -o - | ffmpeg.exe -i - -pix_fmt yuv422p -vcodec mpeg2video -s 1920:1080 -aspect 16:9 -vf setfield=tff -flags +ildct+ilme+cgop -b_strategy 0 -mpv_flags +strict_gop -sc_threshold 1000000000 -r 25 -b:v 50000k -minrate 50000k -maxrate 50000k -bufsize 36408333 -g 12 -bf 2 -profile:v 0 -level:v 2 -color_range 1 -color_primaries 1 -color_trc 1 -colorspace 1 -y "\\mibctvan000\Ingest\MEDIA\temp\output.mxf"

As you can see it's basically an MPEG-2 with a closed GOP M=3 N=12 profile High, Level 2, yv16 (so 4:2:2 planar 8bit) either 25i or 29.970i TFF or BFF at 50 Mbit/s CBR.

https://i.imgur.com/oNcooP2.png

The reason why I'm asking you this is that the current MPEG-2 encoder in FFMpeg was made back when monocore and single socket CPU/PCs were still a thing, so it's terribly non-optimized/parallelized and it doesn't really make use of instruction sets, so having a Dual Xeon 60c/120th AVX512 configuration is useless unless I encode several files at a time. I generally encode 40-60 files at once on such a configuration to make use of the whole CPU power, but it's still slow as it's SSE2 only...
Where does y262 stand in terms of intrinsics/assembly optimizations and parallelization?

As Derek said, the more the better when it comes to open source MPEG-2 encoders, however the only real use case for these encoders nowadays is not consumer-distribution but rather professional/enterprise driven so it would be nice to get this thing working properly with professional formats like XDCAM.
Question: any particular reason why you made your own encoder instead of contributing to the one already implemented in FFmpeg or to x262? (Just a curiosity, 'cause if your encoder gets these things right it might as well be integrated in FFmpeg one day). :)


Anyway thank you for making this available to everyone. ;)

[rwill]

Yeah that would translate to something like this. Maybe drop -flatmat for default quant matrices ?

./y262.exe -in test_interlaced_422_8b.yuv -size 1920 1080 -frcode 3 -profile main -level high -chromaf 422 -bitrate 50000 -vbvrate 50000 -vbv 9600 -interlaced -quality 0 -nump 3 -numb 2 -closedgop -flatmat -videoformat 709 -arinfo 3 -out test.m2v -mpout test.stats -rcmode 1 -threads 1 6 -cbr

./y262.exe -in test_interlaced_422_8b.yuv -size 1920 1080 -frcode 3 -profile main -level high -chromaf 422 -bitrate 50000 -vbvrate 50000 -vbv 9600 -interlaced -quality 0 -nump 3 -numb 2 -closedgop -flatmat -videoformat 709 -arinfo 3 -out test.m2v -mpin test.stats -rcmode 2 -threads 1 6 -cbr

I am somewhat confused by -bufsize 36408333 and i saw somewhere else it being -bufsize 17825792 for xdcam 422. But I am stuck with the first release of the mpeg2 spec from ~1995 which is lacking the 422 profile specs so I do not know the level limits for that. So right now y262 is capped at around ~9600k video buffer because that is what 420 has. I might remove the buffer size check for 422 and 444 but I would feel safer when I have some sort of standard to reference to when checking level limits. Google got me nothing and ISO wants money. y262 currently only accepts rates and buffers in 1000 units so this might be a problem too.

y262 currently does have basic slice threading. I have been thinking about adding frame based threading but this would require some changes to bitrate control and picture re-encode logic in addition to the threading itself. This comes with extensive corner case testing. I think right now it will utilize around 6 cores if told to do so for HD. MPEG2 with pixels being 8 bit, macroblocks being 16x16 and the transform being 8x8 does not benefit much from SIMD registers above 128bit width. Not much one can do with AVX2 or AVX512.

I started y262 before x262 was announced and I think bolting mpeg2 support onto x264 is the wrong development approach anyway. The ffmpeg encoder design is too old. Always starting fresh might not be the fastest way to get some sort of bitstream producing library out but it brings the oportunity to avoid mistakes of the past.

[filler56789]

.....and I think bolting mpeg2 support onto x264 is the wrong development approach anyway.

You are correct. Using the so-called "x264 framework" does not imply that it requires an H.264 encoder to make it work.

(This comment may sound off-topic, but) basically, that's the same kind of mistake made by the developers of the Chromium clones,
who are too lazy to separate the layout engine of a browser from a noobish interface :–/

[rwill]

I just put this here too...

So the ITU has put more recent Mpeg2 standard documents on their page which allowed me to implement somewhat more proper profile (high/422) signaling.

So it is now possible to specify "high" or "422" as profile and "422main" or "422high" as level. This might be useful for the more pro leaning people.

I also noticed recently that odd macroblock line count streams were broken since at least the introduction of Mpeg-1 output, this has been fixed too. Sorry about that.

Latest version is still on github where encountered issues can also be submitted. https://github.com/rwillenbacher/y262/

[FranceBB]

Speaking of the input, all your examples are with .yuv files, does it mean that it can't open Avisynth scripts directly?

Are the limitations we talked about last time scrapped now?
If you want I can send you a proper XDCAM-50 file with the correct GOP and you can test that.
You know, if it can create compliant files for broadcast use (so XDCAM-50 and its flavors, IMX50 and its flavors etc) and it accepts Avisynth input, it might gain attraction.

[rwill]

Well y262 accepts only raw YUV as input, via file or stdin pipe. Thats because its mostly developed as a library and not an application. Tools like avs2yuv are more flexible than doing some own Avisynth reader implementation anyway.

The limitation last time in this thread was that y262 had no concept of signaling 422 profile and its associated levels. This should work now.

I do not see how some XDCAM-50 file encoded by a different encoder would help with testing y262.

If someone can create a stream with y262 where the configuration set at the encoder API does not match the encoders output - I am interested in that and thats what the Issues page on github is for. Likewise for things currently missing at the y262 configuration API to produce certain Mpeg2 video flavors.

[FranceBB]

Well y262 accepts only raw YUV as input, via file or stdin pipe. Thats because its mostly developed as a library and not an application. Tools like avs2yuv are more flexible than doing some own Avisynth reader implementation anyway.

Gotcha, I'm gonna try with yuv4mpegpipe - | y262.exe -
as a pipe and see if it works so that I don't have to specify resolution and other things.


The limitation last time in this thread was that y262 had no concept of signaling 422 profile and its associated levels. This should work now.


Nice. If I have a bit of spare time, I'll try it and compare it with x262. :)

[rwill]

Gotcha, I'm gonna try with yuv4mpegpipe - | y262.exe -
as a pipe and see if it works so that I don't have to specify resolution and other things.


Well it is not going to work because y4m is not raw yuv. y262 does not support y4m input yet. I might add it to my list though.

[FranceBB]

Well it is not going to work because y4m is not raw yuv. y262 does not support y4m input yet. I might add it to my list though.

I see...
Yeah y4m would be a big plus 'cause it allows people to pipe without having to specify any property like resolution, framerate etc

[benwaggoner]

I see...
Yeah y4m would be a big plus 'cause it allows people to pipe without having to specify any property like resolution, framerate etc
I find myself overly infuriated by lack of .y4m support. Debugging .yuv parameters can be a huge hassle, particularly when one works with a variety of resolutions, frame rates, and bit depths.

[rwill]

Well I do not like y4m much.

To seek one has to index. To cut one has to use tools. To rewrite a part one has to rewrite the whole file. I mean it is combining the downsides of a variable size format with being uncompressed.

I can see why some prefer it over raw YUV though.

Me and my friends put resolution, frame rate, chroma format and bit depth in the file name.

Can be something simple like foreman_cif.yuv or something more verbose like XXX_HD_u10_lsb16_420p_1920x1080.yuv.

[benwaggoner]

Well I do not like y4m much.

To seek one has to index. To cut one has to use tools. To rewrite a part one has to rewrite the whole file. I mean it is combining the downsides of a variable size format with being uncompressed.
What sort of real-world use to you get out of being able to do those sorts of operations?

Me and my friends put resolution, frame rate, chroma format and bit depth in the file name.

Can be something simple like foreman_cif.yuv or something more verbose like XXX_HD_u10_lsb16_420p_1920x1080.yuv.
Also an option. Ideally we could define a standard syntax for those which tools could read and then automatically set the parameters correctly.

[rwill]

What sort of real-world use to you get out of being able to do those sorts of operations?

I need to do this a lot when doing Codec or HDR tool development.

If I want to cut a range from a file I can use dd with a raw yuv like so because frame sizes are fixed and offset is 0: "dd if=<inputyuv> bs=$((<width>*<height>*3)) skip=<startframe> count=$((<endframe> - <startframe>)) of=<outputyuv>"

So when I have some uncompressed UHD movie, which comes in at a couple TB, being able to index and cut small samples for further encoder "problem zone" testing or such I can just do that very quickly.

Given that HDD space on a workstation is limited and these files typically are stored on some network attached storage, indexing or avoiding complete rewriting (like when updating a part of a HDR movie with some re-graded stuff) over a slow network link is a real time saver. Time is money and I hate staring at % indicators anyway.

Regarding the file name format, I am using the 'vooya' raw yuv player for inspecting things, its doing the file name thing like this:
"youNameIt_WIDTHxHEIGHT[_FPS[Hz|fps]][_BITSbit][_(P420|P422|P444|UYVY|YUY2|YUYV|I444)].[rgb|yuv|bw|rgba|bgr|bgra Â… ]".
Other YUV player are doing similar but there seems to be no critical mass yet.

[rwill]

So there, I added some sort of .y4m support to the y262 git.