Ok Evariste , I will do...
TS out from the Windows Program TX , or RX record from Minitoutioune , you mean ?
Tnx
JP, ON7MA
DATV-Express Project - January update report
Forum rules
This forum is run by the BATC (British Amateur Television Club), it is service made freely available to all interested parties, please do not abuse this privilege.
Thank you
This forum is run by the BATC (British Amateur Television Club), it is service made freely available to all interested parties, please do not abuse this privilege.
Thank you
Re: DATV-Express Project - January update report
Could be recorded from tutioune to be sure what exactly is received.
30 seconds to 1 minute should be fine.
30 seconds to 1 minute should be fine.
Re: DATV-Express Project - January update report
Hi Evariste
here's the stream, just recorded with minitiouner.
https://www.dropbox.com/s/czlk6kn3ts819 ... 29.TS?dl=0
Meanwhile ,i 'm sending with version 1.07 made yesterday by Charles, with the possibility to code audio at 192Kbits, to see if that improved audio, on the VU+, or Dreambox, which did not
Tnx for concern
JP, ON7MA
here's the stream, just recorded with minitiouner.
https://www.dropbox.com/s/czlk6kn3ts819 ... 29.TS?dl=0
Meanwhile ,i 'm sending with version 1.07 made yesterday by Charles, with the possibility to code audio at 192Kbits, to see if that improved audio, on the VU+, or Dreambox, which did not
Tnx for concern
JP, ON7MA
Re: DATV-Express Project - January update report
Thanks for the stream...
Indeed, the audio is NOT compliant : STD BUFFER which is 3584 Bytes has a BUFFER OVERFLOW with a meaning value of 4700 Bytes in the buffer, which is surely due of porblem with PTS and arrival time in the multiplexer.
Charles has to reduce a little the arrival time in order to be compliant.
Maybe I could look in the code, but not sure that actual version is on github (Charles, let me know).
73's Evariste F5OEO
Indeed, the audio is NOT compliant : STD BUFFER which is 3584 Bytes has a BUFFER OVERFLOW with a meaning value of 4700 Bytes in the buffer, which is surely due of porblem with PTS and arrival time in the multiplexer.
Charles has to reduce a little the arrival time in order to be compliant.
Maybe I could look in the code, but not sure that actual version is on github (Charles, let me know).
73's Evariste F5OEO
Re: DATV-Express Project - January update report
Tnx Evariste
Good news... !
If any change is made, I'll test it and put feedback
JP
Good news... !
If any change is made, I'll test it and put feedback
JP
Re: DATV-Express Project - January update report
Evariste I assume you are talking about receive buffer?
On transmit I am delaying the PTS by an arbitrary 200 ms. I could reduce that slightly.
If I reduce it too much the video will go funny.
I will probably post a new release at the weekend. I have been adding support for band switching
to the FPGA code today and I don't want to release anything until that is done.
If anyone is interested I recorded a TS file from the local BBC DVB-T multiplex.
I may use that as a reference to test against.
- Charles
On transmit I am delaying the PTS by an arbitrary 200 ms. I could reduce that slightly.
If I reduce it too much the video will go funny.
I will probably post a new release at the weekend. I have been adding support for band switching
to the FPGA code today and I don't want to release anything until that is done.
If anyone is interested I recorded a TS file from the local BBC DVB-T multiplex.
I may use that as a reference to test against.
- Charles
Re: DATV-Express Project - January update report
Charles,
Yes I was refering to the standard receiver buffer model defined in ISO13818 norm.
A delay of 200ms is too much, and should be around 120 ms (between PTS/PCR). It should avoid to be in overrun and not too low to not reach underrun.
Could provide you some tools to analysis it if needed.
Evariste
Yes I was refering to the standard receiver buffer model defined in ISO13818 norm.
A delay of 200ms is too much, and should be around 120 ms (between PTS/PCR). It should avoid to be in overrun and not too low to not reach underrun.
Could provide you some tools to analysis it if needed.
Evariste
Re: DATV-Express Project - January update report
I set it to 140 ms in the release I put out yesterday.
This morning I split the definition of the video and audio delay so I can now change
them independently.
I have some software for measuring the buffer sizes but whatever I set it to the software complains.
Even when I try it on a BBC multiplex TS I recorded off air the software complains.
- C
This morning I split the definition of the video and audio delay so I can now change
them independently.
I have some software for measuring the buffer sizes but whatever I set it to the software complains.
Even when I try it on a BBC multiplex TS I recorded off air the software complains.
- C
Re: DATV-Express Project - January update report
OK, great to have audio and video delay independent...it will be easier to tweak and correct eventual lipsync.
The tool to measure buffer size...need maybe an other (check your mailbox).
On an other subject : is ExpressServer up to date on github ? Think to include it by cloning you repositorie and compile for interfacing with rpidtav project on git.
The tool to measure buffer size...need maybe an other (check your mailbox).
On an other subject : is ExpressServer up to date on github ? Think to include it by cloning you repositorie and compile for interfacing with rpidtav project on git.
Re: DATV-Express Project - January update report
I have the files.
Yes the Express Server on Github is the latest. I have been concentrating on Windows
for the last 6 months so not much has happened on Linux along with the fact I have been
concentrating on programming the FPGA in my QuadSDR project (big learning curve).
- Charles
Yes the Express Server on Github is the latest. I have been concentrating on Windows
for the last 6 months so not much has happened on Linux along with the fact I have been
concentrating on programming the FPGA in my QuadSDR project (big learning curve).
- Charles