discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] ReDiscuss-gnuradio Digest, Vol 173, Issue 39


From: Huzaifa niazi
Subject: Re: [Discuss-gnuradio] ReDiscuss-gnuradio Digest, Vol 173, Issue 39
Date: Fri, 28 Apr 2017 01:31:31 +0500


i have problem in picking a data appended after Preamble ..i used correlation and estimate block afterwards i want to remove my preamble can anybody help.plz

On Thu, Apr 27, 2017 at 8:27 PM, <address@hidden> wrote:
Send Discuss-gnuradio mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
        address@hiddenorg

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

   1. Re: WARN: transport stream sync error (address@hidden)


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

Message: 1
Date: Thu, 27 Apr 2017 17:26:44 +0200 (CEST)
From: address@hidden
To: Ron Economos <address@hidden>
Cc: discuss-gnuradio <address@hidden>
Subject: Re: [Discuss-gnuradio] WARN: transport stream sync error
Message-ID:
        <426737191.70439416.1493306804857.JavaMail.zimbra@telenet.be>
Content-Type: text/plain; charset="utf-8"

Hi,

Is there a tool with which i can test if my bitrate is constant?

i'm still having sync lost, sync found messages.

my picture is 95% perfect. but there is a build-up of delay.

my ts stream is still not perfect a presume.


Van: "Ron Economos" <address@hidden>
Aan: "discuss-gnuradio" <address@hidden>
Verzonden: Donderdag 27 april 2017 14:33:21
Onderwerp: Re: [Discuss-gnuradio] WARN: transport stream sync error



