Help Building FFmpeg and/or Handbrake with Special "Flavor" of x264

[simon744]

Hi, everyone! Sorry if this request seems a little odd, or might be too complicated, but I'd appreciate any helpful feedback.

Can the kind folks over here dumb down for me a tutorial to build either ffmpeg or Handbrake with x264-paff (https://github.com/kierank/x264-paff), PLEASE? Some of you are probably familiar with it. It's x264, basically, but with the additional ability/feature, whatever, of PAFF-interlacing and interlaced encoding, in addition to MBAFF, which the base x264 already has. I don't know why to this day it still hasn't been merged into the main source code. It'd literally make x264 the best H.264 encoder around, and make people like me very happy.

Anyways, if it's not too hard and time-consuming, a pre-built Handbrake, specifically, with the encoder would be even better. But you can go ahead and provide detailed instructions for going about on building them myself.

Thanks a lot, in advance, and have a wonderful day!

[simon744]

PLEASE! Hopefully someone chimes in.

[Selur]

as an idea: you could try using https://github.com/m-ab-s/media-autobuild_suite and adjust the path to the x264 source (assuming the build process didn't change the last few years for x264)

[LigH.de]

The paths are defined in build/media-suite_deps.sh there.

[simon744]

as an idea: you could try using https://github.com/m-ab-s/media-autobuild_suite and adjust the path to the x264 source (assuming the build process didn't change the last few years for x264)

Thanks for the suggestion! I would love to, but am not sure if I can actually do that, since am not very familiar with building/compiling. Even this is quite complicated to me, but I need that encoder. As I said above in the original post, I need it dumbed down to me.

[october262]

as an idea: you could try using https://github.com/m-ab-s/media-autobuild_suite and adjust the path to the x264 source (assuming the build process didn't change the last few years for x264)

Thanks for the suggestion! I would love to, but am not sure if I can actually do that, since am not very familiar with building/compiling. Even this is quite complicated to me, but I need that encoder. As I said above in the original post, I need it dumbed down to me.

see this thread here - https://ffmpeg-user.ffmpeg.narkive.com/bpS1lotM/interlaced-x264
x264 does not support PAFF

[simon744]

as an idea: you could try using https://github.com/m-ab-s/media-autobuild_suite and adjust the path to the x264 source (assuming the build process didn't change the last few years for x264)

Thanks for the suggestion! I would love to, but am not sure if I can actually do that, since am not very familiar with building/compiling. Even this is quite complicated to me, but I need that encoder. As I said above in the original post, I need it dumbed down to me.

see this thread here - https://ffmpeg-user.ffmpeg.narkive.com/bpS1lotM/interlaced-x264
x264 does not support PAFF

Thank you! I know the vanilla x264 doesn't support PAFF, but the specific "flavor" am trying to build FFmpeg with does. Now I'm trying to figure out a way of building/compiling either FFmpeg or, preferably, Handbrake with it.

[Selur]

I used mbas, adjusted the path to x264-paff-git (build/media-suite_deps.sh and build/media-suite_compile.sh) and attached x264 and ffmpeg build with that x264 version. (32&64bit)
No clue, whether this does what you want,... (especially no clue whether using that version with ffmpeg actually works as intended)

Cu Selur

[simon744]

I used mbas, adjusted the path to x264-paff-git (build/media-suite_deps.sh and build/media-suite_compile.sh) and attached x264 and ffmpeg build with that x264 version. (32&64bit)
No clue, whether this does what you want,... (especially no clue whether using that version with ffmpeg actually works as intended)

Cu Selur

Thank you so much! This seems to be it. I thought it'd "automatically" use PAFF, however, it's still using MBAFF, at least when trying to encode using FFmpeg. And I can't figure out a proper x264 script. Man, I'm so dumb

[poisondeathray]

The additional switch is --field-encode

      --field-encode          Enable field encoding - one frame will be encoded as two fields

And it is flagged as PAFF, but there are problems with the bitstream and it crashes some decoders. It's not production ready. But thanks to Selur for compiling it

Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First

[simon744]

The additional switch is --field-encode

      --field-encode          Enable field encoding - one frame will be encoded as two fields

And it is flagged as PAFF, but there are problems with the bitstream and it crashes some decoders. It's not production ready. But thanks to Selur for compiling it

Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First

Can you please share with me the full command/script for use with x264? I've only used GUIs, but will probably have to learn CLIs.

[simon744]

I just can't understand why won't the x264 devs make this a thing finally?

[poisondeathray]

Can you please share with me the full command/script for use with x264? I've only used GUIs, but will probably have to learn CLIs.

The bare minimum is the field order (tff, bff) and the new switch . --sar if it's SD

Note the defaults are different for this build than "normal" builds. There is a max GOP of 500, 6 refs

It would look something like this

x264 --tff --field-encode -o output.ext input.ext

I tried feeding separated fields stream (in addition to interleaved fields input), as well the ffmpeg libx264 build - but there are issues with every combination either with timestamps, frame/field size, and some crashing with some decoders. This is not a "proper" polished or finished PAFF build

I just can't understand why won't the x264 devs make this a thing finally?

The general consensus from dev's is "interlace is dead." Why invest time into something dead. MBAFF is superior in terms of efficiency. x264 development basically stopped 10 years ago, the only commits are for SIMD commits, a few bug fixes. AVC is now considered a "legacy" format now too , and people have moved on . (Yes I know there are a few situation where PAFF is required - it won't happen unless someone sponsors $$ it)

