Log in

View Full Version : VC-1 to BluRay compatible AVC


FLX90
6th January 2019, 16:45
Hello everybody,

I have a large BluRay collection and I want to digitalize it and put the movies into a mp4-container.

With AVC and HEVC videostreams I'm fine, unfortunately some streams are in VC-1 format and don't fit into the container.


I want the best quality and also a BluRay compatible output.


I read the sticky (https://forum.doom9.org/showthread.php?t=154533) and this (http://www.x264bluray.com/home/1080i-p) and created my command:

x264-r2935-545de2f.exe --bitrate 16998 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.mkv OLD_BOY.Title0.mkv

x264-r2935-545de2f.exe --bitrate 16998 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out2.mkv OLD_BOY.Title0.mkv

Are these commands correct for my use?


Output file must be in raw 264 elementary stream (extension .264) otherwise settings will not applied correctly. DO NOT USE MKV OR MP4.
I have to use mkv to keep timecodes for VFR embedded in the container.
Or is there a workaround?

I get the bitrate for --bitrate from this:
ffprobe.exe OLD_BOY.Title0.mkv

ffprobe version 4.1 Copyright (c) 2007-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20181017
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Input #0, matroska,webm, from 'OLD_BOY.Title0.mkv':
Metadata:
title : OLD_BOY.Title0
encoder : libebml v1.3.4 + libmatroska v1.4.5
creation_time : 2019-01-04T14:04:03.000000Z
Duration: 01:59:52.51, start: 0.000000, bitrate: 20980 kb/s
Chapter #0:0: start 0.000000, end 359.067000
Metadata:
title : (01)00:00:00:000
Chapter #0:1: start 359.067000, end 518.142000
Metadata:
title : (02)00:05:59:067
Chapter #0:2: start 518.142000, end 736.277000
Metadata:
title : (03)00:08:38:142
Chapter #0:3: start 736.277000, end 997.121000
Metadata:
title : (04)00:12:16:277
Chapter #0:4: start 997.121000, end 1324.031000
Metadata:
title : (05)00:16:37:121
Chapter #0:5: start 1324.031000, end 1720.927000
Metadata:
title : (06)00:22:04:031
Chapter #0:6: start 1720.927000, end 2037.535000
Metadata:
title : (07)00:28:40:927
Chapter #0:7: start 2037.535000, end 2323.112000
Metadata:
title : (08)00:33:57:535
Chapter #0:8: start 2323.112000, end 2557.137000
Metadata:
title : (09)00:38:43:112
Chapter #0:9: start 2557.137000, end 2856.687000
Metadata:
title : (10)00:42:37:137
Chapter #0:10: start 2856.687000, end 3165.620000
Metadata:
title : (11)00:47:36:687
Chapter #0:11: start 3165.620000, end 3430.593000
Metadata:
title : (12)00:52:45:620
Chapter #0:12: start 3430.593000, end 3659.864000
Metadata:
title : (13)00:57:10:593
Chapter #0:13: start 3659.864000, end 4015.219000
Metadata:
title : (14)01:00:59:864
Chapter #0:14: start 4015.219000, end 4356.769000
Metadata:
title : (15)01:06:55:219
Chapter #0:15: start 4356.769000, end 4766.887000
Metadata:
title : (16)01:12:36:769
Chapter #0:16: start 4766.887000, end 5062.766000
Metadata:
title : (17)01:19:26:887
Chapter #0:17: start 5062.766000, end 5350.428000
Metadata:
title : (18)01:24:22:766
Chapter #0:18: start 5350.428000, end 5728.556000
Metadata:
title : (19)01:29:10:428
Chapter #0:19: start 5728.556000, end 6000.494000
Metadata:
title : (20)01:35:28:556
Chapter #0:20: start 6000.494000, end 6426.503000
Metadata:
title : (21)01:40:00:494
Chapter #0:21: start 6426.503000, end 6688.431000
Metadata:
title : (22)01:47:06:503
Chapter #0:22: start 6688.431000, end 7053.379000
Metadata:
title : (23)01:51:28:431
Chapter #0:23: start 7053.379000, end 7192.512000
Metadata:
title : (24)01:57:33:379
Stream #0:0: Video: vc1 (Advanced) (WVC1 / 0x31435657), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Metadata:
BPS : 16998307
BPS-eng : 16998307
DURATION : 01:59:51.476000000
DURATION-eng : 01:59:51.476000000
NUMBER_OF_FRAMES: 172423
NUMBER_OF_FRAMES-eng: 172423
NUMBER_OF_BYTES : 15280364741
NUMBER_OF_BYTES-eng: 15280364741
_STATISTICS_WRITING_APP: DVDFab 11.0.1.0
_STATISTICS_WRITING_APP-eng: DVDFab 11.0.1.0
_STATISTICS_WRITING_DATE_UTC: 2019-01-04 14:04:03
_STATISTICS_WRITING_DATE_UTC-eng: 2019-01-04 14:04:03
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:1(deu): Audio: dts (DTS-HD MA), 48000 Hz, 5.1(side), s16p (default)
Metadata:
BPS : 1964511
BPS-eng : 1964511
DURATION : 01:59:52.512000000
DURATION-eng : 01:59:52.512000000
NUMBER_OF_FRAMES: 674298
NUMBER_OF_FRAMES-eng: 674298
NUMBER_OF_BYTES : 1766221136
NUMBER_OF_BYTES-eng: 1766221136
_STATISTICS_WRITING_APP: DVDFab 11.0.1.0
_STATISTICS_WRITING_APP-eng: DVDFab 11.0.1.0
_STATISTICS_WRITING_DATE_UTC: 2019-01-04 14:04:03
_STATISTICS_WRITING_DATE_UTC-eng: 2019-01-04 14:04:03
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:2(kor): Audio: dts (DTS-HD MA), 48000 Hz, 5.1(side), s16p
Metadata:
BPS : 2014735
BPS-eng : 2014735
DURATION : 01:59:52.512000000
DURATION-eng : 01:59:52.512000000
NUMBER_OF_FRAMES: 674298
NUMBER_OF_FRAMES-eng: 674298
NUMBER_OF_BYTES : 1811376192
NUMBER_OF_BYTES-eng: 1811376192
_STATISTICS_WRITING_APP: DVDFab 11.0.1.0
_STATISTICS_WRITING_APP-eng: DVDFab 11.0.1.0
_STATISTICS_WRITING_DATE_UTC: 2019-01-04 14:04:03
_STATISTICS_WRITING_DATE_UTC-eng: 2019-01-04 14:04:03
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

--> BPS : 16998307


MediaInfo from the VC-1 example:
General
Unique ID : 208572162048080453250143263780006303268 (0x9CE9A22F8C9B346D9895DBE317D0D55B)
Complete name : C:\Movies\Test\OLD_BOY.Title0.mkv
Format : Matroska
Format version : Version 2
File size : 17.6 GiB
Duration : 1 h 59 min
Overall bit rate mode : Variable
Overall bit rate : 21.0 Mb/s
Movie name : OLD_BOY.Title0
Encoded date : UTC 2019-01-04 14:04:03
Writing application : DVDFab 11.0.1.0
Writing library : libebml v1.3.4 + libmatroska v1.4.5

Video
ID : 1
Format : VC-1
Format profile : Advanced@L3
Codec ID : V_MS/VFW/FOURCC / WVC1
Codec ID/Hint : Microsoft
Duration : 1 h 59 min
Bit rate : 17.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.342
Stream size : 14.2 GiB (81%)
Default : Yes
Forced : No

Audio #1
ID : 2
Format : DTS XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 h 59 min
Bit rate mode : Variable
Bit rate : 1 965 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 16 bits
Compression mode : Lossless
Stream size : 1.64 GiB (9%)
Language : German
Default : Yes
Forced : No

Audio #2
ID : 3
Format : DTS XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 h 59 min
Bit rate mode : Variable
Bit rate : 2 015 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 16 bits
Compression mode : Lossless
Stream size : 1.69 GiB (10%)
Language : Korean
Default : No
Forced : No

Menu
00:00:00.000 : en:(01)00:00:00:000
00:05:59.067 : en:(02)00:05:59:067
00:08:38.142 : en:(03)00:08:38:142
00:12:16.277 : en:(04)00:12:16:277
00:16:37.121 : en:(05)00:16:37:121
00:22:04.031 : en:(06)00:22:04:031
00:28:40.927 : en:(07)00:28:40:927
00:33:57.535 : en:(08)00:33:57:535
00:38:43.112 : en:(09)00:38:43:112
00:42:37.137 : en:(10)00:42:37:137
00:47:36.687 : en:(11)00:47:36:687
00:52:45.620 : en:(12)00:52:45:620
00:57:10.593 : en:(13)00:57:10:593
01:00:59.864 : en:(14)01:00:59:864
01:06:55.219 : en:(15)01:06:55:219
01:12:36.769 : en:(16)01:12:36:769
01:19:26.887 : en:(17)01:19:26:887
01:24:22.766 : en:(18)01:24:22:766
01:29:10.428 : en:(19)01:29:10:428
01:35:28.556 : en:(20)01:35:28:556
01:40:00.494 : en:(21)01:40:00:494
01:47:06.503 : en:(22)01:47:06:503
01:51:28.431 : en:(23)01:51:28:431
01:57:33.379 : en:(24)01:57:33:379


Best regards,
Felix

sneaker_ger
6th January 2019, 17:15
Blu-Rays are always CFR so adding --fps 24000/1001 to ensure constant 24/1.001 fps should be fine.

Otherwise the settings look ok. But since neither mkv nor mp4 are part of the Blu-Ray specification successful playback on Blu-Ray players isn't guaranteed. That's only for "true" Blu-Rays with their m2ts structure, on pressed discs with encryption which you cannot produce as a home user. (I personally don't bother when creating mkv beyond maybe the level 4.1 or slices requirements imposed by some hardware H.264 decoders).

Sharc
6th January 2019, 17:42
@FLX90:
I am not quite sure what you want to achieve, however:
- VC-1 video is blu-ray compliant. Why convert?
- .mp4 (your desired container) is NOT blu-ray compliant (as requested by you). What do you actualy mean by "blu-ray compliant"?
- if you want to put the VC-1 video into an .mkv container your could remux it with mkvtoolnix
- or remux it with tsMuxer to .m2ts ….
Maybe I misunderstand your needs?

Edit:
If you want to convert your VC-1 in .mkv to AVC h264 and put it into an .mp4 container you may want to try handbrake.

FLX90
6th January 2019, 19:58
Thank you for your answers.

Blu-Rays are always CFR so adding --fps 24000/1001 to ensure constant 24/1.001 fps should be fine.
I tried this and 58 % of the frames are variable?

ffmpeg -i OLD_BOY.Title0.mkv -vf vfrdet -f null -
[Parsed_vfrdet_0 @ 0000000003174400] VFR:0.583336 (100580/71842) min: 41 max: 42)

I am not quite sure what you want to achieve
I just want to create a video stream that is as close as the video stream would look like if the BluRay was released with AVC.

Just for comprehension.
--bitrate 16997 would be worse quality than the original VC-1.
--bitrate 16999 wouldn't be better quality than the original VC-1 and would just waste space?

Thanks.

Sharc
6th January 2019, 20:20
I just want to create a video stream that is as close as the video stream would look like if the BluRay was released with AVC.

Just for comprehension.
--bitrate 16997 would be worse quality than the original VC-1.
--bitrate 16999 wouldn't be better quality than the original VC-1 and would just waste space?

Thanks.
Well, whenever a lossy source (your VC-1) is getting re-encoded with a lossy encoder such as x264 it will introduce more/new losses and artefacts, unless you set the bitrate very very high or encode "lossless" (--crf 0) producing huge file sizes. The extra losses may however be barely visible when re-encoding with a sufficiently high bitrate or a --crf of say 12 or even less.
So re-encoding with the same bitrate as the "original" source does not mean that the quality remains the same (untouched).

If you want to preserve the quality of your VC-1 source you may just copy the videostream and mux it into a new container, like mkv or mp4 or m2ts.

sneaker_ger
6th January 2019, 20:22
I tried this and 58 % of the frames are variable?

ffmpeg -i OLD_BOY.Title0.mkv -vf vfrdet -f null -
[Parsed_vfrdet_0 @ 0000000003174400] VFR:0.583336 (100580/71842) min: 41 max: 42)
That's probably just some jitter because mkv container cannot accurately store constant 24/1.001 fps.
1000ms/(24/1.001)= 41.70833333333333333.....ms
Mkv will store it so the frame durations switch between 41ms and 42ms so that on average it is 41.7083....ms. Technically it is vfr, but for practical purposes it is cfr (as was the original source).

