Jump to content

Dvb Viewer Has Stooped Working.....help!


MarkRy

Recommended Posts

I think it started a few weeks back. When I recorded BBCHD (H264) and tried to play it back in DVBViewer it would not play. No error message just blank. I never watch my recordings on the PC (so I was not too bothered ) - I convert them with Xmuxer Pro and watch them in a stand alone player. This was fine.

 

Yesterday I recorded Galapagos on BBCHD and Xmuxer says the file is corrupted or unsupported. HELP. I have tried about ten new recordings and none can be played or converted using Xmuxer. Unknown error with Haali Media Splitter. (Previously recorded ts files can still be played or non HD ones).

 

DVBViewerGE still works as expected. Recording and playing back BBCHD ts files. BUT it gets the Haali unknown error trying to open these other DVBViewer recordings.

 

I have reinstalled DVBViewer and it makes no difference. Any ideas what to do next - DVBViewer appears to be recording rubbish. I have tried numerous programs just to try and open the file (such as PacketEditor, splitter) - none recognise it.

 

HELP.

Edited by MarkRy
Link to comment
DVBViewer appears to be recording rubbish.

If it's rubbish you have to blame the BBC. Write a letter to the editor. TS_recordings are YGWIT (you get what is transmitted) >_<

Link to comment

It may be a coincidence but BBC-HD has changed their bit rate (19 to 16mbs) in the last few days and I understand tweeked their encoders.

 

My latest ts file can be analysed by parameter reader

 

Video-PID = 2318

Parameter set position in PES packet = 6

Parameter set position in file = 132577

------------------------------------------------------------

 

profile_idc = 100 -----> high profile

constraint_set0_flag = 0

constraint_set1_flag = 1

constraint_set2_flag = 0

constraint_set3_flag = 0

level_idc = 40 -----> level 4.0

 

seq_parameter_set_id = 0

 

chroma_format_idc = 1

bit_depth_luma_minus8 = 0

bit_depth_chroma_minus8 = 0

lossless_qpprime_flag = 0

seq_scaling_matrix_present_flag = 1

 

seq_scaling_list_present_flag [0] = 0

seq_scaling_list_present_flag [1] = 0

seq_scaling_list_present_flag [2] = 0

seq_scaling_list_present_flag [3] = 0

seq_scaling_list_present_flag [4] = 0

seq_scaling_list_present_flag [5] = 0

seq_scaling_list_present_flag [6] = 0

seq_scaling_list_present_flag [7] = 0

 

log2_max_frame_num_minus4 = 1

pic_order_cnt_type = 0

log2_max_pic_order_cnt_lsb_minus4 = 6

 

num_ref_frames = 2

gaps_in_frame_num_value_allowed_flag = 0

 

pic_width_in_mbs_minus1 = 89 -----> HRes = 1440

pic_height_in_map_units_minus1 = 33 -----> VRes = 1088

frame_mbs_only_flag = 0 -----> interlaced

mb_adaptive_frame_field_flag = 1

 

direct_8x8_interference_flag = 1

frame_cropping_flag = 1

frame_crop_left_offset = 0

frame_crop_right_offset = 0

frame_crop_top_offset = 0

frame_crop_bottom_offset = -1

 

vui_parameters_present_flag = 1

aspect_ratio_info_present_flag = 1

aspect_ratio_idc = 255

sar_width = 4

sar_height = 3 -----> aspect ratio 16:9

 

overscan_info_present_flag = 0

 

video_signal_type_present_flag = 0

 

chroma_loc_info_present_flag = 0

 

timing_info_present_flag = 1

num_units_in_tick = 1

time_scale = 50

fixed_frame_rate_flag = 1 -----> frame rate 25 fps

 

nal_hrd_parameters_Present_flag = 0

vcl_hrd_parameters_Present_flag = 0

 

pic_struct_present_flag = 1

bitstream_restriction_flag = 0

 

------------------------------------------------------------

Header bytes read = 33

 

Plus...

Hauppauge 4000 card, Asus P4c800deluxe and Radeon x1950.

 

