Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > CSDb Entries > Release id #172720 : Capture Tester V1.1
2018-12-19 12:32
0xDB

Registered: Aug 2015
Posts: 27
Release id #172720 : Capture Tester V1.1

capture of "Capture Tester": https://www.youtube.com/watch?v=43pENaKP3G8
capture of "noop-tro-2018": https://www.youtube.com/watch?v=RiL0ipbCr24

(Note: The captures feature the vertical stripes VIC2 hardware interference bug because when I made them I did not know about the "LumaFix64" project.)

equipment used:
* PAL C64
* s-video+rca cable from retrokabel.de (cable has a builtin resistor on the chroma line)
* cheap LogiLink AV-Grabber USB (id from lsusb: Fushicai USBTV007 Video Grabber [EasyCAP])
* arch gnu/linux PC

the problem:
The "EasyCAP" grabber only records 720x576@25fps PAL and there is no option to change resolution or framerate. The C64 outputs approximately 288lines@50fps. In the captured unprocessed video, two C64 frames are placed in a single EasyCAPed frame, one frame on every odd line, another frame on every even line.

Googleing about that problem, the suggested solution is to de-interlace the captured frames to get the original 50fps back. To test any de-interlacing for correctness (no temporal blurring and correct image sequence and frame numbers in the result) I wrote the Capture Tester program.

My problem was that the presented de-interlacing solutions online used scripts for a software called avisynth and I could not find any way to make those scripts work under gnu/linux (all the required software to do that easily appeared to be abandoned).

So I cobbled up a capture solution using ffmpeg,ffplay(for preview during capture),v4l2ctrl,vapoursynth(for de-interlacing and resizing) and avidemux(for cutting):
It consists of two bash scripts, a vapoursynth script and a settings file to configure the capture stick.



script "capture.sh":
#!/bin/bash

echo "delete previous capture..."
rm ./out/c64_capture.mp4

echo "starting capture..."
ffmpeg -f v4l2 -i /dev/video0 -f pulse -i default -c:v libx264 -framerate 25 -preset ultrafast -c:a aac -f tee -map 0:v -map 1:a "./out/c64_capture.mp4|[f=nut]pipe:" | ffplay pipe: &

# load improved settings (only has an effect if ffmpeg is already reading from /dev/video0 otherwise it always reverts to default settings)
echo "loading improved stick settings..."
# wait a bit to make sure ffmpeg and ffplay are already running
sleep 1
# (loading the settings shows error messages on console but the settings are changed as evident by looking at the captured video)
v4l2ctrl -d /dev/video0 -l stick_settings &

FFMPEGPID=`ps T | grep ffmpeg | awk '{ print $1 }'`
FFPLAYPID=`ps T | grep ffplay | awk '{ print $1 }'`

read -p "...................press any key to stop..................." -n1 -s

kill $FFMPEGPID
sleep 1
kill $FFPLAYPID


file "stick_settings" (initially generated with "v4l2ctrl -d /dev/video0 -s stick_settings" then edited):
9963776:                     Brightness:500
9963777:                       Contrast:500
9963778:                     Saturation:750
9963779:                            Hue:0
9963803:                      Sharpness:128


vapoursynth script "vapoursynth_c64.vpy":
import vapoursynth as vs
core = vs.get_core()
clip = core.ffms2.Source(source="./out/c64_capture.mp4")
clip = core.std.SeparateFields(clip=clip, tff=1) # also interleaves after separation
clip = core.std.Crop(clip=clip, left=12, right=24, top=4, bottom=4)
# scale up high for fine control over jitter removal
clip = core.resize.Spline36(clip=clip, width=2160, height=1728)
# get rid of line jitter between frames, by panning the odds
evens = core.std.SelectEvery(clip=clip, cycle=2, offsets=0)
odds = core.std.SelectEvery(clip=clip, cycle=2, offsets=1)
odds = core.std.AddBorders(clip=odds, bottom=2)
odds = core.std.Crop(clip=odds, top=2)
# put frames back together
clip = core.std.Interleave((odds,evens))
# cut off jitter
clip = core.std.Crop(clip=clip, bottom=2)
# resize to 1080p
clip = core.resize.Spline36(clip=clip, width=1350, height=1080, format=vs.YUV420P16)
clip.set_output()


script "transcode.sh":
#!/bin/bash
echo "extract audio..."
ffmpeg -i ./out/c64_capture.mp4 -c:a copy ./out/c64_capture_audio.aac
echo "transcode video..."
vspipe --y4m vapoursynth_c64.vpy - | ffmpeg -i pipe: -c:v libx264 -preset ultrafast -c:a aac ./out/c64_capture_video.mp4
echo "merge video and audio"
ffmpeg -i ./out/c64_capture_video.mp4 -i ./out/c64_capture_audio.aac -c:v copy -c:a copy ./out/c64_capture_deinterlaced.mp4
echo "remove intermediate files..."
rm ./out/c64_capture_audio.aac
rm ./out/c64_capture_video.mp4
echo "done"