[simon744]

Can you please share with me the full command/script for use with x264? I've only used GUIs, but will probably have to learn CLIs.

The bare minimum is the field order (tff, bff) and the new switch . --sar if it's SD

Note the defaults are different for this build than "normal" builds. There is a max GOP of 500, 6 refs

It would look something like this

x264 --tff --field-encode -o output.ext input.ext

My input has 4:2:2 chroma so I got this error:

resize [warning]: converting from yuv422p to yuv420p
x264 [error]: field encoding is not compatible with vfr

I just can't understand why won't the x264 devs make this a thing finally?

The general consensus from dev's is "interlace is dead." Why invest time into something dead. MBAFF is superior in terms of efficiency. x264 development basically stopped 10 years ago, the only commits are for SIMD commits, a few bug fixes. AVC is now considered a "legacy" format now too , and people have moved on . (Yes I know there are a few situation where PAFF is required - it won't happen unless someone sponsors $$ it)

I wonder how much money would it take them to add it to the encoder? Why not kill MBAFF, too, if "interlace is dead"? MBAFF's not working for me. I wish a lot of people started annoying them with this request so that they finally have no other choice, but to do it.

[simon744]

I don't see how "interlace is dead"! It's 2024, and more than half of the world's watching interlaced TV. It's not going away yet. Why make something as simple so frustrating and nerve-wrecking?! I just want to re-encode my archival footage in peace.

[poisondeathray]

My input has 4:2:2 chroma so I got this error:


resize [warning]: converting from yuv422p to yuv420p
x264 [error]: field encoding is not compatible with vfr

422 should be

--input-csp i422 --output-csp i422

However, you have vfr (variable frame rate) input according to the log , so that's a no go .

What is the source file? You can convert it to CFR, or use aviysnth input

Why not kill MBAFF, too, if "interlace is dead"?

Because it already works, and MBAFF has been production ready for many years

MBAFF's not working for me.

Exactly "what is not working ? "

[poisondeathray]

I don't see how "interlace is dead"! It's 2024, and more than half of the world's watching interlaced TV. It's not going away yet. Why make something as simple so frustrating and nerve-wrecking?! I just want to re-encode my archival footage in peace.

And MBAFF works fine for that . Many broadcast providers use MBAFF instead of PAFF. Many retail BD's use MBAFF encoding instead of PAFF . The main reason is better quality , or lower bandwidth for a certain level of quality - which of course appeals to broadcasters

[simon744]

My input has 4:2:2 chroma so I got this error:


resize [warning]: converting from yuv422p to yuv420p
x264 [error]: field encoding is not compatible with vfr

