x264.exe MBAFF field order bug

[Guest]

Normally, for MBAFF, field order is specified with TopFieldOrderCount != BottomFieldOrderCount (see AVC spec section 8.2.1), and the broadcast MBAFF streams I looked at do it that way. But x264.exe generates the same POC for both top and bottom fields.

It's also possible to specify the order with PIC timing SEIs, but x264.exe does not generate them.

Will this bug be fixed?

[akupenguin]

This will be fixed whenever I get around to removing interlace support from x264.

[lexor]

Then shouldn't "Full MBAFF support, for 10-15% improved interlaced coding efficiency." be axed from the pipeline? It will just be more bother to remove it later.

[Guest]

This will be fixed whenever I get around to removing interlace support from x264. Why would you do that? Perhaps I've missed some discussion, but it seems ill-advised to me.

[akupenguin]

Then shouldn't "Full MBAFF support" be axed from the pipeline?
Full MBAFF support is in Avail's pipeline. I never promised to accept it into x264 mainline. From all accounts, the patch so far is a huge mess.
Why would you do that?
Because interlacing needs to die. Why else?

[Guest]

What is "Avail"? Thank you and please excuse my lack of knowledge about this issue.

[akupenguin]

Avail is the company who contracted the programmer who wrote the MBAFF patch.

[Guest]

You'll be displaced by other encoders if you remove interlace support. Do you think 1080i is just going to disappear?

[akupenguin]

Do you think 1080i is just going to disappear?
Not if people keep supporting it...

[LoRd_MuldeR]

Not if people keep supporting it...

Well, companies keep on using interlaced. Hence consumers are forced to use interlaced.
If people are required to encode interlaced, but cannot use x264 to do that, they'll have to go for another encoder.
And the companies won't change their attitude - they don't give a damn about x264, I guess...

:(

[Guest]

MBAFF seems to work fine for me except for the matter of wrong POCs (or missing SEIs).

There's a patch to add the SEIs. Wouldn't that be a reasonable thing to absorb?

Are you planning to remove interlace support any time soon?

[Sagekilla]

We won't need those interlace for those 1080i H.264 captures when you can do hardware deinterlace using your DGAVCDecNV ;)

[lucassp]

Since everybody starts using progressive LCD displays/TVs, we should lose interlacing in a few years :).

[Inventive Software]

What's the difference between MBAFF and PAFF?

[bob0r]

http://forum.doom9.org/showthread.php?t=120317

[Guest]

This problem can be fixed easily in x264.exe by simply setting pic_order_present_flag=1 in the PPS, and adding delta_pic_order_cnt_bottom in the slice header (1 for tff, -1 for bff, 0 for progressive). This is easier than adding PIC timing SEIs.

[bob0r]

Make a patch, and pray pengvado commits the wrong patch, your's, by accident. You get the point.

[Dark Shikari]

This problem can be fixed easily in x264.exe by simply setting pic_order_present_flag=1 in the PPS, and adding delta_pic_order_cnt_bottom in the slice header (1 for tff, -1 for bff, 0 for progressive). This is easier than adding PIC timing SEIs.Interesting--but we'd have to confirm it actually works first. I know that Avail, for example, does actually use the pic timing SEIs for this purpose, and they would have to check to see if the pic_order_present_flag is sufficient to make the STBs display the video correctly.

[Sagekilla]

