Playback Issue with 1080p

[Chapbass]

EDIT: hmmm, should this go in Software for Windows? not sure...



Hey guys,

I have a set of video files that are playing back much more poorly than I was thinking they would, hoping you could give me some pointers. I have two systems I'm doing this one, one plays back great, the specs are:

Core i5-3570k (@stock)
8GB ddr3
256gb samsung 830
AMD 280x
1920x1080 resolution monitor


Playback is perfect, CPU usage is like 40% or something.

On the not-so-great machine (Lenovo X1 Carbon 2nd Gen):

Core i5-4300u
8GB ddr3
some random 256gb SSD
panel is 2560x1440 but im running it at 1920x1080

Obviously the laptop has intel graphics, not an AMD card, so that could hurt, but I'm maxed at 100% cpu and dropped frames, both on VLC and on MPC-HC (using the KCP installer). I can get it very smooth on most scenes except ones where the camera is panning, then it starts to crap out. Heres some info from MediaInfo on the file I'm trying to play.

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L5.0
Format settings, CABAC : Yes
Format settings, ReFrames : 13 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 43mn 44s
Bit rate : 8 378 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 fps
Original frame rate : 59.940 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.067
Stream size : 2.56 GiB (79%)
Title :
Writing library : x264 core 142 r2479kMod dd79a61
Encoding settings : cabac=1 / ref=13 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=3 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=16.0000 / qcomp=0.60 / qpmin=0 / qpmax=41 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No
Color primaries : BT.2020
Transfer characteristics : BT.2020
Matrix coefficients : BT.2020 non-constant
Color range : Limited

Audio #1
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 43mn 44s
Bit rate mode : Constant
Bit rate : 1 509 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 472 MiB (14%)
Title : 5.1 DTS
Language : English
Default : Yes
Forced : No

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 43mn 44s
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 140 MiB (4%)
Title : 2.0 Surround
Language : English
Default : No
Forced : No




You guys think these files are just too much for a haswell-U chip? Seems kinda weird, but I'm not sure what to try.

Thanks!

 

[LoveMachine]

The 4300u should have plenty of power for any standard 1080p file. The two things that might cause issues from the MediaInfo dump would be the profile level and the 10bit color depth. Are these files something you transcoded yourself (e.g. Handbrake)? If you still have the source, try running it again with x264 4.1 profile.

 

[Chapbass]

The 4300u should have plenty of power for any standard 1080p file. The two things that might cause issues from the MediaInfo dump would be the profile level and the 10bit color depth. Are these files something you transcoded yourself (e.g. Handbrake)? If you still have the source, try running it again with x264 4.1 profile.

Hey LoveMachine, thanks for the response.

Unfortunately not, I don't have the source files anymore. Would it be worthwhile to re-encode this file? I thought about doing that, but I also have no idea what settings to use in handbrake

 

[Chapbass]

Also, does quicksync help at all with playback, or just re-encoding? I've tried to do various things with madvr, quicksync, and plenty of others...just haven't found one that really helps.

I'm surprised that the 3570k is that much faster than the 4300u...or is it because of the video card?

 

[LoveMachine]

Hey LoveMachine, thanks for the response.

Unfortunately not, I don't have the source files anymore. Would it be worthwhile to re-encode this file? I thought about doing that, but I also have no idea what settings to use in handbrake

I'm a user of Handbrake, but not an expert on the specific settings. If you select the "high profile" preset, I believe that's a 4.1 x264 profile that I haven't had any problems with using Kodi/VLC/MPC-HC (not using Mad-VR, I never saw much benefit). Run it through Handbrake and see what happens. Like I said, the 264 decoder in the 4300u should be plenty for anything short of MadVr. Quicksync vastly speeds up transcoding, but doesn't do much for playback.

 

[LoveMachine]

Also, I used the iGPU in my 3570k with no playback issues, and it uses the same dedicated playback decoders as the 4300u (just more execution unit cores).

By chance is this an anime file that's causing the problems?

 

[poofyhairguy]

Also, does quicksync help at all with playback, or just re-encoding?

Just encoding.

I'm surprised that the 3570k is that much faster than the 4300u...or is it because of the video card?

