peteru

You might want to look at turning that info into a cuesheet. Look in lib/service/servicedvb.cpp and lib/service/servicedvd.cpp for some ideas.

That's a waste of 2MB or more of RAM for a cache that's going to be lost. Why clear it at all? Let gstreamer manage it's resources - if there are issues with that, then report those issues and fix them, rather than implement hacks.

Why would a normal user not reboot every day? Deep standby will result in a reboot and plenty of users do that.

I have done a bit of research and most modern Broadcom hardware will support PCM input at up to 24 bits @ 192kHz. Even if the hardware can not output that format, the DSPs will do either hi-fidelity sample rate conversion or a simple low-fidelity interpolation.

I guess that 24 bit and 192kHz would be good defaults for MAX settings. Specific boxes that have lower limitations should probably specify alternate values when configuring dvbmediasink.

xvid -> mpeg4 https://bugzilla.gno...g.cgi?id=739196 we need to give more information why we need to know that mpeg4 is actually xvid, please leave your comments on the bug if you want this to get fixed.

Done. It just happens to be in the dvbmediasink and driver code I've been working on for the last week or so, so I'm familiar with it.

I forked gst-plugin-dvbmediasink on sf.net (the repo is at https://sourceforge..../beyonwiz/tree/ ) and submitted a pull/merge request using the standard sf.net git workflow. I'm not sure if that is the standard process for your development workflow, but the development information on the openpli.org wiki is sketchy at best and I could not find a relevant post in the forums in a reasonable amount of time.

The changes are pretty minimal and split up into 7 fairly clean commits. I'm happy to discuss the changes if you need clarification, either using the sf.net collaboration tools, or these forums.

Cheers,

Peter