I demand that Reinhard Nissl may or may not have written...
Darren Salt wrote:
Cool -- are you relying on XINE_STREAM_INFO_VIDEO_AFD?
Yes.
My implementation in libmpeg2 is not perfect. It lacks stacking (AFD information may be valid for a sequence, group or frame, i. e. the AFD for a sequence could be overridden for a single frame duration by a frame AFD) and cannot detect XINE_VIDEO_AFD_NOT_PRESENT.
My code is currently broken wrt some transitions and when paused, but this could be an effect of breakage in your code. (I'm attaching the patch for reference.)
Would you provide me a sample stream which contains some transitions between different XINE_VIDEO_AFD_* values?
URL:http://zap.tartarus.org/~ds/001.vdr is a short clip with one transition and a corresponding aspect change - AFD 14 to AFD 9, 16:9 to 4:3.
The attached patch against xine-lib-cvs/src/libmpeg2 fixes the above mentioned issues (and contains the vdr-xine changes, too).
There's still a pause problem (URL:http://zap.tartarus.org/~ds/002.vdr). That may be caused by my code, though I don't see how when shoot-and-protect isn't enabled.
decode.c contains two fprintf() debug statements: one reports the detected AFD value and whether it was detected at [S]equence, [G]roup or [P]icture level.
Early results show BBC, ITV and Five using picture, and Channel 4 using sequence.
The other statement reports AFD changes.
Be aware that AFD changes are detected in decoding order of the pictures. Further changes would be necessary to have them reported in display order (see comment in decode.c).
Rounding to group /may/ be sufficient - sloppiness with the changes isn't unknown, although some of that may be due to set-top box manufacturers cutting corners.
(I'll be putting this patch or a followup patch in my .debs.)