Results of testing new version (avc2ts)

[BevDan]

Hello Everiste, Congratulation on the new input features, certainly makes the project more flexible. Some issues that I have come across are: -The audio PID doesn't end up being PMT +2 as expected, seems to =PMT for inputs using the avc2ts method, and I have not heard any audio. The only source that generates audio is the CAMMPEG-2 which generates the tones with a PID of PMT +2, A IPTSIN has audio but believe that is due to the PID's being generated on the source PC and not in the PI -The video bit rate is quite low at higher symbol rates (For the testing I used IQ modulation, 3/4 FEC, PatternAudio. I sampled the output stream using Minitioune to decode the DVBS and UDP into TSReader Lite, each symbol rate was measured for around 5mins. At 250ksymbols the Video rate 238.87kbps, stuffing rate 97.86kbps, overall Mux bitrate 345588bps. At 500ksymbols the Video rate 298.17kbps, stuffing rate 383.65kbps, overall Mux bitrate 691097bps. At 1000ksymbols the Video rate 177.42kbps, stuffing rate 1.20Mbps, overall Mux bitrate 1382220bps. At 2000ksymbols the Video rate 462.31kbps, stuffing rate 2.29Mbps, overall Mux bitrate 27647057bps. At 5000ksymbols the Video rate 137.08kbps, stuffing rate 6.77Mbps, overall Mux bitrate 6911764bps.) As you can see the transport stream had an overall Mux rate that was to be expected at each symbol rate, however the stream seemed to just be stuffed with more null packets rather than video data, making it unusable at higher symbol rates. Regards, Bevan VK5BD

At 5000K

At 250K

At 500k

At 1000k

At 2000k

[F5OEO]

Hi Bevan,

Thanks in publish and testing such configurations. Didn't take the time to do it ! Not completely suprised by the results. Using H264 encoder in constant bitrate is not very common. I try to tweak it but as the encoder is in closed source, I can't figure enough deeply the process. However , in order to optimize video bitrate , you can play with :

• encoded resolution
• framerate
• target bitrate of the encoder : that's maybe the hard way : even specify a bitrate , the encoder usually have some very high peaks (depends on video scenes) which force to set it at a lower bitrate to avoid some overflow. All this done in the script a.sh The part to tweak is :

let BITRATE_VIDEO=(BITRATE_TS*5)/10-10000

let DELAY=(BITRATE_VIDEO*8)/10
let SYMBOLRATE_K=SYMBOLRATE/1000

if [ "$BITRATE_VIDEO" -lt 200000 ]; then
VIDEO_WIDTH=160
VIDEO_HEIGHT=140
else
    if [ "$BITRATE_VIDEO" -lt 300000 ]; then
    VIDEO_WIDTH=352
    VIDEO_HEIGHT=288
    else
        VIDEO_WIDTH=720
        VIDEO_HEIGHT=576
    fi  
fi

if [ "$BITRATE_VIDEO" -lt 300000 ]; then VIDEO_FPS=15 else VIDEO_FPS=25 fi

In summary it says that : video bitrate is 50% of the available bitrate (a lot of margin !!!) After that make some test about the video bitrate to adapt size and framerate : This could be improved a lot ...Bevan you can contribute !

[BevDan]

Hello Everiste,

How do I go about contributing?

I have to do more testing but have noticed something a little odd, if I start a transmission with say 2000k symbols, stop it and then start a 5000k symbol transmission, I get a higher video bit rate than if I was to start with 5000k from a reboot. I think you kill all tasks between transmissions so can quite understand how there is an effect, however as I said, I need to do further testing to prove what I think I have witnessed.

73 Bevan VK5BD

[F5OEO]

Bevan,

That's interesting. I had some issues like this, thinking that have some "persistent" variables. As to encoder is restarted at each time, there should not be this behaviour. Thanks for pointing it, need intensive tests and have not always time to do it ! Great to contribute !

[BevDan]

Hello Everiste, Its starting to look like I may have jumped to conclusions about there being difference in encoding bit rate being based on selecting a lower symbol rate and then back to a higher symbol rate. I have now conducted more testing and have found that there can be changes in the amount of data being encoded from one transmission to the next without changing any settings. For my testing I used the pattern input, 5000k symbols and FEC 3/4. After starting and stopping the transmission several time I found that most of time the encoded rate was close to 1Mbps (as determined by TSReader) and the received video was clear and smooth using MiniTioune. However sometimes when the transmission was started the encoded bit rate dropped to 245kbps and the received video was blocky and jerky. I also noticed that when this "Fault" condition was occurring the actual video being displayed on the pi's monitor had appeared to have sped up (the bubbles moving quickly across the screen and then scrolling text was faster and jerking at times). Interestingly I conducted the same tests but this time using 2000k symbols and it took three start / stop / start before the same effect occurred. Also found that the video encoding bitrate was the same at 2000k and it was at 5000k. I have also found that this issue doesn't seem to occur at 1000k symbols

At this stage I have not worked out what could be causing this but thought I would pass on my observations to you in case you think of something that is happening.

73 Bevan VK5BD

[F5OEO]

Thanks Bevan about all these observations : very clear and interesting . I will investigate soon : could be an encoder issue or issue with frame grabbing (patern mode).