Please feel free to ask anthing you want to know.

 

I agree with your comment about YGWIT recordings so it would seem impossible to explain why DVBViewerGE works but not DVBViewer. They would clearly seem to be recording something different.

 

support.zip

Link to comment

..sorry, but that can't be the explanation. I would say the recordings have to be identical. If the channel list is faulty, the corresponding pid would be missing in the recording. If all elementary stream are present in the recording there can't be possibly any difference. Unless bits are changed on-the-fly :bye:

Link to comment
In Pro TS recordings are done by PMT (audiochannels are added on the fly). The GE does TS recording by the channellist. BBC transmits a faulty AC3 stream. Please take a look at http://www.DVBViewer.info/forum/index.php?...mp;#entry135163

 

Thanks Lars. There is an improvement!!! DVBViewer plays the sound now but still no picture. Haali still rejects the file. Has BBCHD got a similar problem on the video side?

 

It would seem to me (without taking sides!) that if the recordings were identical then DVBViewer standard should not be able to play the GE recordings either. It can.

 

Regards

 

Mark

Edited by MarkRy
Link to comment

you must be kidding :) What are you trying to pull off? :bye:

Your test recording consists of a PMT from ServiceID = 6903 - BBC 1 East (W) and the V_PID (H.264) and A_PID (AC-3) from BBC_HD. Don't tell me that this is from a channel scan.

Link to comment

The test was definately of BBCHD and my channels settings have the correct ServiceID for BBCHD, doing a rescan of all channels gives the same results - if my test file is showing a different ServiceID to BBCHD then I assume that will be a problem??

 

I can play the HD files I've recorded this week in GE no problem :) - it can also be viewed in xmuxer, just not DVBViewer pro at this moment in time

 

At least I can use GE for the moment - just need to translate the german menus :bye:

Link to comment

Hello,

 

At least I can use GE for the moment - just need to translate the german menus
had you read the DVBViewer GE Readme?

 

For an English user interface, please remove the file Deutsch.lng in DVBViewer GE\Language

:bye:

Link to comment

Well I suppose DVBV GE is the answer until BBCHD corrects whatever they are doing. The only problem is that, as far as I can see, you can either set up a timer to start a recording or stop a recording but not start and stop - ie you need to be there.

 

My other problem is that I have this recording which I really want to watch. It hasnt been on for months and its no.2 of 3. Thanks to Lars I can hear it but is there anything I can do to watch it? I need Haali not to reject the file as unsupported.

 

Please. I know how clever you guys are.

 

BTW. I looked at a good ts and a bad ts in ProjectX. The difference is as follows:

 

GOOD___________________________________BAD

