Convert MKV "ReFrames" to lower number?

[elgrayso]

Hello. I am trying to watch an MKV on my Samsung player. They typically work but this one doesnt and I believe it is because the "11 frames" under format settings is too high of a number. I'm not sure what that even means but I think somebody said that could be an issue. Is there an easy way to convert this file so I can play it on the samsung? It works fine on the computer (Mac).
Thanks!!


General
Unique ID : 41839194031168151307066563310841561940 (0x1F79EF87A262A69216BD3A4ECF150354)
Complete name : *FILE NAME REMOVED BY ME FOR THIS POST*
Format : Matroska
Format version : Version 1
File size : 1.43 GiB
Duration : 53mn 59s
Overall bit rate : 3 797 Kbps
Encoded date : UTC 2007-04-15 20:43:48
Writing application : mkvmerge v1.8.0 ('Wise Up') built on Nov 12 2006 20:41:30
Writing library : libebml v0.7.7 + libmatroska v0.8.0


Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 11 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 53mn 59s
Bit rate : 3 344 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.151
Stream size : 1.23 GiB (86%)
Writing library : x264 core 54 svn-648
Encoding settings : cabac=1 / ref=8 / deblock=1:1:-2 / analyse=0x3:0x133 / me=umh / subme=7 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=240 / keyint_min=24 / scenecut=40(pre) / rc=2pass / bitrate=3344 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30
Language : English
Default : Yes
Forced : No


Audio
ID : 1
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 53mn 59s
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 173 MiB (12%)
Default : Yes
Forced : No

[elgrayso]

also, i didnt not make this original file.
but i have MKVMerge (MKVtoolnix), Handbrake and iMKVExtract, if any of those will help

[hello_hello]

It seems odd to me because you've got

Format settings, ReFrames : 11 frames

while under encoder settings it's

ref=8

I checked a few encodes and each ref frame value was the same each time. Maybe something changed over time when it comes to the information x264 writes. I kind of remember at one stage MediaInfo would often report a one frame difference but I don't remember it being any greater. Maybe it's got something to do with the h264 level.... I don't know.

Anyway, I gave one of those files a spin (yes I know what they are) using the media player built into my Samsung TV and also a Sony Bluray player. Same number of ref frames as your example. Both players happily played it. As I always remux everything on it's way to my media drive (to check track languages etc) I can't test a file which was muxed with that particular version of MKVMerge (1.8.0), so it'd be worth simply remuxing a file before doing anything else. I hadn't looked before but that veide happily decodes using DXVA/MPC-HC and I'm fairly sure DXVA (or my old video card) doesn't support anything above level 4.1, so it probably depends whether the player checks the file itself or decides whether to play based on the info written to the video stream.

If remuxing doesn't do the trick then give the H264 Level Editor a spin. If that doesn't help you'll probably need to re-encode.

[elgrayso]

sorry, i am new at this stuff. are you saying to throw it into MKVMerge and mux it into a new file without really changing anything?

[elgrayso]

also i had a season of this same show that was encoded at "ref=8" and showed "ReFrames: 8 frames" and I was never able to get those to play on the samsung either. I think 8 is too high. The others are usually like 2 or so.
And what the player does is it plays the video but with a black screen (audio works) for about half a minute and then says it was not recognizable and stops playing.

[johns0]

I already told you in your earlier thread about the same file and it's the Format profile : High@L5.1 that's the problem,if you can't change it with tsmuxer then you need to re-encode it with handbrake.

[elgrayso]

oh jeez I forgot I had posted that question. yeah what happened with that was that it required tsmuxer which would not work on any of the 3 Mac computers I tried. the software would not even start. I can try again when I get home though

[elgrayso]

yes the handbrake method seems to have worked!
thanks guys.
and sorry for the double post

[hello_hello]

also i had a season of this same show that was encoded at "ref=8" and showed "ReFrames: 8 frames" and I was never able to get those to play on the samsung either. I think 8 is too high. The others are usually like 2 or so.

If the player supports High Profile Level 4.1, then for 720p, 8 ref frames isn't too many.

sorry, i am new at this stuff. are you saying to throw it into MKVMerge and mux it into a new file without really changing anything?

Yes. They're muxed with a fairly old version of MKVMerge. There's a chance the file was muxed in a way the player isn't happy about.
If that doesn't work then try the h264 level editor I linked to. It'll change the level without re-encoding (try Level 4.1).
If that doesn't work, then you'll probably need to re-encode with something like Handbrake.