If you are unsure just leave the fps settings alone.

Just for comprehension.
--bitrate 16997 would be worse quality than the original VC-1.
--bitrate 16999 wouldn't be better quality than the original VC-1 and would just waste space?.
Lossy AVC re-encode will always lose information from original. Whether you encode with 16997, 16999 or 10000000 kbps. But 10000000 will lose less information than 16997.

At ~17 Mbps a human will usually not notice any difference to the original Blu-Ray, though, so that's ok. That's your goal, right?

FLX90
6th January 2019, 20:48
Well, whenever a lossy source (your VC-1) is getting re-encoded with a lossy encoder such as x264 it will introduce more/new losses and artefacts, unless you set the bitrate very very high or encode "lossless" (--crf 0) producing huge file sizes. The extra losses may however be barely visible when re-encoding with a sufficiently high bitrate or a --crf of say 12 or even less.
So re-encoding with the same bitrate as the "original" source does not mean that the quality remains the same (untouched).

Lossy AVC re-encode will always lose information from original. Whether you encode with 16997, 16999 or 10000000 kbps. But 10000000 will lose less information than 16997.

Ah, okay. That makes it clear.
I tried --crf 0 and the filesize would be many terabytes. So that's unusable.


At ~17 Mbps a human will usually not notice any difference to the original Blu-Ray, though, so that's ok. That's your goal, right?

