PDA

View Full Version : Looking for the opinions of others with a few questions


Seraphic-
27th September 2009, 18:59
Hi. Have several questions in relation to x264 that I seek thoughts on.

First
Wanted to do multiple versions of my videos, one for PC, and others for PS3/XB360, and maybe PSP. My question is how much limitation is imposed when encoding for such hardware? I mean, when you encode for PC, you can use unrestricted crf, but how restricted are profiles for hardware playback vs pc playback? I'm also trying to get at if it would be a good idea to encode a version just for PC, or if the profiles for PS3/XB360 would be about same quality as unrestricted crf (at same bit-rate).

Second
This might be linked to the first question. But do the resolution requirements differ for playback on console vs pc? In my case, my videos are mod16 horizontal and mod2 vertical, while in other cases, they are mod4 horizontal and mod16 vertical. In more cases, they are mod4 horizontal and mod2 vertical, and one other mod2 horizontal and mod2 vertical. What sucks is that in all cases, they are just two to four pixels under mod16 after cropping, and I don't want to re-size (in some cases source is mod16, but has darken overlay lines (one to two pixels) that can't really be counted as a full pixel, so thought would be best to crop them off).

Third
One of my video source has a resolution that changes based on what you are doing, they come as 636x478, 636x462, 636x446. Now there is no way to encode adaptive resolution changes, right? So they only real choice is to crop the two larger two match the smallest? Adding so many black boarders to the smaller ones to match the larger, just doesn't seem like it would look too good.

Thanks

setarip_old
27th September 2009, 19:07
Hi!

A question rather than an answer:

Why have you created your videos in so many different resolutions?

Seraphic-
27th September 2009, 19:17
The resolutions are based on the sizes of the source video stream (after cropping).

thewebchat
28th September 2009, 02:15
As for the mod issue, you can't go wrong with mod16. Short of that, I've never had problems with players handling mod8 width video, but as soon as I hit mod4, I run into all kinds of strange issues even with software players. So, I think mod8 width and mod4 height is a safe common ground.

akupenguin
28th September 2009, 02:25
Variable resolution is standard compliant. x264 can generate it by encoding each segment separately and then concatenating them. But many players don't support it.

Seraphic-
28th September 2009, 07:13
As for the mod issue, you can't go wrong with mod16. Short of that, I've never had problems with players handling mod8 width video, but as soon as I hit mod4, I run into all kinds of strange issues even with software players. So, I think mod8 width and mod4 height is a safe common ground.

It's seems like such a waste to toss away perfectly good pixels though.

Variable resolution is standard compliant. x264 can generate it by encoding each segment separately and then concatenating them. But many players don't support it.

Interesting. Could you go into more detail on how that works?
Sounds like not something for the consoles, but for PC playback.

Blue_MiSfit
28th September 2009, 20:14
I imagine akupenguin means simply encoding several videos as-is, and then concatenating the elementary streams. Maybe as simple as just copy /b movie1.264+movie2.264 moviejoined.264

I could be wrong though :)

~MiSfit

Seraphic-
29th September 2009, 00:08
So does the player window resize with the video or just the video itself (with supported players).

As for safe cropping, seeing as I will be working with progressive video that is RGB, YUY2, and YV12, and some avisynth filters here and there. I would need to use at least mod4 width and mod2 height, correct? And again, the overall resolutions are two to four pixels under mod16, so less padding needed. I was thinking of maybe adding the needed boarders to make mod16 w/h, but not sure about it yet.

thewebchat
29th September 2009, 01:49
Actually, what happens when a player finds a resolution change in the middle of a stream is an interesting question. I know that on DVDs, the aspect can and does change quite frequently, and that MPC-HC resizes itself when it encounters this. In addition, if I check and uncheck the "resize and aspect" box in ffdshow, it causes the player window to change as well. Of course, this behavior probably varies with player.

dstln
29th September 2009, 04:25
Encode mod4. Also I've never encountered any problem with mod4 and there isn't any significant reason to overcrop to go higher.

Either overcrop to get rid of all the black bars or crop to get the full picture on the largest, it's up to you. I'd personally go for the latter.

There's not a fantastically good reason to encode separately for pc/360 either. Just find the 360 limits and encode for that. I assume this is from a dvd source so you shouldn't have issues really, you'll just need to have h264/aac audio in mp4.

Seraphic-
30th September 2009, 05:54
There's not a fantastically good reason to encode separately for pc/360 either. Just find the 360 limits and encode for that. I assume this is from a dvd source so you shouldn't have issues really, you'll just need to have h264/aac audio in mp4.

