y262

[filler56789]

Originally Posted by rwill

.....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]

Originally Posted by 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.

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.

Originally Posted by rwill

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]

Originally Posted by FranceBB

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]

Originally Posted by rwill

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]

Originally Posted by FranceBB

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]

Originally Posted by 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.

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]

Originally Posted by benwaggoner

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.