↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
Who | What | When | |
---|---|---|---|
yang | tfiga: I am using SCART -> USB dongle capturing device
It works ok, except there is some "noise" present in the stream "noise" is there also before I start the VCR play ffmpeg -f v4l2 -standard PAL -thread_queue_size 512 -i /dev/video0 -f alsa -thread_queue_size 512 -i hw:1,0 -vcodec libx264 -preset superfast -crf 25 -s 720x576 -r 25 -aspect 4:3 -acodec libmp3lame -b:a 128k -channels 2 -ar 48000 out6.avi this is the command line which i use | [06:48] | |
.... (idle for 17mn) | |||
There seems to be the noise at 1:15 when VCR is in "standby" mode https://vimeo.com/443944189
like stripes | [07:08] | ||
.................................. (idle for 2h49mn) | |||
Is there a method to capture "VBI from VHS tapes" by using the usb dongle capturer? It works for videostream capture with /dev/video0, but this seems to be something different. | [09:58] | ||
........................ (idle for 1h56mn) | |||
tfiga | yang: ah, okay, I mixed up the replies earlier. Still, wondering what exactly hardware it is. Which driver is it using? | [11:54] | |
yang | i dont know
Bus 001 Device 005: ID 1b71:3002 Fushicai USBTV007 Video Grabber [EasyCAP] I am trying to resolve this thing -> "If the teletext software is giving an error when you try to access dev/vbi0 the capture card isn't creating the vbi0 device" how do i create /dev/vbi0 device ? | [11:57] | |
........................................ (idle for 3h15mn) | |||
tfiga | yang: it depends on whether the video capture device supports that. I suppose it could be a USB video class device so it wouldn't have vbi nodes.
I guess you can check with `lsusb -v` | [15:15] | |
yang | tfiga: http://paste.debian.net/hidden/a207a864/
can you see if vbi is mentioned? | [15:18] | |
ndufresne | usbtv is reversed engineered, I doubt it will offer sepearte VBI node, but I could be wrong | [15:32] | |
.... (idle for 18mn) | |||
jernej | btw, anyone interested in VC-1 codec for request API?
some videos are already properly decoded on Cedrus... | [15:50] | |
...... (idle for 26mn) | |||
tfiga | yang: as ndufresne said, it's some less common hardware and it might only have basic support | [16:16] | |
...... (idle for 25mn) | |||
yang | ok | [16:41] | |
........ (idle for 38mn) | |||
ndufresne | jernej: make an RFC for the uAPI review,make sure you are willing to go through the review though, I think we will long term want all legacy codecs, but we can't really do them all at once, as for ezequielg and I, finishing H.264 and making initial proposal to fix HEVC is enough, adding more half backed support would be a pitty | [17:19] | |
jernej | ndufresne: I don't plan to make RFC until I fix all issues and that will take time
I'm just asking in order to prevent duplicated effort or join effort... | [17:20] | |
ndufresne | I see | [17:21] | |
jernej | I have zero documentation so REing is slow
not to mention that conformance bitstreams are not freely available | [17:21] | |
ndufresne | I think this is old enough, that copying DXVA, NVDEC or VA-API (or a superset of the three) is a good approach to ensure it's right
just adding what cerdus needs won't do for sure jernej: good luck with the RE
(let's admit, I'll only trust our work the day we actually gain CI, with conformance tests being wrong on changes before we actual get them landed into the next kernel) | [17:23] | |
jernej | oh, nice, I didn't know about that
well, right now it seems that only few bits are set differently in comparison to closed source library | [17:28] | |
................... (idle for 1h31mn) | |||
ezequielg | We should really start thinking about ci quite soon. I don't see a reason to delay this. | [19:01] |
↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |