Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 3rd December 2018, 07:19   #21  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,677
Quote:
I don't know how you should read time codes so it's a black magic for me just a numbers (but I can see the video is going as it should every ~34 frames or whatever it is and the audio is also going in same numbers ~22).
timestamp format v2:
a. line for each frame
b. each line shows when to start displaying the frame in 'ms'
if the video is cfr (and isn't interlaced or telecined) the difference between the timestamps should ideally be constant.
Seeing that the timestamp differences between frames just switch between 33 and 34, I would drop the time codes.
To do that:
a. extract video using mkvextract
b. extract audio using mkvextract
c. multiplex audio&video using mkvmerge (make sure to set your frame rate during this step)
this way you dropped all time codes, if the multiplexed content plays fine/synch your content is cfr.

Quote:
Not tried yet but maybe I should just try the standard settings and see what happens now TFM().TDecimate() as hello_hello said or with different settings not defaults?
I would try it, shouldn't hurt. (just make sure to adjust the output frame rate)

Quote:
~or I simply didn't encode with a code in .avs to say encoder about color matrix? I should add some line?
If you don't use any rgb<>yuv conversion changing the color matrix is not really necessary. It's recommend to change it, when you resize between HD and SD, but it should not be necessary.
Question is what you are comparing, I thought you compared one file in different players, not a file and it's reencode.

Cu Selur
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 4th December 2018, 00:43   #22  |  Link
Blovesx
Registered User
 
Join Date: May 2015
Posts: 14
I did that but nothing is in synch... only the MediaCoder is helping me there restoring framerates to 30000/1001 and the audio is in sync though it's stuttering sometimes. Gah, I don't really know how to sync will have to read more when I will have more time.

One last question:
I put my original DVD .vob file into GSpot and it says (pics/s and frames/s = 29.97, progressive). When I look at the file it's 3:2 or 4:1 pulldown? I don't know how you call it... this is what happens: https://files.tinypic.pl/i/00975/9ug3t40a28sb.jpg

What settings should I use to encode it and plugins? What to choose in DGIndex (honor flags, force film or the other one?).

PS. What will happen when I encode the video trough x264 with audio then save frames as images run batch file resizer and encode them again with same settings and copying audio? I will have problems with sync? What to do if so?

Last edited by Blovesx; 4th December 2018 at 07:13.
Blovesx is offline   Reply With Quote
Old 4th December 2018, 18:28   #23  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,783
Quote:
Originally Posted by Blovesx View Post
Code:
video = FFVideoSource("TRY_track1.h264", fpsnum=30000, fpsden=1001)
Only that. I'm very happy with the output. It's super fluid as it should be without ghosting, blending, banding, duplicates... now the most important question: How do I sync the audio now?
If the audio was in sync originally, it should still be in sync. Converting the frame rate doesn't change the duration.
When VFR is decoded as constant frame rate without converting it, the frames, which would display for different durations, display with the same duration (usually the average), changing the audio sync.
Decoding while converting to CFR adds (or drops) frames to keep the frame rate constant, but the original frames should stay (roughly) in the same place, so the audio sync shouldn't change.

Edit: I just notice you're applying the frame rate conversion to a raw .h264 stream. I've no idea if a raw stream retains the VFR timecode information. I've only used the frame rate conversion method with an MKV as the source. It should work for MP4 though. From what you've said it appears to be working, but I've never done it that way. Likewise, I'm not sure if you'd be able to index a raw.h264 and have FFVideoSource write the correct VFR timecodes. Someone else may know.

Quote:
Originally Posted by Blovesx View Post
I don't know how you should read time codes so it's a black magic for me just a numbers (but I can see the video is going as it should every ~34 frames or whatever it is and the audio is also going in same numbers ~22).
The audio timecodes aren't relevant here. The video timecodes.... well they can be almost impossible to interpret, especially as there's so many of them. For PAL (25fps) the frame durations are exactly 40ms. For 23.976fps the durations are roughly 41.708ms and for 29.97fps it's 33.667. The time-codes are usually in exact millisecond increments though, so for 29.97fps they usually alternate between 34ms and 33ms in some sort of pattern.

Quote:
Originally Posted by Blovesx View Post
Code:
play around with sRestore and similar filters to go for 23.976 and see how they handle the file
Not tried yet but maybe I should just try the standard settings and see what happens now TFM().TDecimate() as hello_hello said or with different settings not defaults?
SRestore is designed to fix blending so it's not the right tool here (I assume). If your MP4 video was originally 23.976fps before it was encoded, it was probably converted to 29.97fps by repeating fields (3:2 pulldown), that process was reversed and it was encoding for the MP4 by dropping duplicate frames to become VFR, and you've put them back by converting to CFR. If that's all that happened, then the defaults for TFM().TDecimate() would be fine and the output would be 23.976fps CFR, but one reason for encoding as VFR is a video can be a combination of 23.976fps "film" sections and 29.970fps "video" sections.

TFM().TDecimate() can be used to convert "hybrid" video to a single constant frame rate (see the Hybrid option in the TDecimate help file), but it involves adding or dropping frames using frame blending. Often that's okay, as sources are often mostly one frame rate or the other, and back in the Xvid/AVI days they had to be CFR. Encoding as VFR avoids any conversion though (in theory the output ends up being a combination of two different constant frame rates). I live in PAL land but these days I'd encode any "hybrid" NTSC DVD as VFR.
That can also be done with TFM().TDecimate(). It requires 2 passes, but read the help file and if you can't make it work ask for help here. It's not hard once you know how to do it, although I use MeGUI to make it a bit easier.

Quote:
Originally Posted by Blovesx View Post
Some replies to hello_hello:
Code:
Your x264 and Spline64 screenshots have slightly different colours, by the way
Yeah, default x264 for x264 image and again default settings + resizing trough Spline64. That's it not sure why it's a bit different should I force some color matrix or something?
When you upscaled, either the wrong colormatrix was set or no colormatrix was set. The SD source was probably meant to be converted with BT601 on playback, you upscaled it, so the player converted it using BT709 instead. I think DGIndex will give you the correct colorimtery if you open the index file with notepad, but that's also assuming the original video contained colorimetry info. Often it doesn't, in which case I'd assume SD was BT601 and HD was BT709. That's why converting to BT709 while upscaling is probably a good idea.

Quote:
Originally Posted by Blovesx View Post
I got it. Just a personal question: do you prefer encoding DVDs with original color settings or full RGB is more popular for PC use? I'm not really using TV much or anything beside PC but does it matter nowadays what's the color primaries, is it TV range or PC or any x264 settings which won't allow to play encodes on TV? I know for sure I can't play High10 bit videos on my TV but everything else is playing fine. I wasn't even looking at if there is a difference in colors: DVD standards and RGB but everything is working.
For PC/full range the luminance levels are 0-255. 0 being black and 255 being white.
For TV/limited range the luminance levels are 16-235, where 16 is black and 235 is white.
Pretty much all video is limited range. Keep it that way. When playing video on a PC, a player (or your video card) should expand the limited range levels to full range. TVs expect limited range (although it can often be changed for when they're connected to PCs etc). These days, some PC monitors default to limited range for the HDMI inputs, even though PCs are traditional full range. The LCD monitor I bought a while back defaults to limited range. VGA and DVI inputs should always be full range.

Color primaries and TV/PC range are two different things. You can convert between TV and PC range with Avisynth.
ColorYUV(Levels="PC->TV")
but don't unless you know you need to.
The x264 --range option has no effect on how the video is encoded, it just provides information on how it should be decoded. You don't need to bother setting it at all.

Quote:
Originally Posted by Blovesx View Post
Back to the topic FranceBB gave me this code I wasn't really looking into the plugins settings and what these means. How is it different from your simple Rec->Rec setting?
Code:
#ColorMatrix(mode="Rec.601->Rec.709", interlaced=false, threads=0, thrdmthd=0, opt=3)
interlaced=false is the default. If a video is interlaced I de-interlace first and then convert the colors if need be with interlaced=false. I've never used the other settings (I had to read the help file), but they control how colormatrix uses the CPU. Theoretically they'd ensure a more accurate conversion, so they can't hurt.

Quote:
Originally Posted by Blovesx View Post
That was just an option if the video settings wouldn't work and video wasn't smooth? I'm not really sure if I understand you. This --tcfile-in "x:\xxxx.txt" should be put in x264 encoder settings? What's the command to write in .avs script to get the file with timecodes trough ffms or can I aswell use timecodes taken from mkvtoolnix? Timecodes help with smoothing, settings the frames?
If you encode the video using the timecodes file the output would have the same VFR as the source and there's no need to convert to a CFR, or use TFM().TDecimate(). You don't need to do anything else if x264 is writing the output directly to an to MKV. For MP4 you might have to add the timecodes file to the output and I'd have to research that one.
I always remux as MKV and extract the timecodes myself if necessary, but to get ffms2 to do it while indexing it should be:

FFVideoSource("D:\Video.mp4", timecodes="D:\VideoTimcodes.txt")

Once the indexing is done, it might pay to remove the timecodes option. I'm not sure if ffms2 would keep over-writing it otherwise.

--tcfile-in is just another x264 command line option. ie

--level 4.1 --preset slow --tune film --crf 18.0 --tcfile-in "D:\VideoTimcodes.txt"

If x264 rejects the timecodes file, open it with notepad and check to see it says this at the top

# timecode format v2

If it says

# timestamp format v2

change it.

The format name was changed (at least for mkv) a while back and the last time I tried it, x264 wouldn't recognise "timestamp".

Last edited by hello_hello; 5th December 2018 at 08:56.
hello_hello is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:52.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.