I demand that Reinhard Nissl may or may not have written...
> Darren Salt wrote:
>>> Cool -- are you relying on XINE_STREAM_INFO_VIDEO_AFD?
>>> 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
>>> 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
> 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
> 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
Early results show BBC, ITV and Five using picture, and Channel 4 using
> 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
(I'll be putting this patch or a followup patch in my .debs.)
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Lobby friends, family, business, government. WE'RE KILLING THE PLANET.
You will visit the Dung Pits of Glive soon.
vdr mailing list