Beiträge von Jukka Aho

    Zitat

    Originally posted by digi_casi


    don't know. for dvb-ip it might work, but i haven't seen a single iptv channel using dvb-ip...


    Trinet – the student network provider for Helsinki University of Technology – multicasts a couple of dozen tv channels (and many radio channels, too) on their campus WAN.


    The stream format would appear to be MPEG-2 TS where the transport stream packets have been encapsulated within TCP/UDP/RTP packets. (That’s pretty much the definition of DVB-IPI, isn’t it?) The transport streams come complete with video, DVB subtitles (depending on the channel), Teletext service (depending on the channel), and multiple audio tracks (depending on the channel.)


    As far as I can tell, no downsampling or re-encoding of any kind is done to the pictures or the sound. That is, this is a “real” tv-over-IP service – not some reduced-quality Internet stream. The video and the audio streams are both multicast in their original, full broadcast quality. (The “payload” data in the streams seems to be exactly the same as how it appears in the “official” DVB-T/DVB-C/DVB-S broadcasts for these same channels, when receiving them via an ordinary rooftop antenna, cable tv subscription, or satellite dish.)


    I believe these streams are modeled after the DVB-IPI standard and could be received with a set-top box conforming to the DVB-IPI specifications even though many of the students are currently using VLC and a desktop PC for receiving and viewing them, due to DVB-IPI set-top boxes not being readily available. (I think some of the more “advanced” users are using VDR or MythTV based Linux HTPCs connected to their tv sets.)


    I’ve actually tried capturing these streams with VLC and playing them back on my DM 500. The DM 500 displays these .ts captures fine – for example, you can view the Teletext pages, choose between audio tracks in different languages, etc. The stream format would appear to be completely compatible with the ordinary DVB-T/S/C streams – the only exception being that I don’t think that the streams contain EIT schedule (EPG) data.


    It would be great if the DM 500 (and the other Dreamboxes, too – such as the DM 7025, of course) allowed easy viewing, channel-surfing, and recording of these kind of services “live”. As already suggested, some sort of virtual DVB-IPI (TCP/UDP/RTP) Ethernet “NIM” would be an ideal way to implement it.

    Hi! I have created an updated Finnish translation file (fi.po) for Enigma2 v2.2. It’s a major overhaul to the existing Finnish translation catalog: almost everything has been revamped and made better.


    If possible, I’d like to have this translation included to the official Dream Multimedia Enigma2 distribution (DM7025 firmware.) The translation catalog can be downloaded here:

    The package also includes a precompiled enigma2.mo for those end-users who are currently using Enigma2 v2.2 and would like to try it out.


    For what it’s worth, my DM 7025 (with 2×DVB-T tuners) works fine. No reception problems whatsoever in normal weather conditions. The transmitter site is about 60 km away. Seeing that you’re located very near to the transmitter, perhaps you’re getting too strong a signal (which overdrives the tuner) and would need an RF attenuator dongle of some sort?

    Zitat

    Originally posted by Jukka Aho


    Interesting. It did not occur to me to me that playing back the same .ts recording several times in a row could yield different results. I have not tried that yet, but I’m now wondering whether that would also be the case for the built-in DVB subtitling support in Enigma 2.


    I just put this theory to test today by playing back the original sample clip (243 MB) several times in a row in Enigma2 – with the built-in DVB subtitling support enabled – and recapturing the decoded/rendered video + subtitles to the computer from the analog video outputs of the DM 7025 for further analysis.


    As far as I can tell, everything – including those subtitle panels that have obvious rendering errors (as per the timecode table) – was rendered identically in each test run. I would take that as a proof that it’s a systematic problem in Enigma2’s subtitle decoding/rendering algorithm and not something that would only occur semi-randomly due to buffering/demuxing problems.

    Zitat

    Originally posted by Gruffy
    I will see if can get some time to investigate the file and see if 2SUB logging can reveal some new clues to this problem.


    That would be nice. I don’t think there are too many people around who would have a good technical grasp on how DVB subtitles work, so any pair of experienced eyeballs (such as yours) would potentially be very valuable in helping to solve the problem.


    Zitat

    About the mentioned bugs for 2SUB...I have not gotten any of those reports, but...I have also been very busy with other things so I could have missed it in some way.


    I’ve seen the 2SUB “hanging DVB subtitles” problem mentioned a couple of times on Finnish forums (here, for example) but I don’t know if anyone has reported it back to you.


    If you haven’t seen any such problems yourself, my working theory is that perhaps there is enough leeway in the DVB subtitling standard that it allows broadcasters do things a bit differently from one country to the other.


    In other words, the Finnish YLE – which is currently the only broadcaster in Finland using DVB subtitles on all their channels, and, subsequently, the only broadcaster whose broadcasts I’ve been able to test a) with the 2SUB plugin and b) with Enigma2’s built-in DVB subtitling support (and from whose broadcasts the sample clips linked to this thread have been captured) – might be doing something a bit different way than, e.g., the broadcasters local to you. This is just pure speculation on my part as I have not done any analysis on the actual streams, but a similar thing was already found to be true with the other Enigma2 bug report which I recently filed!


    Since both the 2SUB plugin and the built-in DVB subtitling support in Enigma2 show partly similar traits – namely, 1) that the text is left hanging on the screen for a long time, and 2) that there are no natural gaps in the subtitle display between two consecutive subtitle panels (in places where such gap is displayed in the analog simulcast and by other set-top boxes on the market) – this could certainly be a case where the broadcaster is perhaps interpreting and using some aspect of the DVB subtitling standard in an unexpected (but yet not necessarily non-standard) way. (Standards are [too] often like that – open to interpretation in some little details.)


    • • •


    One reason for not getting too many bug reports from Finland might be that many Finnish Dreambox owners seem to prefer 2SUB/gSUB and the Teletext subtitles over the DVB subtitles. The reason for this preference is quite simple: Teletext subtitling – when available – allows the viewer to set the font, the size of the font, and positioning to their liking.¹) It’s also the path of least resistance at this moment since the Teletext subtitling support in 2SUB does not suffer from the “hanging text” problem.


    YLE, however, does not give any guarantees about continuing to simulcast the Teletext subtitles in the future. DVB subtitling is their “official” subtitling format, and Teletext subtitles are only broadcast for the time being, for compatibility reasons – and that service is not really even publicly advertised anywhere. So a time might come when they will finally pull the plug on the Teletext subtitles once and for all...


    ¹) OK, limited scaling and positioning support could be done for DVB subtitles as well – at least when allowing some broadcaster-specific heuristics and assumptions – but I have never seen that implemented anywhere. It woud be a nice feature, though!


    Zitat

    I will see if I can get any time to look at this some day...at the moment I am trying to spend the small time I have on other things than 2SUB and gSUB....


    Yes, I noticed you have recently closed down the blog where you used to report gSUB/2SUB-related developments. :frowning_face:


    If you don’t have the time for further development – for the time being, at least – how about open-sourcing the project so that others could help, or even take over? It would be a real shame to see all that good work go in vain, or to be left in an unmaintained state.


    As it stands now, with the current (built-in) Enigma2 DVB subtitling support being... ahem... in its early days, 2SUB is a very valuable addition to the DM 7025 user experience in all the subtitling-crazy countries.

    Zitat

    Originally posted by Gruffy
    it seems like the DVB PES packets arrive VERY late some times and in this case I will have to drop them as their PTS has been passed. The strange thing with this is that I have a recording and this is behaving differently when I playback it. Some times, the text is OK and some not. [...] I have traced this back to that my (PES) filters does not receive the data properly and to me it seems as the driver is buffering my PES packets too much some times so that it is taking too long for them to pop out in my filter.


    Interesting. It did not occur to me to me that playing back the same .ts recording several times in a row could yield different results. I have not tried that yet, but I’m now wondering whether that would also be the case for the built-in DVB subtitling support in Enigma 2. It should be tested at the earliest opportunity. (That would have to be done by someone else, though, as I don’t have a physical access to the DM 7025 for the next two weeks or so.)


    If someone would like to give it a try, the above-mentioned web site of mine contains an ideal test clip (243 MB) for this purpose: a 10-minute .ts capture of a German police detective show with Finnish DVB subtitles. One just needs to select the Finnish DVB subtitles from the subtitle menu at the beginning of the playback. An analog video capture device would be useful as that allows capturing the test runs and running an easy side-by-side comparison. AviSynth will come handy as well – that’s what I used for creating the original three-panel montage clip.


    Actually, I could post the AviSynth script which I originally used for combining the captures on a single screen:



    • • •


    Zitat

    Please let me know if I can help you trace this in any way.


    I would like to take this opportunity to thank you for your work on the 2SUB plugin – it’s much appreciated on this side of the Gulf.


    The following can mostly be ignored as far as Enigma 2 and its built-in DVB subtitling support is concerned, but for your information, some bug reports about the 2SUB plugin as well:

    • For some reason or the other, 2SUB 2.06 – when used with an official Enigma 2 v2.2 image – does not seem to erase the previous DVB subtitle panel at all. Instead, it leaves it hanging on the screen until a new panel comes along. (If there are silent passages in a tv show, the previous text panel will be stuck on the screen indefinitely until something is said and a new panel replaces it.)


    • Another weird thing is that Teletext subtitles work fine with live broadcasts, but 2SUB cannot seem to pick them up from recordings (again, with a standard Enigma 2 v2.2.) Is this a known issue?

    I have created two sample video clips which illustrate various problems in Enigma2’s current DVB subtitling implementation. Both video clips, and the actual ’bug report’ (which is actually supplied in the form of a colorful timecode table at the bottom of that page) are available here:

    The following picture is a sample frame from a montage video clip featured on that page. It compares the DVB subtitle rendering support in Enigma2 to some other sources. (Disregard that you may not know the language used in the subtitles and you may already spot one of the typical glitches that occur quite constantly in DVB subtitles rendered by Enigma2.)


    Zitat

    Originally posted by Rodajo
    I tried to share the connection through the windows ICS but its not working.


    Do you have two network interface cards on your Windows PC?

    Zitat

    Originally posted by Brave
    Mal ne blöde Frage zum Video-Modus. Warum muss ich im Video-Modus, um diesen zu verlassen die Stop- oder TV-Taste drücken und nicht EXIT ???


    Gibt es dafür nen speziellen Grund dafür, dass dies nicht so konfiguriert ist ??? Bei allen anderen Menüs oder Plugins (MediaPlayer, PicturePlayer, usw.) gehts mit EXIT raus, nur im hier nicht.


    I think this is a usability problem, too. By all means, keep the STOP and TV buttons as they currently are, but make the EXIT button function in the same role as well – as a logical alternative to these other buttons.


    Another DM 7025 usability gripe of mine is that when playing back recordings, playback is not automatically paused when Enigma2 asks a confirmation about something – such as resuming or stopping. Instead, the video keeps running on the background all the time. It would be nicer if the playback paused for the time it takes to answer the question, so you don’t miss anything if you just accidentally happen to press the STOP (or EXIT) button.


    Last but not least, you can enter TuxTxt (the teletext viewer) by pressing the TEXT button, but you can’t come back to the normal TV viewing mode by pressing the TV button. Only EXIT works there. This is contrary to the logic used of all other tv remote control / teletext user interfaces I’ve ever used. (In a way, this is a reverse of the original complaint!)

    Zitat

    Originally posted by npumcrisz
    May be the first question is, does dvb-c work in USA.


    The digital cable system used in the US is related to DVB-C, but I don’t think it is quite the same. For example, the US documents always seem to mention only 64-QAM and 256-QAM as the two possible modulation parameters for cable tv transmissions, but the DVB-C standard specifies 16-QAM, 32-QAM, and 128-QAM as well.

    • The DVB-C standard is defined in ETSI EN 300 429 (“Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for cable systems”)
    • The US digital cable standard is defined in ANSI/SCTE 07 2006 (“Digital Transmission Standard For Cable Television”)

    Curiously, the Wikipedia page about the US system (see the first link in this message) mentions that it is “part of the DVB standard”. Go figure. This document might (or might not) explain the differences better:

    Also see the comments by “CityK” on this page. I’d say it’s all clear as mud, but it is probably sufficiently safe to say that the US cable standard(s) is(/are) not compatible with DVB-C.


    • • •


    The question then becomes would it be possible to support the US cable standards on the DM 7025 hardware, given a compatible tuner module?


    Theoretically speaking, yes, but the contents of the transmitted MPEG-2 transport stream metadata (service lists, etc.) are likely to be in a different format. Hence, the underlying logic related to tuning, parsing service lists, EPG, closed captions, etc. in Enigma2 would need to be rewritten from scratch for the US system. Not impossible, but a non-trivial amount of work.


    The beaty of the DVB standards – as used in Europe and other parts of the world – lies in that the transport stream remains, logically speaking, pretty much identical regardless of whether you receive it from cable (DVB-C), antenna (DVB-T), or satellite (DVB-S). This common base between all DVB transmission methods is what allows the current modularity of the DM 7025. Once you add in support for a completely different system, or require a single device to support two different digital tv transmission standards at the same time – as would be the requirement for the DM 7025 – the implementation details get more hairy.

    Zitat

    Originally posted by vale
    other possibility is, if you have two network interfaces on your pc. you can make a "bridge" and use your pc internet connection for the dreambox. for the provider it appears as only your pc beeing online.


    Bridging wouldn’t really work for point-to-point connections, such as PPPoE, but a one-to-many NAT (NAPT) would.


    If the PPPoE connection is established from a Windows computer, one can use the built-in Internet Connection Sharing capability for sharing the connection to the rest of the home network. This requires two network adapters on the Windows computer: one for the Internet connection and another for the local network. (Internet Connection Sharing, or “ICS” for short, is basically a Microsoft term for NAPT + DHCP server.)


    If the PPPoE connection is established from a Linux computer, the built-in netfilter/iptables firewall provides the same capability. Because the exact same thing must have a different name on each system, on Linux, NAPT is commonly called “IP masquerading”, in order to confuse beginners. Again, two network interface cards are needed (or at least recommended, or configuration goes a bit hairy.)


    Zitat

    or buy a router. providers normaly don't check what is behind a router and the router still just shows one ip-adress ...


    Exactly. Many (all?) broadband routers provide a built-in PPPoE client, and NAPT + DHCP functionality as well. Sharing the PPPoE-based Internet connection using a broadband router is probably the best option, and as an added bonus, the OP doesn’t need to keep his computer running in order to access the network from the Dreambox.


    • • •


    The OP didn’t specify how his current “Internet PPPoE” connection works, exactly. Is the connection ADSL-based? Fiber? Cable modem? Old-fashioned POTS modem? ISDN? HomePNA? Or does he simply have an Ethernet (“RJ-45”) wall jack in his apartment, the other end of the cable going... somewhere?


    What kind of equipment does he use for connecting to the Internet now? For example, does he have an ADSL modem or a cable modem? Or an ADSL card inside the computer? Or a USB-based ADSL modem? More information should be provided for getting better answers.

    Another test capture of the whole mux is available here (392 MB) – just in case.


    For completeness sake, here’s the corresponding lamedb file as well, for easy reference to the available services. If we’re looking things from the perspective of that file, the captures have been taken from mux (“transponder”) eeee0000:1001:20f6.


    This and the previous full transport stream capture might come handy for testing DVB subtitling and multilanguage EPG support as well, so interested parties would be advised to grab the files while they’re still there. (The built-in DVB subtitling support Enigma2 v2.2 has appeared to still have some rough spots, and I’m probably going to write more about that subject later, in another thread.)

    Zitat

    Originally posted by tmbinc
    How did you create the unfiltered capture? With the DM7025 and pid 0x2000? Or with another device?


    With a budget DVB-T card (on a Linux PC) and the dvbstream utility, like this:


    dvbstream -o 8192 > stream.ts


    (As the manpage for dvbstream says, “8192 is a "dummy PID" (legal PIDS are in the range 0-8191) and the driver interprets this to mean the entire TS.”)


    Zitat

    Can you upload some PID=0x81 packets somewhere?


    Here’s a 5-minute capture of YLE’s entire multiplex:

    Of course, if you only want to see a couple of those PCR packets, you don’t need to download the entire file. I think a couple of megabytes from the beginning should be enough for that purpose.


    Note that each service on that stream seems to have a separate PCR stream. For example, YLE TV1 uses a PCR PID of 0x80 whereas YLE TV2 uses 0x81.


    Also note that this capture might have some problems with signal quality – I made it yesterday, remotely on a far away machine, and could not check the aerial connections and such. I might be able to make a better capture later this evening, if needed.

    (This bug report is a followup to a recent discussion on the Enigma 2 Developer forum.)


    Short description:


    Enigma 2 appears to erroneously filter out the PCR (Program Clock Reference) when recording or streaming certain tv channels. This happens if the PCR is broadcast as a separate stream, with its own PID, and not as a part of the ordinary audio, video, DVB subtitle, or teletext streams.


    The missing PCR causes problems in many (but not all) video players when the recorded file is later played back. One of the players that cannot handle PCR-less files well is VLC. On VLC, such files have a silent audio, the playback is skipping erratically, and seeking on the timeline does not work properly. This affects streaming, too: live streams received from the DM 7025 using VLC do not have sound on certain tv channels.


    Technical details:

    In an earlier discussion, I posted a sample .ts file (80 MB) which was originally recorded with the DM 7025, and which exhibits all the previously-mentioned problems in VLC. When this file is analyzed in a suitable program, such as Ethereal MPEG-2 TS Dissector, one can see that the broadcaster periodically advertises a PCR_PID of 0x81 in the Program Map Table. (For instance, see this summary of the packet number 140.)


    However, the stream recorded by the DM 7025 does not have any packets with that PID! The DM 7025 (Enigma 2? Some lower-level component?) has filtered them out. Apparently, the PCR_PID field of the PMT is not checked at all when recording or streaming. Instead, the current versions of Enigma 2 assume that the PCR is part of some of the audio, video, teletext, or DVB subtitle streams, which will get recorded, anyway. (This is the case for some tv channels and broadcasters, but not for all of them.)


    • • •


    To test my theory further, I made a raw, unfiltered .ts capture containing everything that is being sent within the whole multiplex. And lo and behold, the separate PCR stream (with a PID of 0x81, in this case) was there. The DM 7025 just leaves it out of the recorded file.


    Now, could this be fixed? It happens to affect all the channels broadcast by the Finnish national broadcaster, YLE, so it is a pretty annoying thing (in Finland, at least. :smiling_face: If needed, I can provide short, unfiltered .ts captures of the whole multiplex for testing.


    P.S. Enigma 1 does not have this problem – at least not on the DM 500.

    Zitat

    Originally posted by tmbinc
    I've added my comment to the bug entry, though i don't have a clue what's wrong.


    Thanks for your effort, anyway. I was kind of hoping it would be something obvious and relatively simple to pin-point, but it now appears it isn’t. :frowning_face: I wonder where we could get some kind of MPEG specialist to take a hard look into the deep bowels that sample file and determine where the fault lies, exactly.


    I think I’m going to do as I already suggested above and record a raw sample clip of the whole multiplex, too. Perhaps it would offer some further clues to solving this puzzle.

    A sample file that demonstrates the problem (80 MB) is now available for download (for the time being, at least.) It was originally recorded with Enigma2 v2.2 but then truncated to 80 MB with dd since the original recording was over 600 MB in size.


    As you can see yourself by downloading the file, it plays fine on Enigma2 itself, but acts weird in VLC and some other players. (Media Player Classic seems to play it back well, though.) This also affects streaming – if I’m streaming live tv from the DM 7025 to VLC, the stream is missing audio as well.


    My skills at analyzing MPEG-2 transport streams and their technical validity are limited, so I cannot confirm whether the comment about “missing PTS” on the VLC bugtrack discussion holds true or not. But I would like to get to the bottom of this problem, so if any better-informed person can take a look at the sample stream and identify what exactly is wrong with it, please do so.


    If desired, I could also provide full, raw dumps of the entire multiplex. (Can this be done with the DM 7025 hardware itself, btw? Does it allow direct unfiltered access to the raw DVB stream?)

    Some .ts files recorded with the DM 7025 seem to exhibit strange problems when played back in VLC (0.8.6a):

    • The audio track is present, but silent.
    • The video periodically breaks up in blocks and automatically skips forward – several minutes at a time.
    • The seek bar (at the bottom of the VLC window) works erratically.

    At first, I suspected this was a problem with VLC itself, since Media Player Classic (and the DM 7025) seemed to play back the same files fine. However, the VLC folks now claim that the problem is caused by missing PTS information in the audio stream, and that it is either the broadcaster’s fault, or possibly a bug in DM 7025 (Enigma 2).


    • • •


    The curious thing about this problem is that it consistently only occurs on certain multiplexes and channels – not all of them. Nonetheless, only the DM 7025 seems to be affected. Other DVR-type devices (or recordings made with ordinary DVB cards from the same source) do not seem to suffer from this problem.


    In my case, the problem is present on local DVB-T channels broadcast by YLE – the Finnish equivalent of BBC. If you take a look at the above-mentioned VLC bug report, the original poster seems to have the same problem with some Polish DVB-S channels. I have also seen reports from my fellow countrymen who seem to have the same problem with their DM 7025s, YLE’s channels, and VLC, so it’s not just me.


    • • •


    Would someone of the developers please take a closer look at this problem and see if the VLC folks are right? (I can provide sample .ts files on request; just e-mail me and ask.) It would also help if people who have seen this problem themselves would post information about the channels on which it occurs, and where they get those channels from.