Re: Question regarding linux1394 and bug report
Brought to you by:
aeb,
bencollins
From: Tasos S. <ta...@ta...> - 2024-01-21 16:50:58
|
Hi, Thank you for your response. It is much appreciated. Apologies for the late reply; I was hoping to respond after I've discovered something new as I don't want to create noise, but I haven't made much progress. On 2024-01-05 17:02, Takashi Sakamoto wrote: > Hi, > > I'm not good at any type of video protocol over IEEE 1394, thus less help > to your issue, sorry. > > As a quick glance, you need to identify the direct cause of your issue > that dvgrab never receives video data at recent version of kernel at > first, then go to investigate kernel implementation if needed. > > In my opinion, the best way is to investigate whether dvgrab (and > libavc1394) can operate your hardware to transfer isochronous packet > to your system. Indeed. I attempted that by reading through the source code and following the chain of libraries but I got lost really quickly. > For example, you have dumped the part of communication between dvgrab > and your hardware for AV/C commands. You can interpret them according to > specification specific to tape recorder and player protocol. You can see > two documents in 1394TA site archived by internet-archive project[1]. > > * AV/C Digital Interface Command Set General Specification Version 4.2 > (2004006) > * AV/C Tape Recorder/Player Subunit Specification 2.4 (2004005) Thank you very much for linking those documents. I searched online for the documents in my attempt to understand the communication but I was unable to locate them. This helps a lot! > Below communication expresses: > > ``` > firewire_ohci: AT spd 0 tl 2a, ffc1 -> ffc0, ack_complete, QW req, fffff0000b00 = 0120d07f > firewire_ohci: AR spd 0 tl 2a, ffc0 -> ffc1, ack_pending , QW req, fffff0000d00 = 0c20c460 > firewire_ohci: AT spd 0 tl 2a, ffc1 -> ffc0, ack_complete, W resp > ``` > > [dvgrab -> hardware] > 0x01: command type: status > 0x20: subunit type/id: tape recorder/player > 0xd0: opcode: transport state: > 0x7f: operand[0]: 0x7e > > [hardware -> dvgrab] > 0x0c: response: stable > 0x20: subunit type/id: tape recorder/player > 0xc4: opcode: transport_mode: wind > 0x60: operand[0]: transport_state: stop > > Below communication expresses: > > ``` > firewire_ohci: AT spd 0 tl 2d, ffc1 -> ffc0, ack_complete, QW req, fffff0000b00 = 0020c375 > firewire_ohci: AR spd 0 tl 2d, ffc0 -> ffc1, ack_pending , QW req, fffff0000d00 = 0920c375 > firewire_ohci: AT spd 0 tl 2d, ffc1 -> ffc0, ack_complete, W resp > ``` > > [dvgrab -> hardware] > 0x00: command type: control > 0x20: subunit type/id: tape recorder/player > 0xc3: opcode: play > 0x75: operand[0]: playback_mode: forward > > [hardware -> dvgrab] > 0x09: response: accepted > 0x20: subunit type/id: tape recorder/player > 0xc3: opcode: play > 0x75: operand[0]: playback_mode: forward > > > I expect that if dvgrab takes the hardware to be prepared, it > keeps isochronous resources by operating both CHANNEL_AVAILABLE registers > (0xfffff0000224-0228) and BANDWIDTH_AVAILABLE register (0xfffff0000220), > and operate plug control registers (0xfffff0000900-0904) according to > IEC 61883-1. Then the hardware start transmission of isochronous > packets, defined in IEC 61883-1 and -2/-3/-5. > Understood. Thanks for the detailed explanation! > [1] https://web.archive.org/web/20200204014929/1394ta.org/specifications/ > > > Regards > > Takashi Sakamoto |