[Milhouse]

No new build today - network/routing problems with BT (my ISP) mean it's impossible to reliably download (from git/github) or upload (to ftp server). Not sure when the problem will be resolved as BT are yet to accept there is even a problem despite multiple reports from users nationwide throughout the day. Ho hum.

[popcornmix]

No new build today - network/routing problems with BT (my ISP) mean it's impossible to reliably download (from git/github) or upload (to ftp server). Not sure when the problem will be resolved as BT are yet to accept there is even a problem despite multiple reports from users nationwide throughout the day. Ho hum.

If anyone is missing out I did a Milhouse-style build.
https://drive.google.com/file/d/0B-6zmED...sp=sharing

Highlights.
New firmware with fixes for timestamps (fix for time jumping to zero when seeking/ff/rew)
HD advanced deinterlace should now trigger turbo mode automatically.
Improved smoothness with ff/rew.
Some files where video stopped before audio at end of file should be improved.

Changes:

New firmware:
firmware: arm_loader: Make turbo request reference counted rather than boolean
firmware: di_adv: Request turbo mode when doing qpu deinterlace
firmware: video_decode: fixes to timestamp handling

newclock4:
[mmalcodec] Use both dts and pts for determining amount of queued data
dvdplayer - consider clock not last frame on screen when going rewind PR7655

[wchick132]

@popcornmix and @Milhouse

I just noticed that in Kodi official release, it's using ffmeg 2.6.3, whereas for RPi/RPi2 version, ffmeg was bumped to 2.7.1 in built #0713. Is it possible that it's the ffmeg that lead to problem in x265/HEVC video playback?

Is it possible to have a build with rolled back to pre- ffmeg 2.7.1 (or ffmeg 2.6.3 specifically) for me to test?

[popcornmix]

I just noticed that in Kodi official release, it's using ffmeg 2.6.3, whereas for RPi/RPi2 version, ffmeg was bumped to 2.7.1 in built #0713. Is it possible that it's the ffmeg that lead to problem in x265/HEVC video playback?

I don't think it's ffmpeg. I think it's a kernel update to firmware/mailbox driver which is heavily used by gpu accelerated hevc.
Note: gpu accelerated hevc is only in milhouse builds, so official OE shouldn't have this issue (but hevc performance is lower).

[zaphod24]

Thanks for keeping thing going popcornmix! Those latest firmware changes look nice.

What is the overclock recommendation for 1080i60 playback using advance deinterlacing at this point? I've been using gpu_freq=300 with success, but every now and then a news ticker will get jittery. It gets even more so when I bring up the playback information overlay to see if it is skipping frames.

Also, for using advanced deinterlacing, what are the recommended settings for "adjust display refresh rate to match video" (mine is on) and "sync playback to display" (mine is on and using method resample audio) ?

[delinend]

I just tested many movies on RPi1 and 2 (MP4/DVD/ISO/PAL/24p/25p) after "The "prefer pts" option is gone."
And all content play's super smooth via OMX=on and MMAL=off and No overclocking here.

Great ! Thanks popcornmix and Milhouse for all your works.

[wchick132]

I just noticed that in Kodi official release, it's using ffmeg 2.6.3, whereas for RPi/RPi2 version, ffmeg was bumped to 2.7.1 in built #0713. Is it possible that it's the ffmeg that lead to problem in x265/HEVC video playback?

I don't think it's ffmpeg. I think it's a kernel update to firmware/mailbox driver which is heavily used by gpu accelerated hevc.
Note: gpu accelerated hevc is only in milhouse builds, so official OE shouldn't have this issue (but hevc performance is lower).

How about OE 5.95.3, does it also uses gpu accelerated hevc? Please note that the OE 5.95.3 also has the same x265/HEVC playback problem as build #0714.

[popcornmix]

Thanks for keeping thing going popcornmix! Those latest firmware changes look nice.

What is the overclock recommendation for 1080i60 playback using advance deinterlacing at this point? I've been using gpu_freq=300 with success, but every now and then a news ticker will get jittery. It gets even more so when I bring up the playback information overlay to see if it is skipping frames.

Also, for using advanced deinterlacing, what are the recommended settings for "adjust display refresh rate to match video" (mine is on) and "sync playback to display" (mine is on and using method resample audio) ?