A modern AMD or Nvidia GPU is on another planet of decoding robustness compared to an Intel GPU but I don't know if that is what you ran into. 99% of the time the Intel GPU is good enough you can't tell, but you hit an edge case and it becomes obvious.

I would just re-encode the file in Handbrake if the issue is just a single file.

 

[Chapbass]

Also, I used the iGPU in my 3570k with no playback issues, and it uses the same dedicated playback decoders as the 4300u (just more execution unit cores).

By chance is this an anime file that's causing the problems?

Neg, not anime. Actually its a fan-made re-encoding of all 5 seasons of Babylon 5. Gonna be a lot of re-re-encoding, I guess...

 

[Chapbass]

Just encoding.



A modern AMD or Nvidia GPU is on another planet of decoding robustness compared to an Intel GPU but I don't know if that is what you ran into. 99% of the time the Intel GPU is good enough you can't tell, but you hit an edge case and it becomes obvious.

I would just re-encode the file in Handbrake if the issue is just a single file.

Oh sure, obviously the AMD and nvidia gpu's are a ton better at this in general. Guess I just figured we were past most of this sort of thing with any of the core i series chips...seems not.

 

[LoveMachine]

Neg, not anime. Actually its a fan-made re-encoding of all 5 seasons of Babylon 5. Gonna be a lot of re-re-encoding, I guess...

Oh, you really only need season 3 anyway...

 

[Chapbass]

Oh, you really only need season 3 anyway...

Negative! Season 4 as well! Besides, the gf is watching it for the first time, so we need everything

 

[razel]

Getting low CPU usage when playing back a file all depends on your player and if it is using your CPU/GPU to it's full advantage. Primarily using the decoding features. It's pretty much automatic though. I have not run into many major problems playing back 1080p content on any of my older laptops that are Core 2. However, I am not using any special software. It's just Windows Media Player and the Nvidia drivers off Windows Update.

Hell, even 1080p playback on the $30 ChromeCast is stutter free, so your Haswell should be barely breathing. The only thing that could be using that much CPU is if the files you are playing back is encoded with an codec that isn't hardware supported.

 

[JAG87]

OP, is the source material actually 59.94 progressive fps? This is generally not the case it's usually interlaced material that runs at 59.94 fps, and while it might be too late to de-interlace properly, you may want to check consecutive frames for duplicates because if the encoder fps was set to "same as source", and it de-interlaced the source using blending or weaving, you may have 29.97 duplicate frames, in which case you can halve the fps when you re-encode and end up with the same result, while reducing your encoding/decoding load.

Just a thought...

 

[poofyhairguy]

OP, is the source material actually 59.94 progressive fps? This is generally not the case it's usually interlaced material that runs at 59.94 fps, and while it might be too late to de-interlace properly, you may want to check consecutive frames for duplicates because if the encoder fps was set to "same as source", and it de-interlaced the source using blending or weaving, you may have 29.97 duplicate frames, in which case you can halve the fps when you re-encode and end up with the same result, while reducing your encoding/decoding load.

Just a thought...

Good eye

 

[Chapbass]

I'm guessing the source material was the DVDs, as thats really the only source material for this. Thats 29.97, correct? I'm pretty new to encoding/decoding, so I'm not sure how all of this works.

Edit: I have noticed that on my laptop, on the scenes that ARE smooth, they feel VERY smooth. Not as in the fake smooth soap opera vision of some TVs, but I found myself going "wow, this looks really good when its smooth".

 

[JAG87]

If the source was DVD, it's very likely that the fps was 29.97. However it could have also been 23.976 with pulldown flag. If it was the former, roll the fps back to 29.97 when you re-encode, because you very likely have duplicate consecutive frames. If it was the latter, well, it's probably too late to re-encode it properly.

My real question at this point is, why in god's name did you end up with a 1920x1080 59.94p 4:4:4 color space encode if your source was a DVD.... We've established that you are pretty new to encoding, but holy...

Cranking everything to max isn't going to turn it into HD, and you are just wasting encoding and decoding resources.

 

[Chapbass]

I didn't do the encoding, so dont look at me.