Is changing reframes value possible without re-encoding?

[jack616]

I have some files with a reframes value of 3 which work fine on PC's but my PVR player
(Humax) doesn't seem able to cope - video playback has incorrect frame rate.

I have established this is the problem by re-encoding with mkvTOmp4 (nice program by the way)
which does change the value to 4.

I tried winff but that doesnt seem able to change the reframes value when it re-encodes.

So does anyone know if ffmpeg or something else could be be used to just change this value or must
the video be re-encoded to do this?

If it can be done can someone tell me how?

thanks

[jagabo]

You cannot change the number of reference frames without a reencode.

[jack616]

Thanks jagabo

Fortunately (since it took 37hours to re-encode the first one - hence my question ) I only have 3 of these to do.
Hopefully I won't get anymore.

Do you (or anyone) know of an ffmpeg flag to make this change when it re-encodes? I cant seem
to find it in the docs I have.

[jagabo]

It's an x264 setting, --ref, add it to the x264 settings. Somewhere in your command line you have something like:

-c:v libx264 -preset slow -crf 18

add "-ref 4" or whatever value you need:

-c:v libx264 -preset slow -crf 18 -ref 4

37 hours is a awfully slow encode. I don't know what settings you're using but try the veryfast preset:

-c:v libx264 -preset veryfast -crf 18 -ref 4

[hello_hello]

I have some files with a reframes value of 3 which work fine on PC's but my PVR player
(Humax) doesn't seem able to cope - video playback has incorrect frame rate.

I have established this is the problem by re-encoding with mkvTOmp4 (nice program by the way)
which does change the value to 4.

That doesn't make sense. Increasing the number of reference frames can increase encoding/decoding complexity. If there's a restriction, it'd just be a maximum value. http://en.wikipedia.org/wiki/Reference_frame_%28video%29
Some devices check for "compliance" (in respect to what they'll play) which probably includes a maximum number of reference frames. If they don't and the number exceeds their limit, playback may stutter or freeze. Reducing the reference frame value written to the video stream doesn't change the video in any way, however it might fool a player into thinking it can play a video, but that doesn't mean it can play it successfully, only that it mightn't refuse to try.
I've never seen a certain number of reference frames cause a player to play video at the wrong frame rate. I have seen such oddities as an incorrect sample rate used for the audio causing the playback speed to change as a result, and removing the audio lets the video on it's own play at the correct speed, or re-encoding it might do the same. It might be that the frame rate written to the video stream and the frame rate written to the container are different.
In your case re-encoding may have created something your player will play, but it wouldn't be reference frame related.

There's a demuxer/muxer only ffmpeg build here that'll change the number of reference frames written to the H264 bitstream, but I very much doubt that'll fix the problem. If it does, it'll probably be the remuxing that does it, not the change in ref frame value.

You haven't specified what types of files they are or what types your player supports, but I'd try just remuxing first (maybe with something like MKVMergeGUI or MP4Box etc).

If it takes 37 hours to re-encode, it might pay to re-encode just a section for testing, or split off a small section and only re-encode that. 37 hour long test encodes seem like over-kill.

[jagabo]

I have to confess I didn't read the initial post closely. I just replied to the title. Too many reference frames can be a problem because it requires more memory and horsepower to decode. But I've never heard of too few reference frames being a problem for a player. Your problem is elsewhere. Just because an encoding has N max reference frames doesn't main every frame uses N references. Usually most frames will use less. So it makes no sense that having less than the max reference frames would cause problems. Especially playback speed problems.

[jack616]

Thanks jagabo - I have 1 more of these to do so I will research that specific flag and try adding it to my winff presets.
It takes so long to re-encode because the files are 35GB+ in size and I do need good quality. I can put a PC aside to do
this on the very odd occasion they may appear.

hello_hello

No - the problem is 3 ref frames. To be more specific about the results the video appears decimated on playback rather
than the wrong frame rate exactly - ie video is very odd (if you've ever massively decimated on virtualdub you may recognise the effect.)
Audio stays in sync and correct pitch.

I can't speak to any other hardware but the reframes value of 3 will cause this on the humax PVR every time regardless
of file size. (I cut a 60 second segment to test on and did repeated trials).

The humax does some hardware trickery in order to playback 1080p because the chip they use can only
do 1080i - my guess would be that it is something to do with that - or maybe a math rounding error.

However it is the case I've explained - zero doubt.

Thanks to both for the input.

[jagabo]

It takes so long to re-encode because the files are 35GB+ in size and I do need good quality.

The size of the source doesn't really matter. More important is the frame size, frame rate, and duration. As a comparison Handbrake with the Intel Quick Sync h.264 encoder can encode a 1920x1080, 24 fps, 100 minute movie in about 25 minutes on my i5 2500K.

[hello_hello]

I can't speak to any other hardware but the reframes value of 3 will cause this on the humax PVR every time regardless of file size. (I cut a 60 second segment to test on and did repeated trials).

Well yesterday I'd have said that's very, very, very unlikely, but I'll take your word for it. It's quite odd though. Quite odd.