IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> BDA MPEG2TS splitting
lyncher
post May 9 2012, 11:19 AM
Post #1


Be nice to me, I am new.


Group: New Members
Posts: 4
Joined: 1-May 12
Member No.: 14,963
Card: None


Hi all,
First of all thank for the valuable information available in this forum.
I was able to make a graph in graphedit to record from a DVB-T source and write 4 channels (video/PCR PID + audio PID +PMT Pid) in different files TS files.
To achieve that I used one demux with TIF and 4 other demuxes (one for each channel).
Was this the right approach or it would be a valid (better) solution to use only 2 demuxes: one with TIF and the other outputting all individual channels transport streams?
(I'm not sure about that because PCR is in each video PID and I set the TIF demux as the reference clock... since only one of them can have this setting active)

Another question: besides TsFileReader for DirectShow based players (as stated here, but I didn't tried it yet) is there any player that can read directly the TS files extracted for each channel? The VLC 2.0.1 can't recognize the file contents and ffplay x64 just crashes... I can only watch the contents of the files with ffplay x86 with shared dlls....

Thanks

Lyncher
Go to the top of the page
 
+Quote Post
bear
post May 9 2012, 06:25 PM
Post #2


Forum Regular


Group: Members
Posts: 3,099
Joined: 24-April 04
From: Queensland
Member No.: 808
Card: VisionPlus DVB-t


@lyncher,
QUOTE
Was this the right approach or it would be a valid (better) solution to use only 2 demuxes: one with TIF and the other outputting all individual channels transport streams?.

I have no data to say which way is best, maybe try it and see, I prefer to use seperate demuxes incase one file writer is being blocked so you don't hold up the stream data for the other file writers. There is no msdn documentation on the buffer structure within the demux only what has been discovered so far.

QUOTE
The VLC 2.0.1 can't recognize the file contents and ffplay x64 just crashes... I can only watch the contents of the files with ffplay x86 with shared dlls....

You need to include the PAT so the file parser can correctly identify the PMT for the program content. Suggest you include the following pids, 0x0, 0x1, 0x10, 0x11, 0x12, 0x13, 0x14 to get all the PSI info, does not take up that much bandwidth.

TSFileSource filter has stream selection capability to output a TS stream for individual programs.
Go to the top of the page
 
+Quote Post
lyncher
post May 10 2012, 08:46 AM
Post #3


Be nice to me, I am new.


Group: New Members
Posts: 4
Joined: 1-May 12
Member No.: 14,963
Card: None


Thanks bear for your answer.

I forgot to mention that the output pin of each channel demux is of type "Transport Stream" and I'm mapping selected pins as "Transport Packet (complete)".

QUOTE (bear @ May 9 2012, 07:25 PM) *
You need to include the PAT so the file parser can correctly identify the PMT for the program content. Suggest you include the following pids, 0x0, 0x1, 0x10, 0x11, 0x12, 0x13, 0x14 to get all the PSI info, does not take up that much bandwidth.


I mapped some more pins:
0x10 (NIT PID)
0x11 (SDT PID)
0x12 (EIT PID)
0x14 (TOT/TDT PID)

And the recorded TS file is still playable with 32 bits ffmpeg (and it still crashes with 64 bits ffmpeg and isn't recognized by VLC).

But if I also add 0x0 PID, ffmpeg (32 bits) starts to present lots of decoding errors and the video is no longer watchable with quality (lots of squares). I noticed that when I route the PID 0x0 to the output PIN the demux also gets the PMT pids of all the other channels (added as MPEG2 PSI Sections).
If I try to force the demux to map that PMT pins to type "Transport Packet (complete)" when I start the graph they content goes back to PSI Sections....

I've checked the MPEG2 Demultiplexer docs in: http://msdn.microsoft.com/en-us/library/wi...2(v=vs.85).aspx and noticed this:
QUOTE
MEDIA_TRANSPORT_PACKET The filter delivers entire TS packets. The demux routes the TS packets according to their PIDs, but does not otherwise examine or process the packets. Packets with errors are not filtered out. The demux does not re-multiplex the packets, and the resulting output stream is not a compliant MPEG-2 transport stream. This mode is called pass through mode.


Does it means that if I set my demux output pin as "Transport Stream" I'm creating an non-compliant MPEG2-TS stream (file)?

Thanks once again

Lyncher





Go to the top of the page
 
+Quote Post
bear
post May 10 2012, 08:05 PM
Post #4


Forum Regular


Group: Members
Posts: 3,099
Joined: 24-April 04
From: Queensland
Member No.: 808
Card: VisionPlus DVB-t


@lyncher,
QUOTE
I forgot to mention that the output pin of each channel demux is of type "Transport Stream" and I'm mapping selected pins as "Transport Packet (complete)".
This is correct, but do not add or map any pins on the demux that has the TIF connected as the TIF registers the demux with the NP and so the NP controls the demux and output pins and their mappings. Only use output pins that you can map on the slave demuxers. Else you will need to unregister the demux from the NP post connecting the TIF.

QUOTE
I mapped some more pins: 0x10 (NIT PID) 0x11 (SDT PID) 0x12 (EIT PID) 0x14 (TOT/TDT PID) And the recorded TS file is still playable with 32 bits ffmpeg (and it still crashes with 64 bits ffmpeg and isn't recognized by VLC).

These are just extra PSI and it should only need the PAT included in the mappings.

QUOTE
But if I also add 0x0 PID, ffmpeg (32 bits) starts to present lots of decoding errors and the video is no longer watchable with quality (lots of squares). I noticed that when I route the PID 0x0 to the output PIN the demux also gets the PMT pids of all the other channels (added as MPEG2 PSI Sections).
If I try to force the demux to map that PMT pins to type "Transport Packet (complete)" when I start the graph they content goes back to PSI Sections....
As above don't mess with the BDA demux.

QUOTE
Does it means that if I set my demux output pin as "Transport Stream" I'm creating an non-compliant MPEG2-TS stream (file)?
This detail in my opinion is written incorrectly, as long as all the pids are mapped that are in the incomming stream it will be compliant. If your only passing some of the packets then yes it is no longer complient, but the PCR packets are still valid, your just unable to re-broadcast the stream data. Any half decent file parser should be able to play it.

Try using TVScheduler with TSMux capture type to record a file and see if it can be played.
Go to the top of the page
 
+Quote Post
lyncher
post May 22 2012, 11:56 AM
Post #5


Be nice to me, I am new.


Group: New Members
Posts: 4
Joined: 1-May 12
Member No.: 14,963
Card: None


QUOTE (bear @ May 10 2012, 08:05 PM) *
@lyncher, This is correct, but do not add or map any pins on the demux that has the TIF connected as the TIF registers the demux with the NP and so the NP controls the demux and output pins and their mappings. Only use output pins that you can map on the slave demuxers. Else you will need to unregister the demux from the NP post connecting the TIF.


These are just extra PSI and it should only need the PAT included in the mappings.

As above don't mess with the BDA demux.

This detail in my opinion is written incorrectly, as long as all the pids are mapped that are in the incomming stream it will be compliant. If your only passing some of the packets then yes it is no longer complient, but the PCR packets are still valid, your just unable to re-broadcast the stream data. Any half decent file parser should be able to play it.

Try using TVScheduler with TSMux capture type to record a file and see if it can be played.


I finally managed to have partially working graph. The changes that I had to do were:
- Use Monogram's Grapstudio instead of graphedit (http://blog.monogram.sk/janos/tools/monogram-graphstudio/).
- Add a extra output pin in each slave demux of type PSI and map pin 0x0. This output is never connected to any input.

After demonstrating that it was possible to do it with Graphstudio I converted the graph to C++ and after each channel demux I also added a InfTee with two outputs: a Dump filter and an adapted DSNetwork (which multicasts the TS and also accept TCP viewers all the. This filter has an internal thread).

The problem that I'm having and I don't know if it from the player (VLC) or some weird problem in the graph: when watching the saved files (or even connected though TCP) the video have some weird artifacts and squares.... When I tune with DVBViewer I don't notice those artifacts.

My questions are:
- since I have 5 demuxes (1 master, 4 slaves) connected to a InfTee filter what will happen to the graph if one of the DumpFilters or DSNetwork take a bit too long to process (write) the media sample?
- I didn't set any ReferenceClock to my C++ graph. For what I read the last inserted filter which exposes IReferenceClock will be used as a reference clock (my last demux belongs to my 4th captured channel). Should I explicitly set the reference clock to the main demux?


Thanks

lyncher
















Go to the top of the page
 
+Quote Post
bear
post May 22 2012, 07:38 PM
Post #6


Forum Regular


Group: Members
Posts: 3,099
Joined: 24-April 04
From: Queensland
Member No.: 808
Card: VisionPlus DVB-t


Hi lyncher,
QUOTE
I finally managed to have partially working graph.
This is great to see, sounds like your well under way.

QUOTE
- Use Monogram's Grapstudio instead of graphedit (http://blog.monogram.sk/janos/tools/monogram-graphstudio/).
This I have on my desktop, it is a very good tool. Graphedit should work as well.

QUOTE
- Add a extra output pin in each slave demux of type PSI and map pin 0x0. This output is never connected to any input.
I have never seen a requirement for this to make the graph work for multiple demux operation. Is this documented somewhere or is it something that you have observed?

QUOTE
After demonstrating that it was possible to do it with Graphstudio I converted the graph to C++ and after each channel demux I also added a InfTee with two outputs: a Dump filter and an adapted DSNetwork (which multicasts the TS and also accept TCP viewers all the. This filter has an internal thread).
Is this DSNetwork Filter the one developed from this forum or from another site?

QUOTE
The problem that I'm having and I don't know if it from the player (VLC) or some weird problem in the graph: when watching the saved files (or even connected though TCP) the video have some weird artifacts and squares.... When I tune with DVBViewer I don't notice those artifacts.
As an inital guess you are getting lost corrupted or out of sequence data packets, run the file through tsreaderlite and look for discontinuities. The artifacts are due to the data errors flowing direct into the decoders in VLC. The MS MPEG-2 Demultiplexer is useful for playback in that it identifies these and blocks them from entering the decoder so you get glitch free playback to some extent.

QUOTE
since I have 5 demuxes (1 master, 4 slaves) connected to a InfTee filter what will happen to the graph if one of the DumpFilters or DSNetwork take a bit too long to process (write) the media sample?
As an example, if you have decoders and renders on the master demux then these can cause blocking on other master demux pins. As you have two renders via a tee on each slave demux then if one blocks the tee, back towards the demux then you can loose data on the other tee output. Question is I guess is which one is blocking the demux.

QUOTE
- I didn't set any ReferenceClock to my C++ graph. For what I read the last inserted filter which exposes IReferenceClock will be used as a reference clock (my last demux belongs to my 4th captured channel). Should I explicitly set the reference clock to the main demux?
If you are using A/V renders in the live graph then set the clock to the audio render, if the graph is just for recording then set the defaultsync source on the filtergraph interface prior to the run function.

The Tuner is a push filter so data will flow un-interrupted to the demux input pins even via the tee, The demux is where the data can be blocked by the output pins.

This post has been edited by bear: May 22 2012, 07:51 PM
Go to the top of the page
 
+Quote Post
lyncher
post May 24 2012, 07:44 AM
Post #7


Be nice to me, I am new.


Group: New Members
Posts: 4
Joined: 1-May 12
Member No.: 14,963
Card: None


Hi bear,

I've simplified my capture graph to have only the master demux and a slave demux to Dump the TS of only one channel to a file.
Opening the stored file in TSReaderLite it presents TEI errors, continuity errors and it also indicates that there are PIDs in file that weren't even present in DVB-T source... Watching file in VLC shows some squares/artifacts mainly is fast moving images/changing scenes.

QUOTE
This is correct, but do not add or map any pins on the demux that has the TIF connected as the TIF registers the demux with the NP and so the NP controls the demux and output pins and their mappings. Only use output pins that you can map on the slave demuxers. Else you will need to unregister the demux from the NP post connecting the TIF.


What do you mean with "unregistering the demux" from Network Provider? Do I have to call IBDA_NetworkProvider::UnRegisterDeviceFilte to all slave demuxes?
Do I have to explicitly register my TIF with NP?

I've looked into the code of StreamConsumer and StreamProducer and the flow of my program is very much alike, except:
- My tune requests are made after creating and connecting all filters (I already tried to create a tune request after creating a TIF without any improvement in output file).
- My approach is single process (no shared memory), so all demuxes are in same process/graph.

Maybe the NP/TIF is messing around with slave demuxes because if I don't add a PSI output Pin to all demuxes (not connected to any filter) the result file becomes even worse (much worse...).

Why did you split StreamProducer/StreamConsumer in different processes/graphs? Did you have problems like the ones I'm having?
Do you know any successful project that achieved single graph demux (with MS MPEG2 demux)?

QUOTE
Is this DSNetwork Filter the one developed from this forum or from another site?

I was using an adaptation of DSNetwork from DirectX SDK (maybe August 2004).

QUOTE
If you are using A/V renders in the live graph then set the clock to the audio render, if the graph is just for recording then set the defaultsync source on the filtergraph interface prior to the run function.

I just wan't to write individual channel contents in a file (no live view). I'm setting default sync source on the filter graph. Having 5 demuxes in the graph... which of them will be selected has sync source?


Thanks bear for your patience

lyncher
Go to the top of the page
 
+Quote Post
bear
post May 24 2012, 06:45 PM
Post #8


Forum Regular


Group: Members
Posts: 3,099
Joined: 24-April 04
From: Queensland
Member No.: 808
Card: VisionPlus DVB-t


hi lyncher,
QUOTE
Thanks bear for your patience
Your Welcome, I too was new to BDA once, but here I found lots of helpful members.
QUOTE
I've simplified my capture graph to have only the master demux and a slave demux to Dump the TS of only one channel to a file.
Opening the stored file in TSReaderLite it presents TEI errors, continuity errors and it also indicates that there are PIDs in file that weren't even present in DVB-T source... Watching file in VLC shows some squares/artifacts mainly is fast moving images/changing scenes.
At a guess, the demux is not passing all the data correctly and your loosing data. If you can provide a link to a sample file I could look at what it's doing to confirm your observations. If you want to PM me the source code I can take a look to see if I can reproduce the same on another system.
QUOTE
What do you mean with "unregistering the demux" from Network Provider? Do I have to call IBDA_NetworkProvider::UnRegisterDeviceFilte to all slave demuxes? Do I have to explicitly register my TIF with NP?

Your best to read the MSDN documentation on the NP but this link is the interface used.http://msdn.microsoft.com/en-us/library/wi...3(v=vs.85).aspx
To clarify, when you connect the TIF to the master demux, the TIF registers it'self to the NP so it can be controlled. You can unregister the TIF to enable you to manually control the master demux. This demux is used to supply PSI data to the TIF for the BDA service collection interfaces and to pass the stream to the S&T Filter if you want to parse out the EIT etc.
QUOTE
Maybe the NP/TIF is messing around with slave demuxes because if I don't add a PSI output Pin to all demuxes (not connected to any filter) the result file becomes even worse (much worse...).

You should not need to unregister any slave demuxs. I must say that since Win7 TV was introduced I have always had to map the wanted pids post running the graph.
QUOTE
Why did you split StreamProducer/StreamConsumer in different processes/graphs? Did you have problems like the ones I'm having?

I believe that this was to allow the Full TS to be split into different programs and to allow post recording after the producer has started. Saves on device usage.
QUOTE
Do you know any successful project that achieved single graph demux (with MS MPEG2 demux)?

There are some older versions of DVB Webscheduler about prior to the introduction of the Producer/Consumer graphs, DNTV Scheduler Pro uses a combination of both features, DNTVLive! uses a single slave demux.
QUOTE
I was using an adaptation of DSNetwork from DirectX SDK (maybe August 2004).
Nate and I also modified the SDK version which we used for DigitalWatchII some time ago.
QUOTE
I just wan't to write individual channel contents in a file (no live view). I'm setting default sync source on the filter graph. Having 5 demuxes in the graph... which of them will be selected has sync source?
I can understand your frustration, it is not that easy when things are hidden but your making progress, all I do is use "m_pFilterGraph->SetDefaultSyncSource();" prior to running the graph but this should not be required.
Go to the top of the page
 
+Quote Post
bear
post Jun 3 2012, 09:44 AM
Post #9


Forum Regular


Group: Members
Posts: 3,099
Joined: 24-April 04
From: Queensland
Member No.: 808
Card: VisionPlus DVB-t


hi lyncher,

I have had a chance to look at the method to get the multi demux graph working for splitting the transport streams.

The following is what I have found so far:-

Build your filtergraph connecting the first Tee output to the first demux as the standard BDA Demux and adding the TIF.
Add the additional demux to the Tee and create the TS pins and connect to the file writer and network sender etc. (the MS "File writer" filter is not valid to use in this application.)
Submit the tune request on the NP and then run the filtergraph.
Wait 500ms then map the transport stream packets to the TS pin as MEDIA_TRANSPORT_PACKET.
Include pids 0x00, 0x01, 0x10, 0x11, 0x12, 0x13, 0x14 as well as the PMT, PCR, Video, Audio, TTxt and any other associated pids for the program.
The first data bytes output by the demux TS pin will have the media type identifier.
This data can cause some players (e.g. VLC) to not recognise the transport stream so you will need to block this data at the file writer until the transport stream packets begin.
The Webscheduler filewriter filter can be set to a mode where it searches the stream for the first two valid packet sync bytes before writing data.
This is all that should be required.

Note: If you map any pins with pids on any additional demux filters before you submit a tune request or run the filtergraph the NP will recognise that the pin it is fair game and will map all the PMT pids in the stream to any of the additional demux pins as MEDIA_MPEG2_PSI.
This will result in either the wanted PMT packet not being passed as MEDIA_TRANSPORT_PACKET or the addition of all the other PMT packets being passed as MEDIA_MPEG2_PSI and so corrupting the output stream with unwanted data.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 14th December 2018 - 07:16 AM