Opened 18 years ago
Closed 18 years ago
#1722 closed defect (invalid)
ATrpms stable packages include DVB-T patch which breaks mpeg2 transcoding
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | dvb | Version: | 0.19 |
Severity: | medium | Keywords: | |
Cc: | alex.butcher.pgp0106@… | Ticket locked: | no |
Description
I've never submitted a ticket before so apologies in advance if something here is inappropriate. Somewhere between changeset 9486 and changeset 9656 something changed in the recording of DVB streams. Possibly this is related to the DVB Radio changes that I've seen discussed.
Here in Australia at least, the result seems to be additional streams being added to the resulting mpeg file, which appear to cause lossless transcoding to fail with a 'No more queue slots' error.
Two examples from the backend log follow. The first shows an additional stream #0.2 flagged as mpeg2 video at 90000 fps (!). As far as I'm aware from previous recordings only the first two streams are valid video and audio.
2006-04-23 21:54:23.224 Input #0, mpegts, from '/video/recordings/2054_200604211 35900.mpg': 2006-04-23 21:54:23.227 Duration: N/A, bitrate: N/A 2006-04-23 21:54:23.230 Stream #0.0[0xa1](eng), 25.00 fps(r): Video: mpeg2vide o, yuv420p, 720x576, 6000 kb/s 2006-04-23 21:54:23.236 Stream #0.1[0x51](eng): Audio: mp2, 48000 Hz, stereo, 192 kb/s 2006-04-23 21:54:23.240 Stream #0.2[0x29](eng), 90000.00 fps(r): Video: mpeg2v ideo 2006-04-23 21:54:25.351 No more queue slots!
This second example is from a recording which actually does have additional streams, in this case two audio streams. The additional 'spurious' stream is #0.3 flagged as mp1 audio at 32kb/s. The same error results when lossless transcoding is attempted.
2006-04-24 11:45:17.578 Input #0, mpegts, from '/video/recordings/2045_200604232 25800.mpg': 2006-04-24 11:45:17.580 Duration: N/A, bitrate: N/A 2006-04-24 11:45:17.587 Stream #0.0[0x200], 25.00 fps(r): Video: mpeg2video, y uv420p, 704x576, 12000 kb/s 2006-04-24 11:45:17.592 Stream #0.1[0x28a](eng): Audio: mp2, 48000 Hz, stereo, 256 kb/s 2006-04-24 11:45:17.594 Stream #0.2[0x28b](eng): Audio: ac3, 48000 Hz, stereo, 256 kb/s 2006-04-24 11:45:17.596 Stream #0.3[0x240]: Audio: mp1, 32 kb/s 2006-04-24 11:45:26.712 No more queue slots!
Reading the recent commits and changeset logs leads me to guess that perhaps this is an unintended side effect of the DVB radio patches, which occured within the changeset range where the problem manifested. It may well be peculiar to Australian DVB broadcasts, which I don't think currently have DVB radio, but may perhaps have something that confuses the DVB radio stream handling stuff in Myth.
If further information is required please let me know.
Cheers,
Dennis
Attachments (1)
Change History (17)
comment:1 Changed 18 years ago by
Version: | → 0.19 |
---|
comment:2 Changed 18 years ago by
comment:3 Changed 18 years ago by
The 'No more queue slots' error is one that I have been getting since a recent upgrade, using the latest 0.19-126 rpms supplied by atrpms.net . The transcoding fails to complete and the only error reported is 'No more queue slots!' I originally felt it was related to /usr/bin/mythtranscode supplied by mythtv-frontend-0.19-126.rhfc4.at.i386.rpm , which has the revision note Update to latest svn fixes (r9656). I can be more specific about the rpm and version in question once the problem area is identified, or anything else that needs clarification.
The myth users mailing list has two posts (one is mine) relating to No more queue slots, the 90000.00 fps(r) and the Audio: mp1, 32 kb/s issues that lennier76 mentions. An extract from my posted log extract shows...
2006-04-23 11:27:15.627 Duration: N/A, bitrate: N/A 2006-04-23 11:27:15.631 Stream #0.0[0x207], 25.00 fps(r): Video: mpeg2video, yuv420p, 720x576, 10000 kb/s 2006-04-23 11:27:15.635 Stream #0.1[0x2d0](eng): Audio: mp2, 48000 Hz, stereo, 256 kb/s 2006-04-23 11:27:15.639 Stream #0.2[0x2d1](eng): Audio: ac3, 48000 Hz, stereo, 192 kb/s 2006-04-23 11:27:15.643 Stream #0.3[0x247]: Audio: mp1, 32 kb/s 2006-04-23 11:27:17.764 No more queue slots! 2006-04-23 11:27:17.793 Unknown socket closing
I'm not sure if it's relevant but the comment about "DVB Radio changes" reminds me that one of the cards here has a radio tuner.
CORE cx88[0]: subsystem: 1822:0025, board: digitalnow DNTV Live! DVB-T Pro [card=42,autodetected] TV tuner 63 at 0x1fe, Radio tuner -1 at 0x1fe input: cx88 IR (digitalnow DNTV Live! as /class/input/input1 cx88[0]/0: found at 0000:02:09.0, rev: 5, irq: 11, latency: 32, mmio: 0xfa000000 tuner 1-0061: chip found @ 0xc2 (cx88[0]) tuner 1-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner) CORE cx88[1]: subsystem: 17de:a8a6, board: digitalnow DNTV Live! DVB-T [card=23,autodetected] TV tuner 4 at 0x1fe, Radio tuner -1 at 0x1fe input: cx88 IR (digitalnow DNTV Live! as /class/input/input2
comment:4 Changed 18 years ago by
I too have seen this happen, but only when recording on this channel. (ABC Adelaide) (I happened to have all debug on at the time and captured this)
Program Map Table ver(1) pid(0x100) pnum(1) len(98)
Smoothing Buffer Descriptor (0x10) length(6)
Stream #0 pid(0x200) type(video-mpeg2 0x2)
Video Descriptor (0x2) length(3) Stream Identifier Descriptor (0x52) length(1)
Stream #1 pid(0x28a) type(audio-mp2-layer[1,2,3] 0x4)
Audio Descriptor (0x3) length(1) ISO-639 Language: code(eng) canonical(eng) eng(English) Stream Identifier Descriptor (0x52) length(1)
Stream #2 pid(0x294) type(audio-ac3 0x129)
AC-3 Descriptor (0x6a) length(3) ISO-639 Language: code(eng) canonical(eng) eng(English) Stream Identifier Descriptor (0x52) length(1)
Stream #3 pid(0x240) type(private-data 0x6)
Teletext Descriptor (0x56) length(5) Stream Identifier Descriptor (0x52) length(1)
Stream #4 pid(0x17c0) type(private-data 0x6)
Unknown(195) Descriptor (0xc3) length(3) Stream Identifier Descriptor (0x52) length(1)
mpegts_add_stream: at pid 0x200 with type 2 mpegts_add_stream: stream #0, has id 0x200 and codec MPEG2VIDEO, type Video at 0x97529d0 mpegts_add_stream: at pid 0x28a with type 4 mpegts_add_stream: stream #1, has id 0x28a and codec MP3, type Audio at 0x9752a90 mpegts_add_stream: at pid 0x294 with type 129 mpegts_add_stream: stream #2, has id 0x294 and codec AC3, type Audio at 0x975a1b0 mpegts_add_stream: at pid 0x240 with type 257 mpegts_add_stream: stream #3, has id 0x240 and codec DVB_VBI, type Data at 0x97c6a60 mpegts_add_stream: at pid 0x17c0 with type 6 mpegts_add_stream: stream #4, has id 0x17c0 and codec MPEG1VIDEO, type Video at 0x9764fa0
Cheers, Darryl
comment:5 Changed 18 years ago by
I wonder whether this has to do with the way DVB private streams are handled in mpegts.c . This was added for UK MHEG and I wonder whether there is something wrong with this code. I've created a very simple patch that turns this off and I'd be very interested to know if applying this patch fixes the problem. If it does I'll need to look more closely and come up with a proper solution. If it doesn't then the problem is obviously elsewhere.
David.
Changed 18 years ago by
Attachment: | disableprivate.txt added |
---|
comment:6 Changed 18 years ago by
I found the source package for the version I'm using - mythtv-0.19-126.rhfc4.at.src.rpm - Unpacking this and looking at the file /usr/src/redhat/BUILD/mythtv-0.19/libs/libavformat/mpegts.c shows that STREAM_TYPE_PRIVATE_DATA was already commented out in this build.
case STREAM_TYPE_AUDIO_AAC: case STREAM_TYPE_AUDIO_AC3: case STREAM_TYPE_AUDIO_DTS: // case STREAM_TYPE_PRIVATE_DATA: case STREAM_TYPE_SUBTITLE_DVB: val = 1; break;
Cheers, Glenn
comment:7 Changed 18 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
It looks like this is an atrpms bug.
The spec is applying the DVB-Radio patch from SVN-head without some of the supporting changes that have gone into SVN. You need to report this problem directly to Axel.
comment:8 Changed 18 years ago by
Reported to Axel as http://bugzilla.atrpms.net/show_bug.cgi?id=810
I've made a note there that Dennis's install was an atrpms one - correct? - I'm unsure of either stephen.gw or Darryls (djm2006) setup.
Thanks to all, Glenn
comment:9 Changed 18 years ago by
Cc: | alex.butcher.pgp0106@… added |
---|---|
Resolution: | invalid |
Status: | closed → reopened |
I'll rebuild the packages asap. Sorry for breaking bits. :/
comment:10 Changed 18 years ago by
Owner: | changed from danielk to Axel.Thimm@… |
---|---|
Status: | reopened → new |
comment:11 Changed 18 years ago by
Owner: | changed from Axel.Thimm@… to anonymous |
---|---|
Status: | new → assigned |
Summary: | 'Spurious' streams being recorded from DVB-T sources cause lossless mpeg2 transcoding to fail with 'No more queue slots' → ATrpms stable packages include DVB-T patch which breaks mpeg2 transcoding |
comment:12 Changed 18 years ago by
Owner: | changed from anonymous to Axel.Thimm@… |
---|---|
Status: | assigned → new |
comment:13 Changed 18 years ago by
Note:
My problem is with the current SVN.. I have not used any of the MythTV ATrpms in my setup.
Cheers, Darryl
comment:14 Changed 18 years ago by
Hm, I've now taken over this bug and renamed its summary, so that it only fits to the -fixes branch and ATrpms' buggy backport of the patch.
Maybe it should be renamed back, but I already fuzzed too much in the ticketing system, I'll better get the ATrpms builds fixed.
comment:15 Changed 18 years ago by
Thanks everyone for your input and response, much appreciated. Glad to see it was a 'simple' fix (if not from Axel's perspective :) )
Cheers,
Dennis
comment:16 Changed 18 years ago by
Priority: | major → minor |
---|---|
Resolution: | → invalid |
Status: | new → closed |
This trac is for myth bugs, not packaging issues.
I'm not 100% sure this is the same problem (but sounds very close), with 0.19-Fixes I have problems where on playback 'spurious' streams from DVB-T are confusing NVP. Note, this is without the DVB radio patch.
The following log is from playback of DVB-T material
As you can see, stream number 3 is 'spurious' with a highly negative duration (and though further investigation, a bitrate of 0).
The spurious streams pick up default properties (i.e. 640x480 at 29.97fps) which are have been causing problems for NVP with AV sync as i'm playing back PAL content at 25fps. To get around this I have been running with a 'hack' to AFD which ignores streams with a 0 bitrate.