422 should be

--input-csp i422 --output-csp i422

However, you have vfr (variable frame rate) input according to the log , so that's a no go .

What is the source file? You can convert it to CFR, or use aviysnth input

Why not kill MBAFF, too, if "interlace is dead"?

Because it already works, and MBAFF has been production ready for many years

MBAFF's not working for me.

Exactly "what is not working ? "

Not really sure, on what could truly be the problem, but MBAFF encodes always kind of struggle to play on my PC, while PAFF encodes play back smoothly and with minimal to no stuttering, if any.

And MBAFF works fine for that . Many broadcast providers use MBAFF instead of PAFF. Many retail BD's use MBAFF encoding instead of PAFF . The main reason is better quality , or lower bandwidth for a certain level of quality - which of course appeals to broadcasters

Dunno about you, but I haven't come across anybody that uses MBAFF, especially for broadcasting. I collect satellite feeds, and the majority of them are PAFF. From the most unknown and low-profile feeds to extremely high profile ones like the Grammys, or something else, they are all PAFF. Even a few rare IPTV streams that happen to be interlaced use PAFF.

(Yes I know there are a few situation where PAFF is required - it won't happen unless someone sponsors $$ it)

I wonder how much would it take them to do that...? I'd be willing to make not one, but even a few donations, though modest, to the best of my current abilities, if I knew for sure they're finally doing something about it. It's not even impossible, they just need to want to do it, and invest the time into the process, which am sure won't be long considering there are already unofficial modified builds with PAFF-support which I can't get a hold of (I can send links to a few sample videos). Do you have any idea on where would be the best place for making this suggestion to directly get the devs' attention? Again, I am willing to make donations.

P.S. SORRY for the late reply. I've been extremely busy the last couple of days, so couldn't reply right away. Thanks a lot for your help.

[poisondeathray]

Not really sure, on what could truly be the problem, but MBAFF encodes always kind of struggle to play on my PC, while PAFF encodes play back smoothly and with minimal to no stuttering, if any.

It might your software isn't deinterlacing automatically , or you don't have it setup properly

Dunno about you, but I haven't come across anybody that uses MBAFF, especially for broadcasting. I collect satellite feeds, and the majority of them are PAFF. From the most unknown and low-profile feeds to extremely high profile ones like the Grammys, or something else, they are all PAFF. Even a few rare IPTV streams that happen to be interlaced use PAFF.

BBC HD, Sky HD, CNBC Europe, ITV, ...

(Yes I know there are a few situation where PAFF is required - it won't happen unless someone sponsors $$ it)

I wonder how much would it take them to do that...? I'd be willing to make not one, but even a few donations, though modest, to the best of my current abilities, if I knew for sure they're finally doing something about it. It's not even impossible, they just need to want to do it, and invest the time into the process, which am sure won't be long considering there are already unofficial modified builds with PAFF-support which I can't get a hold of (I can send links to a few sample videos). Do you have any idea on where would be the best place for making this suggestion to directly get the devs' attention? Again, I am willing to make donations.

P.S. SORRY for the late reply. I've been extremely busy the last couple of days, so couldn't reply right away. Thanks a lot for your help.

Contact Kieran Kunhya (kierank on Github) since he's the maintainer of that fork

Sponsoring a project tends to bring more people "out of the woodwork"

[simon744]

It might your software isn't deinterlacing automatically , or you don't have it setup properly

I don't think that's the problem, because, then, why would other videos be de-interlaced just fine, including H.264 PAFF and MPEG2, both up to 4:2:2 10-bit?

Contact Kieran Kunhya (kierank on Github) since he's the maintainer of that fork

Sponsoring a project tends to bring more people "out of the woodwork"

I actually did try to get a hold of him a few months back, but for making available a compiled copy of the fork so that it's easier for noobs to get the encoder. He was like, "an exe is not possible" even when clearly, it IS possible. And it only took him another comment by me under the Issue to respond. So, not sure if he'd do anything even if I were to offer a donation or anything. What am thinking of/about is reaching out to VideoLAN directly to see if they'd do something. What would be the right place/platform to make them aware of this?

[poisondeathray]

It might your software isn't deinterlacing automatically , or you don't have it setup properly

I don't think that's the problem, because, then, why would other videos be de-interlaced just fine, including H.264 PAFF and MPEG2, both up to 4:2:2 10-bit?

Then why does mbaff work ok for everyone else, but not you?

e.g. it works ok in MPCHC/LAV, Potplayer. You can pause , go frame by frame to check - they automatically double rate deinterlace to 59.94p/ 50p . 100% definitely ok for 10-15 years for 8bit 4:2:0. A software playback problem would have been dealt with a long time ago... e.g. it works ok on Hardware players, such as HDTV's , android players. This would have been a critical bug fixed a long time ago, on multiple fronts, libavcodec, x264 - had it been an issue

But 10bit 4:2:2 AVC will not be HW accelerated by anything - so if the decoding path is through GPU or HW decoding, and there is no SW deinterlacer setup in the path, it might not process properly automatically - you might have to enable it manually

What software are you using, what decoder, what setup ? HW or SW decoding ?

What hardware ?

Or maybe you didn't encode it properly ? Such as wrong field order ?

Contact Kieran Kunhya (kierank on Github) since he's the maintainer of that fork

Sponsoring a project tends to bring more people "out of the woodwork"

I actually did try to get a hold of him a few months back, but for making available a compiled copy of the fork so that it's easier for noobs to get the encoder. He was like, "an exe is not possible" even when clearly, it IS possible. And it only took him another comment by me under the Issue to respond. So, not sure if he'd do anything even if I were to offer a donation or anything. What am thinking of/about is reaching out to VideoLAN directly to see if they'd do something. What would be the right place/platform to make them aware of this?

Proper channel is still kierank , let him know you're offering a bounty . You can try VideoLAN , or even a post a ffmpeg developer bounty


EDIT: just tested this right now

All these mbaff x264 encoded pixel formats play ok automatically deinterlaced in MPCHC+LAV for me 8bit420 , 8bit422, 10bit422

[pandy]

Doubt if bounty able to convince Kieran or someone else to work on PAFF in x264 will be lower than https://www.mainconcept.com/ffmpeg#buy-now .

[simon744]

It might your software isn't deinterlacing automatically , or you don't have it setup properly

I don't think that's the problem, because, then, why would other videos be de-interlaced just fine, including H.264 PAFF and MPEG2, both up to 4:2:2 10-bit?

Then why does mbaff work ok for everyone else, but not you?

e.g. it works ok in MPCHC/LAV, Potplayer. You can pause , go frame by frame to check - they automatically double rate deinterlace to 59.94p/ 50p . 100% definitely ok for 10-15 years for 8bit 4:2:0. A software playback problem would have been dealt with a long time ago... e.g. it works ok on Hardware players, such as HDTV's , android players. This would have been a critical bug fixed a long time ago, on multiple fronts, libavcodec, x264 - had it been an issue

But 10bit 4:2:2 AVC will not be HW accelerated by anything - so if the decoding path is through GPU or HW decoding, and there is no SW deinterlacer setup in the path, it might not process properly automatically - you might have to enable it manually

What software are you using, what decoder, what setup ? HW or SW decoding ?

What hardware ?

Or maybe you didn't encode it properly ? Such as wrong field order ?

Not really sure, honestly. And to be clear, I never said MBAFF encodes do not get de-interlaced whatsoever on my end. I only said they "struggle to play on my PC." I do pause, check the frames, and the rate indeed is doubled to 50 for PAL, and to 59.94 for NTSC, though, usually when playing back PAFF encodes. With MBAFF, there are often lots of dropped frames. This applies to/for both my own encodes, and those downloaded from the internet. This is not a constant occurrence, but a frequent one. On the other hand, even 10-bit 4:2:2 PAFF is smooth. Trust me, I wouldn't make up a whole story simply because I want x264 to get PAFF support.

Contact Kieran Kunhya (kierank on Github) since he's the maintainer of that fork

Sponsoring a project tends to bring more people "out of the woodwork"

I actually did try to get a hold of him a few months back, but for making available a compiled copy of the fork so that it's easier for noobs to get the encoder. He was like, "an exe is not possible" even when clearly, it IS possible. And it only took him another comment by me under the Issue to respond. So, not sure if he'd do anything even if I were to offer a donation or anything. What am thinking of/about is reaching out to VideoLAN directly to see if they'd do something. What would be the right place/platform to make them aware of this?

Proper channel is still kierank , let him know you're offering a bounty . You can try VideoLAN , or even a post a ffmpeg developer bounty

As long as it ends up getting merged into the main x264 [source code] instead of remaining an independent fork like it is now, am seriously considering it. Not right now, though.

[simon744]

Doubt if bounty able to convince Kieran or someone else to work on PAFF in x264 will be lower than https://www.mainconcept.com/ffmpeg#buy-now .

Why would it be any higher or the same in price as the "AVC Broadcast Encoder Plugin", though? As far as I know, base x264 does almost everything offered by that plugin, for free! It's not even like PAFF support is what really is giving that product its price tag. Especially not, considering there are modified x264 forks with PAFF support that could do the same job if one managed to find them. More than likely, the "Pre-configured encoding and multiplexer profiles for professional Sony and Panasonic cameras" give it the hefty price tag.

[poisondeathray]

Not really sure, honestly. And to be clear, I never said MBAFF encodes do not get de-interlaced whatsoever on my end. I only said they "struggle to play on my PC." I do pause, check the frames, and the rate indeed is doubled to 50 for PAL, and to 59.94 for NTSC, though, usually when playing back PAFF encodes. With MBAFF, there are often lots of dropped frames. This applies to/for both my own encodes, and those downloaded from the internet. This is not a constant occurrence, but a frequent one. On the other hand, even 10-bit 4:2:2 PAFF is smooth. Trust me, I wouldn't make up a whole story simply because I want x264 to get PAFF support.

I'm not doubting your observation, but don't you want to understand the actual problem ?

This sounds like an older hardware issue (or it could still be misconfigured SW)

Can you answer the previous questions on hardware configuration and software used ?

If there was critical issue that affected everybody - this would make it a high priority issue - and you wouldn't have to pay a developer to convince them to work on it . And it would be examined at both sides; MBAFF encoding and the decoding side in libavcodec to see where the problem was


Other options:

Upgrading HW would be less expensive than hiring a developer

Cheapest way for smooth MBAFF playback if you don't have sufficient HW resources is to add a cheap GPU card (at least for 4:2:0 AVC)

You can encode 4:2:0 AVC PAFF using NVEenc using a cheap card as well . Sure, the quality isn't as good as x264 with MBAFF, but it' s decent if you use enough bitrate

AVC PAFF comes with many commercial NLE's as well (e.g. Vegas, Premiere), usually the licensed mainconcept AVC variety . Again, quality is lower than x264 MBAFF, but it's decent if you use enough bitrate

[pandy]

Doubt if bounty able to convince Kieran or someone else to work on PAFF in x264 will be lower than https://www.mainconcept.com/ffmpeg#buy-now .

Why would it be any higher or the same in price as the "AVC Broadcast Encoder Plugin", though? As far as I know, base x264 does almost everything offered by that plugin, for free! It's not even like PAFF support is what really is giving that product its price tag. Especially not, considering there are modified x264 forks with PAFF support that could do the same job if one managed to find them. More than likely, the "Pre-configured encoding and multiplexer profiles for professional Sony and Panasonic cameras" give it the hefty price tag.

You probably no need commercial license for broadcast AVC encoder - there is fundamental difference between x264 and Mainconcept products - you get warranty and proven broadcast (x264 is proven but without warranty). Don't get me wrong - using x264, no need to use Mainconcept and no need to have PAFF. Try to raise some action, collect at least 4..5 figures bounty and convince someone to create broadcast PROVEN PAFF for x264, soon there will be need to create interlace support for x265 (h.265 formally is progressive but left some backdoor for interlaced content) so perhaps this can be extended on both.


added after brief:

Or use ChatGPT or similar fancypancy ML crap to create working code (perhaps using Kieran PAFF as entry point - not sure about copyright and license).

[poisondeathray]

soon there will be need to create interlace support for x265 (h.265 formally is progressive but left some backdoor for interlaced content) so perhaps this can be extended on both.

You would have to pay a bounty for the decoding side too - because proper interlaced decoder doesn't exist for HEVC either, professional or open source. Encoder is useless without any decoding tools. And it wouldn't be part of the "official" specifications (unless they update it) or would it necessarily work on hardware chips - it would be some "other" project limited to open source software

h266 / VVC is in the same situation - it does not include proper support for interlace either . The fact that 2 generations of codecs omit proper interlace support in their official specifications should suggest something obvious....

[pandy]

soon there will be need to create interlace support for x265 (h.265 formally is progressive but left some backdoor for interlaced content) so perhaps this can be extended on both.

You would have to pay a bounty for the decoding side too - because proper interlaced decoder doesn't exist for HEVC either, professional or open source. Encoder is useless without any decoding tools. And it wouldn't be part of the "official" specifications (unless they update it) or would it necessarily work on hardware chips - it would be some "other" project limited to open source software

h266 / VVC is in the same situation - it does not include proper support for interlace either . The fact that 2 generations of codecs omit proper interlace support in their official specifications should suggest something obvious....

You are absolutely right about lack of formal requirements on decoders to support interlace content encoding in h.265/h.266 and i never claimed anything opposite.

If i recall correctly interlace content encoding (after separating frame to fields) in h.265 was briefly mentioned during h.265 standardization process.

This will be less efficient but still can be option to consider if someone searching for higher compression than h.264 can deliver.

For HW decoders this proposed encoding method is not substantially different than PAFF but of course it is up to implementer to deliver proper implementation.

Hope it is clear now.

[simon744]

Not really sure, honestly. And to be clear, I never said MBAFF encodes do not get de-interlaced whatsoever on my end. I only said they "struggle to play on my PC." I do pause, check the frames, and the rate indeed is doubled to 50 for PAL, and to 59.94 for NTSC, though, usually when playing back PAFF encodes. With MBAFF, there are often lots of dropped frames. This applies to/for both my own encodes, and those downloaded from the internet. This is not a constant occurrence, but a frequent one. On the other hand, even 10-bit 4:2:2 PAFF is smooth. Trust me, I wouldn't make up a whole story simply because I want x264 to get PAFF support.

This sounds like an older hardware issue (or it could still be misconfigured SW)

Can you answer the previous questions on hardware configuration and software used ?

It's highly unlikely to be an older hardware issue. I'm using a relatively low-laptop with a 10th gen i3 CPU, and a weakly 4 GBs of RAM.

Upgrading HW would be less expensive than hiring a developer

Cheapest way for smooth MBAFF playback if you don't have sufficient HW resources is to add a cheap GPU card (at least for 4:2:0 AVC)

You can encode 4:2:0 AVC PAFF using NVEenc using a cheap card as well . Sure, the quality isn't as good as x264 with MBAFF, but it' s decent if you use enough bitrate

AVC PAFF comes with many commercial NLE's as well (e.g. Vegas, Premiere), usually the licensed mainconcept AVC variety . Again, quality is lower than x264 MBAFF, but it's decent if you use enough bitrate

Unfortunately, the upgrading part might well be out of the question for me right now. Although, I do plan to get one of the latest of either an i5 or i7 Intel NUCs by Simply NUC for more ease with both encoding, and decoding stuff (heard they perform very well for their size). Not that it matters much. Anyways...

[poisondeathray]

You should be able to playback MBAFF smoothly with HW or SW decoding - there is something else going on

Intel QSV can encode PAFF too. 10th gen i3 should be able to.

eg.Rigaya's QSVencC . There might be some GUI's for it like StaxRip