Hello,
I just got new Vero 4K+. H.265 videos play perfectly, but I’m having issues with 4K H.264 files - there is visible stuttering. I have set it up with automatic frequency change, firmware is latest and network is 1GbE.
I tested it on few videos files and issue is similar, here is an example:
http://s1.demo-world.eu/uhd_trailers.php?file=samsung_seven_wonders_of_the_world_china_uhd-DWEU.mkv
I would appreciate any feedback on this.
This demo clip is a
H.264 AVC, high profile level 5.1 4K with 60 (60000/1001) frames per second
The underlying hardware architecture of the Vero is a AML S905X which supports (following the specs) up to
H.264 AVC, high profile level 5.1, 4K with 30 frames per second
You are right, that is bad example. What about following video?
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, RefFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2 h 1 min
Bit rate : 7 797 kb/s
Width : 3 840 pixels
Height : 1 600 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(PixelFrame) :* 0.053
Stream size : 6.60 GiB (61%)
Writing library : x264 core 152 r2851 ba24899
Encoding settings : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=4 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=7797 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No
On first view looks ok, where to download?
It’s a BluRay rip and I don’t have a sample.
It plays fine directly on Panasonic smart. With Vero it’s stutter-fest 
Shall I provide a log? Which one?
Did you rip it directly using a tool like MakeMKV, or was it ripped and then encoded with Handbrake to shrink the size?
As to logs:
To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.
Depending on the used skin you have to set the settings-level to standard or higher, in summary:
enable debug logging at settings->system->logging
reboot the OSMC device
reproduce the issue
upload the log set either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A
publish the provided URL from the log set upload, here
Thanks for your understanding. We hope that we can help you get up and running again shortly.
OSMC skin screenshot:
I don’t know witch tool was used for encoding.
Here are the logs from playback:
http://paste.osmc.tv/exodemiyef
That is a very strange frame size. A Bluray is normally 1980x1080 and a UHD would be 3840x2160.
Also the file size is very small for a Bluray. I’d suggest re-ripping the disc.
Well yes, but Panasonic is playing it fine…
Another example, same symptoms, same codec, same frame size:
| Format : | AVC |
|---|---|
| Format/Info : | Advanced Video Codec |
| Format profile : | High@L4.1 |
| Format settings : | CABAC / 4 Ref Frames |
| Format settings, CABAC : | Yes |
| Format settings, RefFrames : | 4 frames |
| Codec ID : | V_MPEG4/ISO/AVC |
| Duration : | 2 h 43 min |
| Bit rate : | 8 369 kb/s |
| Width : | 3 840 pixels |
| Height : | 1 600 pixels |
| Display aspect ratio : | 2.40:1 |
| Frame rate mode : | Constant |
| Frame rate : | 23.976 (24000/1001) FPS |
| Color space : | YUV |
| Chroma subsampling : | 4:2:0 |
| Bit depth : | 8 bits |
| Scan type : | Progressive |
| Bits/(PixelFrame) :* | 0.057 |
| Stream size : | 9.55 GiB (61%) |
| Writing library : | x264 core 152 r2851 ba24899 |
| Encoding settings : | cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=4 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=8369 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00 |
| Default : | Yes |
| Forced : | No |
Those frame sizes are completely out of spec. 4K should have a height of 2160, NOT 1600.
Because of that, it’s unlikely that the hardware decoder in the 4K can handle it. You could try turning off the hardware decoder and decode in software instead.
But my real suggestion is to properly rip your discs in the future.
The video is out of spec. So we can’t play that.
But the good news is you will find no content out there encoded in this way.
Sam
I’d actually appreciate a small sample of this file that doesn’t play right (Dropbox link would be great)
Sam
It’s a re-encode of a UHD with the the letterbox bars cropped out.
But, nothing needs to be able to play it back, because it claims to be H.264 at L4.1, which can’t be that many pixels. It’s got about 2.3x too many to be in spec. Same for the macroblock count.
Even L4.2 won’t cut it…you need L5 to push that many pixels per second. It’s a testament to the quality of the chip in the Vero that it gets any output at all.
Besides the strange encoding of this video material, I found something in your settings which you should not configure that way:
<videoplayer>
....
<usedisplayasclock>true</usedisplayasclock>
This SHOULD NOT be activated, so go to Settings -> Player ->Videos->Sync Playback to Display and deactivate that since it prevents audio passthrough and adjust refresh rate to work as expected. I’m sure your modern TV understands a lot more audio codecs than PCM 2.0 which is actual the target codec format for all audio input following your settings. If you need help to configure audio more optimal, please, open another thread.
Thanks for catching that, I missed it.
One other thing about the re-encode that came to mind…x264 was used to re-encode. Unless you explicitly tell x264 what H.264 level to put in the stream metadata (using --level), it will figure out the correct minimum value based on the video parameters. So, somebody had to manually set the level to 4.1.
Plus, --ref was manually set to 1, but it doesn’t appear that this was honored. Very weird, non-standard encode.
AVC High 4.1 supports a maximum resolution of 1920x1080. This video is out of spec (4.1 ends at 2048*1024). For AVC with that resolution you need to Encode at least at Level 5.1. What you have here is just a crappy Encode created by someone who had no clue what he was doing.
That’s not actually true. High@4.1 supports 245,760 macroblocks per second. It could support 3840x2160 at up to 7 frames per second.
then you just have to play at 4 times the speed to have a fluent picture 
This