PID 0x90E (#11) H264_____________________0x901 (#1)

PID 0x910 NAR (#7) ______________________0x902 (eng) (#51)

PID 0x90F AC-3

PID 0x911 Eng s.888______________________0x904 eng i100 eng s888

 

The fact that 0x901 doesnt say H264 in the bad stream does not look good.

 

If I record BBCHD with DVBV GE then all the PID's are as per the GOOD stream (unsurprisingly) which is why it works. I think it is safe to say that the recorded ts stream is different (using the standard version and the GE version) on both the audio, video and subtitles PID's.

Edited by MarkRy
Link to comment

What are you guys talking about? Your so called bad PIDs are not part of BBC_HD.

 

<Eurobird_1___Astra_2A_2B_2D_at_28.2_E_10847_V>
<ServiceID HValue="0x1AF7" Name="BBC 1 East (W)">
  <PMT PID="0x0100">
	<PCR PID="0x0901"/>
	<Descriptor HValue="0x0E" Name="Maximum Bitrate">
	  <MaximumBitrate Value="316783" Unit="kbps"/>
	</Descriptor>
	<ES PID="0x0901" Name="MPEG2 Video">
	  <StreamType HValue="0x02" Name="MPEG2 Video (ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2)"/>
	  <Descriptor HValue="0x0E" Name="Maximum Bitrate">
		<MaximumBitrate Value="31674" Unit="kbps"/>
	  </Descriptor>
	  <Descriptor HValue="0x06" Name="Data Stream Alignment">
		<AlignmentType Value="4" Name="SEQ"/>
	  </Descriptor>
	  <Descriptor HValue="0x52" Name="Stream Identifier">
		<ComponentTag Value="1"/>
	  </Descriptor>
	  <Descriptor HValue="0x0F" Name="Private Data Indicator">
		<DescriptorLength Value="4"/>
		<Data Dump="4F 54 56 00"/>
		<ASCII String="OTV "/>
	  </Descriptor>
	  <Descriptor HValue="0xFE" Name="User defined">
		<DescriptorLength Value="4"/>
		<Data Dump="56 49 44 00"/>
		<ASCII String="VID "/>
	  </Descriptor>
	</ES>
	<ES PID="0x0902" Name="MPEG Audio">
	  <StreamType HValue="0x03" Name="MPEG Audio (ISO/IEC 11172)"/>
	  <Descriptor HValue="0x0E" Name="Maximum Bitrate">
		<MaximumBitrate Value="31674" Unit="kbps"/>
	  </Descriptor>
	  <Descriptor HValue="0x0A" Name="ISO 639 Language">
		<Language String="eng"/>
		<AudioType Value="0" Name="Not defined"/>
	  </Descriptor>
	  <Descriptor HValue="0x0F" Name="Private Data Indicator">
		<DescriptorLength Value="4"/>
		<Data Dump="4F 54 56 00"/>
		<ASCII String="OTV "/>
	  </Descriptor>
	  <Descriptor HValue="0xFE" Name="User defined">
		<DescriptorLength Value="4"/>
		<Data Dump="41 55 44 31"/>
		<ASCII String="AUD1"/>
	  </Descriptor>
	  <Descriptor HValue="0x52" Name="Stream Identifier">
		<ComponentTag Value="51"/>
	  </Descriptor>
	</ES>
	<ES PID="0x0904" Name="Videotext">
	  <StreamType HValue="0x06" Name="Private Data PES (ITU-T Rec. H.222.0 | ISO/IEC 13818-1)"/>
	  <Descriptor HValue="0x0E" Name="Maximum Bitrate">
		<MaximumBitrate Value="31674" Unit="kbps"/>
	  </Descriptor>
	  <Descriptor HValue="0x56" Name="Teletext">
		<PageType Value="1" Name="Initial Page">
		  <Language String="eng"/>
		  <Magazin Value="1"/>
		  <Tens HValue="0x00"/>
		  <Units HValue="0x00"/>
		  <Number Value="100"/>
		</PageType>
		<PageType Value="2" Name="Subtitles">
		  <Language String="eng"/>
		  <Magazin Value="8"/>
		  <Tens HValue="0x08"/>
		  <Units HValue="0x08"/>
		  <Number Value="888"/>
		</PageType>
	  </Descriptor>
	  <Descriptor HValue="0x0F" Name="Private Data Indicator">
		<DescriptorLength Value="4"/>
		<Data Dump="4F 54 56 00"/>
		<ASCII String="OTV "/>
	  </Descriptor>
	  <Descriptor HValue="0xFE" Name="User defined">
		<DescriptorLength Value="4"/>
		<Data Dump="53 55 42 00"/>
		<ASCII String="SUB "/>
	  </Descriptor>
	  <Descriptor HValue="0x52" Name="Stream Identifier">
		<ComponentTag Value="4"/>
.
.
.
.

Link to comment

Hi Derrick,

 

We are not all experts you know. We bought the software to watch BBCHD not analyse it. The data is only trying to help understand the problem. I'm not sure what your print out is, but it looks very impressive even if its no help whatsoever.

 

0x901, 902 and 904 are the PIDs that projectX finds looking at the "bad" stream recorded by DVBViewer. They are different from a good recording stream such as recorded by DVBV GE (. If they are not BBCHD then what is DVBViewer recording? ...........You are watching the channel (BBCHD), you hit record and, according to basic analysis, it has recorded PIDs 901,202 and 904. According to DGIndex 901 is Mpeg2 video, 902 audio audio and 904 teletext. 903,5,6,7,8,9 and a are private.

 

With DVBV GE the PIDs are 90e, 90F, 910 and 911 + private. Don't ask me the difference (I didnt write the software) but one plays and one doesnt.

Link to comment
We are not all experts you know. We bought the software to watch BBCHD not analyse it.

IMHO you started it by citing the log of a DVBViewer tool (H264Reader) My citation is from transedit, another very useful tool also written by @Griga :)

 

Again, there's nothing wrong with DVBViewer or any other application that records the transport stream. I've checked it again with the latest DVBViewer beta, a fresh channel scan performed by DVBViewer's internal scanning engine (normally I prefer transedit :) ). The TS-recording I made from BBC_HD only showed PIDs that actually belongs to that channel and nothing else.

 

Apparently you don't know how the program works or you use wrong settings to get those alien PIDs into you recording.

 

Further, this section is about DVBViewer. Watching and recording any channel including BBC_HD can be done with the the DVBViewer without using 3rd party splitters. If you want to process your recording in any way, please inform yourself and use a more appropriate place to post you questions.

 

Maybe a last question. How do you manage to record pids that are not part of the channel you want to record? :bye:

Edited by Derrick
Link to comment

It would seem that DVBViewer pro 3.6.1.20 is acting differently to other versions

 

1- I saved all of the transport stream for 10847V (30sec length) using TransEdit - Derricks favourite tool, I can see why ;)

2- Pulled the stream into TSPlayer and selected BBCHD (ignoring the AC3 issue that has a workaround elsewhere) and converted to a separate ts file (tsplayer plays BBCHD ok)

 

3- Tried the new ts file with DVBViewer GE and the BBCHD sample plays with no issue :bye:

 

4- Next tried it with DVBViewer Pro 3.6.2.2 Beta and the BBCHD sample plays with no issue :) - got one error closing the app, but hey it's beta

 

