okay, thanks.
So I'm gonna try the unstable repository and see if I still have these framerate issues using yadif.
But I guess since all features have been merged this doesn't mean that yadif is available on Windows (because it's done using vaapi)?
Yadif should be available in windows, but only when doing sw decoding. VAAPI takes a special path and output via VAAPINV12 render
(2014-11-30, 21:39)tommy_99 Wrote: [ -> ]To bad FernetMenta that you are not going to fix this.
It has worked already in Gotham with VAAPI without any issue and now it looks like that is broken completely (see Fritsch's - Posting - at the moment removing black bars does not work with VAAPI but is also broken on Software when Yadif is enabled).
Im wondering only why you are going to drop an so good function. Does Intel has droped the support for Openelec, is this the reason?
(2014-11-30, 18:55)FernetMenta Wrote: [ -> ]crop black bars was never intended to work with vaapi. the actual issue is that the option is visible in video settings dialog. Apart from this the feature is unreliable, means it does not work with many material.
Probably I move this setting to advanced setting before entirely drop it in some future version.
The facts:
- this feature does not work reliable
- it was not implemented correctly
- it has never worked with vaapi in official repo
- it requires desktop power and only a very small number of entire xbmc/kodi users have such systems in use
- and a even smaller number own outdated plasmas which may require this feature
I am not going to spend time on something only 0.0x user may use. Further I seriously doubt that black bars burn-in is still an issue and if so this feature should be implemented in the tv sets that suffer from the issue.
You right that it use CPU Power, but with the other things you are not right.
1. It worked with Openelec Gotham since beta phase up to last gotham release without any issue and vaapi decoding.
2. The best testet TV's Sets for last years are Plasmas from Panasonic (VT60, VT50, Z60) and many of enthusiasts have them.
By the way, Oleds will have the same problem, because the agening of oleds display will not be the same if used most of times with black bars because they aged faster when they shine and that will produce over time brighter lines where bars where previosly.
3. You are right when you say that not many plasmas are left, but OLEDS are coming and the remoal of black bars feature is i think not the best way to cut development time.
But is ok, when you are not interested in this feature at the Moment, maybe someone from Panasonic, LG(OLED) and Samsung(OLED) will read this thread and motivate
you to implement this feature again.
So long
(2014-12-01, 21:28)FernetMenta Wrote: [ -> ] (2014-11-30, 21:39)tommy_99 Wrote: [ -> ]To bad FernetMenta that you are not going to fix this.
It has worked already in Gotham with VAAPI without any issue and now it looks like that is broken completely (see Fritsch's - Posting - at the moment removing black bars does not work with VAAPI but is also broken on Software when Yadif is enabled).
Im wondering only why you are going to drop an so good function. Does Intel has droped the support for Openelec, is this the reason?
(2014-11-30, 18:55)FernetMenta Wrote: [ -> ]crop black bars was never intended to work with vaapi. the actual issue is that the option is visible in video settings dialog. Apart from this the feature is unreliable, means it does not work with many material.
Probably I move this setting to advanced setting before entirely drop it in some future version.
The facts:
- this feature does not work reliable
- it was not implemented correctly
- it has never worked with vaapi in official repo
- it requires desktop power and only a very small number of entire xbmc/kodi users have such systems in use
- and a even smaller number own outdated plasmas which may require this feature
I am not going to spend time on something only 0.0x user may use. Further I seriously doubt that black bars burn-in is still an issue and if so this feature should be implemented in the tv sets that suffer from the issue.
just a quick update: I tested the unstable repository and the current openelec 5.0 preview (4.97.1)
I get the same result :/ (47.95 fps until I stop the movie, if I resume it I get nice 23.98 fps)
The problem is not just the framerate itself, the deinterlacing also looks really bad.
Can somebody reproduce this behaviour ...?
at least with openelec my basic setup should be alright I guess (no bad drivers, packages, etc ...)
(2014-12-03, 08:48)tommy_99 Wrote: [ -> ]The best testet TV's Sets for last years are Plasmas from Panasonic (VT60, VT50, Z60) and many of enthusiasts have them.
As an enthusiast you would need a new telly every year anyway. If your TV shows a black bars burn-in within one year, RMA it and get a new one.
(2014-12-03, 08:48)tommy_99 Wrote: [ -> ]3. You are right when you say that not many plasmas are left, but OLEDS are coming and the remoal of black bars feature is i think not the best way to cut development time.
But is ok, when you are not interested in this feature at the Moment, maybe someone from Panasonic, LG(OLED) and Samsung(OLED) will read this thread and motivate you to implement this feature again.
I use OLEDs at work all the time and love them (They have replaced CRTs for quality picture monitoring in broadcast - LCDs have never quite delivered in that arena, and plasmas are too big and dither too much).
But sadly it appears that Samsung are not likely to pushing them that hard now that they are concentrating on Quantum Dot LCDs.
http://www.cnet.com/uk/news/samsung-says...next-year/
Does look like 4K is really pushing LCDs to the fore (it is what has killed plasmas, and may well delay OLEDs before they really take hold)
Hi guys,
as discussed with fritsch briefly in irc here are details of my problem, let me know if you need any more info.
Problem:
Renderer is frequently detecting changes in 1080i live tv video properties which results in momentary dark flashes/blinks on screen as it reconfigures
System:
- Kodi 14 RC2
- configured as per
http://forum.kodi.tv/showthread.php?tid=165707
- SNB vaapi enabled
- auto deinterlace,Bob,bilinear
- source material live tv 1080i h264 served via tvheadend 3.4.27
Observations:
- variable frequency of screen flashes between channels and source programmes
- no visual artefacts other than screen flash is observed
- not specific to Bob, also happens with "De-interlace" method although VAAPI-BOB method shows video picture quality "glitches" rather than renderer flashes
- tvh debug log shows no errors on its side when problem occurs in kodi
- also occurs with recorded livetv using tvh's "passthrough mode" saving to .ts file so assumed raw and untouched by tvh?
- deinterlacing-test.mp4 plays without exhibiting the problem
Logs:
- Hollyoaks debug log
http://paste.ubuntu.com/9429918/
- Hollyoaks .ts file
https://www.dropbox.com/s/tiic24k25ai4ew...05.ts?dl=0
The scene with the woman in the leopard print jacket speaking on the phone displays the problem frequently through the scene for me
- Hollyoaks .ts file mediainfo
http://paste.ubuntu.com/9430615/
- deinterlacing-test.mp4 debug file (for comparison)
http://paste.ubuntu.com/9430580/
I did not see that this afternoon, same issue if you run without "unity"? :-)
Quote:17:45:38 T:139887412017088 DEBUG: Window Manager Name: Compiz
I've chosen kodi session at the lightdm login screen so it runs standalone and re-ran the test but I get the same problem.
I was getting screen tearing running kodi under fluxbox so I lazily went back to the default wm the other day instead of trying to fix it!
In the UK on DVB-T2 the encoders auto detect interlaced vs progressive and flag accordingly.
The sample is progressive, but there is an interlaced deaf signer overlaid so depending on how much he moves the flags are constantly changing.
ph4[int-prog-2]$ ffprobe -show_frames stream.ts 2>/dev/null | grep video -A 19 | grep interlac | uniq -c
614 interlaced_frame=1
126 interlaced_frame=0
252 interlaced_frame=1
40 interlaced_frame=0
413 interlaced_frame=1
66 interlaced_frame=0
45 interlaced_frame=1
23 interlaced_frame=0
19 interlaced_frame=1
32 interlaced_frame=0
109 interlaced_frame=1
63 interlaced_frame=0
365 interlaced_frame=1
14 interlaced_frame=0
182 interlaced_frame=1
10 interlaced_frame=0
770 interlaced_frame=1
429 interlaced_frame=0
332 interlaced_frame=1
34 interlaced_frame=0
134 interlaced_frame=1
662 interlaced_frame=0
27 interlaced_frame=1
910 interlaced_frame=0
833 interlaced_frame=1
91 interlaced_frame=0
127 interlaced_frame=1
42 interlaced_frame=0
550 interlaced_frame=1
Yes. All UK Freeview HD (DVB-T2) broadcasts use the adaptive progressive/interlaced switching encoder profile. This will dynamically switch between 1080/25p and 1080/50i encoding on a GOP-by-GOP (I believe) basis - allowing material shot 1080/25p (but carried in a a 1080/50i wrapper) to be detected and compressed more efficiently.
This confused a lot of early DVB-T2 TVs here - particularly Sony sets which would sound glitch on the format change.
Currently the same channels on DVB-S2 are using standard 1080/50i permanent encoding (albeit with MBAFF interlaced encoding)
Ah good info, that explains the screen flash as renderer reconfigures itself on the change of format. A random check of some DVB-T2 recordings using that ffprobe command does show the mixed progressive/interlaced content.
Seems some programmes are switching format frequently even between different camera shots in the same drama scene, which I find a little odd, and can lead to frequent screen flashes. Either that or maybe the encoders used aren't perfect and sometimes flagging frames incorrectly? Of course now I'm sensitive to the flashes I can't unsee them and they're annoying me now on every change!
Hollyoaks (without the deaf signer) seems to be a heavy user of the switching between camera shots, it would be interesting if anyone else can record the DVB-T2 broadcast at 6.30pm Tue on CH4HD and look for the format changes in scenes just to confirm they're there and not something tvh is introducing for me - anyone a DVB-T2 user? You don't have to be a hollyoaks watcher, I'm not either, but it's now my test broadcast
It also explains why when I tried xbmc on my android box a while back, it was unwatchable during the proper HD programme but would play perfectly when the commercials were on.
Here's a short clip of interlaced format changes, there are two at 10secs and 17secs which produce the screen flash. Pressing 'o' on kb you can see the W(fps:num) switching between 25 an 50.
Using vaapi but either disabling deiniterlacing or forcing it on does not produce the screen flash, just to confirm it is the format changes causing it.
Switching off vaapi to use software decoding does not produce the screen flash.
https://dl.dropboxusercontent.com/u/1021...s40secs.ts (23MB)
ffprobe -show_frames hollyoaks40secs.ts 2>/dev/null | grep video -A 19 | grep interlac | uniq -c
235 interlaced_frame=0
178 interlaced_frame=1
569 interlaced_frame=0
(2014-12-09, 03:02)Dogchow Wrote: [ -> ]Ah good info, that explains the screen flash as renderer reconfigures itself on the change of format. A random check of some DVB-T2 recordings using that ffprobe command does show the mixed progressive/interlaced content.
Seems some programmes are switching format frequently even between different camera shots in the same drama scene, which I find a little odd, and can lead to frequent screen flashes. Either that or maybe the encoders used aren't perfect and sometimes flagging frames incorrectly? Of course now I'm sensitive to the flashes I can't unsee them and they're annoying me now on every change!
Hollyoaks (without the deaf signer) seems to be a heavy user of the switching between camera shots, it would be interesting if anyone else can record the DVB-T2 broadcast at 6.30pm Tue on CH4HD and look for the format changes in scenes just to confirm they're there and not something tvh is introducing for me - anyone a DVB-T2 user? You don't have to be a hollyoaks watcher, I'm not either, but it's now my test broadcast
It also explains why when I tried xbmc on my android box a while back, it was unwatchable during the proper HD programme but would play perfectly when the commercials were on.
Interesting. Hollyoaks is shot 25p - but any dissolves or wipe/fade to black transitions will be 50i (as is required by all UK broadcasters for 25p shot content) as will all rolling/crawling credits. With no overlaid 50i sign-language interpreter, I'd expect the encoder to be 25p for most of the time, but shot changes could also trigger a drop to 50i (as it is the safer of the two encoder profiles) until the encoder has decided the next shot is also 25p?
I guess it is a problem for Kodi to 'know' that an MPEG2 transport stream with H264 video that is constantly switching between 25p and 50i GOP-by-GOP should be treated as 50i constantly (or any transitions between 25p and 50i deinterlaced to 50p should be transparent?)
As a matter of interest 1080i 4:2:2 interlaced stuff isn't detected as interlaced by XBMC (or wasn't last time I checked) and you have to force de-interlacing to be on to get it de-interlaced as well. (There were also rendering issues with 4:2:2 interlaced 50i content which caused saturated content to look 25p even when de-interlaced)