View Full Version : Encoding Video for Blu-Ray using H264/AVC
Pages :
1
2
3
4
5
6
7
[
8]
9
kieranrk
11th March 2014, 01:29
2) How data enters to MB1 buffer? In T-STD model the data enters to multiplexor buffer according to transport_rate which is derived from successive PCRs. In BDAV-STD each TS packet is extended by the time-stamp. i conjecture that the TS packet in BDAV-STD enters to TB1 according to these timestamps.
No, in T-STD and data enters TB1 at the transport rate - I don't have the spec on me but I would guess the BDAV-STD defines the timestamp to be the entry time into TB1. It then leaves TB1 into MB1 at a rate defined in the spec. For Video this is usually a little higher than the max bitrate to account for PES overhead; audio is hardcoded in the specs.
Alex-Kid
11th March 2015, 15:00
I want to encode my 1080p60 footage that is going to be authored to a AVCHD 2.0 blu-ray disc, as is the only standard that supports this resolution and frame rate. Given that purpose, I did some search and came with these x264 settings:
x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 25000 --vbv-bufsize 25000 --level 4.2 --keyint 120 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file
x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 25000 --vbv-bufsize 25000 --level 4.2 --keyint 120 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out.264 input.file
Does these x264 settings conform with AVCHD 2.0 standard on blu-ray media?
A.Fenderson
11th March 2015, 16:46
I'm not sure all the parameters and constraints on AVCHD Progressive/2.0 are well-known, since it's not intended as a distribution format and more intended for use in camcorders, so keep that in mind. Hopefully someone who has tried this before can share their results.
You need to constrain bitrate to under 28000.
If AVCHD 2.0 closely follows Blu-ray constraints, you will need to reduce keyint to 60 (1 second GOP), but this is a guess.
Also, AVCHD format is intended for SD cards and DVD discs, and as seemingly trivial as it would be to support it on Blu-ray discs, not all players seem to do so; maybe try burning to BD-RE first and see if that will play back in the target device. If you want to target all Blu-ray players, consider converting to 1080i, as you'll retain the high-motion aspect (60 Hz) if properly done, and only lose some (maybe acceptably-small) visual fidelity from the interlacing/deinterlacing.
Alex-Kid
12th March 2015, 07:19
I've been doing some more searching and I came up with this (from http://www.sony-asia.com/microsite/cybershot_userguides/DSC-HX200V/eng/contents/08/04/01/01.html):
To create a Blu-ray disc from movies recorded in [AVC HD 28M (PS)], you need to use device that is compliant with an AVCHD format Ver. 2.0. The created Blu-ray disc can be played back only on the device that is compliant with the AVCHD format Ver. 2.0.
My Samsung BD-H6500 user manual says that "the product won't play any content burnt on DVD-R media with any bitrate higher than 10 Mbps" and "the product won't play any content burnt on BD-R media or USB device with a bitrate higher than 25 Mbps". There's no information about AVCHD 2.0 but I already burnt a DVD-R which content was flawlessly played by this player. Software updates maybe?
jpsdr
12th March 2015, 09:35
DVD-R can be understundable because of physical drive limitation (and maybe DVD spec), but BD-R... It's strange... It seems more like a restriction to not allowing to play too much good quality BD-R (preventing for exemple playing even legal copy) than a real physical limit.
Precomposed
13th June 2015, 02:41
I'm about to setup an x264 encode for a still image menu background on a Blu-ray disc.
What parameters would be used to create a single frame Blu-ray compliant .264 file? Input would be 1920x1080 jpeg or png. I was not able to find information on this in any of the guides.
2themax
13th June 2015, 03:54
I've done this once before using avisynth as a source.
ImageSource("%d.png", 0, 0, 24)
You're still would be named 0.png and the script is just saying to read from frame 0 to frame 0 giving one frame. The 24 is the fps.
neil wilkes
15th June 2015, 08:20
I'm about to setup an x264 encode for a still image menu background on a Blu-ray disc.
What parameters would be used to create a single frame Blu-ray compliant .264 file? Input would be 1920x1080 jpeg or png. I was not able to find information on this in any of the guides.
I'm not sure how much help this will be as I use the x264Pro plugin variant of this excellent encoder in Premiere Pro CS2014 and it gets outstanding results.
An important thing to consider with Blu-ray is that even for menus, they are nothing like how we understand them from DVD as in BD everything is a movie, even menus.
How we attack this is to set up a 30 second "film" with the still (please do not use JPEG - use either TIF or BMP and keep those graphics lossless - avoid data reducing forms like JPEG) with your source at 23.976fps at 72DPI if using 10920x1080.
Encode as a regular movie at around 5Mbps CBR using highest quality options, although if you do want to use slideshow tuning this will not hurt but in all honesty I do not think it makes much difference - treat as a movie.
foxyshadis
15th June 2015, 18:41
I'm not sure how much help this will be as I use the x264Pro plugin variant of this excellent encoder in Premiere Pro CS2014 and it gets outstanding results.
An important thing to consider with Blu-ray is that even for menus, they are nothing like how we understand them from DVD as in BD everything is a movie, even menus.
How we attack this is to set up a 30 second "film" with the still (please do not use JPEG - use either TIF or BMP and keep those graphics lossless - avoid data reducing forms like JPEG) with your source at 23.976fps at 72DPI if using 10920x1080.
Encode as a regular movie at around 5Mbps CBR using highest quality options, although if you do want to use slideshow tuning this will not hurt but in all honesty I do not think it makes much difference - treat as a movie.
That's exactly how menus work in DVD, they're all MPEG2. You can use a one-frame still just as easily in BD (set the frame duration appropriately), and you can use the 30-second trick in DVD as well. CBR is just a waste of bits.
Precomposed
15th June 2015, 20:15
I analyzed the m2ts that Adobe Encore creates for a Blu-ray still image background and it is only 1 frame in duration, not 30 seconds. I completely understand that Blu-ray backgrounds need to be videos per the Blu-ray spec, even when they are just still images. This is why I wish to convert my still image (png) background to a single frame video (.264) using x264 or ffmpeg + libx264. I was wondering if there are any special settings I should be using to create a 1 frame .264 file that is Blu-ray compliant or will the normal settings of x264 be compliant for a single frame?
2themax
17th June 2015, 04:20
I analyzed the m2ts that Adobe Encore creates for a Blu-ray still image background and it is only 1 frame in duration, not 30 seconds. I completely understand that Blu-ray backgrounds need to be videos per the Blu-ray spec, even when they are just still images. This is why I wish to convert my still image (png) background to a single frame video (.264) using x264 or ffmpeg + libx264. I was wondering if there are any special settings I should be using to create a 1 frame .264 file that is Blu-ray compliant or will the normal settings of x264 be compliant for a single frame?
I answered that exact question 3 posts above. Use avisynth to feed x264 1 PNG.
kit90
24th January 2016, 08:47
In addition to movie applications (for which the x264 settings given in the first post are valid), Blu-ray also provides timebased and browsable slideshow applications, as given in the white papers (http://www.blu-raydisc.com/assets/Downloadablefile/BD-ROM-AV-WhitePaper_110712.pdf and http://www.blu-raydisc.com/assets/Downloadablefile/BD-ROM_Part3_V3.0_WhitePaper_150724.pdf). An example browsable slideshow is http://www.dvd-logic.com/downloads/examples/DVDLOGICBS.ZIP. The Mediainfo report on BrowsableSlideshow.avc shows Format settings, GOP:N=1. Does anyone know the settings to create timebased and browsable slideshows with x264?
PS: In the first post, the maximum reference frames for 1080 is given as 4. However, this is valid only if b-pyramid is disabled. In the default case in MeGUI (b-pyramid=strict), it is 3.
sneaker_ger
24th January 2016, 09:12
PS: In the first post, the maximum reference frames for 1080 is given as 4. However, this is valid only if b-pyramid is disabled. In the default case in MeGUI (b-pyramid=strict), it is 3.
Using --ref 4 in x264 is totally fine for 1080p BluRay, even with b-pyramid. Note that MediaInfo's "ReFrames" is actually DPB size.
kit90
24th January 2016, 11:01
Using --ref 4 in x264 is totally fine for 1080p BluRay, even with b-pyramid. Note that MediaInfo's "ReFrames" is actually DPB size.
1) Thanks. So if I specify these settings
--level 4.1 --bluray-compat --tune film --pass 2 --bitrate 20000 --stats ".stats" --keyint 24 --open-gop --ref 4 --slices 4 --vbv-bufsize 30000 --vbv-maxrate 40000 --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1
in x264 (which defaults to b-pyramid=strict), the actual number of reference frames is 4, even though MediaInfo reports
Format settings, ReFrames: 3 Frames
Is it correct?
2) Also, how can we enforce
Format settings, GOP: N=1
to create timebased and browsable slideshows in x264? This is the setting given in the MediaInfo report of the browsable slideshow AVC file in my previous post.
jpsdr
26th January 2016, 09:34
For the Ref frames, it's correct.
For the second part, personnaly, i don't know.
Precomposed
25th February 2016, 23:33
Having an issue with PS4 playback only. Video appears choppy (like every other frame is being displayed) and the image quality is not as good as it should be.
Here are the settings from x264:
x264 --input-res 1920x1080 --fps 24000/1001 --crf 15 --preset slow --tune film --bluray-compat --vbv-maxrate 20000 --vbv-bufsize 20000 --level 4.1 --keyint 24 --open-gop --b-pyramid strict --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1
Muxing is performed with latest version of BD Author (DVDLogic) which muxes to spec.
Muxed video stream passes Sony BD verifier with flying colors, and the disc works fine on every other player, including PS3. Does anyone know if PS4 has problems with b-pyramids? Or is there something else going on here?
poisondeathray
26th February 2016, 01:18
Having an issue with PS4 playback only. Video appears choppy (like every other frame is being displayed) and the image quality is not as good as it should be.
Here are the settings from x264:
x264 --input-res 1920x1080 --fps 24000/1001 --crf 15 --preset slow --tune film --bluray-compat --vbv-maxrate 20000 --vbv-bufsize 20000 --level 4.1 --keyint 24 --open-gop --b-pyramid strict --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1
Muxing is performed with latest version of BD Author (DVDLogic) which muxes to spec.
Muxed video stream passes Sony BD verifier with flying colors, and the disc works fine on every other player, including PS3. Does anyone know if PS4 has problems with b-pyramids? Or is there something else going on here?
DVDLogic muxer had known issue in the past with b-pyramid. I don't know if they ever fixed it.
Yes, it is. I just got confirmation from DVD Logic; their muxer has a problem with b-pyramids. Bad news for me, but it's good to know where the problem was, regardless.
Thank you very much indeed to all who took time to reply & comment.
Precomposed
26th February 2016, 01:28
DVDLogic muxer had known issue in the past with b-pyramid. I don't know if they ever fixed it.
DVDLogic did fix the muxer issue with b-pyramids. I've been working closely with them. It now muxes b-pyramids to spec and passes Sony BD verifier.
Before the muxing issue was fixed with their software, this choppy issue was happening on PS3 as well and the stream was not passing verification. Now it is passing verification, and working great on PS3 and other players. This leads me to believe there is an issue with PS4 not supporting b-pyramids, though I find it hard to believe no other commercial releases use b-pyramids. I do not see an issue with any other movies on PS4. The only difference I can see is that my videos are playing from a BD-R, and commercial releases are from a pressed disc.
benwaggoner
26th February 2016, 19:01
DVDLogic did fix the muxer issue with b-pyramids. I've been working closely with them. It now muxes b-pyramids to spec and passes Sony BD verifier.
Before the muxing issue was fixed with their software, this choppy issue was happening on PS3 as well and the stream was not passing verification. Now it is passing verification, and working great on PS3 and other players. This leads me to believe there is an issue with PS4 not supporting b-pyramids, though I find it hard to believe no other commercial releases use b-pyramids. I do not see an issue with any other movies on PS4. The only difference I can see is that my videos are playing from a BD-R, and commercial releases are from a pressed disc.
B-pyramids may require a longer lookahead read, so if you have dodgy BD-R media, some read errors might cause a problem there.
But the fact that a muxing fix fixed things suggests that commercial discs were created using a different muxer. I certainly have always used B-pyramid strict with any BD encodes I've done. Note the BD spec requires that Strictly Hierarchical Pyramids be used.
Precomposed
26th February 2016, 19:09
B-pyramids may require a longer lookahead read, so if you have dodgy BD-R media, some read errors might cause a problem there.
But the fact that a muxing fix fixed things suggests that commercial discs were created using a different muxer. I certainly have always used B-pyramid strict with any BD encodes I've done. Note the BD spec requires that Strictly Hierarchical Pyramids be used.
What about the vbv buffer? It is my understanding it should never exceed the max rate. Do you think a vbv-bufsize and vbv-maxrate both set at 20000 impact the PS4's ability to load the frames properly?
benwaggoner
26th February 2016, 19:20
What about the vbv buffer? It is my understanding it should never exceed the max rate. Do you think a vbv-bufsize and vbv-maxrate both set at 20000 impact the PS4's ability to load the frames properly?
Those are within spec. But certainly in the DVD-R era we found older players needed peak bitrates significantly below spec when using writable media.
I'm a fan of the Level 4.0 single-slice 2-sec GOP --vbv-maxrate 15000 --vbv-bitrate <=15000 mode encoding for your case. With x265, most content will look good at that bitrate, and being able to use a 2-sec GOP helps quality/efficiency significantly. The specifics should be upthread in various places.
I've been able to get a 2-hour move onto DVD-9 media this way, as an experiment, back when BD-R was expensive and the per-title encryption for replicated BD discs was way high for short-run titles. You could stamp a DVD-9 with a BD payload without needing encryption, and at a much lower price.
sneaker_ger
3rd June 2017, 21:20
I just realized the images are stored externally. Better have backup:
FranceBB
6th June 2017, 01:20
Thank you for this guide.
I gotta make a Bluray out of a PAL XDCAM MXF file and I'm gonna use Avisynth and x264 this time (not to bother AVID).
I need the maximum compatibility and I think these settings should be fine:
avs4x264mod.exe "AVS Script.avs" --x264-binary "x264.exe" --bitrate 25000 --preset medium --ref 4 --level 4.1 --profile High --vbv-bufsize 25000 --vbv-maxrate 25000 --overscan show --keyint 25 --slices 4 --sar 1:1 --videoformat PAL --tff --nal-hrd vbr --bluray-compat --colormatrix bt709 --transfer bt709 --colorprim bt709 --range tv --log-level info --thread-input --opencl --output raw_video.h264
Can you confirm they are fine? Any suggestions?
Sharc
6th June 2017, 08:18
Thank you for this guide.
I gotta make a Bluray out of a PAL XDCAM MXF file and I'm gonna use Avisynth and x264 this time (not to bother AVID).
I need the maximum compatibility and I think these settings should be fine:
avs4x264mod.exe "AVS Script.avs" --x264-binary "x264.exe" --bitrate 25000 --preset medium --ref 4 --level 4.1 --profile High --vbv-bufsize 25000 --vbv-maxrate 25000 --overscan show --keyint 25 --slices 4 --sar 1:1 --videoformat PAL --tff --nal-hrd vbr --bluray-compat --colormatrix bt709 --transfer bt709 --colorprim bt709 --range tv --log-level info --thread-input --opencl --output raw_video.h264
Can you confirm they are fine? Any suggestions?
What is your script?
For blu-ray compliant x264 settings you find references here:
http://forum.doom9.org/showpost.php?p=1399419&postcount=1
https://sites.google.com/site/x264bluray/
jpsdr
6th June 2017, 09:06
You miss the following to be sure :
--b-pyramid strict --min-keyint 1 --mvrange 511 --bframe 3 --aud
I'm not sure if --b-pyramid strict is included with the --bluray-compat, so, it will not hurt to add it.
As you're using --tff it means that your video is not progressive, in that case, you also need :
--pic-struct
You don't need this last one for progressive video.
If you want optimal result, you can add :
--open-gop
And, you can also go up to these values if you want :
--vbv-maxrate 40000 --vbv-bufsize 30000
sneaker_ger
6th June 2017, 10:56
I'm not sure if --b-pyramid strict is included with the --bluray-compat
It is, as are --min-keyint 1, --bframes 3 and --aud. (pyramid and bframes as min(x,y)). Special --mvrange isn't necessary either.
As you're using --tff it means that your video is not progressive, in that case, you also need
--pic-struct is implied by --tff/--bff/--fake-interlaced.
/edit: Oh, he does want to make a Blu-ray out of XDCAM MXF. I didn't read correctly. Personally, I'd just use the examples linked by Sharc. Maybe even use a good deinterlacer like QTGMC to go 720p50.
--sar 1:1 and bt709 are not allowed for PAL. See start post.
benwaggoner
6th June 2017, 18:16
It is, as are --min-keyint 1
Is my dim recollection of --min-keyint 2 being requires/preferable incorrect?
Also, since he's only using 25 Mbps vbv-bufsize/maxrate, he might as well use Level 4.0 and eliminate --slices 4.
Slices are only required with Level 4.1.
sneaker_ger
6th June 2017, 18:23
Is my dim recollection of --min-keyint 2 being requires/preferable incorrect?
It would have always been required by the specs but the x264 developers only noticed it in 2012.
http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=9fb055856a617f5ddca15a0c5745ff1c1486ad9a
jpsdr
6th June 2017, 19:34
--sar 1:1 and bt709 are not allowed for PAL. See start post.
I thought the video was 1080p.
If video is indeed 576i, that's a total another story.
A lot of optimization can be done indeed.
Reduce the level to 4.0 to avoid slices, and reduce buffer/bitrate max to 15000 to have 2s GOP length.
Buffer and bitrate max at 15000 is very largely enough to properly encode a 576i video. This will allow a max keyint of 50, which will produce even better results.
i would suggest for 576i :
--profile high --level 4.0 --vbv-maxrate 15000 --vbv-bufsize 15000 --keyint 50 --ref 6 --open-gop
No need for slices. And as video is only 576i, you can increase ref frames to 6.
The sar is according the video, is it a 4/3 or 16/9 video ?
4/3, you have to use :
--sar 12:11
16/9, you have to use :
--sar 16:11
The color for pal 576i is :
--colorprim bt470bg --transfer bt470bg --colormatrix bt470bg --videoformat pal
FranceBB
8th June 2017, 00:14
It's 1080i, it's not 720p.
My source it's an XDCAM 1080i 50Mbit/s 4:2:2 yv16, interlaced 25fps (50i), 4 audio tracks: CH.1-2 PCM Stereo German Full Mix, CH.3-4 PCM Stereo Music & Effects. It's really interlaced, it's not just flagged as interlaced and I would like to keep it that way.
Source:
General
Complete name : Filemaster.mxf
Format : MXF
Commercial name : XDCAM HD422
Format version : 1.2
Format profile : OP-1a
Format settings : Closed / Complete
File size : 12.0 GiB
Duration : 28mn 56s
Overall bit rate : 59.2 Mbps
Encoded date : 2017-06-03 20:21:00.208
Writing application : Omneon Inc. Omneon Media Subsystem 6.4.1.0.1
Writing library : Omneon Media Api (linux)
Video
ID : 2
Format : MPEG Video
Commercial name : XDCAM HD422
Format version : Version 2
Format profile : 4:2:2@High
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Format settings, picture structure : Frame
Format settings, wrapping mode : Frame
Codec ID : 0D01030102046101-0401020201040300
Duration : 28mn 56s
Bit rate : 50.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25 fps
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.965
Time code of first frame : 00:00:00:00
Time code source : Group of pictures header
Stream size : 10.1 GiB (84%)
Color primaries : BT.709
Transfer characteristics : BT.709
Audio #1
ID : 3
Format : PCM
Format settings, Endianness : Little
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100
Duration : 28mn 56s
Bit rate mode : Constant
Bit rate : 2 304 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Frame rate : 25 fps
Bit depth : 24 bits
Stream size : 477 MiB (4%)
Audio #2
ID : 4
Format : PCM
Format settings, Endianness : Little
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100
Duration : 28mn 56s
Bit rate mode : Constant
Bit rate : 2 304 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Frame rate : 25 fps
Bit depth : 24 bits
Stream size : 477 MiB (4%)
Audio #3
ID : 5
Format : PCM
Format settings, Endianness : Little
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100
Duration : 28mn 56s
Bit rate mode : Constant
Bit rate : 2 304 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Frame rate : 25 fps
Bit depth : 24 bits
Stream size : 477 MiB (4%)
Audio #4
ID : 6
Format : PCM
Format settings, Endianness : Little
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100
Duration : 28mn 56s
Bit rate mode : Constant
Bit rate : 2 304 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Frame rate : 25 fps
Bit depth : 24 bits
Stream size : 477 MiB (4%)
Other #1
ID : 1-Material
Type : Time code
Format : MXF TC
Time code of first frame : 10:00:00:00
Time code settings : Material Package
Time code, striped : Yes
Other #2
ID : 1-Source
Type : Time code
Format : MXF TC
Time code of first frame : 10:00:00:00
Time code settings : Source Package
Time code, striped : Yes
My Avisynth Script:
video=FFVideoSource("Filemaster.mxf")
ch1=WAVSource("ch1.wav")
ch2=WAVSource("ch2.wav")
audio=MergeChannels(ch1, ch2)
AudioDub(video, audio)
Normalize(0.89, show=false)
Converttoyv12(interlaced=true)
f3kdb(range=15, Y=80, Cb=60, Cr=60, grainY=0, grainC=0, keep_tv_range=True, input_depth=8, output_depth=8)
My "new" x264.bat (I added jpsdr suggestions):
avs4x264mod.exe "AVS Script.avs" --x264-binary "x264.exe" --bitrate 25000 --preset medium --ref 4 --level 4.1 --profile High --vbv-bufsize 40000 --vbv-maxrate 30000 --overscan show --keyint 25 --slices 4 -b-pyramid strict --min-keyint 1 --mvrange 511 --bframe 3 --aud --sar 1:1 --pic-struct --videoformat PAL --interlaced --tff --nal-hrd vbr --bluray-compat --colormatrix bt709 --transfer bt709 --colorprim bt709 --range tv --log-level info --thread-input --opencl --output raw_video.h264
If you want optimal result, you can add :
--open-gop
Uhm... I noticed that XDCAM files require closed GOP: M=3, N=12. I'm gonna encode a Bluray, which is different and in H.264, so it's different, but is --open-gop going to be a problem? Will I benefit from it without affecting compatibility?
Maybe even use a good deinterlacer like QTGMC
I know QTGMC, it's my first favorite deinterlacer (the second one is tdeint). Anyway, my source is 1080i, is it really worth deinterlacing? I don't think 1920x1080 25fps progressive is allowed by Bluray, is it?
--sar 1:1 and bt709 are not allowed for PAL. See start post.
Ok. --sar 1:1 it's the one for 1920x1080, right? And BT.709 it's the colormatrix for HD contents, like my source. Also, it seems that it's also suggested as option here: https://sites.google.com/site/x264bluray/home/1080i
Are you sure it's not supported?
jpsdr
8th June 2017, 08:41
Source and target are different. If you target Blu-Ray, you can use open-gop (needs bluray-compat but you've put it, so it's fine), it doesn't matter what source has, this parameter is for the target only.
And as it's HD 1920x1080, the sar is 1:1 and color is BT.709. For me, your command line is good.
About deinterlace and the remark about the sar and color, it's probably because he thought it was 576i.
sneaker_ger
8th June 2017, 09:35
About deinterlace and the remark about the sar and color, it's probably because he thought it was 576i.
Yes, he only mentioned "PAL XDCAM MXF" which I assumed to be 720x576 interlaced. He didn't say anything about 1080i.
I would remove "--videoformat PAL" and "--overscan show", I'm not sure they are allowed or appropriate. (And maybe --opencl if you're targeting production. The minor speedup might not be worth the additional stability risks.)
Sharc
8th June 2017, 11:51
"If something CAN be made complicated, it WILL..." (Murphy).
Why not follow the instructions for blu-ray compliant encoding given in the first post of this thread, and the links to the examples with commandlines provided at the end of the first post of this sticky ... :devil:
FranceBB
8th June 2017, 15:39
Source and target are different. If you target Blu-Ray, you can use open-gop (needs bluray-compat but you've put it, so it's fine), it doesn't matter what source has, this parameter is for the target only.
And as it's HD 1920x1080, the sar is 1:1 and color is BT.709. For me, your command line is good.
About deinterlace and the remark about the sar and color, it's probably because he thought it was 576i.
Got it.
Yes, he only mentioned "PAL XDCAM MXF" which I assumed to be 720x576 interlaced. He didn't say anything about 1080i.
I would remove "--videoformat PAL" and "--overscan show", I'm not sure they are allowed or appropriate. (And maybe --opencl if you're targeting production. The minor speedup might not be worth the additional stability risks.)
Yes, I'm gonna remove them.
Thank you, everyone! :)
mp3dom
8th June 2017, 19:47
Everything can be summarized as:
avs4x264mod.exe "AVS Script.avs" --x264-binary "x264.exe" --bitrate 25000 --preset medium --ref 4 --level 4.1 --profile High --vbv-bufsize 30000 --vbv-maxrate 40000 --keyint 25 --slices 4 --bframe 3 --sar 1:1 --tff --bluray-compat --colormatrix bt709 --transfer bt709 --colorprim bt709 --log-level info --thread-input --output raw_video.h264
and you'll get the same quality.
NOTE: In your command line you've switched the values of bufsize and maxrate. Bufsize needs to be 30 Mbps max, while maxrate can be up to 40 Mbps.
With your values, you'll get out of specs discs. Depending by the authoring software, you can get your file rejected or accepted but with buffer overflows problems during multiplexing or verification process.
Also, can't understand why you're normalizing your audio by peak (that can create weird results). I guess you know there are EBU standards and normalizing by peak will likely alter the audio in a not-standard way. Do you have valid reasons for that?
benwaggoner
8th June 2017, 19:50
And yes, if your source is interlaced, you probably should just leave it like that. Anything else will lose spatial or temporal detail.
Sent from my iPhone using Tapatalk
sneaker_ger
8th June 2017, 20:01
Everything can be summarized as:
--profile High --bframe 3 --log-level info --thread-input could also be dropped, while we're at it (and default is --ref 3). But of course it doesn't make any difference.
As Sharc said people make things too complicated instead of just reading the docs/examples...
FranceBB
9th June 2017, 02:03
Everything can be summarized as:
and you'll get the same quality.
NOTE: In your command line you've switched the values of bufsize and maxrate. Bufsize needs to be 30 Mbps max, while maxrate can be up to 40 Mbps.
With your values, you'll get out of specs discs. Depending by the authoring software, you can get your file rejected or accepted but with buffer overflows problems during multiplexing or verification process.
Also, can't understand why you're normalizing your audio by peak (that can create weird results). I guess you know there are EBU standards and normalizing by peak will likely alter the audio in a not-standard way. Do you have valid reasons for that?
Got it. I'm gonna bring them back to 25Mbit/s just to be 100% sure.
Besides, I need my audio to be as close as possible to -24 LUFS. We generally use a machine called "Sony DP 600" to achieve this. Is there a similar way to achieve this via avisynth?
mp3dom
9th June 2017, 08:40
Besides, I need my audio to be as close as possible to -24 LUFS. We generally use a machine called "Sony DP 600" to achieve this. Is there a similar way to achieve this via avisynth?
As far as I know, no, there isn't. You need a DAW and proper plugins to do that. -24db(-23, depending on the program) LUFS is the standard and is not so loud. If you normalize by peak you can get totally wrong results. Think of an inaudible audio with just a single peak at -3 dB, you'll get your audio boosted by only 2dB. The LUFS in that case will be even lower than -24 (probably -30) so it will be rejected. The other case, a very compressed (by dynamic range) audio where you have plenty of spikes at -5dB, you'll get a boost of 4dB so a very louder audio will be even louder. The LUFS in that case will probably be -18 or even higher. Normalizing by peak is, almost always, a bad choice.
If you can't access to a DAW/plugins, you can get decent results normalizing by RMS, with a target value of -26/-27dB. Still, this may be fine for non-professional jobs, because if you deliver the audio for broadcasting, you need to strictly follow the EBU standard.
imsrk48
1st January 2018, 04:04
where is color correction option in MeGui Latest Version
Sent from my P4 using Tapatalk
DenisRodman
11th March 2018, 17:13
The HDMV Timebased Slideshow is an application to present still pictures. It is same as movie presentation except that a presenting picture is a still picture. A still picture is coded as an MPEG-4 AVC IDR I-frame or an HEVC IDR I-frame. Presentation timing of the still picture is controlled by the associated PTS value and the presentation progresses with predefined timing axis. The stream of the Timebased Slideshow may contain data of Audio, Subtitle and Graphics. The presentation timing of these data is controlled by each PTS value in the stream.
I have 10 pictures 1.png, 2.png, 3.png ... 10.png how can create Timebased Slideshow MPEG-4 AVC IDR I-frame?
Please write the full code Command Line.
Thanks.
Qarmaa
15th May 2018, 10:32
I have 10 pictures 1.png, 2.png, 3.png ... 10.png how can create Timebased Slideshow MPEG-4 AVC IDR I-frame?
Please write the full code Command Line.
Thanks.
There is no way you can do this by using only x264. To create compliant timebased or browsable slideshow you need to integrate AVC SEI metadata:
ct_type: 2
nuit_field_base_flag: 1
counting_type: 4
full_timestamp_flag: 0
discontinuity_flag: 0
cnt_dropped_flag: 0
n_frame: 0
seconds_flag: 1
seconds_value: 1
(From stream produced by Scenarist's Still Image Encoder)
Those parameters can be set via libav's API
WorldOfCrap
23rd August 2018, 04:22
So, as a bit of a side project, I thought I would attempt to start encoding Blu-rays in ffmpeg instead of x264 with AVIsynth. Since ffmpeg natively supports almost any video format, and is 64-bit all the way through, it would offer much faster encoding, not to mention support for Mac and *nix systems.
Since ffmpeg uses libx264, I thought that, once I translated the x264 syntax to ffmpeg syntax, we should be able to get identical results. The Scenarist crew has offered to assist in running some verification checks.
Two minor hiccups so far: First, ffmpeg apparently doesn't enforce the Level 4.0/4.1 limit on reference frames, so that setting has to be manually spelled out in ffmpeg with the flag "-refs 4"
Secondly, interlaced ProRes isn't handled properly by ffmpeg unless you tell it to use interlaced scaling (even if you're not scaling the image at all).
After some trial and error, we have the following command line that, so far, passes Eclipse verification (for 1080p/23.976):
ffmpeg -i "filename" -c:v libx264 -pass 1 -b:v 30000k -tune film -level 41 -g 24 -r 24000/1001 -pix_fmt yuv420p \
-preset veryslow -vf setsar=sar=1/1 -refs 4 -color_primaries bt709 -color_trc bt709 -colorspace bt709 \
-x264opts bluray-compat=1:vbv-bufsize=30000:vbv-maxrate=40000:slices=4:open-gop=1:force-cfr=1 -y \
-f rawvideo /dev/null
ffmpeg -i "filename" -c:v libx264 -pass 2 -b:v 30000k -tune film -level 41 -g 24 -r 24000/1001 -pix_fmt yuv420p \
-preset veryslow -vf setsar=sar=1/1 -refs 4 -color_primaries bt709 -color_trc bt709 -colorspace bt709 \
-x264opts bluray-compat=1:vbv-bufsize=30000:vbv-maxrate=40000:slices=4:open-gop=1:force-cfr=1 -y \
-f rawvideo "filename.264"
So far, so good. Now I'm working on doing the other formats. One problem is, I can't find any reference on how to pass the x264 "--pulldown 32" flag for encoding 24p SD material. The closest thing I can find is the telecine filter, but that ACTUALLY adds the extra fields to convert 24 to 30 frames, instead of just the RFF flags.
Anyone know how to do that? Thanks!
(Edit: Yes, I already tried adding pulldown=32 to -x264opts, but that didn't work.)
mp3dom
23rd August 2018, 13:08
As far as I know, ffmpeg doesn't support all the parameters of x264cli, so you can also evaluate to use ffmpeg just to read the file and pipe it to x264cli.
kolak
23rd August 2018, 21:43
You can't add soft pulldown with ffmpeg for x264. Use x264 binary.
WorldOfCrap
24th August 2018, 02:51
Thanks mp3dom and kolak! I'll tinker with piping from ffmpeg to x264.
In the mean time, we've passed verification for encoding 1080i on ffmpeg! Even better, I'm getting SIGNIFICANT speed increases -- sometimes nearly 2x -- over just encoding with x264 & AVIsynth.
We've only passed as 29.97i/TFF, but 25i and BFF should work too (we'll check those next week). Just change -g 30 to -g 25 if you're doing 25 fps, and fieldorder=bff if necessary.
I'm not sure if "-flags +ilme+ildct" is still necessary or if those are deprecated, but it passed verification like this, so I'm leaving 'em in for now.
ffmpeg -I input.file -c:v libx264 -pass 1 -b:v XXXXX -tune film -level 41 -g 30 -r 30000/1001 -flags +ilme+ildct -pix_fmt yuv420p -preset veryslow \
-filter_complex scale=interl=1,setsar=sar=1/1,fieldorder=tff -refs 4 -color_primaries bt709 -color_trc bt709 -colorspace bt709 \
-x264opts bluray-compat=1:vbv-bufsize=30000:vbv-maxrate=40000:slices=4:open-gop=1:force-cfr=1 -y -f rawvideo /dev/null
ffmpeg -I input.file -c:v libx264 -pass 2 -b:v XXXXX -tune film -level 41 -g 30 -r 30000/1001 -flags +ilme+ildct -pix_fmt yuv420p -preset veryslow \
-filter_complex scale=interl=1,setsar=sar=1/1,fieldorder=tff -refs 4 -color_primaries bt709 -color_trc bt709 -colorspace bt709 \
-x264opts bluray-compat=1:vbv-bufsize=30000:vbv-maxrate=40000:slices=4:open-gop=1:force-cfr=1 -y -f rawvideo output.264
Update: 480i/29.97 verified OK too! (Below is for 16x9 video, if you need 4x3 change sar=40/33 to sar=10/11, and also field order if necessary)
ffmpeg -I input.file -c:v libx264 -pass 1 -b:v XXXXX -tune film -level 41 -g 30 -r 30000/1001 -flags +ilme+ildct -pix_fmt yuv420p \
-preset veryslow -filter_complex scale=interl=1,fieldorder=tff,setsar=sar=40/33 -refs 6 -color_primaries smpte170m -color_trc smpte170m \
-colorspace smpte170m -x264opts bluray-compat=1:vbv-bufsize=30000:vbv-maxrate=31000:slices=4:open-gop=1:force-cfr=1 -y -f rawvideo /dev/null
ffmpeg -I input.file -c:v libx264 -pass 2 -b:v XXXXX -tune film -level 41 -g 30 -r 30000/1001 -flags +ilme+ildct -pix_fmt yuv420p -preset veryslow \
-filter_complex scale=interl=1,fieldorder=tff,setsar=sar=40/33 -refs 6 -color_primaries smpte170m -color_trc smpte170m -colorspace smpte170m \
-x264opts bluray-compat=1:vbv-bufsize=30000:vbv-maxrate=31000:slices=4:open-gop=1:force-cfr=1 -y -f rawvideo output.264"
benwaggoner
28th August 2018, 18:42
In the mean time, we've passed verification for encoding 1080i on ffmpeg! Even better, I'm getting SIGNIFICANT speed increases -- sometimes nearly 2x -- over just encoding with x264 & AVIsynth.
Not surprising. Since you're really encoding 24 progressive frames instead of 30 interlaced frames, there's a lot less work for the encoder to do; fewer frames and no MBAFF.
sneaker_ger
28th August 2018, 19:42
If you get 2x speed increase it means your test is flawed.
benwaggoner
29th August 2018, 00:42
If you get 2x speed increase it means your test is flawed.
They also switched from 32-bit to 64-bit.
WorldOfCrap
26th September 2018, 03:44
Welp, that didn't work. Despite passing both Sony and Panasonic's verifier, we're still getting weird stuttering errors on PS4. So I guess scratch that, gotta stick with full-blown x264.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.