My goal is to preserved most information I can (but with usable filesize).
But as I take it the one exlcudes the other.

Would more passes bring me closer to the original without dramatically increasing the filesize?


-p, --pass <integer> Enable multipass ratecontrol
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file

asarian
6th January 2019, 22:33
I'm still kinda unclear what container exactly won't take a VC1 stream, anno 2019; .mt2s certainly will.

Way back when -- before my Zbox -- my old PS3 wouldn't play VC1, so I needed to re-encode those streams. It's hard to imagine there's still a need for that these days.

Sharc
6th January 2019, 23:17
Would more passes bring me closer to the original without dramatically increasing the filesize?

Multipass does not increase the filesize.
2 passes are typically used to hit a target size precisely e.g. in order to fill a disc. More than 2 passes is considered a waste of encoding time with little to no benefit for x264.
If the file size isn't critical one would normally prefer a 1 pass crf encode, e.g. --crf 16 or --crf 17 for very good quality. But as has been already said even when you encode with 1-pass ABR at around 17 Mbps it will be difficult to spot differences against your VC-1 source. Nothing to worry about.

Sharc
7th January 2019, 00:01
I'm still kinda unclear what container exactly won't take a VC1 stream, anno 2019; .mt2s certainly will.

Way back when -- before my Zbox -- my old PS3 wouldn't play VC1, so I needed to re-encode those streams. It's hard to imagine there's still a need for that these days.
The .mp4 standard (MPEG-4 Part 14) does not support VC-1 AFAIK. So if .mp4 is essential for the OP he has to re-encode the video to AVC.

