I have perhaps a slightly unusual issue.
I'm recording videos from my Amstrad CPC464 computer, using an X-RGB Mini Framemeister and a Hauppauge HD PVR Rocket recorder. The end goal is to put these on a blu-ray disc. I'm using Ubuntu Linux for this.
The Amstrad CPC464 is an old 8-bit retro computer from 1984, and it's sending out a 51.43hz signal to the Framemeister.
The Framemeister receives this signal and converts it to a firstname.lastname@example.org stream which it then sends to the Hauppauge device.
The Hauppauge recorder then records fine - but the result is a 51.43fps video inside a 59.94fps container.
These recorded videos confuses both VLC and Kdenlive, showing a lot of jerkiness. Frames duplicated and some seemingly missing.
I can fix this by running a 2-pass x264 command, using two terminals.
Pass 1 in terminal 1:
mplayer -vo yuv4mpeg:file=stream.y4m -nosound recording.mp4
Pass 1 in terminal 2:
x264 --bitrate 13000 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 50 --fps 50 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o recording-fixed.264" stream.y4m
Pass 2 in terminal 1:
mplayer -vo yuv4mpeg:file=stream.y4m -nosound recording.mp4
Pass 2 in terminal 2:
x264 --bitrate 13000 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 50 --fps 50 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o recording-fixed.264 stream.y4m
(These commands should be down to blu-ray spec, producing a compliant blu-ray h264 video stream, at least if the source video were somewhat "normal". It still needs to be muxed with audio at this point, but this thread isn't about that part).
The resulting recording-fixed.264 file now plays great in a blu-ray player (after muxing with audio into a m2ts file). 50 fps without any duplicates and no frames missing either. Very nice smooth animation as it should be. But various tools seem to indicate that the video now resides inside a 100 fps container, and I'm afraid this might cause some trouble with certain blu-ray players.
So trying another approach I use the first method on this site, in order to convert the source into a 50 fps video in a 50 fps container:
The result is indeed a 50 fps video inside a 50 fps container - but it seems to have taken all 59.94 fps from the source now rather than the actual 51.43 fps, resulting in a lot of duplicate frames and of course therefore a video that is far too slow.Originally Posted by hdslr-cinema.com (but edited to fit the resolution and framerate I need)
So, now I have to ask here:
How would you go about converting such a weird 51.43 fps video in a 59.94 fps container into a straight 50fps video inside a 50fps container, keeping all 51.43 fps only slightly slower - i.e. no interpolation or tweening.
+ Reply to Thread
Results 1 to 6 of 6
you can set it up in mkvtoolnix. For video. Load your video and choose video track. Then in Default duration/FPS type 50p. But it didnt work with audio. You can extract it and in Audacity load your extracted audiofile. Then you can use change speed or change tempo. I suggest the change tempo. Set desired lenght in seconds, that is new duration of your video track in seconds. Export audio. And mux it together. But because it is unusual framerate I think there could be some sync problem. If you have only videotrack so no problem.
Sorry if it is more confusing than helpful. I dont speek english well and my software is in my native language (moreless)
Thanks for taking time to reply.
It's true the audio becomes out of sync with the video. This is easily fixed as you say, by using Audacity. I prefer slowing down the speed, but I use the "Change Tempo" option first to find out how many percentage I need to use in the "Change Speed" option. I.e. I don't actually change the tempo, I just input the desired length in order to find the percentage, which I then copy into the "Change Speed" option.
I was told on another forum that I can trust x264 though. There's no way the above x264 commands will output anything but a 50 fps video in a 50 fps container. So I think I'll stick with that way of doing it for now.
(Edit: It occurred to me while writing this post we're probably in Linux mode here, but anyway.....)
In Avisynth you could:
AviSource("D:\Captured Video.avi") # or whatever method is appropriate for opening the source video type
LoadPlugin("C:\Program Files\avisynth_plugin\TIVTC.dll") # http://avisynth.nl/index.php/TIVTC
TDecimate(mode=7, rate=51.43) # remove the duplicate frames
AssumeFPS(50,1) # slow the frame rate from 51.43 to 50fps. http://avisynth.nl/index.php/FPS
Then encode the output of the script with whatever settings you prefer.
If there's missing frames that were replaced with duplicates there's no way to replace those duplicates with the missing frames, but the above should remove the duplicates solely created to increase the frame rate.
There's a few different ways to handle the audio with Avisynth, or use another program if you prefer.
Assuming we're in Linux mode (I'm not sure if there's a VapourSynth version of the TIVTC plugin), it seems ffmpeg can decimate duplicate frames. It doesn't seem to have a frame rate decimation mode (unless I missed it) but it does do "1-in-N" decimation. It appears you'd specify the cycle size and ffmpeg will drop one duplicate frame per cycle. You could try telling it to drop one frame in seven for 51.034fps to see how that looks. If the duplicate frames are spread out evenly that might be fine. https://ffmpeg.org/ffmpeg-all.html#decimate-1
For ffmpeg you might need to use the -r option on the input video to slow the input frame rate to 58.334fps, then delete one frame in seven for 50fps. https://ffmpeg.org/ffmpeg-all.html#Video-Options
Last edited by hello_hello; 6th May 2016 at 08:11.
My best guess is that the firmware sees that the input is higher than 50 fps and then choose a 59.94 fps container. But the actual recorded frames are still only 51.43 fps.
Running the recorded video through x264 ignores the 59.94 fps container, and produces a nice smooth 50 fps video. There aren't any frames missing and no duplicates either. But I was in doubt whether I could trust this.
A user on another forum told me I can trust x264 though, so I'm sticking with that for now.
If specifying a frame rate for x264 works, then I'd be fairly confident your video is being recorded as variable frame rate, so there's no duplicate frames in the captured video, just some frames with a longer duration than others to give you an effective 59.940fps. By specifying --fps 50 in the x264 command line you're forcing a 50fps constant frame rate, and because there's no duplicate frames as such, it works fine.
If it works, it works.... but as long as you open the video the right way (using a method that doesn't automatically convert those longer duration frames into duplicates) you could no doubt achieve the same thing in an Avisynth script with AssumeFPS(50,1) without any need for decimation, and I'd imagine specifying -r 50 for the input file would have the same result for ffmpeg, no decimation required. If there are no duplicate frames, remuxing the source file (such as muxing with MKVMergeGUI) while specifying a frame rate should also achieve the same thing, as that forces a constant frame rate without changing the number of frames. You could specify the original 51.43fps (which should keep the audio in sync), or 50fps to slow the video down a little. Then you could re-encode the remuxed file.
I just went with the "duplicate frames" idea as that's how you originally described it.
I'll confess I don't understand your double terminal encoding process, but maybe I'm missing the obvious. Anyway, as I said.... if it works, it works.... that's the main thing. I'm just (hopefully) adding to the information.
Last edited by hello_hello; 8th May 2016 at 12:16.