[_Al_]

I checked a few encodes and each ref frame value was the same each time. Maybe something changed over time when it comes to the information x264 writes. I kind of remember at one stage MediaInfo would often report a one frame difference but I don't remember it being any greater. Maybe it's got something to do with the h264 level.... I don't know.

Encoding my own videos I noticed that MediaInfo always shows 1 more ReFrame. For example I set --ref 3 , MediaInfo reported 4. Then I read on Doom9, I think it was there, that --b-pyramid adds 1 ref frame and it looks like that is set as default. Try for example --b-pyramid none instead and MediaInfo would report 3 ReFrames.

[hello_hello]

I ran a few little test encodes and it seems you're correct, --b-pyramid none results in MediaInfo reporting the same ref frame number each time, but I don't quite understand why sometimes the same ref frame number is reported by MediaInfo without --b-pyramid none.

The encoder parameters followed by the two ref frame numbers in brackets (ReFrames/Ref). High Profile 4.1 used each time.

Medium x264 speed preset, default ref=3 (4/3)
Medium x264 speed preset plus ref=5 (5/5)
Slow x264 speed preset, default ref=5 (5/5)
Slow x264 speed preset plus ref=3 (4/3)

When I ran the 1st and last encodes again with --b-pyramid none, the two reference frame values became (3/3).

Most of my encodes a done using the slow x264 speed preset so that explains the ref frame numbers mostly being the same for me. I did run an encode the other day using the medium speed preset and when I checked the ref frame numbers were indeed (4/3).

[_Al_]

It is not just --b-pyramid. Using --preset slow or veryslow for example will shoot reference frames up to the roof, it changes --b-adapt and other settings into motion that can cause increase number of reference frames. But including --ref 3 in the same command will keep it down (3 plus 1 because of -- b-pyramid) , but not sure if that makes sense then, quality wise, I did not test it.

Number of reference frames should be realy kept down. Virtual DPB (decode picture buffering) size together with Level and number of reference frames are interconnected. It is in the specs for H.264. So hardware player could use only that size for DPB to store already decoded parts of video following specs. But real size needed to store already decoded video (as a reference still needed) depends on resolution and number of reference frames. That is why lower resolution videos can have more reference frames. So specs create size for that DPB, therefore for given resolution and LEVEL, basically it could be calculated to get maximum number for reference frames to follow specs. For FullHD using LEVEL 4.1 it is 4 and for 720p it is 9.

adding a link that explaines it more:
https://en.wikipedia.org/wiki/H.264

[_Al_]

ok, I made myself to read specs a bit more

so here for example there is right to the point said that number of reference frames controls DPB, and that default, --ref is 3, so it doesn't have to be included in basic comand line if --ref 3 is desired (result is 4 at the end with --b-pyramid, so this is ok for fullHD and L4.1 to keep specs)

here it says that x264 tries automatically detect level if not specified (vbv-maxrate and --vbv maxsize needed to be more correct)

looking at --b-adapt now , not sure if that is playing some role creating reference frame number at all, because it just increases b-frames

so there is something in --preset that sets reference frames higher choosing slow, slower, not looking intokeeping specs and disregarding DPB size,..., so maybe that "something" is just simple --ref parameter that is being increased and that my first sentence in previous input #12 is wrong?

[jagabo]

so there is something in --preset that sets reference frames higher

I posted a table of the preset settings here:

https://forum.videohelp.com/threads/347067-VirtualDub-H-264-Encoder-Speed?p=2169830&vie...=1#post2169830

Things may have changed a bit since then -- they fine tune presets now and then. The actual settings used by x264 can be seen in MediaInfo's "Encoding Settings" line. When using the command line x264 encoder you can modify individual settings after specifying the preset. For example:

x264 --preset=veryslow --crf=18 --ref=4 --bframes=3...

With that you'll get the veryslow settings but with only 4 reference frames, 3 consecutive bframes.

[_Al_]

nice,
so this brings file slightly smaler, time to encode slightly longer, quality the same, and tiny bit power increase needed to decode:

x264 --preset=slow --crf=18 --bframes=3...

instead of just using:

x264 --crf=18 --ref=4 --bframes=3...

and what about using --preset slow --ref 3 against --preset default --ref 3
is it something between, differences between those two lines above? Never mind, I guess it is doable, slightly better compressibility ...