asarian
7th January 2019, 03:20
The .mp4 standard (MPEG-4 Part 14) does not support VC-1 AFAIK. So if .mp4 is essential for the OP he has to re-encode the video to AVC.

In that case, he might want to look into denoising the film a bit too (if applicable); that way at least he'll get something useful out of the re-encode. :)

But why .mp4 then? Does it even support DTS-MA? Or TrueHD? Seems like an odd container to mux one's blu-rays to, but I suppose the OP has reasons.

nevcairiel
7th January 2019, 09:59
MP4 supports DTS in all variants (at least in theory, how many players play that is another question), but not TrueHD.

Sharc
7th January 2019, 11:13
@FLX90
As a quick test for what gets packed into an .mp4 container and whether your playback device will play it you may want to try:
ffmpeg.exe -i "yoursource.mkv" -c:a copy -c:v copy "output.mp4"

It should pack your VC-1 untouched (=original quality) plus the first acceptable audio stream into an .mp4 container. Then try to play the file "output.mp4" with your player. What do you get?

filler56789
7th January 2019, 15:04
The .mp4 standard (MPEG-4 Part 14) does not support VC-1 AFAIK.

Yes, it does. Both L-Smash's muxer and ffmpeg are able to wrap VC-1 streams in MP4 files since years ago.

FLX90
7th January 2019, 15:34
I tried the re-encode yesterday and it took 20 hours for the 2 passes on my i7 5th gen.

I'm glad that only a few BluRays of my collection are in VC-1.