5- Finally tried it with DVBViewer Pro 3.6.1.20 and can't see any picture :), just the sound from the stereo track, see it look like a problem affecting this version

Link to comment
got one error closing the app, but hey it's beta
´

Please post such things (with the needed data) in the beta forum, otherwise this error may make it into the final...

Link to comment
5- Finally tried it with DVBViewer Pro 3.6.1.20 and can't see any picture , just the sound from the stereo track, see it look like a problem affecting this version

..it is of course possible that playback will be affected by the syntax error in the ac3 stream of bbc_hd. But this has nothing to do with the recording itself. I take TSPlayer (with cyberlink7 decoder), which is not affected by this error for playback of H.264 HDTV recordings.

Link to comment
IMHO you started it by citing the log of a DVBViewer tool (H264Reader) My citation is from transedit, another very useful tool also written by @Griga :)

 

Again, there's nothing wrong with DVBViewer or any other application that records the transport stream. I've checked it again with the latest DVBViewer beta, a fresh channel scan performed by DVBViewer's internal scanning engine (normally I prefer transedit :) ). The TS-recording I made from BBC_HD only showed PIDs that actually belongs to that channel and nothing else.

 

Apparently you don't know how the program works or you use wrong settings to get those alien PIDs into you recording.

 

Further, this section is about DVBViewer. Watching and recording any channel including BBC_HD can be done with the the DVBViewer without using 3rd party splitters. If you want to process your recording in any way, please inform yourself and use a more appropriate place to post you questions.

 

Maybe a last question. How do you manage to record pids that are not part of the channel you want to record? :bye:

 

Thanks Derrick, I will start with the last question if I may. "How do I manage to record PID's....?" I am watching BBCHD and I hit the red (record) button.

 

Having recorded the .ts using the above technique, as I said in a previous post, the stream does not play back in DVBViewer. Using BBCHD fixer I can now hear the sound but there is no picture.

 

