multi-threads break hd dvd compliance (bug?)

[vmrsss]

No, again, you are making false assumptions and thus deducing false conclusions.

Just because a setting triggers a problem does not mean the setting is at fault for the problem.

Yes, I understand and agree entirely with that!

Your device cannot handle this, yet you still refuse to stop using a min-keyint that is incompatible with it!

Well, where have you read that? I am not refusing to do anything, I am just trying to understand what's going on; I have tried all your suggestions, reported that it appears to work with --min-keyint 4, but I am not yet convinced this is the final solution, because with --min-keyint > 3 some frames are mysteriously omitted by the muxer. I conjecture there might be a bug in the muxer, not in x264! (in one of my previous posts I asked explicitly whether it is the muxer that by removing frames breaks compliance!) and asked your opinion and help to look inside those .EVO files.

I don't care if you are incapable of listening to basic instructions to solve your own problems, but I don't want you spreading FUD about "bugs in x264"--we have enough real bugs and don't need people to come up with fake new ones just to confuse people.

Please, calm down! I do not wish to upset you. I am not sure you are referring to me with that; if so, please accept my apologies, as you misunderstood my statements: when did I spread FUD about bugs? I am simply trying to investigate this issue with the highest regard for x264. And I think we are making good progress towards clarifying it...

Friendly,
-vmrsss

[Dark Shikari]

Yes, I understand and agree entirely with that!



Well, where have you read that? I am not refusing to do anything, I am just trying to understand what's going on; I have tried all your suggestions, reported that it appears to work with --min-keyint 4, but I am not yet convinced this is the final solution, because with --min-keyint > 3 some frames are mysteriously omitted by the muxer. I conjecture there might be a bug in the muxer, not in x264! (in one of my previous posts I asked explicitly whether it is the muxer that by removing frames breaks compliance!) and asked your opinion and help to look inside those .EVO files.



Please, calm down! I do not wish to upset you. I am not sure you are referring to me with that; if so, please accept my apologies, as you misunderstood my statements: when did I spread FUD about bugs? I am simply trying to investigate this issue with the highest regard for x264. And I think we are making good progress towards clarifying it...

Friendly,
-vmrsssI apologize, I was not paying enough attention to usernames and I though it was all one person :p

[vmrsss]

It's not my problem(i just keep an eye on all settings that break HW compatibility)

Exactly. As I said, this could be a problem with HW compatibility of a particular command line, or silly bug of silly Toast9 which while muxing breaks the stream generated by x264.

Damn and i read it twice too, i didn't see his min-keyint in the first post. If he stops using that the file should work.

Why do you say so? It sounds as though you knew that 2 is the wrong value for that parameter, which cannot be the case. Please read my recent post, the more I raise --min-keyint the more frames are dropped by the muxer. Is that normal/expected?

That is where I started to think that this may all be a red-herring, and after all there might be nothing wrong with --min-keyint 2 nor with my device, and that is the conjecture I am trying to test at the moment...

PS. Again, lest we misunderstand each other, I am not saying x264 is at fault. I am investigating an issue with HW compatibility.

[Sharktooth]

ok, so try using a different muxer and see if the problems persists

[vmrsss]

so whats the problem?

the answer is:
no it's not a bug. rise the min-keyint if you use more than 1 thread.

Just trying to understand you: you speak as though you knew I was obviously doing something wrong in --min-keyint 2, which I am not as I took it from MeGUI's SA-HD-DVD profile (which is yours, if I am not mistaken).

If instead your sentence is because of what you read in this thread, I would like to remark that the statement that --min-keyint 4 solves the problem is not a proven fact, it is just a conjecture of mine which I am still in the process of checking out.