It should pack your VC-1 untouched (=original quality) plus the first acceptable audio stream into an .mp4 container. Then try to play the file "output.mp4" with your player. What do you get?


That works, I'm really surprised (also Wikipeadia (https://en.wikipedia.org/wiki/MPEG-4_Part_14#Data_streams) don't list VC-1 as a proper stream).
I only tried it with m4v, because that is the container I'm working with at the end.
Thought that m4v is a mp4 container ...

However. VC-1 in M4V don't work.

Sharc
7th January 2019, 17:03
That works, I'm really surprised (also Wikipeadia (https://en.wikipedia.org/wiki/MPEG-4_Part_14#Data_streams) don't list VC-1 as a proper stream).

Good to see that it works. It will save you a lot of encoding time (if your player plays it).
I only tried it with m4v, because that is the container I'm working with at the end.
Thought that m4v is a mp4 container ...

However. VC-1 in M4V don't work.
m4v is not a container, m4v its just the extension of a video stream. The container is .mp4

benwaggoner
7th January 2019, 20:29
The .mp4 standard (MPEG-4 Part 14) does not support VC-1 AFAIK. So if .mp4 is essential for the OP he has to re-encode the video to AVC.
VC-1 has always had a MP4 mapping. The whole DASH/Adaptive Streaming ecosystem was launched with VC-1 in fragmented MPEG-4 containers. The Smooth Streaming .ismv files were just fragmented MP4 files (either VC-1 or H.264) with a different extension because a lot of parsers back then couldn't handle fMP4.

Maybe a given muxer can't handle VC-1 input, and there are certainly some players that won't play it back, but it is definitely a standard.

asarian
7th January 2019, 21:46
However. VC-1 in M4V don't work.

Still, out of sheer curiosity, why .mp4? (Is it because of ffmpeg?) I personally mux everything to an .m2ts container: that's always guaranteed to play on every blu-ray compatible device, and can contain all types of HD audio.

FLX90
7th January 2019, 22:24
Thought that m4v is a mp4 container ...

m4v is not a container, m4v its just the extension of a video stream. The container is .mp4

That's also my knowledge.

But:

Oldboy (2003) - VC-1:
ffmpeg -i OLD_BOY.Title0.mkv -map 0:0 -c copy temp.m4v

[ipod @ 000000000067adc0] Could not find tag for codec vc1 in stream #0, codec not currently supported in container
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
--> doesn't work.


Sympathy for Mr. Vengeance - AVC:
ffmpeg -i SYMPATHYFORMRVENGEANCE.Title5 -map 0:0 -c copy temp.m4v
--> works.

benwaggoner
7th January 2019, 22:38
That's also my knowledge.

But:

Oldboy (2003) - VC-1:
ffmpeg -i OLD_BOY.Title0.mkv -map 0:0 -c copy temp.m4v

[ipod @ 000000000067adc0] Could not find tag for codec vc1 in stream #0, codec not currently supported in container
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
--> doesn't work.

Sympathy for Mr. Vengeance - AVC:
ffmpeg -i SYMPATHYFORMRVENGEANCE.Title5 -map 0:0 -c copy temp.m4v
--> works.
That's mkv, not MP4. Entirely different container. MPEG-4 has codec mappings for almost anything you could think of.

Sharc
7th January 2019, 22:51
VC-1 has always had a MP4 mapping. The whole DASH/Adaptive Streaming ecosystem was launched with VC-1 in fragmented MPEG-4 containers. The Smooth Streaming .ismv files were just fragmented MP4 files (either VC-1 or H.264) with a different extension because a lot of parsers back then couldn't handle fMP4.

Maybe a given muxer can't handle VC-1 input, and there are certainly some players that won't play it back, but it is definitely a standard.
Thanks for clarification.

lvqcl
7th January 2019, 23:19
That's mkv, not MP4. Entirely different container. MPEG-4 has codec mappings for almost anything you could think of.

AFAICS he tries to remux .mkv with vc1 into mp4 container.

I tried to do the same. ffmpeg 4.1 from Zeranoe failed (current build also failed), but ver. 3.4.2 works.

benwaggoner
7th January 2019, 23:46
AFAICS he tries to remux .mkv with vc1 into mp4 container.

I tried to do the same. ffmpeg 4.1 from Zeranoe failed (current build also failed), but ver. 3.4.2 works.
Not entirely surprising that products would be deprecating that feature. It's not like a lot of VC-1 content has been published in the last five years.

