I've proved it can't work, even if you start from uncompressed YUV (see post #103).
If you still don't understand: let's say you have a function y = f(x), where x ranges from say -128 to +128, and let's say you have f(x) = x/100 (or something close to that). You can look at y and you should recover x. There's one little issue: you are working on integer math 
ah sorry, i didnt want to say it will work with the current state of implementation.
should have added "somehow", that would explain what this fragment of sentence should have expressed.
if you squeeze the integer range with a custom pic style / lut, you will lose color resolution but can cover the exposure ranges.
this will for sure raise some other problems too, no doubt!
and even if there is a workaround that is capable of cover the re-quantization (14 to yuv) properly, the H.264 compression is still lossy.
what i wanted to make clear:H.264 is based on removing data your eye (brain) doesnt really need to see whats happening.
but in the case dual_iso the obvious thing isnt the interlaced bright/dark line thingy, but the relatively small deltas on top of that.
and H.264 algorithms will now try hard in reducing that "unimportant" data.
there could be one lucky circumstance: the vertical pattern equals the maximum vertical frequency that can be expressed with DCT parameters.
this would allow the encoder to use only fewer bits for describing that pattern. but i am quite sure the encoder can not detect that 1/2 * f_max pattern.
it will most likely detect a 1.9999998 * f_max + 0.00000001 * (f_max-1) - 0.00000001 + (f_max - 2) etc.
so we lose a lot more bits on describing that pattern.
-> reduced details in the whole image