I would be very happy however to agree that this is not a bug with x264 (can I change the thread's title?), so that nobody has to feel defensive in this discussion.

[vmrsss]

No, he should raise it even if he's only using one thread, because the fact that one thread worked fine is sheer luck/coincidence.

Agreed.

[Sharktooth]

i was going by logic. 2 doesnt work, 4 does... keep 4.
however, have you access to another muxer? coz if not, we wont be able to estabilish if that's a muxer problem or not.

[vmrsss]

ok, so try using a different muxer and see if the problems persists

Trying with the tools I have. I am having problems with mplayer, seem to be having some success with ffmpeg and VLC. Unfortunately, I don't seem able to find an alternative to generate the HDDVD_TS folder with Toast, which is indeed the weakest link in the chain...

[vmrsss]

however, have you access to another muxer? coz if not, we wont be able to estabilish if that's a muxer problem or not.

If I fail to find one, I will try again to look inside the EVO files generated by Toast. Incidentally, do you know of any tool for doing that?

[tetsuo55]

If I fail to find one, I will try again to look inside the EVO files generated by Toast. Incidentally, do you know of any tool for doing that?

Do you have access to a windows(dualboot or VM)

[vmrsss]

Do you have access to a windows(dualboot or VM)

Yes, via Parallels.

[Sagittaire]

1) You use certainely Sonic scenarist for the mux and Sonic Cinevision encoder profil use 4 frames for minimum interval between Iframe. Perhaps simply muxer limitation here.

2) For HDDVD compliant stream all the Iframe must be IDR.

[tetsuo55]

maybe this helps??

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

[Sharktooth]

as i did for blu-ray megui presets, i ensured they will work on ALL HD-DVD compatible HW/SW, so i will keep min-keyint 4 in the HD-DVD presets.

[tetsuo55]

as i did for blu-ray megui presets, i ensured they will work on ALL HD-DVD compatible HW/SW, so i will keep min-keyint 4 in the HD-DVD presets.

Are you sure its needed? Dark Shikari said x264 already respects the limits required.
Also vmrsss said that although it fixes the first problem it causes a new one

[Sharktooth]

i dont care. 4 is ok and seems to work well with hd-dvd sw/hw.

[vmrsss]

2) For HDDVD compliant stream all the Iframe must be IDR.

is that so?, i didn't realise it before. this is not the way x264 operates, can it be controlled from the command line?

[Quark.Fusion]

Correct me if this is wrong, but:min-keyint

Integer: 25

Sets the minimum length between IDR frames. See keyint for an explanation of IDR frames. Very small IDR ranges can reflect incorrect frame placement (for example, a strobing scene). This option limits the minimum length after each IDR frame before another can be placed.

Recommendation: Default, or whatever your framerate is.

See also: keyint (http://mewiki.project357.com/wiki/X264_Settings#keyint), scenecut (http://mewiki.project357.com/wiki/X264_Settings#scenecut)
Why you set min-keyint so small? It's not about I-frames versus non-I-frames — it's about normal-I-frame vs IDR-I-frame.

2) For HDDVD compliant stream all the Iframe must be IDR.
Where it from?


P.S. is IDR stays for "I Delete References"? :)

[kemuri-_9]

The major reason to reduce the min-keyint/max-keyint values is to increase the frequency of IDR frames to improve seeking.

since i'm not all that good with names of things, wikipedia had the answer of Instantaneous Decoding Refresh

as for x264 producing non-IDR i-frames, afaik the only way it produces them is when it's told to via a qpfile.
Would need akupenguin or DS's confirmation on this though.

[Dark Shikari]

The major reason to reduce the min-keyint/max-keyint values is to increase the frequency of IDR frames to improve seeking.

since i'm not all that good with names of things, wikipedia had the answer of Instantaneous Decoding Refresh

as for x264 producing non-IDR i-frames, afaik the only way it produces them is when it's told to via a qpfile.
Would need akupenguin or DS's confirmation on this though.If scenecut triggers but min-keyint hasn't been reached, it uses an I-frame instead of IDR.

[Quark.Fusion]

So on first frame of strobing scene x264 deny references to previous frames and drops new IDR every min-keyint? Or that case can be only with pre-scenecut?

[vmrsss]

i dont care. 4 is ok and seems to work well with hd-dvd sw/hw.

Unfortunately, I can't confirm yet. I spent a lot of time on this, without any real result. I downloaded all the muxer/burners with a trial period I could find, but for one petty reason after another I couldn't get any of them to accept the h264 generated by x264. So, no actual burning, no actual tests on the HW. Very frustrating.

[vmrsss]

If scenecut triggers but min-keyint hasn't been reached, it uses an I-frame instead of IDR.

