This is still the million-dollar question. Has there been any progress
on this front? I'm afraid the longer we wait, the less flexibility we
will have.
Oh my - I think the largest content owner moving to WebM is YouTube,
so I would chat with those guys if they can stop the transcoding and
apply a new format (aren't there Google people here who would have the
relationship to the right YouTube guys?). That new format would need
to be released asap though.
Just my 2c.
Silvia.
To be pedantic, this change does change the bitstream, though it does
not break any existing streams. I'm fine with accepting this patch
as-is to fix the issue today, but I think that a better approach is to
remove this "secondary" clamping for both the split and non-split
cases and do it at the prediction stage instead, which would make the
bounds checking implementation defined, which seems cleaner to me.
Both of these options need buy-in on the hardware side. The only other
option is to leave the mv-decoding as-is and do the bounds checking at
the prediction stage for split-mvs.
Based on the history of this code, I'm not sure that this secondary
clamping was communicated well to the hardware folks, so there's a
risk that there are multiple inconsistent implementations. The
hw-devel@ list has been created to provide a forum to discuss these
sorts of things, and we should bring this up there as the first order
of business once people have a chance to sign up.
For those following this thread, John's proposal has been committed in
the following two commmits:
http://review.webmproject.org/gitweb?p=libvpx.git;a=commit;h=3085025fa1392e99bc95a519657374f2e9a4249b
http://review.webmproject.org/gitweb?p=libvpx.git;a=commit;h=05c6eca4db7f2abec32c9ce0fc325d9a0b933fb7
These should supersede the patch I posted at the beginning of this thread.