[Linux-kernel-mentees] [v10 0/4] media: vidtv: Implement a virtual DVB driver

Mauro Carvalho Chehab mchehab+huawei at kernel.org
Fri Sep 11 13:56:40 UTC 2020


Em Fri, 11 Sep 2020 15:10:46 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> escreveu:

> Em Fri, 11 Sep 2020 09:18:20 -0300
> "Daniel W. S. Almeida" <dwlsalmeida at gmail.com> escreveu:

> > > 	3. dvbv5-zap wrote an empty audio file (without -P flag).
> > > 	   Probably there are still some issues at the program
> > > 	   channel descriptor or service;    
> > 
> > I don't remember whether I tried this. I tried dumping the stream to a
> > file with dvbzap, which should work. By the way, I guess we should be
> > comparing the output to this
> > 
> > $ ffmpeg -f lavfi -i sine=frequency=1000:duration=5 -ac 2 -c:a s302m
> > -strict -2 out.ts
> > 
> > Since it produces a playable transport stream file that actually sounds
> > like a sine tone.
> > 
> > Inspecting ffmpeg & vidtv output side by side in dvbinspector, you'll
> > see that they're mostly the same. I have a separate PID for the PCR and
> > some other minor differences.  
> 
> The problem is here:
> 
> 	$ dvbv5-zap -c dvb_channel.conf "S302m: Sine Wave PCM Audio" -t 30 -o pcm_audio.ts -P
> 	using demux 'dvb0.demux0'
> 	reading channels from file 'dvb_channel.conf'
> 	service has pid type 06:  273
> 
> See, it identified the EL type ID as type 6, which is handled by
> dvbv5 library here:
> 
> 		case 0x06: /* private data */
> 			/*
> 			* Those can be used by sub-titling, teletext and/or
> 			* DVB AC-3. So, need to seek for the AC-3 descriptors
> 			*/
> 			dvb_desc_find(struct dvb_desc_service, desc, stream, AC_3_descriptor)
> 				has_ac3 = 1;
> 
> 			dvb_desc_find(struct dvb_desc_service, desc, stream, enhanced_AC_3_descriptor)
> 				has_ac3 = 1;
> 
> 			if (has_ac3) {
> 				entry->audio_pid = realloc(entry->audio_pid,
> 							   sizeof(*entry->audio_pid) *
> 							   (audio_len + 1));
> 				entry->audio_pid[audio_len] = pid;
> 				audio_len++;
> 			} else {
> 				entry->other_el_pid = realloc(entry->other_el_pid,
> 							   sizeof(*entry->other_el_pid) *
> 							   (other_len + 1));
> 				entry->other_el_pid[other_len].type = stream->type;
> 				entry->other_el_pid[other_len].pid = pid;
> 				other_len++;
> 			}
> 			break;
> 
> Basically, it is not recognizing the stream as an audio PID, but
> as some other random data. Due to that, the output of
> dvb_channel.conf will be wrong.
> 
> As type 6 seems to be the correct one for SMPTE 302M, we need to fix
> dvbv5-tools (and likely other tools like kaffeine), in order to
> recognize it as audio as well.

Ok, I guess I got what should be done here. ETSI TS 102 154 says that
SMPTE 302M should use the "registration_descriptor".

From the specs, such descriptor should be filled with 
format_identifier = 0x42535344.

We need to add this on both at v4l-utils and at the vidtv driver.


Thanks,
Mauro


More information about the Linux-kernel-mentees mailing list