Does this mean that --min-keyint 1 forces all I-frames to be IDR-frames?

[Dark Shikari]

Does this mean that --min-keyint 1 forces all I-frames to be IDR-frames?Yes, it does.

[F J Walter]

Is it at all possible that there could be an HD-DVD compliance issue caused by using I frames which are not IDR?

Sagittaire mentioned this above but sofar nobody has confirmed or denied it.

If that is plausible, it might be worth checking vmrsss' "threads 1 without pre-scenecut" output to see if it just happens to have no I frames which are not IDR. It might also be interesting to do an encode with min-keyint of 1 (just for troubleshooting; I know it's off-spec) to see if that causes any problems with the muxer or hardware player.

[vmrsss]

Sagittaire mentioned this above but sofar nobody has confirmed or denied it.

I found another reference to this in the context of a posting about main concept as a compliant HD-DVD encoder. I've been reading pages and pages, I dont yet have a view myself.

If that is plausible, it might be worth checking vmrsss' "threads 1 without pre-scenecut" output to see if it just happens to have no I frames which are not IDR.

How do I tell whether or not an I-frame is an IDR-frame? Can anybody kindly explain the detailed meaning of eg:

x264 [debug]: frame= 0 QP=17.42 NAL=3 Slice:I Poc:0 I:6120 P:0 SKIP:0 size=41769 bytes
x264 [debug]: frame= 1 QP=19.90 NAL=2 Slice:P Poc:4 I:0 P:262 SKIP:5858 size=478 bytes
x264 [debug]: frame= 2 QP=25.00 NAL=0 Slice:B Poc:2 I:0 P:151 SKIP:5969 size=163 bytes


It might also be interesting to do an encode with min-keyint of 1 (just for troubleshooting; I know it's off-spec) to see if that causes any problems with the muxer or hardware player.

Will do. (I am currently experimenting with Nero; I finally managed to get it to accept my h264 raw stream, but still can't prevent it from re-encoding them.)

[kemuri-_9]

How do I tell whether or not an I-frame is an IDR-frame?

in the .stats generated by x264
i.e.
in:500 out:500 type:I q:16.45 itex:165538 ptex:0 mv:23069 misc:337 imb:1350 pmb:0 smb:0 d:s;
a type of upper case 'I' is an IDR frame
a type of lower case 'i' is a regular i-frame

so can run grep/find on the .stats looking for "type:i" and if any hits occur, it has i-frames:
windows: find "type:i" xxx.stats
linux (or with gnuwin32 tools for windows): grep type:i xxx.stats

[vmrsss]

I think we can write the bottom line of this thread.

I have finally managed to feed another muxer with x264's output, and guess what: the muxer likes x264 and the toshiba hd-e1 plays the resulting hd-dvd perfectly, with --min-keyint = 1, 2, 3, ..., 14 (and --bframes 3, --ref 4, --b-pyramid and all the rest), 720x576, 1280x720, 1440x1080 and 1920x1080.

I suppose this finally proves that it was all due to a bug with buggy Roxio Toast; not the first time I'm forced to make this observation after having wasted precious days. Indeed, the fact that it autonomously dropped frames when muxing was a strong indication that something wasn't quite right. Quite why then Toast appears to mux well h264 streams generated without --pre-scenecut and fails hopelessly with --pre-scenecut I will probably never know. Yet, quite frankly, I don't give a toss. I am going to buy something else anyway. (A just in time decision, as next week it is back to work, and at least till Xmas I won't be able to spend this sort of time on my encoding hobby :-)

Thanks everybody for paying attention to me, and apologies for wasting your time too. Please feel free to round this up, if there is anything you want to add/ask.

-vmrsss

[Sharktooth]

cool, so i can set min-keyint back to 2 into the megui hd-dvd presets... damn toast...

[vmrsss]

cool, so i can set min-keyint back to 2 into the megui hd-dvd presets... damn toast...

Indeed. Mind you, we have not really learned more about what is and what is not HD-DVD compliant: also --min-keyint 1 (as suggested in a post by Sagittaire) works well (and I am using --ref 4 --bframes 3 --b-pyramid just as well).

[Sharktooth]

i wont include b-pyramid in any hardware compatible presets until it gets properly fixed.