VideoHelp Forum
+ Reply to Thread
Results 1 to 6 of 6
Thread
  1. Member
    Join Date
    Sep 2014
    Location
    Denmark
    Search Comp PM
    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 720p@51.43fps 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:
    mkfifo stream.y4m
    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:
    mkfifo stream.y4m
    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:
    http://www.hdslr-cinema.com/news/workflow/convert-between-framerates/
    Originally Posted by hdslr-cinema.com (but edited to fit the resolution and framerate I need)
    • extract the frames as rawvideo
      ffmpeg -i input.mov -f rawvideo -b 50000000 -pix_fmt yuv420p -vcodec rawvideo -s 1280x720 -y temp.raw
    • recreate the video with new framerate
      ffmpeg -f rawvideo -b 50000000 -pix_fmt yuv420p -r 50 -s 1280x720 -i temp.raw -y output.mov
    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.

    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.

    Thanks
    Quote Quote  
  2. Member Bernix's Avatar
    Join Date
    Apr 2016
    Location
    Europe
    Search Comp PM
    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)

    Bernix
    Quote Quote  
  3. Member
    Join Date
    Sep 2014
    Location
    Denmark
    Search Comp PM
    Hi Bernix,

    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.
    Quote Quote  
  4. Originally Posted by mr_lou View Post
    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 assume by "51.43fps inside a 59.94fps container" you mean the video is being recorded at 59.94fps and frames are being duplicated as necessary to increase the frame rate? There's definitely no way to tell the Hauppauge HD PVR Rocket to stop messing with the frame rate?

    (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 09:11.
    Quote Quote  
  5. Member
    Join Date
    Sep 2014
    Location
    Denmark
    Search Comp PM
    Originally Posted by hello_hello View Post
    I assume by "51.43fps inside a 59.94fps container" you mean the video is being recorded at 59.94fps and frames are being duplicated as necessary to increase the frame rate? There's definitely no way to tell the Hauppauge HD PVR Rocket to stop messing with the frame rate?
    The "problem" here is that the Hauppauge device offers recording of 30fps source, 50fps sources and 60fps sources. And I'm using it to record a 51.43fps source. Older firmware didn't even accept such a "weird" framerate, but newer firmwares do.
    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.
    Quote Quote  
  6. Originally Posted by mr_lou View Post
    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.
    You can trust it to change the frame rate, but that's all it does. It doesn't change the number of frames.

    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 13:16.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!