[Cin] Record HDV cam Live video with IEC61883 failed

Fri Jun 20 00:43:27 CEST 2025

пт, 20 июн. 2025 г., 01:25 Terje J. Hanssen <terjejhanssen at gmail.com>:

>
>
> On 19.06.2025 12:43, Terje J. Hanssen wrote:
>
>
>
> Den 18.06.2025 22:17, skrev Andrew Randrianasulu:
>
>
>
> ср, 18 июн. 2025 г., 23:13 Terje J. Hanssen via Cin <
> cin at lists.cinelerra-gg.org>:
>
>> I tried CinGG-20250430-x86_64.AppImage to record HDV cam Live video
>> connected via IEEE-1394 (Sony iLink, Firewire) using the iec61883 driver.
>>
>
> "For the IEC 61883 driver, the compression must be DV."
> I think HDV (mpeg2) was never implemented there?
>
>
> I noticed "must be DV", but was not sure how literal "DV" was meant(?)
>
> According to the ffmpeg man page for iec61883:
>
>
> *The iec61883 capture device supports capturing from a video device
> connected via IEEE1394 (FireWire), using libiec61883 and the new Linux
> FireWire stack (juju). This is the default DV/HDV input method in Linux
> Kernel 2.6.37 and later, since the old FireWire stack was removed. Specify
> the FireWire port to be used as input file, or "auto" to choose the first
> port connected. *
> https://www.mankier.com/1/ffmpeg-devices#Input_Devices-iec61883
>
> Kernel 2.6.37 was released in Jan 2011.
> And according to Phoronix:Linux Has A New Firewire IEEE-1394 Maintainer -
> Intends To Maintain Support To 2029
> https://www.phoronix.com/news/Linux-Firewire-New-Maintainer
>
>
> I am not sure if I can do anything even if changes very simple - I have no
> such hardware.....
>
>
> Yeah, I understand that will be difficult.
> My legacy SuperMicro workstation had a Firewire port on its front panel,
> which now is working with a
> Texas Instruments XIO2200A IEEE-1394a-2000 Controller (pci) mounted on the
> MSI mobo.
>
> libIEC 61883 has not been enabled on my system ffmpeg-7, but recently I
> got this bug accepted by OBS, and iec61883 is just enabled in Factory.
> So when it is available for Slowroll, I will try recording with ffmpeg.
>
>
> According to the manual:
> The file format must be Quicktime for Linux and video recording must be
> enabled for it. Click on the wrench to set the video compression.
> For the IEC 61883 driver, the compression must be DV.
> https://cinelerra-gg.org/download/CinelerraGG_Manual/Live_Video.html
>
> So I tried first
> Shift-P
> FFMPEG and qt, mp4 audio and dv_pal.qt video
>
> I also tried
> FFMPEG mpeg, Audio mpeg_mp2, Video mpeg and mpeg_hdv
>
> But got these error messages in both cases using default port 0 or
> alternative port 1
>
> *AVC1394Control::initialize(): couldn't set port: Invalid argument *
> int FFMPEG::init_encoder(const char*):
> bad file format: /home/terje/test.mpeg
>
> rom1394_0 warning: read failed: 0x0000fffff0000414
> AVC1394Control::initialize(): node 0
> int FFMPEG::init_encoder(const char*):
> bad file format: /home/terje/test.mpeg
>
> A control test of the connection with the legacy 'dvgrab' recorded a m2t
> file ok.
>
>
> Add here that dvgrab 3.5 was released 07.09.2009
> This version automatically detects when your device is DV or HDV so you do
> not have to remember to supply "-f hdv."
> https://github.com/ddennedy/dvgrab/blob/master/NEWS
> * Automatically detect DV vs. HDV when not using -noavc, -input, or -stdin.
> * Now waits indefinitely for DV or HDV instead of giving up after 10
> seconds.
> * Bugfixes
>
>
> Repeat here my short dvgrab test on Leap 15.6, which also has a possible
> related "libiec61883 error: Failed to get channels available."
> Yet, robust and worked as follows:
>
> dvgrab -size 0 -autosplit
> Found AV/C device with GUID 0x0800460104db475b
> libiec61883 error: Failed to get channels available.
> Waiting for HDV...
> Capture Started
> ^C"dvgrab-001.m2t":   344.78 MiB 2764 frames timecode 45:85:85.45 date
> 2025.06.19 22:37:52
> Capture Stopped
>
>
> ffprobe -hide_banner dvgrab-001.m2t
> [mpeg2video @ 0x55dc29972d80] Invalid frame dimensions 0x0.
>     Last message repeated 7 times
> [mpegts @ 0x55dc2996d740] Could not find codec parameters for stream 2
> (Unknown: none ([160][0][0][0] / 0x00A0)): unknown codec
> Consider increasing the value for the 'analyzeduration' (0) and
> 'probesize' (5000000) options
> [mpegts @ 0x55dc2996d740] Could not find codec parameters for stream 3
> (Unknown: none ([161][0][0][0] / 0x00A1)): unknown codec
> Consider increasing the value for the 'analyzeduration' (0) and
> 'probesize' (5000000) options
> Input #0, mpegts, from 'dvgrab-001.m2t':
>   Duration: 00:01:50.82, start: 627.021311, bitrate: 26099 kb/s
>   Program 100
>   Stream #0:0[0x810]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002),
> yuv420p(tv, bt709, top first), 1440x1080 [SAR 4:3 DAR 16:9], 25000 kb/s, 25
> fps, 25 tbr, 90k tbn
>       Side data:
>         cpb: bitrate max/min/avg: 25000000/0/0 buffer size: 7340032
> vbv_delay: N/A
>   Stream #0:1[0x814]: Audio: mp2 (mp3float) ([3][0][0][0] / 0x0003), 48000
> Hz, stereo, fltp, 384 kb/s
>   Stream #0:2[0x815]: Unknown: none ([160][0][0][0] / 0x00A0)
>   Stream #0:3[0x811]: Unknown: none ([161][0][0][0] / 0x00A1)
> Unsupported codec with id 0 for input stream 2
> Unsupported codec with id 0 for input stream 3
>

good to know, at least kernel part is working ok then.

ffmpeg's interface seems to support both cases, but demuxing might be a
problem for us .. it must be some cross between iec input and mpeg2/dvb
input IMO ...

https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavdevice/iec61883.c

>
>
>
>
>
>
> Related references:
>
> https://www.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/cinelerra/avc1394control.C;h=dfde60d96fecf935c89fb7cfd5b766d1f4d9914f;hb=HEAD
> https://www.mail-archive.com/cin@lists.cinelerra-gg.org/msg05661.html
> https://www.ffmpeg.org/ffmpeg-devices.html#iec61883
>
>
>
>
>
>> --
>> Cin mailing list
>> Cin at lists.cinelerra-gg.org
>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20250620/17e782e0/attachment.htm>