VC-1 was a quite good codec when software decoding on single-core 32-bit x86 processors without advance SSE stuff was an important feature requirement. It was quite competitive with H.264 Baseline Profile. But H.264 High Profile was almost a superset of VC-1. And once the H.264 patent pool got down to a reasonable price/structure to allow building with Windows, there wasn't a lot of point in further enhancing VC-1 for Microsoft.

Blue_MiSfit
8th January 2019, 09:08
VC-1 was a quite good codec when software decoding on single-core 32-bit x86 processors without advance SSE stuff was an important feature requirement. It was quite competitive with H.264 Baseline Profile. But H.264 High Profile was almost a superset of VC-1. And once the H.264 patent pool got down to a reasonable price/structure to allow building with Windows, there wasn't a lot of point in further enhancing VC-1 for Microsoft.

QFT! VC-1 was some great stuff for sure. Microsoft was ahead of the game for awhile here :)

Sharc
8th January 2019, 09:34
AFAICS he tries to remux .mkv with vc1 into mp4 container.

I tried to do the same. ffmpeg 4.1 from Zeranoe failed (current build also failed), but ver. 3.4.2 works.
Strange. I have made a few test with VC-1 in mkv (interlaced and progressive video), wrapping these (copy) into MP4 using Zeranoes latest (nightly 20190107) 32-bit build for Windows. Seems to work without problems …..

lvqcl
8th January 2019, 12:26
Well, maybe the only file with VC-1 that I have is slightly corrupted, or something like this... I downloaded a VC-1 sample from Kodi wiki page and indeed, it can be remuxed to mp4.

FLX90
8th January 2019, 12:54
Strange. I have made a few test with VC-1 in mkv (interlaced and progressive video), wrapping these (copy) into MP4 using Zeranoes latest (nightly 20190107) 32-bit build for Windows. Seems to work without problems …..

So it works with 64-bit but doesn't with 32-bit.
That's really strange.


I need those rips for an Apple environment.
VC-1 won't natively work with Apple. So I need to re-encode.

I have some final questions:

x264-r2935-545de2f.exe --bitrate 16998 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.mkv OLD_BOY.Title0.mkv

x264-r2935-545de2f.exe --bitrate 16998 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out2.mkv OLD_BOY.Title0.mkv

- How does these commands alter my source. I mean, would there be less alteration when I do something like this (and would that bring me closer to the source? Do I need to worry about BluRay compliance, when the source is a BluRay?):

x264-r2935-545de2f.exe --bitrate 16998 --preset veryslow -o out.mkv OLD_BOY.Title0.mkv


- Why does x264 show the following during encoding:

lavf [info]: 1920x1080p 1:1 @ 24000/1001 fps (vfr)
--> vfr

Is it that problem:

That's probably just some jitter because mkv container cannot accurately store constant 24/1.001 fps.
1000ms/(24/1.001)= 41.70833333333333333.....ms
Mkv will store it so the frame durations switch between 41ms and 42ms so that on average it is 41.7083....ms. Technically it is vfr, but for practical purposes it is cfr (as was the original source).

If you are unsure just leave the fps settings alone.

And would it be better to use --fps 24000/1001 (implies --force-cfr?)?

Sharc
8th January 2019, 15:00
Why don't you try yourself an tell us whether you see a difference? Cut out a snippet of say 1 minute duration from your source and try your settings and Apple playback scenarios.
Why are you so much worried about quality when you won't see a difference at these high bitrates of about 17Mbps as you suggest?

Your first example (2-pass encode) is blu-ray compliant and time consuming. Blu-ray compliance does not by itself mean that it is the best possible quality. It puts some constrains on certain parameters to ensure that the video stream complies with the blu-ray standard. I don't know whether your Apple devices require blu-ray compliant video streams or not.

Your second example is a 1-pass ABR encode. The stream will not be blu-ray compliant. The quality will be excellent as well though. Just try.

What are you going to do with the audio and subtitles b.t.w.?

Finally, why dont you simply throw your .mkv sources to HANDBRAKE and let it do the job? It has even a number of Apple presets for MP4.

asarian
8th January 2019, 16:00
QFT! VC-1 was some great stuff for sure. Microsoft was ahead of the game for awhile here :)