To capture a C64 video, I first run the capture script (which captures via ffmpeg and opens an ffplay window for preview(not deinterlaced yet) and loads better than default settings file for the capture stick). And afterwards de-interlace and resize with the transcode script. Then I cut using avidemux.

Two specific questions I have:
1) Is there a way I can get vapoursynth to de-interlace and preview in realtime? (e.g. for playing games in a window without recording) All my attempts at reading directly from /dev/video0 in the vapoursynth script failed, also tried pipe-ing through a fifo pipe.
2) How can I get a sharper output? (seems a bit blurry, wondering if "LumaFix64" would help with that, the "sharpness" control in the stick_settings seems to only have little effect)

Apart from those two question all thoughts and improvement suggestions are welcome.
 
... 20 posts hidden. Click here to view all posts....
 
2019-07-04 22:26
encore

Registered: Aug 2010
Posts: 61
Golara: Try something like this (I adjusted your line)

ffmpeg -f v4l2 -framerate 50 -vf setfield=prog,separatefields,fps=50,scale=720:576 -i /dev/video2 -c:v copy testcap_50fps.avi

When you specify 'setfield=prog,separatefields' you will get a 'flat' picture that contains every second line, alternating each frame. You then use scale to make it double the height (like you expect it). That way you will get 50fps progressive video.

I more or less use 0xDB's script to do the capturing because then it's possible to adjust the video settings (brightness, contrast etc) with the script. To say the setup is a bit "quirky" is an understatement and having a relatively new kernel (within a year) does make a difference when it comes to the drivers, but it's pretty stable for me at this point.

Edit: Not really the best example, but I used a 50fps recording of my C64 here: https://youtu.be/Cx69RUonBl4?t=126
2019-07-04 23:00
Golara
Account closed

Registered: Jan 2018
Posts: 212
Quote: Golara: Try something like this (I adjusted your line)

ffmpeg -f v4l2 -framerate 50 -vf setfield=prog,separatefields,fps=50,scale=720:576 -i /dev/video2 -c:v copy testcap_50fps.avi

When you specify 'setfield=prog,separatefields' you will get a 'flat' picture that contains every second line, alternating each frame. You then use scale to make it double the height (like you expect it). That way you will get 50fps progressive video.

I more or less use 0xDB's script to do the capturing because then it's possible to adjust the video settings (brightness, contrast etc) with the script. To say the setup is a bit "quirky" is an understatement and having a relatively new kernel (within a year) does make a difference when it comes to the drivers, but it's pretty stable for me at this point.

Edit: Not really the best example, but I used a 50fps recording of my C64 here: https://youtu.be/Cx69RUonBl4?t=126


That doesn't help. ffmpeg produces a video file with one field only, but it has the same problems as in my post above. I've looked at the driver code a bit and I think I know what's the problem.

USBTV007 grabber has a custom driver (linux driver was based on reverse engineered Windows driver). It takes 480 pixels in one chunk of data, the driver it self receives all these chunks and produces a frame out of them (and that 240p hacked driver just removes the code that combines 2 fields into one frame). My grabber, however, uses UVC, universal video class. It acts in similar fashion to a webcam. Linux (and windows too but under a different name I think) has a generic UVC driver, the device just says that it can produce a video with such and such parametsrs, in this case, 720x576@25FPS and the driver gets a whole frame in one go. In other words, it's the hardware that reads the 2 fields, combines them (poorly) and sends them to the system. Probably not fixable. Well, bummer. That piece of crap can go straight to the garbage bin. I just wish there was some way to make sure that you are buing a grabber with that particular USBtv007 chip. It's not cheap enough to just risk it and buy it 5 times :P
2019-07-04 23:16
encore

Registered: Aug 2010
Posts: 61
Golara: Ok. For the record I bought exactly this product: http://logilink.eu/showproduct/VG0001A.htm from here: https://www.computersalg.se/i/969644/logilink-vg0001a-ntsc-pal-..
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
DJ Gruby/TRiAD
St0rmfr0nt/Quantum
bugjam
Nordischsound/Hokuto..
Krill/Plush
Laurikka
Frida Katarina
CA$H/TRiAD
YTM/Elysium
Dymo/G★P
Guests online: 130
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)
Top onefile Demos
1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Wafer Demo  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Nostalgia  (9.3)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Coders
1 Axis  (9.8)
2 Graham  (9.8)
3 Lft  (9.8)
4 Crossbow  (9.8)
5 HCL  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.055 sec.