Adjust display refresh rate to match video is recommended.
Sync playback to display is recommended with dvdplayer. (with omxplayer it's less important).
If "PLL adjust" works for you, then it is theoretically better. It can make small adjustments to audio/video sync without resampling audio, so avoids pitch warbles and works with passthough.
Some displays/receivers don't like it and you can get audio/video dropouts. Resample audio is the safer choice.

If you switch deinterlace to "bob" do you still get the same stutter?
We are hoping gpu_freq=300 is enough for 1080i60 advanced deinterlace, but it is quite close and a bit more may be safer.
Try removing "force_turbo", set "over_voltage=2" and "gpu_freq=400" and see if it works better.

[Milhouse]

If anyone is missing out I did a Milhouse-style build.

Thanks @popcornmix!

I probably won't be in a position to upload a new build tonight either - BT have just announced they've identified the fault in their network, but will only be able to implement the fix overnight. I'll publish a new build (with all the missed updates) once the fix is in, whenever that happens.

[doldi]

hi,
with the build #0729-gc37b5a7 my first RPi2 with hifiberryDACplus hang-off (freeze) with videoAddons (MTV.de).
Not able to handle this hardwired network rpi2. (fresh install)

The second rpi2 on my LCD TV over HDMI makes this Job better, but stops on playing between two Videos with this build

...switch back to #0721 and all work fine on both RPi2.

[doldi]

(OT)

Have any people testet here Windows 10pro?

I'm not able ( and also other people in the net) to share files on this System over smb - after 2 days a click on my Win7pro backup and all's right with the world.

Windowsdisaster²

:-)

[popcornmix]

I probably won't be in a position to upload a new build tonight either - BT have just announced they've identified the fault in their network, but will only be able to implement the fix overnight. I'll publish a new build (with all the missed updates) once the fix is in, whenever that happens.

Oh no! Don't BT know how important your internet connection is?

I'll try making another build as I've got a few new fixes for testing.
I've been giving Isengard branch some care and attention as release is imminent (OpenELEC and OSMC are close to releasing, but I've got a chance for a few last minute fixes).
Getting a build out with the new fixes in gives a chance to spot regressions before Isengard final is in widespread use.

[maxodolo]

will the "advanced deinterlacing" (which is *fantastic* by the way) also be included in the openelec isengard release?

Thanks,
Max

[popcornmix]

will the "advanced deinterlacing" (which is *fantastic* by the way) also be included in the openelec isengard release?

Not the first release. It's currently just a bit too risky (e.g. people enabling it without overclock and getting stuttery video).
When we get to a point where it is seamless (e.g. no overclock needed, or fully automatic overclock) then it might be added to Isengard branch.

I'll think about adding an advancedsetting to unlock it...

[popcornmix]

Another Milhouse-style build:
https://drive.google.com/file/d/0B-6zmED...sp=sharing

newclock4

• [omxplayer] Set audio properties for passthrough
  We weren't setting the stream_channels property for passthrough for omxplayer (we do with Pi Sink)
  That means we were using 2 in number of channels of the AudioInfoFrame packet, rather then 0
  which is 'refer to stream header' which is correct for passthrough
  
  
• [omxplayer] Allow automatic switching back to omxplayer after it has been disabled
  Omxplayer gets disabled when it is unsuitable (e.g. software decoder required, or ALSA audio or AC3 transcode).
  However if you play another file without quitting dvdplayer, it doesn't reconsider.
  E.g. play divx3 file and omxplayer is disabled. If you then launch a h.264 file while first file is still playing it doesn't switch
  back to omxplayer as you might expect.
  This patch allows a switch back to omxplayer mode
  
  
• [rbp] Leave 3D framepacking output disabled by default
  
  
• [omxplayer] Support per refresh rate display latency settings
  See here
  
  
• [mmalrenderer] Wait for vsync before submitting to mmal when display sync is disabled
  This avoids an issue where video occasionally goes stuttery after a seek, until the next pause/play or seek.
  The issue is when display sync is disabled, and framerate of video matches display, and render times are coincident with vsync
  you find that depending on timestamp/scheduling jitter, you may or may not get an update each vsync resulting in stuttery video.
  Some scheme to force render times to be dependent on vsync is required. We do this by blocking in RenderUpdate unto next vsync.