x264 re-encoding segments

[dattrax]

Hi,

I was looking at the info on the sonic site about re-encoding segments and figured whether this was possible on x264. A first pass encode should give the PSNR for each frame and then a simple app should be able to analyse the segments which need attention. We could then feed in .avs files with different Trim() commands and increase the bitrate in those areas. Only problem is splicing the output together.

Anyone know if this is possible?

Jim

[Sergey A. Sablin]

Hi,

I was looking at the info on the sonic site about re-encoding segments and figured whether this was possible on x264. A first pass encode should give the PSNR for each frame and then a simple app should be able to analyse the segments which need attention. We could then feed in .avs files with different Trim() commands and increase the bitrate in those areas. Only problem is splicing the output together.

Anyone know if this is possible?

Jim

As x264 doesn't write any VBV/HRD info into stream and basically doesn't calculate it according spec, you may easily do this as resulting stream will be also without any VBV/HRD info and so won't break VBV/HRD rules.
The only problem is that you in most cases won't be able to import such re-encodings into BluRay/HDDVD authoring application as they do check VBV/HRD compliance (well also with some errors but anyway).

[Sagittaire]

Hi,

I was looking at the info on the sonic site about re-encoding segments and figured whether this was possible on x264. A first pass encode should give the PSNR for each frame and then a simple app should be able to analyse the segments which need attention. We could then feed in .avs files with different Trim() commands and increase the bitrate in those areas. Only problem is splicing the output together.

Anyone know if this is possible?

Jim

Well x264 support segments based encoding with zone option ( --zone 150000,173500,b=0.5 for example). The probleme here is not x264 but frontend for x264. For make segments reencoding, frontend must have these functionality:

- input and output visual comparison
- PSNR and SSIM values
- Segment based editing
- Complete encoding with segment modification

[dattrax]

Its not exactly what I was looking for as, from what I can gather, Cinevision encodes only the sections that require attention and then merges them back into stream. In this way you can check the output (via PSNR or visually) and decide to increase the bitrate in this segment. It is an itterative process until you like the result.

I agree that --zone would do what is required, but would ulimatly take longer.

Jim

[Kuukunen]

You could use MSU VQM to get PSNR/SSIM readings on per-frame basis. (Maybe preferably SSIM, since it correlates better to perceived quality on higher quality levels.)

From the top of my head easiest way to split and join segments could be with mkvmerge. If you have the whole thing in one file, you can split it with "mkvmerge -o split.mkv --split timecodes:12:33.5,15:56.95 stream.264" naturally, the timecodes in the case of raw h.264 sreams won't work too well since the fps isn't specified. (25fps assumed, I think) So you could handle everything in mkv in the first place. Joining them is easy: "mkvmerge -o join.mkv split_001.mkv +split_002.mkv". Naturally you can only split at I-frames.

Of course you probably don't have the source in mkv, but if you can use Trim() in Avisynth like you suggested.

If you don't like joining with mkvmerge, nothing stops you from simply concatenating the raw H.264 files. In Windows: "copy /b part1.264+part2.264 joined.264". This gives some problems though, as explained below.

There's the problem of SPS and PPS ids. (The id that tells the decoder which decoding settings should be used for that segment.) Whether you use mkvmerge or binary concat, you have to encode different segments with different "--sps-id [number]". (option in x264) You can only have it in range from 0 to 31, so you can't have more than 32 different encoding settings. You can, however, use the same sps-id for different segments if the settings are the same. (I think)

Now, if you concatenate the raw streams, the NALs (parts of which H.264 stream consists) that contain the SPS/PPS settings are located in the beginning of the stream, so when you concat them, they'll be scattered around the stream and you want them to the beginning of the whole thing. I've heard newer versions of mkvmerge gather those NALs, but I had some troubles with the version I had, so I used mp4box. (Just running it through mp4box should gather the SPS/PPS NALs and place them in the beginning.)

Sorry for possible factual mistakes, I tried my best. :P

EDIT:
A first pass encode should give the PSNR for each frame and then a simple app should be able to analyse the segments which need attention.
Oh didn't notice this... If you mean the first pass of a two pass encode should give the PSNR, it's impossible, because of course you need the final encode so you can compare that to the original.

And one more thing, it's not really x264's problem, you can do what I described with any H.264 encoder that supports different SPS/PPS ids. Encoder encodes, if you want to join the stream to another after that, it doesn't concern x264.

[reiser]

Oh didn't notice this... If you mean the first pass of a two pass encode should give the PSNR, it's impossible, because of course you need the final encode so you can compare that to the original.

I think the 3 pass encode does a similar job. It has to go trough the hole source in order to keep the average bitrate. If you (let's say) copy the "good" segments and reencode the "bad" ones with higher bit rates, obviously you will end up with higher average bit rate and larger file in the end.