Unfortunately, that bit-rate calculator (even though it's the first hit on Google) is in error by a small amount. I have a DVB-S2 bit-rate calculator here.

[ https://github.com/drmpeg/dtv-utils/blob/master/dvbs2rate.c | https://github.com/drmpeg/dtv-utils/blob/master/dvbs2rate.c ]

The actual TS bitrate is 8.710102 Mbps
Your combined video and audio bit-rate must be less than the TS bit-rate. Also (and this is crucial), the stream must have stuffing packets to arrive at that exact bit-rate.

I've created a properly muxed file for you to test with. It's 3.175 Mbps H.264 720p video with 384000 bps AC3 audio muxed at exactly 8.710102 Mbps.

[ http://www.w6rz.net/4msyms8psk34.ts | http://www.w6rz.net/4msyms8psk34.ts ]

It's 328,080,492 bytes.

Ron

On 04/27/2017 04:43 AM, [ mailto:address@hidden | address@hidden ] wrote:



Hi,

i can now set my packet size at 1316 (7 times 188)
i send now the whole 7 packets of 188 into ZMQ to gnuradio
Added your sync module.

i'm getting sync found
UUUUUUUUUUUUUU sync lost
etc...

how can i prevent underrun?
i'm sending 4Msymb in 8psk dvb-s2 3/4 code rate
this gives me: following this site: [ http://www.satbroadcasts.com/DVB-S_Bitrate_and_Bandwidth_Calculator.html | http://www.satbroadcasts.com/DVB-S_Bitrate_and_Bandwidth_Calculator.html ]
a netto ts rate of 8.7159 Mbps
minus the 128K of the audio gives me 8584828 bytes

do i have to set my video rate to exact that same number?


Van: "Ron Economos" [ mailto:address@hidden | <address@hidden> ]
Aan: "discuss-gnuradio" [ mailto:address@hiddenorg | <address@hidden> ]
Verzonden: Donderdag 27 april 2017 12:25:49
Onderwerp: Re: [Discuss-gnuradio] WARN: transport stream sync error



Fix pushed. stdio.h gets included on my system through some other means. I'm guessing maybe log4cpp, which not everyone has installed on their system.
Ron

On 04/27/2017 12:47 AM, [ mailto:address@hidden | address@hidden ] wrote:

BQ_BEGIN

i got an error in make:

address@hidden:~/gr-tssync/build$ make
Scanning dependencies of target gnuradio-tssync
[ 4%] Building CXX object lib/CMakeFiles/gnuradio-tssync.dir/tssync_bb_impl.cc.o
/home/guy/gr-tssync/lib/tssync_bb_impl.cc: In member function ?virtual int gr::tssync::tssync_bb_impl::general_work(int, gr_vector_int&, gr_vector_const_void_star&, gr_vector_void_star&)?:
/home/guy/gr-tssync/lib/tssync_bb_impl.cc:81:38: error: ?printf? was not declared in this scope
printf("TS sync found!\n");
^
/home/guy/gr-tssync/lib/tssync_bb_impl.cc:95:39: error: ?printf? was not declared in this scope
printf("TS sync lost!\n");
^
lib/CMakeFiles/gnuradio-tssync.dir/build.make:62: recipe for target 'lib/CMakeFiles/gnuradio-tssync.dir/tssync_bb_impl.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-tssync.dir/tssync_bb_impl.cc.o] Error 1
CMakeFiles/Makefile2:137: recipe for target 'lib/CMakeFiles/gnuradio-tssync.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-tssync.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
address@hidden:~/gr-tssync/build$





Van: "Ron Economos" [ mailto:address@hidden | <address@hidden> ]
Aan: "discuss-gnuradio" [ mailto:address@hiddenorg | <address@hidden> ]
Verzonden: Donderdag 27 april 2017 02:38:18
Onderwerp: Re: [Discuss-gnuradio] WARN: transport stream sync error



I've created an OOT module that has a TS synchronizer block.

[ https://github.com/drmpeg/gr-tssync | https://github.com/drmpeg/gr-tssync ]

The block will show up in the Digital Television category under DVB.

Just place it before the BBheader block. It will search for an initial sync byte and check for subsequent sync bytes. When it attains synchronization, it will print "TS sync found!". When it loses synchronization, it will print "TS sync lost!".

Under normal operation, you'll see either one or none "TS sync found!" message at the beginning of the stream. You should not see any "TS sync lost!" messages. If you see many "TS sync lost!" messages followed by "TS sync found!" messages, your not feeding a good stream to the block.

Ron
On 04/26/2017 02:47 PM, [ mailto:address@hidden | address@hidden ] wrote:

BQ_BEGIN

how much bytes is the overhead?

does the recieving ZMQ block has to get the bytes in chunks of 188 bytes?

i recieve the udp ts stream in varies packet sizes... and send the straight to the ZMQ framework.

does a 188 byte packitizer exist in gnuradio, so he can do this job?

or isn't this the reason for the sunc errors?

i somethimes get a few frames visible... so it has to be related to timings...


Van: "Ron Economos" [ mailto:address@hidden | <address@hidden> ]
Aan: "discuss-gnuradio" [ mailto:address@hiddenorg | <address@hidden> ]
Verzonden: Woensdag 26 april 2017 21:21:39
Onderwerp: Re: [Discuss-gnuradio] WARN: transport stream sync error

You may want to put a file sink block after your ZMQ block to make sure you're chain is working as expected.

Usually 188 byte alignment is just done by picking a UDP packet size that's a multiple of 188 bytes (plus overhead). For example, VLC in UDP mode uses 1358 byte packets and puts 7 TS packets in each UDP packet. Like so:



Ron

On 04/26/2017 11:52 AM, [ mailto:address@hidden | address@hidden ] wrote:

BQ_BEGIN


Are you saying that there are no sync bytes in my stream?

or should i wait until i get byte 0x47 in my udp packet, wait till i get 188 bytes, and send them as an array of bytes in the zeroMQ?


Van: "Ron Economos" [ mailto:address@hidden | <address@hidden> ]
Aan: "discuss-gnuradio" [ mailto:address@hiddenorg | <address@hidden> ]
Verzonden: Woensdag 26 april 2017 20:16:10
Onderwerp: Re: [Discuss-gnuradio] WARN: transport stream sync error



The BBheader block expects the Transport Stream to start with a sync byte (0x47) and that a sync byte appears every 188 bytes.

There's no sync byte synchronization in the BBheader block, so if the stream doesn't start with a sync byte, you'll get continuous errors.


Ron
On 04/26/2017 10:56 AM, [ mailto:address@hidden | address@hidden ] wrote:

BQ_BEGIN

Hi,

My setup:
Linux gnuradio with dvb-s2 tx sample code. adjusted to read from ZeroMQ pull source
5M symbol. in 8psk dvb-s2 3/4 code rate

Windows side: 2 programs:
1) program to make udpts stream from webcam(5M) -> send udp stream to 127.0.0.1:1234
2) program to listen to udp port 1234 get udp packets and send them to ZeroMQ push socket

gnuradio is complaining about transport stream sync error.

What can be the reason for this?






_______________________________________________
Discuss-gnuradio mailing list
[ mailto:address@hiddenorg | address@hidden ]
[ https://lists.gnu.org/mailman/listinfo/discuss-gnuradio | https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ]

BQ_END


_______________________________________________
Discuss-gnuradio mailing list
[ mailto:address@hiddenorg | address@hidden ]
[ https://lists.gnu.org/mailman/listinfo/discuss-gnuradio | https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ]

BQ_END


_______________________________________________
Discuss-gnuradio mailing list
[ mailto:address@hiddenorg | address@hidden ]
[ https://lists.gnu.org/mailman/listinfo/discuss-gnuradio | https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ]

BQ_END


_______________________________________________
Discuss-gnuradio mailing list
[ mailto:address@hiddenorg | address@hidden ]
[ https://lists.gnu.org/mailman/listinfo/discuss-gnuradio | https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ]

BQ_END


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170427/68160df6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 358290 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170427/68160df6/attachment.png>

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

Subject: Digest Footer

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

End of Discuss-gnuradio Digest, Vol 173, Issue 39
*************************************************


reply via email to

[Prev in Thread] Current Thread [Next in Thread]