New Image

[ingo]

Thank you in HDMU_16125_AzboxHD_OE_2717_Flash fix progress bar Paus / fvd / rev. Audio is not fix.
Audio must be corrected with the next build image.
Once again thank you for the work done.

----------
The theme mediasink not apply. Crash when navigating in GraphMultiEpg continues.
Dear bonkel, please help.

[dazulrich]

Ingo.
i noticed I had pused the audio fix to the wrong branch. fixed now, next build should contain it.
Attached 3 sets of sink files. as mentioned in earlier post, its combination of either change reverted and both reverted.
This may not change anything. Lets see. there is another change I can revert, but its a bit extensive, so i tried to get the small ones out of the way.
audiosink and videosink got changed. i know your issue is with video. but please replace both to test the effect.

There is a good chance this won't fix anything. between 16027 and the current builds, GST version has changed from 1.9.9 to 1.10.0. there may well be changes in gstreamer relating to HLS streaming, recipe changes, patches needed / not needed anymore that haven't been identified. It would be interesting to know if those streams are not smooth on other boxes or just azbox..
Btw, can you say how choppy the playback ist. how much does it stutter. like microstutter , how visible is it..

EDIT: there is one test you can do. use the 16027 image (with gstreamer 1.9.9) and copy the 2717 mediasink files. if this results in smoorth stream and smooth avi media, then we know its most related to gstreamer itself. if you get same smooth / not smooth result, then its the mediasink.

On the epgrefresh. this has been reported on other images too and Bokel stated this will take him a little longer to fix. please be patient, he is working on it.

/daz

[ndminion]

Who can tell me why in the latest builds bad works IPTV on HD channels, constantly pours the picture and the sound disappears? Why bad working gstreamer? Who know image OpenPLI 4.0 on our Azbox, do not have this problem.

[dazulrich]

How can anyone help you if you don't provide any details?

[dazulrich]

@Ingo.
did a bit of reading about streaming issues and there were lots of problem over the past year. one of the issues was exzessive Tags due to bitrate changes with resulting much higher CPU usage.
I ran the streams and the output from livestreamer and compared the debug logs.
The live stream shows about 25 TAG events per second for video bitrate changes, while the fliesrc doesn't show any videobitrate changes for the same period.

What would be a good test is it get a sinkcombination where streams is smooth and capture debug log (and check CPU load), and then switch sink files to make it stutter and do the same debug log capture (and check CPU load). maybe there is different handling of TAG events..
Could you capture with following settings and post both logs?

INIT 4
ENIGMA_DEBUG_LVL=4 GST_DEBUG=dvbvideosink:5,dvbaudiosink:5 enigma2.sh > /var/tmp/axbozsmoothstreamtest.log 2>&1

Another interesting thing to know would be whether fixing the audio on the no_audio streams makes them not smooth... can you confirm they play smoothly even with audio.

As there is no other enigma image using GST 1.10 that i'm aware of, the gst patch recipes may need to be updated.. (which isn't anything I can do).

[ingo]

Hi dazulrich.
Testing conducted on the image 16117 (GST 1.10.0).
Results:

mediasink.statechg - nok ( avi smoothly, m3u8 not smooth)
mediasink.statechg_synctrue - nok ( avi smoothly, m3u8 not smooth)
mediasink.sync_true - nok ( avi smoothly, m3u8 not smooth)

there is one test you can do. use the 16027 image (with gstreamer 1.9.9) and copy the 2717 mediasink files. if this results in smoorth stream and smooth avi media, then we know its most related to gstreamer itself. if you get same smooth / not smooth result, then its the mediasink.
/daz

Result replacement: - nok ( avi smoothly, m3u8 not smooth)
Previously, I had a reverse substitution test:

The image used HDMU_16117_AzboxHD_OE_2711_Flash updates gstreamer1.0-plugin-azbox-dvbmediasink_1.0+git90+aced153-r11_azboxhd that contains libgstmpeg4p2unpack.so. If I understand correctly, in libgstdvbvideosink.so introduced changes to work with libgstmpeg4p2unpack.so. These changes in libgstdvbvideosink.so play well avi, but do not lead to a smooth playback m3u8. I used to HDMU_16117 file libgstdvbvideosink.so from HDMU_16027, smooth operation m3u8 recovered at play avi became not smooth.

The result is: -ok (avi not smoothly, m3u8 smoothly)
I want to draw attention to "in libgstdvbvideosink.so introduced changes to work with libgstmpeg4p2unpack.so"

Makes his conclusion: the problem does not depend on the version of the GST, the same does not depend on libgstdvbaudiosink.so. There is a direct relationship only libgstdvbvideosink.so, at which it became "avi smoothly, m3u8 not smooth".

Ingo.
Btw, can you say how choppy the playback ist. how much does it stutter. like microstutter , how visible is it..

This is very similar to avi playback until patching.
Visually, this manifests itself as a "forwarding frames", ie, there is a discrete moving objects in the frame.

What would be a good test is it get a sinkcombination where streams is smooth and capture debug log (and check CPU load), and then switch sink files to make it stutter and do the same debug log capture (and check CPU load). maybe there is different handling of TAG events..
Could you capture with following settings and post both logs?

I did log on 16117. Where the "smooth" replaced only libgstdvbvideosink.so.
I assume that the problem does not depend on the CPU load.

Another interesting thing to know would be whether fixing the audio on the no_audio streams makes them not smooth... can you confirm they play smoothly even with audio.

It is not correlated (independent of libgstdvbaudiosink.so).

Maybe it's important. When Using a third-party player able to play m3u8 (ie not from userbouquet), the effect of "not smooth" can be eliminated by changing the playback position. Ie using the numeric keys change positions, or TimeSeekBar.
In my humble opinion, by making changes to better play avi, more harm than good.

I hope you are not too tired.
Regards, ingo

[dazulrich]

Thanks a lot for the testing!!!
I wasn't really expecting those test files to "fix" the problem.
I have two more changes to test.
- revert the use of the libgstmpeg4p2unpack plugin.
- revert a change to pass events to the base sink.
in previous videosink versions both changes were either in or out. never only one of them.

I saw in the changelog that Bonkel sudmitted change trying to fix the epg issue. todays build should also have the audio fix in.

/Daz

[ingo]

Very grateful!
Fixed audio, thanks.
I am ready for further testing. Now I must be something else to do?

Made a nice change in GraphMultiEPG, I confirm.
Many thanks bonkel!
But there is a crash at the exit from the menu "Electronic Program Guide Setup".

[dazulrich]

Hi Ingo,
I don't think the not smooth playback of streams is because of the mpeg4packer plugin itself, but rather a sloppy merge into the mediasink , affecting other stream types.
the packer is versy specific which streams it will do its magic on

"video/mpeg, " "mpegversion = (int) 4, " "systemstream = (boolean) false; "
"video/x-divx, " "divxversion = (int) [ 4, 5 ]"

neither of which we are using here, we use "video/x-h264".
before reverting the packerplugin altogether, i'll try to find why h264 streams are worse than before. they shouldn't.

[ingo]

I don't think the not smooth playback of streams is because of the mpeg4packer plugin itself, but rather a sloppy merge into the mediasink , affecting other stream types.

Totally agree with you, I presume that this is the case.