It was a PITA, though, that Sony (= PS3) wouldn't support VC1 (at least not on anything not on an official blu-ray disc). Nobody needs these codec wars. Good thing it's all in the past.

FLX90
9th January 2019, 04:14
According to this I changed my command:

NB: If your source file is not natively the correct framerate you will have to add the following settings (example for 23.976):

--fps 24000/1001 --force-cfr

I think I have found the perfect command for me:
x264-r2935-545de2f.exe --fps 24000/1001 --force-cfr --bitrate 17971 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o tempx.264 LADY_VENGEANCE.Title0.mkv
x264-r2935-545de2f.exe --fps 24000/1001 --force-cfr --bitrate 17971 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o temp.264 LADY_VENGEANCE.Title0.mkv


OT:
Another question. Don't want to open a new thread.

This is how my final muxing command looks like:
ffmpeg^
-r 24000/1001 -i video -i SYMPATHYFORMRVENGEANCE.Title5.mkv -fix_sub_duration -i SYMPATHYFORMRVENGEANCE.Title5_german_forced.srt -i SYMPATHYFORMRVENGEANCE.Title5_german.srt^
-map 0:0 -map 1:1 -map 1:2 -map 2:0 -map 3:0^
-metadata:s:v:0 handler="AVC"^
-metadata:s:a:0 language=deu -metadata:s:a:0 handler="DTS-HD Master Audio"^
-metadata:s:a:1 language=kor -metadata:s:a:1 handler="DTS-HD Master Audio"^
-metadata:s:s:0 language=ger -metadata:s:s:0 handler="Deutsch (forced)"^
-metadata:s:s:1 language=ger -metadata:s:s:1 handler="Deutsch"^
-movflags disable_chpl^
-c:s mov_text -c:v copy -c:a alac -sample_fmt:a s16p^
SYMPATHYFORMRVENGEANCE.m4v

I tried to force ffmpeg to read the correct cfr of the input with -r (-i video with raw 264 only for testing, because when I take the video stream from the mkv I get no error but vfr is still taken). But:
[ipod @ 0000000002fc1100] pts has no value
Last message repeated 104 times
[ipod @ 0000000002fc1100] pts has no value time=00:02:38.19 bitrate= 715.9kbits/s speed= 307x
Last message repeated 107 times
[ipod @ 0000000002fc1100] pts has no value time=00:02:38.19 bitrate=1312.4kbits/s speed= 154x
Last message repeated 71 times
[...]

Does someone know a workaround?

FLX90
9th January 2019, 08:53
The h264 cfr stream is finally encoded and I tried to mux it in the container with ffmpeg.
I get the same pts has no value message. But the stream is actually cfr, so what timestamps?
I don't understand this.
What is the muxer telling me.
Could someone explain me please.
(When I use mkv as output format for x264 there is no problem.)

nevcairiel
9th January 2019, 10:30
Raw h264 doesn't have any timestamps. You should use a container format with timestamps as your source to avoid such problems.

SeeMoreDigital
9th January 2019, 17:08
Hi FLX90,

I don't know if this question has already been asked/answered but... What playback devices are you using to play your encodes?

benwaggoner
9th January 2019, 17:37
QFT! VC-1 was some great stuff for sure. Microsoft was ahead of the game for awhile here :)
Yeah, peak MIPS-per-pixel for decode were a lot lower than the H.264 worst case. And there were some great encoder implementations with advanced adaptive deadzone and other features. And hey, 720p24 SW and DXVA playback in the early 2000's!

But Moore's law turns as always, and as computers got fast enough and HW decoders were deployed to handle multiple ref frames, b-frame weighted prediction, and the more complex in-loop deblocking of H.264, and CABAC, the SW decode advantages stopped mattering. And the explosion of torrented video piracy, and all those quality obsessed video pirates wailing away on a huge variety of real-world content in x264 made x264 increasingly hard to beat for lots of real-world VBR content. Psychovisual tuning is more important than any particular bitstream feature! And x264's popularity lead to a lot of investment in performance, with single-slice parallelism and advanced vectorization, which eliminated any encoder speed penalty.

I think a xVC1 would have been quite competitive (using CRF and psy-rd etcetera but outputting to VC-1)

