hybrid input to X264

[rhbc73]

Hi guys,

I'm trying to encode a variable frame rate (hybrid) video with X264 and have a problem.

The video is 2 mins long, 1st min frames are at 30fps, 2nd min frames are at 25 frames.

I want X264 to encode the video so that the encoded video stream

1st min frames at 30 fps and 2nd frames at 25 fps (same as encoder)
output has same number of frames as input. Time stamps of output frames same as those in input file.


What settings should I use? (I'm not encoding via the command line tool, I'm using the X264 API programmatically). I see that param.i_timebase_num
param.i_timebase_den
param.i_fps_num
param.i_fps_den

will always be default set to 25 if I don't set them. Does that mean I have to specify an output frame rate, so output timestamps always based on that fps?

Thanks

[Selur]

Time codes for vfr should not be part of the video stream, but part of the container encapsulating the video stream.
So I would say:
a. extract the time codes (from the container; or generate them if no container is available)
b. reencode the frames
c. add the video stream and time codes (to the container)

[hello_hello]

Time codes for vfr should not be part of the video stream, but part of the container encapsulating the video stream.

Is there really a rule?
You've got to give a timecodes file to someone, so my preference would be to give it to the x264 encoder if possible and encode in variable frame rate mode.
Plus if the source is VFR, most Avisynth decoders would output the average frame rate. I'm not saying it necessarily makes a huge difference, and the very limited testing I did a while back seemed to indicate encoding as VFR and encoding as CFR using the average frame rate, both resulted in much the same bitrate for a given CRF value, but still, technically wouldn't it be better for the encoder to know how long each frame will really display??

Sorry rhbc73,
I don't know the answer to your question.
It's easy enough to give the CLI x264 a timecodes file to play with, although with -stitchable in the errrr... command line.... I had no problem creating a little 25fps .264 stream and another at 30fps, and appending them as an MKV with MKVToolNix. Does the frame timestamp requirement mean that's not an option?

[Selur]

@hello_hello: I don't think there is a rule and iirc x264 does make some internal optimizations for different frame rates (ran into that, when I was wondering why bobbed content in x264 produces double the output size; I expected a lot less than double, due to motion compensation and general similarity between frames). But from what I know normally frame rate / time codes are sort of an external characteristic which normally should not influence encoding of content (aside from rate control stuff when aiming to hit a specific average bitrate).

[hello_hello]

Bobbed content in x264 doesn't even come close to doubling the output size for me. I assume you're referring to double vs single rate deinterlacing, or Yadif(mode=1) vs Yadif() etc? Now I think about it, haven't we discussed this before? Heads off for a look.....

Back to the thread.....

Ah yes..... it was you (http://forum.videohelp.com/threads/354092-Converting-video-frame-rates?p=2225176&viewfull=1#post2225176).
The results in posts 17 and 20 would still be typical for me. Somewhere in the vicinity of a 10% file size increase.

[Selur]

was way more when I tested it https://forum.doom9.org/showthread.php?t=128545 may be I'll redo some testing :)

[hello_hello]

I still think that's a CRF vs CQ encoding difference. I tried 1000 frames of a small standard definition video at 24fps, then after converting it to 50fps with ChangeFPS(50,1) and then again converting to 50fps with Interframe. CRF/CQ18 with default x264 settings, -keyint 250 or -keyint 500

CRF18 25fps, 736kbps, 3.5MB
CRF18 Duplicate Frames 50fps, 751kbps, 3.6MB
CRF18 Interframe 50fps, 787kbps, 3.7MB

CQ18 25fps, 901kbps, 4.3MB
CQ18 Duplicate Frames 50fps, 1055kbps, 5.0MB
CQ18 Interframe 50fps, 1308kbps, 6.2MB

I tried comparing the encodes with duplicate frames for quality, but at CRF18 it's pretty hard. All I could really see were differences in the way they were encoded, so I compared them visually to the source for accuracy instead, I'd say for frames with little or no motion, the CRF encode was more accurate, where there was a lot of movement the CQ encode retained a bit more detail.
When I checked the Interframe encodes I thought much the same thing, only maybe the differences were a fraction more pronounced, especially in areas with movement.

The CRF18 Interframe encode:
frame I:10 Avg QP:15.65 size: 20836
frame P:724 Avg QP:17.84 size: 3541
frame B:1269 Avg QP:21.78 size: 921

The CQ18 Interframe encode:
frame I:10 Avg QP:15.00 size: 23567
frame P:725 Avg QP:18.00 size: 4589
frame B:1268 Avg QP:19.77 size: 2356

And for fun, I ran a 2 pass Interframe encoding using the same bitrate as the CQ encode above
frame I:10 Avg QP:12.52 size: 30489
frame P:734 Avg QP:14.75 size: 5848
frame B:1259 Avg QP:19.19 size: 1445

For 2 pass vs CQ at the same bitrate, I still thought 2 pass looked more accurate in static scenes and CQ where there was movement, but at the same bitrate the differences were fairly marginal.