See, one thing you could do is just drop support for all interlacing in x264 main trunk, and provide a set of interlacing patches (Except you'd have to find a developer who would want to keep them current) to let anyone who really needs interlacing to use the patched builds.

[Dark Shikari]

See, one thing you could do is just drop support for all interlacing in x264 main trunk, and provide a set of interlacing patches (Except you'd have to find a developer who would want to keep them current) to let anyone who really needs interlacing to use the patched builds.Impossible to maintain.

[Shinigami-Sama]

Well, companies keep on using interlaced. Hence consumers are forced to use interlaced.
If people are required to encode interlaced, but cannot use x264 to do that, they'll have to go for another encoder.
And the companies won't change their attitude - they don't give a damn about x264, I guess...

:(

and then they'll see how horrible it looks and maybe move to a sane solution...

[Sagekilla]

With fast, high quality hardware based deinterlacing coming up for all modern formats (MPEG-2, H.264, and VC-1) on neuron2's VP2 based decoder, hopefully most sane people will either decide to use that or one of the free alternatives available in avisynth..

I don't see any reason to use interlacing anymore unless you specifically require interlacing for your final output, since progressive is more efficient and, if done right, better looking too.

[LoRd_MuldeR]

I don't see any reason to use interlacing anymore unless you specifically require interlacing for your final output

And that's the point. If you can only decide between 25p and 50i, then 50i might be the better solution for "high motion" footage (e.g. Sports).

[Sagekilla]

Why only 25p and 50i though? I'd just go for 50p in that case.

[LoRd_MuldeR]

Why only 25p and 50i though? I'd just go for 50p in that case.

I said 50i might be the preferred solution for some content, given that you can only choose between 25p and 50i. Of course 50p would be even better ;)

So the question: Is 50p officially supported by the BR specs? Are there any such discs available? :confused:

[Guest]

Interesting--but we'd have to confirm it actually works first. I know that Avail, for example, does actually use the pic timing SEIs for this purpose, and they would have to check to see if the pic_order_present_flag is sufficient to make the STBs display the video correctly. I already KNOW it works. That's how broadcasters signal the field order for MBAFF. It's the whole point of delta_pic_order_cnt_bottom.

Guys, can we please not get into any useless interlace bashing discussions? I know how you feel, but it's not going to go away any time soon. It's still a useful form of compression when high temporal resolution is required.

I've offered a simple fix that is generally used by broadcasters and follows the spec. It should be easy to implement.

[Dark Shikari]

I already KNOW it works. That's how broadcasters signal the field order for MBAFF.That doesn't mean it necessarily works for everything, especially since were told explicitly by Sigma Designs that we should use pic timing struct SEIs (then again, they also wanted to us to use a really obscure portion of that struct that I've never seen used in any stream ever, so who knows...)

This does sound rather easy to implement though, so I'll probably write a short patch sometime and pass it off to Avail to see if it works for them.

Another thought: should we remove the --interlaced commandline and simply made it --tff and --bff, since it doesn't make sense to do interlaced encoding without signaling a field order?

[LoRd_MuldeR]

So what will happen with Avail's efforts to implement full MBAFF support, if interlacing support is dropped from x264 git?

Will it be maintained as a patch and will it be publicly available?

[Guest]

That doesn't mean it necessarily works for everything, especially since were told explicitly by Sigma Designs that we should use pic timing struct SEIs (then again, they also wanted to us to use a really obscure portion of that struct that I've never seen used in any stream ever, so who knows...) Well, I'm STMicro, asking you to use the coding layer and not the SEI layer. :) Of course, the decoder must honor delta_pic_order_cnt_bottom according to spec.

This does sound rather easy to implement though, so I'll probably write a short patch sometime and pass it off to Avail to see if it works for them. I'd appreciate it. I can provide broadcast streams that demonstrate it if you need them.

Another thought: should we remove the --interlaced commandline and simply made it --tff and --bff, since it doesn't make sense to do interlaced encoding without signaling a field order? Definitely yes!

[Shinigami-Sama]

So what will happen with Avail's efforts to implement full MBAFF support, if interlacing support is dropped from x264 git?

Will it be maintained as a patch and will it be publicly available?

they have to release the patch if anyone asks for it
infact someone asked in the IRC channel a little while ago and we had a link pretty quck after that

[LoRd_MuldeR]

they have to release the patch if anyone asks for it

No, they don't! The GPL says that if you modify GPL'd code and decide to give away a binary of it, then the receiver can request the source codes of it.
However you can modify a GPL'd software and keep your modifications in private. That is: You never release any binary or any sources...

[Shinigami-Sama]

No, they don't! The GPL says that if you modify GPL'd code and decide to give away a binary of it, then the receiver can request the source codes of it.
However you can modify a GPL'd software and keep it in private. That is: You never release any binary or any sources...

dark said they're required to release it, then provided a link so...

[LoRd_MuldeR]

dark said they're required to release it, then provided a link so...

Not, they are not required to release a modified version. But if they decide to release it, then they must make the sources available too.

That is described in #4 of the above points. It's from German Wikipedia.


I also found the statement in the English Wikipedia:Copyleft applies only when a person seeks to redistribute the program. One is allowed to make private modified versions, without any obligation to divulge the modifications as long as the modified software is not distributed to anyone else. Note that the copyleft applies only to the software and not to its output (unless that output is itself a derivative work of the program); for example, a public web portal running a modified derivative of a GPL'ed content management system is not required to distribute its changes to the underlying software.


[EDIT]

Sorry, for the off topic. I won't post any further comment to the legal discussion. But I still hope for a definite answer to post #28, which I think is on topic :)

[Guest]

Guys, stay on topic. This is a technical discussion of a purported bug. You have been warned.

You can open a new thread to discuss legal issues if you wish.

[Manao]

Beware : though it is indeed recommended to use a different POC for top and bottom fields (thus to use delta_pic_order_cnt_bottom), it's not "just" a matter of changing the way the slice header is written. POCs influence implicit weighted prediction and temporal direct, so you have to check that the computation of weights & temporal direct in x264 doesn't take any shortcuts that would have been made possible by using the same POC for top & bottom.

[Gabriel_Bouvigne]

Another thought: should we remove the --interlaced commandline and simply made it --tff and --bff, since it doesn't make sense to do interlaced encoding without signaling a field order?

--interlaced tff/bff : if someone wants to signal interlacing, he is also very likely to want to signal fields display order.

[qyqgpower]

current patch adds --tff(alias for --interlaced) and --bff switches, so just leave them as they were.

[Jay Bee]

Remove interlacing? Are you kidding? Thanks to to the recent improvements in x264 (psy rdo etc.) I've finally come to a point where I'm thinking about converting my high motion sports DVB streams to x264 and keeping them on Hard disk instead of burning them to MPEG-2 DVDs.

I might as well quit my testing right now if interlacing is about to be scrapped. Is this going to happen for certain?

You do realize that there is a whole world of broadcast content out there that isn't hollywood movies or animee? And you do realize that current GPU HW deinterlacing has such high quality that deinterlacing before encoding is a waste of time and filesize?

[Dark Shikari]

--interlaced tff/bff : if someone wants to signal interlacing, he is also very likely to want to signal fields display order.But my original plan was to use --interlaced to choose the MBAFF decision mode.

[Sharktooth]

@Jay Bee: and do you realize interlacing support is slowing down the encoder even if it's not used? do you realize you can deinterlace before encoding? do you realize modern videocards can deinterlace sources at high quality/speed BEFORE encoding?
interlacing is an abomination and must die... period.

[Dark Shikari]

@Jay Bee: and do you realize interlacing support is slowing down the encoder even if it's not used?Not significantly, and if you were that obsessive, you could do what certain decoders do and provide two codepaths.

[LoRd_MuldeR]

@Jay Bee: and do you realize interlacing support is slowing down the encoder even if it's not used? do you realize you can deinterlace before encoding? do you realize modern videocards can deinterlace sources at high quality/speed BEFORE encoding?

The problem here is: If you already have a 25i source (as it exists in realty, if we like that or not), then deinterlacing before encoding is not the perfect solution. If you deinterlace 25i to 25p, you loose temporal resolution, which isn't acceptable for "high motion" stuff (e.g. sports). And if you bob your 25i source to 50p, then you unavoidably get some overhead. Compared to an 25i encode of the same source, the 50p encode will require more bitrate for the same quality. Of course the bobbed 50p has more redundancy than a "real" 50p source, so the bitrate won't double (compared to 25i). However there will be some overhead for sure...

[Sharktooth]

that's why interlacing must die.

[Guest]

It's all OT guys. I am going to ask one final time and then start striking. Please open a new thread to discuss the pros and cons of interlacing. This is a technical thread about a specific purported bug in x264. You are welcome to open any kind of thread you like but established threads must remain on topic. Thank you.

[Quark.Fusion]

Another thought: should we remove the --interlaced commandline and simply made it --tff and --bff, since it doesn't make sense to do interlaced encoding without signaling a field order?

IMHO it's better to make tff and bff parameter of interlaced switch — less switches and more logical. --tff and --bff can be short aliases.

[pcat]

that's why interlacing must die.

Why such hateful comments regarding interlacing ? "must die", "should have never existed", "must be dropped" ?

Of course 50p/60p would be ideal, but...
- is it widely supported ?
- is x264 efficient at encoding 50p/60p ?

Do you recommend to drop x264 when dealing with high motion ?

[Guest]

@pcat

You were warned three times to stay on topic. Struck for rule 3.