I did two test 720p encodes using x264 Unrestricted 1pass Const. Quality Insane (20) for one and the Xbox360/PS3 profile for the other. Both versions seems to play perfectly fine on both PS3 and Xbox360. Didn't notice and lag/hanging on PS3, but on Xbox360 there was some slow down. Although, the slow down on the Xbox360 could be because the Unrestricted version had a 15500 bit-rate and the Console profile I encoded at 12,500. Maybe the 360 just is not able to support a video with that high of a bit-rate. Anyone done more testing in this area?

Seraphic-
2nd October 2009, 01:41
In addition to my above questions, does anyone know if PS3/360 support CRF?

J_Darnley
2nd October 2009, 01:47
They can't not support it, provided you use the appropriate VBV limits. Or to avoid the double negative, yes.

Seraphic-
2nd October 2009, 03:05
Did you mean they can, within appropriate VBV limits?

kemuri-_9
2nd October 2009, 03:10
Did you mean they can, within appropriate VBV limits?

as long as
A. you use the proper VBV limits for the device
B. x264 reports no VBV violations

then yes, CRF will work on those devices.

Seraphic-
2nd October 2009, 03:11
What is the VBR limits of both consoles?
Seems like PS3 has a higher limit then 360.

benwaggoner
2nd October 2009, 03:23
What is the VBR limits of both consoles?
Seems like PS3 has a higher limit then 360.
The published 360 peak bitrate is pretty conservative. If you don't go crazy on multiref and perhaps b-pyramid, it can handle quite a bit higher with fine playback. Under the hood it's really a software player.

Seraphic-
2nd October 2009, 03:44
The published 360 peak bitrate is pretty conservative. If you don't go crazy on multiref and perhaps b-pyramid, it can handle quite a bit higher with fine playback. Under the hood it's really a software player.

Interesting. Is PS3 the same way?

benwaggoner
2nd October 2009, 04:46
Interesting. Is PS3 the same way?
Probably. But the Cell is a decoding monster, so I don't know that anyone ever bumps into is practical limits.

With MBTree, I'm beginning to think that 15 Mbps peaks may be all we really need for 1080p24 film/video content. x264 in BD-compliant 8-15 Mbps can even do the StEM "confetti open" sequence pretty darn well.

Seraphic-
2nd October 2009, 05:09
I did a high detail 720p video using CRF at 20, and it was average bit-rate came out to 15,550.
This was Constant Quality insane profile, PS3 played it fine, 360 had some slow down.

Another thing to take into account is that PS3 uses FAT32, so files must be under 4GB.
Does 360 use NTFS? Whatever the case, it does not seem to allow you to copy videos to the console harddrive, PS3 lets you do this.

benwaggoner
2nd October 2009, 05:47
I did a high detail 720p video using CRF at 20, and it was average bit-rate came out to 15,550.
This was Constant Quality insane profile, PS3 played it fine, 360 had some slow down.
ABR doesn't tell us anything, really. Do you recall the VBV? A little trial and error would probably determine a VBV that can be used safely for a given frame size and rate.

Was this 720p60? That's a high ABR for 720p24!

Another thing to take into account is that PS3 uses FAT32, so files must be under 4GB.
Does 360 use NTFS? Whatever the case, it does not seem to allow you to copy videos to the console harddrive, PS3 lets you do this.
360 can't read NTFS formatted drives, but it can play >4 GB files shared from WMP or Media Center.

Seraphic-
2nd October 2009, 06:28
It was 720p 59.94. No, don't recall, just that HQ Insane Profile with 20 for the CRF setting and the encoding results showed average bit-rate as 15,550.
I was really only testing a non-mod 16 resolution encode to see if there would be playback issues. Didn't encounter any.

kemuri-_9
2nd October 2009, 07:10
I was really only testing a non-mod 16 resolution encode to see if there would be playback issues. Didn't encounter any.

why would there be issues?
A. x264 pads input videos to mod 16 dimensions and adds crop flags to the output stream so that the padding isn't displayed back at decode time (unless ignored by specific request).
B. a common example that's padded is the standard 1920x1080 resolution; it is actually 1920x1088 with 8 rows flagged to be cropped

Seraphic-
2nd October 2009, 09:24
Yes. I am aware of the padding added to encoding. But in this case I was using mod2, which is known to have issues sometimes on playback on PC, so I was testing both consoles to see if there would be any issues. But did not notice any, you just have to set the display mode to native/original.

benwaggoner
2nd October 2009, 20:20
It was 720p 59.94. No, don't recall, just that HQ Insane Profile with 20 for the CRF setting and the encoding results showed average bit-rate as 15,550.
I was really only testing a non-mod 16 resolution encode to see if there would be playback issues. Didn't encounter any.
That's good to hear.

Anyway, any encodes targeting devices really should have VBV set. If it did a 15 Mbps ABR well, that's pretty impressive! Unless it was very constant complexity, I bet you had peaks north of 20 Mbps.

Seraphic-
6th October 2009, 22:25
Variable resolution is standard compliant. x264 can generate it by encoding each segment separately and then concatenating them. But many players don't support it.