We saw some movie studios using VC-1 for Blu-ray titles for years after Microsoft stopped developing the technology, because the tools for that use case were better than what was available for H.264 (x264 didn't really offer operator-friendly hand-tuned high bitrate encoding). Some of that was probably because of the xdither dithering tool, however, which wasn't codec-specific

A decade ago the codec people at Microsoft thought that VC-1 could have remained competitive with H.264 if:

A stronger H.264-style in-loop deblocking filter was available
The (in-standard!) optional postprocessing filtering was used
Encoder development investments were continued


I'd probably add CABAC to the list as well, although VC-1's entropy encoding was IIRC better than CAVLC in practice.

SeeMoreDigital
10th January 2019, 10:32
Nice informative post Ben.

Did Microsoft ever officially announce that development for VC-1 (or more of their AV formats) had ceased or did it just quietly fizzle out?

benwaggoner
10th January 2019, 18:53
Nice informative post Ben.

Did Microsoft ever officially announce that development for VC-1 (or more of their AV formats) had ceased or did it just quietly fizzle out?
I don’t recall any official announcement. There were still minor improvements they went into Windows 7 and the last version of Expression Encoder, which were not long before I left the company. Bug and security fixes at least would have been done as needed through now.

The Pro SDK and Expression Encoder versions were better than the Windows versions, so anyone doing professional VC-1 would probably have been using those.

The Smooth Streaming variable bitrate, GOP duration, and frame size implementation was remarkably competitive for long after it had been abandoned, especially where software decode was important. It had been surpassed now, but it held its own against H.264 CBR fixed GOP in Flash back in 2012.

SeeMoreDigital
11th January 2019, 11:42
Towards the end of last year I dug out some of my old 'HD DVD' discs, most of which were encoded using VC-1 and Dolby Digital Plus audio.

Anyway, long story short, all the discs I tried playing using my LG GGC-H20L (Hybrid ROM) drive and Toshiba HD DVD player have sadly developed faults. :eek:

benwaggoner
11th January 2019, 20:29
Towards the end of last year I dug out some of my old 'HD DVD' discs, most of which were encoded using VC-1 and Dolby Digital Plus audio.

Anyway, long story short, all the discs I tried playing using my LG GGC-H20L (Hybrid ROM) drive and Toshiba HD DVD player have sadly developed faults. :eek:
Too bad. I have a few dozen of those somewhere in the depths of my basement.

Even today's SoCs still include support for VC-1 decoding; I bet WMV is supported in all kinds of things that have come out long after WMV stopped being a mainstream format. Anything that plays Blu-ray obviously has VC-1 support.

FLX90
17th January 2019, 11:31
Hi FLX90,

I don't know if this question has already been asked/answered but... What playback devices are you using to play your encodes?

I'll use Apple TV 4K.

BTW, does someone know if Apple still doing some crap like that: http://amiexp.blogspot.com/2011/11/airplay-to-airport-express-with-2496.html
Watching movie from iTunes on ATV via homeshare:
Source (ALAC 24/48) --> iTunes samples down to 16/44.1 --> Apple TV samples up to 16/48

SeeMoreDigital
17th January 2019, 16:12
I'll use Apple TV 4K.

BTW, does someone know if Apple still doing some crap like that: http://amiexp.blogspot.com/2011/11/airplay-to-airport-express-with-2496.html
Watching movie from iTunes on ATV via homeshare:
Source (ALAC 24/48) --> iTunes samples down to 16/44.1 --> Apple TV samples up to 16/48Oh yes I remember you now from this topic (https://forum.doom9.org/showthread.php?t=175875).

Just buy yourself a decent 'smart TV' and use it to play your media files instead of the 'crippled' Apple TV 4K player!

FLX90
17th January 2019, 16:23
I think what an ATV makes out of an clean tagged library is worth the effort.

SeeMoreDigital
17th January 2019, 16:53
If all you're doing this for is so you can access your media files via a flashy looking UI, I'm of the personal opinion that it's a huge waste of (everyone's) time!

FLX90
17th January 2019, 16:56
I don’t know why you think this. Maybe someone has the same interests as me and could look in the threads in the future.
I really don’t know why it should be an everyones waste of time.

If someone isn’t interested he doesn’t have to answer.

Stereodude
19th January 2019, 21:28
Oh yes I remember you now from this topic (https://forum.doom9.org/showthread.php?t=175875).

Just buy yourself a decent 'smart TV' and use it to play your media files instead of the 'crippled' Apple TV 4K player!
Or use Kodi or Plex or any number of other more flexible solutions.