The size of the ts (7Gb p/hr) suggests it is recording the data in the stream but something is wrong with the PIDs. Its not like I changed something. One day it worked, the next it didn't. I understand that you do not support 3rd party splitters - if you can watch it in DVBViewer that is good enough. Unfortunately I cant. Reading between the lines a channel scan might be in order.

 

I would appreciate any practical advice for getting BBCHD to play in DVBViewer. The problem that the file can't be opened by Haali splitter / converted into another format / watched on anything but DVBViewer (hopefully) will remain a limitation of the software.

 

Thanks for your comments LakeUK.

 

BTW I have tried the beta version. The BBCHD fixer gets "lost sync while reading TS packets" There is some sort of jerky playback of the video. The file appears to open in 3rd party applications but there are problems processing it. PLUS The beta version will play the file recorded on the previous version of DVBViewer but the sound is terrible (stop/start) after the BBCHD fix.

 

OK, my final findings are: when I record BBCHD (by pressing red button) it records the info / PIDs from BBC1E (service 6903 which is on same transponder) and all the PIDs (901,902) are those of that channel. That channel is also MPEG2 so h264 is not recognised. The stream it records is BBCHD but all the PIDs are incorrect. Why? Havent the foggiest.

Edited by MarkRy
Link to comment

Ok i dont know whether this is going to help you, along with various other alterations last week, BBC HD altered the PMT

it's now 258 it was 256, they also altered the pids of some SD channels too, it's well worth rescanning and checking the PMT has altered to 258 on the transponder containing BBC HD, this fixed some issues in my case, they are experimenting at present however so further changes may occur.

Now obviously this wont fix any borked recordings that have been made it should however ensure that your current transponder info is up to date.

 

Z

Edited by zarqy
Link to comment
Ok i dont know whether this is going to help you, along with various other alterations last week, BBC HD altered the PMT

it's now 258 it was 256, they also altered the pids of some SD channels too, it's well worth rescanning and checking the PMT has altered to 258 on the transponder containing BBC HD, this fixed some issues in my case, they are experimenting at present however so further changes may occur.

 

Z

 

 

Thanks Zargy. Rescanning has corrected the PIDs. It still won't play back in DVBViewer though but it will now open in my remuxing program so I can play it elsewhere. I am not sure if I have ever been able to play back BBCHD in DVBViewer (current version). This together with audio fix and PMT change has rather muddled the problem. It was three things rather than one.

 

Do you think it is possible to patch the file I recorded prior to rescanning (with wrong PIDs but the data is there) so I can watch it?

 

Thanks again Zargy.

Link to comment

..yep, @zarqy pinpointed the right spot :bye: With correct settings as I recommended it wouldn't had happened. I thought you had wrong pids in your recording but it was the wrong pmt.

 

But in case you've acitvated the auto-update checkbox you would have been the victim of a very nasty bug in the dvviewer. I just found it by accident cos I'm myself a victim ;) Channel_auto_update does not work with the Pro, no problem in the GE.

 

For your recordings messed up by the pro you have to find a way to remultiplex video and audio with a correct pmt. Now those recording are pretty useless.

Link to comment
The BBCHD fixer gets "lost sync while reading TS packets"

Which means the packet structure is corrupted. Happens if buffers (Recorder and/or Windows HDD cache) cannot be flushed in time, e.g. due to high processor load or setting the DVBViewer priority to real time in the task manager. Make sure that Options -> Recorder -> Use Smart Buffer is ticked, and give it some MB.

 

you have to find a way to remultiplex video and audio with a correct pmt. Now those recording are pretty useless.

DVBViewer & TSPlayer should be able to play them even with a wrong PMT.

Link to comment
DVBViewer & TSPlayer should be able to play them even with a wrong PMT.

no, even with increased search depth 50MB) tsplayer is helpless..

Link to comment

Thanks everyone. With DVBViewer playing the channel normally despite the wrong PMT it is impossible to tell if it is going to record it correctly until after you have recorded it. Either that or rescan the channel before recording each time / do a test recording each time.

 