What is the process for concatenating three videos of different resolutions into one file?
I want to make a test version and try playing it back on PS3/Xbox360 and see how it goes.
Videos are same horizontal, but different vertical.

LoRd_MuldeR
6th October 2009, 22:31
If you have "raw" H.264 streams, then a binary concatenation ("COPY /B File1.264 + File2.264 + ... + FileN.264 Output.264") of the existing files should work.

But as akupenguin said, players may not support changing resolution within the same H.264 stream. In that case the process is: Decode -> Resize -> Append -> Re-encode ;)

Seraphic-
6th October 2009, 23:13
If you have "raw" H.264 streams, then a binary concatenation ("COPY /B File1.264 + File2.264 + ... + FileN.264 Output.264") of the existing files should work.

But as akupenguin said, players may not support changing resolution within the same H.264 stream. In that case the process is: Decode -> Resize -> Append -> Re-encode ;)

Could you go into a little more detail on how to do a binary concatenation? Have never done that before.

I have a feeling the adaptive resolution shouldn't be a problem for PC playback. Consoles on the other hand, might have a problem, so want to test first. I'm working with 636x446, 636x462, 636x478.

LoRd_MuldeR
6th October 2009, 23:18
If you are on Windows, go to START -> "Run", then type "cmd.exe" (without the quotes) and press Enter.

In the command prompt, that will pop up now, you can type the command that I already mentioned in my previous post:

COPY /B File1.264 + File2.264 + ... + FileN.264 Output.264

Of course you must replace the file names with the actual file names ;)

And if all those files aren't located in the current working directory, then full or at least relative path names must be used.

Seraphic-
6th October 2009, 23:50
Thanks, I'll give that a try and report results.
Also, I take since you are showing .264, the file format has to be encoded as RAWAVC?
File format can not be .mp4 or .mkv?

LoRd_MuldeR
7th October 2009, 00:07
Thanks, I'll give that a try and report results.
Also, I take since you are showing .264, the file format has to be encoded as RAWAVC?
File format can not be .mp4 or .mkv?

Yes. As said before, the binary concatenation will only work with "raw" H.264 streams. Concatenating two valid H.264 streams gives a valid H.264 stream again.

But concatenating MKV or MP4 files probably won't work. If you want to mux several H.264 streams into one MKV or MP4 container, use a muxing tool like MKVToolnix or MP4Box.

However you can demux the H.264 streams from their containers, do the binary concatenation of the "raw" streams and finally mux the result into MKV or MP4 again.

Seraphic-
7th October 2009, 01:03
Concatenating two valid H.264 streams gives a valid H.264 stream again.

Is two the limit? Or can you do say three by replacing "+ ... +" with "+ File3.264 +"? You might have added the "..." to imply you can add additional files to the script, but wasn't sure if that was the case or if it should be removed if just using two files.

LoRd_MuldeR
7th October 2009, 02:15
Is two the limit? Or can you do say three by replacing "+ ... +" with "+ File3.264 +"? You might have added the "..." to imply you can add additional files to the script, but wasn't sure if that was the case or if it should be removed if just using two files.

If you can concatenate two valid H.264 streams and get a new valid H.264 stream, then this implies you can concatenate an arbitrary number of valid streams.

Example: If we want to join valid streams A, B, C and D, then we can concatenate A + B to X and C + D to Y. Since X and Y are valid again, we can now concatenate X + Y to Z.

Of course it doesn't need to happen in this particular order. And you can concatenate several streams in one single call to Copy ;)

Seraphic-
7th October 2009, 03:45
Tried with a video that was 636x462 and 636x446. Resulting Output.264 file plays in what appears to be slow motion, and at 720 x 480 (AR 1:1). Was using Media Player Classic Homecinema.

So next I did an adaptive mux of the output.264 to output.mp4. Now the video plays back at normal speed, but still displays as "Video: MPEG4 Video (H264) 720x480 59.94fps [Video]" and not the desired cropped sizes.

Resolution just says at 720x480 and does not change based on the video. Did I do something wrong or should I try playback in another player?

Thanks for your help by the way, LoRd_MuldeR.

EDIT: Well it appears that it is working, just that it plays the video as 720x480 and the cropped video plays within that resolution.
It did this in both PS3 and PC playback as well as 360. So guess it worked out then.

benwaggoner
9th October 2009, 02:36
EDIT: Well it appears that it is working, just that it plays the video as 720x480 and the cropped video plays within that resolution.
It did this in both PS3 and PC playback as well as 360. So guess it worked out then.
If you're changed encoded frame size mid-stream, many decoders may not adapt correctly. This is something we've found in testing with Smooth Streaming, where we pass concatenated elementary streams to the decoder. Lots of decoders work well, lots work as long as the size changes aren't too frequent, and a significant number do something visually incorrect.