Hello.. First post, I'm new around here...
I'm having a strange issue when De-interlacing (QTGMC Bob) DV captured videos, using Hybrid.
[ProRes, very slow, order 2 for Lower field first]
Analyzing the output frame by frame, I noticed:
a - Every 'x' amount of frames, seems like it adds a 'prior' frame (so the video kind of rewinds momentarily before continuing)...
b - When I try it without Bob (29.97), instead of adding a 'prior' frame, it 'repeats' a frame, giving a momentary pause to the video...
Strange thing is that doing .mp4 comes out nice, but I need ProRes for further editing...
Hopefully someone around here can shed more light on this...
Thank you in advance.
** Selur (Hybrid) suggested using sRestore, but specially at 29.97...
- - - Links to test videos (41 sec), as well as the original:
(ProRes QTGMC-Bob 59.94) https://drive.google.com/open?id=1nif8-2mQlyviry_43eCRYtiBv8iBdH9h
(ProRes QTGMC 29.97) https://drive.google.com/open?id=1sTVhzfaIRJXSkrKGAkiQ0KYh9Oa3PAwK
(MP4 QTGMC-Bob 59.94) https://drive.google.com/open?id=1LhepUFweZS5WqDfHl3VqjGZVivLwIyUf
(Original DV avi) https://drive.google.com/open?id=1_N2nKAqiCF2oh6E0pMKRQIZ68ZC1gJDD
+ Reply to Thread
Results 1 to 19 of 19
Last edited by SupermanTV; 1st Aug 2019 at 20:50.
Can you fix your links ? 3 are truncated (...) . The original is important one.
Thanks for the heads-up, links fixed!!
Did you use the same script for both the 59.94 mp4 , and the 59.94 prores mov ?
I see the prores problem. The source does have a few issues - but you should get the same thing for both 59.94 files
What were the command lines used ? or have a look for the log files that hybrid writes somewhere (I'm assuming it writes a log file)
If you discussed with Selur somewhere already , post the link to the thread so you don't have to retype any already mentioned background info
Yes, log file is fine. And log looks ok
When I do it locally (copy paste everything - script for vpy, vspipe command line to ffmpeg) , it works fine . That suggests an issue with that ffmpeg binary , since both used essentially the same script (both MP4 and MOV, except MOV had 1 extra step to scale to yuv422p10)
My prores file is a lot larger 367MB compared to your 101MB "Crespo_QTGMC-Bob.mov" prores file
looking at mediainfo, some strange entries in your file . I'll highlight the ones of interest
It should be "apcn", because -vtag apcn was used with -profile:v 2 according to the log. (apcn is "normal" prores; apco is for prores proxy)
Actually I didn't look farther down the log; he uses ffmbc to re-wrap the mov for some reason. I'm wondering if that caused the issue . Re-wrapping it using his same command works ok here, no frames out of order . But it's still apcn, the Writing application however matches FFmbc 0.7
Thanks, yes, I see the good result you get!!
I did produce those debug files today in order to post them here, and I may have done proxy the first time...
I don't have the mp4 original debug file...
Here's the ProRes original debug:
Last edited by SupermanTV; 5th Aug 2019 at 22:59.
It works ok for apco here too . I think the vapoursynth part is ok; especially since your MP4 came out as expected. It might have something to do with that ffmpeg binary used by hybrid (you can try replacing it by dropping in a replacement) or some threading issue that you're having
The log says ffmpeg -threads 8 (and that's what I used too, but I'm on Intel) , but frames out of order like that suggests maybe some threading problem, maybe some AMD issue ? According to the log, the MP4 used x264 , not ffmpeg to encode
But for other editors - even at very high bitrates , like low CRF values 1-4 maybe, will be significantly higher quality - than even prores XQ4444 or cineform filmscan 2
SD is usually not a problem for editing latency, but the timeline/scrubbing performance is "sluggish" compared to cineform , even with --tune fastdecode and --keyint 1 . Cineform is really good in that regard, even if the quality is "lower" (splitting hairs here at filmscan 2)
If you really wanted to use cineform, you could use the script generated by hybrid and use that as input into vdub2 . vdub2 supports both the cineform sdk (it has a filmscan 3), and the official go pro cineform implementation (filmscan 2 is the highest), as well as .vpy scripts . I still use cineform occasionally for UHD projects, when I'm not using proxy edits.
But the observations here suggest some issue with that ffmpeg binary since the x264 on your setup encoded as expected (vspipe was used for both the MP4 and MOV)
Indeed, seems like the issue is somewhre within the ffmpeg binary implementation (or ffmbc), though I did replace them..
I did try x264 lossless and it looks pretty good...
Question about it: Since I have SD, do I stay with i420, or go i422/i444?
* I don't use vDub, but I might look into it as well for the Cineform option...
Replacing the ffmpeg did not work ? Some work for selur to do then, because that should not happen since your x264/mp4 output did not have the issue (it can't be some global computer or hardware issue)
I would use i420, because for your source (if they are all similar) it already exceeds NTSC DV chroma . The rest is just upscaling the chroma, ballooning the filesize for nothing
The decoded lossless will be the exact output of the script processing - ie. no compression losses. If you used uncompressed video, it would look the same
But if you don't need truly lossless, you can choose any quality in between . There is a filesize tradeoff. It's difficult to see the difference even pixel peeping zoomed in on frames with low quantizers/high bitrates . Metrics, however, can see the difference
Same result with the 'other' ffmpeg file...
I did try lossless i420/i422 and it produces comparable ProRes regular and HQ sizes, so that's fine I guess..
(i444 is almost double the size..)
Thanks a lot for all your input and help, I really appreciate it..
Now I have a few options to play with..
Last edited by SupermanTV; 2nd Aug 2019 at 09:24.