As far as my cherished recording is concerned, I can see the PIDs with the data are there (using TSReaderLite) but those PIDs are not part of the PMT (I think that is the right terminology). I didn't quite understand - is there a way to extract the right PIDs and remux it? It would be useful - it could happen again.

 

As I said, the current version of DVBViewer has never been able to play back my BBCHD recordings. TSplayer only finds the audio channel on the "bad" recordings.

Link to comment

Sorry, I fixed the seq_scaling_matrix_present_flag handling, that is important for detecting BBC HD H.264 in a file (missing it is not caused by the wrong PMT), but I didn't upload TSPlayer 1.8.3 yet. Got confused about all these versions... however, at least DVBViewer GE 2.2.6 should be able to play the video stream, because it already contains the fix.

 

I have a BBC HD sample here, with PAT, wrong PMT (BBC 1 East), H.264 Video, AC3 audio. State of the art:

 

- Without using BBC_HD_Fixer DVBViewer Pro 3.1.6.20 detects no stream at all, DVBViewer GE 2.2.6 and TSPlayer 1.8.3 the video stream only.

 

- After using BBC_HD_Fixer DVBViewer Pro 3.1.6.20 detects the AC3 stream, DVBViewer GE 2.2.6 and TSPlayer 1.8.3 both streams.

 

Usually DVBViewer & TSPlayer don't need PAT & PMT in a file for detecting streams and finding out how they belong together (the time stamps are compared as substitute), but here we have a coincidence of several unfavourable circumstances.

 

Ok, I'll upload TSPlayer 1.8.3 right now... if BBC goes on like this, there will be many updates in the forthcoming weeks :bye:

Link to comment
if BBC goes on like this, there will be many updates in the forthcoming weeks

..2 pairs of shoes. With the correct PSI there is no problem. But if due to a bug the necessary PSI_support is missing...

 

 

I'm still recording the 810 minutes of BBC HD music :bye:

 

The early recordings were messed up by this nasty non_AU_bug ! ;)

 

I tried to solve the problem with the help of TSReader :)

 

Program Association Table
PAT Version Number: 1
Transport Stream ID: 1 (0x0001)

PMT PID 32 (0x0020) - Program 1 

Program Map Table(s)
Program Number: 1 



Stream Type: 0x1b H.264 Video PID 2318 (0x090e)
H.264 Video: Resolution 1440 x 1080 Interlaced: 0

Stream Type: 0x81 AC-3 Audio PID 2319 (0x090f)
AC3: Bitrate 384 Kbps Sample Rate 48 KHz
AC3: Mode complete main Coding 3/2 5 L, C, R, SL, SR
AC3: Center Mix Level -3.0 dB Surround Mix Level -3.0 dB 
AC3: LFE Mode On Dialogue normalization -23 dB
Descriptor: AC3 Audio Descriptor
Flags: AC3 Type: False BSID: True Main ID: False ASVC: False
BSID: 67

Stream Type: 0x03 MPEG-1 Audio PID 2320 (0x0910)
MPEG1 Audio: Bitrate 256 Kbps Sample Rate 48 KHz
MPEG1 Audio: Layer II Mode Stereo

Stream Type: 0x06 ISO/IEC 13818-1 PES packets containing private data PID 2321 (0x0911)

Network Information Table
Service Description Table
SDT Channel 1
Service Name: 
Provider Name: Generated by TSReader 2.7.45e on 2007/05/08 00:39
Transport Stream ID: 1 (0x0001)

Link to comment
With the correct PSI there is no problem.

Even with correct PSI there are still the additional values in the H.264 sequence_parameter_set and the wrong PES start_codes in the private 1 AC3 stream.

Link to comment

..doesn't bother playback :bye:

 

btw. maybe the pes_start_code does not provide the correct stream_id but this time it's only DVBViewer complaining. It used to be humax et al. but apparently they don't suffer ;)

Link to comment
..doesn't bother playback

Because I fixed it.

 

maybe the pes_start_code does not provide the correct stream_id but this time it's only DVBViewer complaining.

ProjectX can't handle it and reports hundreds of errors:

 

--> MPEG Audio (0xC0) on PID 0x90F

Audio PTS: first packet 02:48:20.427, last packet 02:48:35.211

-> adjusting audio at its own timeline

!> missing syncword @ 0, @ 00:00:00.000

!> PTS without a frame (1536/1537)

!> PTS without a frame (3072/3073)

!> PTS without a frame (4608/4609)

!> PTS without a frame (6144/6145)

.....

You are picking on DVBViewer, others are doing the work. The usual division of labour....

 

@Everybody else: Ignore the old man's grumbling, rather read this. The same fix will be applied to DVBViewer Pro at the next opportunity.

Link to comment

I didn't say it's not useful to fix syntax errors if possible. What I said is, that the whole story became a real problem because DVBViewer-pro doesn't perform autoupdate properly.

Link to comment
because DVBViewer-pro doesn't perform autoupdate properly

In my DVBViewer Pro channellist I still had a BBC HD entry with the wrong PMT PID (256 -> BBC 1 East instead of 258). Tuned to it -> PMT PID was auto-corrected, as the channel editor showed. Also see here.

 

As long as we have no reproducable test procedure that reveales a bug (if there is any), we are just waisting time with it... did anybody notice a change of the service ID lately? Because that is the anchor point of the auto-update function. Without a correct service ID it can't find the correct PMT PID.

 

Let's summarise:

 

1) BBC HD has changed the PMT PID lately, resulting in recordings with wrong PMT, and requiring a channel update (re-scan or auto-update). However, this alone should not cause playback problems in DVBViewer/TSPlayer, as stated above.

 

2) BBC HD has changed the sequence_parameter_set of the H.264 stream, preventing format detection on live playback and stream detection on file playback. It's fixed now in DVBViewer Filter 2.8.5, TSPlayer 1.8.3 and DVBViewer GE 2.2.6. I'm sure DVBViewer Pro will follow soon. TSPlayer and DVBViewer GE were able to detect the H.264 stream in a file even without this fix, but only with a correct PMT (no proper resolution and aspect ratio detection in this case).

 

3) BBC HD is (still) broadcasting wrong AC3 PES start codes. This must be handled with the BBC HD Fixer, otherwise DVBViewer Pro will not detect the AC3 stream when playing a BBC HD recording. TSPlayer and DVBViewer GE were/are able to detect it, if the correct PMT is present in the file, or, in case of a wrong PMT, after the BBC HD Fixer has corrected the start codes.

 

That's why I wrote:

 

but here we have a coincidence of several unfavourable circumstances.... if BBC goes on like this, there will be many updates in the forthcoming weeks
Link to comment
3) BBC HD is (still) broadcasting wrong AC3 PES start codes. This must be handled with the BBC HD Fixer, otherwise DVBViewer Pro will not detect the AC3 stream when playing a BBC HD recording. TSPlayer and DVBViewer GE were/are able to detect it, if the correct PMT is present in the file, or, in case of a wrong PMT, after the BBC HD Fixer has corrected the start codes.

..sometimes I feel here like the keeper of the holy dvb_grail ;) but in this case I don't think it's such a terrible error. PES is just a packing format. Assembling the ESs into a mpeg2_like_PS doesn't make much sense. In future we may have to deal with other containers. Important are of course the correct descriptors in the PMT. Even there 2 different possibilities exist. One is ETSI style the other ATSC. If the application forwards the correct descriptors to the dcoder, there won't be any problem. Try VLC.. ..the player doesn't bother about the wrong pes_packet_start_code. :bye:

Link to comment

According to ISO/IEC 13818-1 the startcodes of a private_stream_1 must be 00 00 01 BD, and nothing else, thus being used for stream identification. Of course, for someone who's main purpose is to blame DVBViewer things like that don't matter. He will take every opportunity...

Link to comment

..yes, any private stream. The only relevant part to tell a DVB IRD about AC-3 is the AC-3 descriptor. The stream type is not sufficient. Not to forget that 13818-1 relates to MPEG2 :bye:

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...