ISDB-T Support on VLC 2.0/2.1

[hobbes_ba]

Hi everyone.

I'm already using a 1.3 build of VLC and since 1.2 builds my ISDB-T USB dongle stop working.

Nothing really seems to happen.

It used to work on VLC 1.1 but not without some hiccups.

I posted a very short screencast (no sound) on how we used to make things work.

The channel.conf file that I drag into VLC contains the TV frequencies of my region.

http://youtu.be/0sO6aFntrLw

I also would like to offer my help to test anything the devs may need to proper support ISDB-T on VLC.

Thanks!

[Rémi Denis-Courmont]

VLC 1.1 did not support ISDB-T. If it worked, I guess your device driver pretended to provide DVB-T.

VLC 1.2 ISDB-T support is entirely based on guess work and likely broken. We have no way to make it work in Europe since there are no ISDB broadcasts.

[hobbes_ba]

VLC 1.1 did not support ISDB-T. If it worked, I guess your device driver pretended to provide DVB-T.

VLC 1.2 ISDB-T support is entirely based on guess work and likely broken. We have no way to make it work in Europe since there are no ISDB broadcasts.

Thanks for answering Rémi.

It was a post on your website that brought me here in the first place.

Isn't there a developer who happens to live in a ISDB-T country? (i.e. Japan, Brazil, Argentina..pretty much the whole South America)

Please if *you* by chance reading this message have some programming skills or possess any technical information about ISDB-T, drop a post on this thread or contact the devs.

I guess people on this countries are still running VLC 1.1 or there is a workaround that I'm currently unaware of.

just to reinforce it: unfortunately I'm not a programmer. But nonetheless I still can help. As a live in Brazil if any of the devs wants to 'keep guessing' on how to properly support ISDB-T on VLC 1.3 and on feel free to ask me to try it out!

I'm also betting that as soon as VLC 1.2 is released more people will search for a solution for the problem I'm already having and probably more technical information will come out.

Thanks for reading

[Rémi Denis-Courmont]

I am not sure ISDB-T receiver really work in Japan. Are every terrestrial broadcasts not encrypted there? Then that is down to South America, and there are no VLC developers in that (sub)continent.

Can you paste the channels.conf anyway?

[nkoriyama]

Especially in Japan, I think ISDB-T tuner support is a little hard. Because of driver, protection(encryption), supported hardware ...
I personally started to add a feature to show digital closed caption (ARIB STD-B24) from recorded stream (MPEG-TS).

[hobbes_ba]

I am not sure ISDB-T receiver really work in Japan. Are every terrestrial broadcasts not encrypted there? Then that is down to South America, and there are no VLC developers in that (sub)continent.

Can you paste the channels.conf anyway?

Sure.

I'll do better.

My USB dongle:

Code: Select all

[ 15.509397] dvb-usb: found a 'DiBcom STK8096GP reference design' in warm state. [ 15.521144] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 16.086194] dvb-usb: schedule remote query interval to 50 msecs. [ 16.086200] dvb-usb: DiBcom STK8096GP reference design successfully initialized and connected. [ 16.086372] usbcore: registered new interface driver dvb_usb_dib0700

First the ISDB Frequency table:

ISDB-T Frequency Table

Code: Select all

# ISDB-T channel frequencies as defined in Brazil # By ABNT NBR 15608-1 # VHF channels 7 to 13 are also specified but not in usage yet # # UHF channels 14 to 69 T 473142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 14 T 479142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 15 T 485142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 16 T 491142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 17 T 497142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 18 T 503142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 19 T 509142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 20 T 515142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 21 T 521142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 22 T 527142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 23 T 533142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 24 T 539142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 25 T 545142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 26 T 551142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 27 T 557142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 28 T 563142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 29 T 569142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 30 T 575142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 31 T 581142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 32 T 587142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 33 T 593142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 34 T 599142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 35 T 605142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 36 # channel 37 not used T 617142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 38 T 623142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 39 T 629142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 40 T 635142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 41 T 641142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 42 T 647142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 43 T 653142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 44 T 659142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 45 T 665142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 46 T 671142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 47 T 677142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 48 T 683142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 49 T 689142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 50 T 695142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 51 T 701142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 52 T 707142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 53 T 713142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 54 T 719142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 55 T 725142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 56 T 731142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 57 T 737142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 58 T 743142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 59 T 749142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 60 T 755142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 61 T 761142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 62 T 767142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 63 T 773142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 64 T 779142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 65 T 785142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 66 T 791142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 67 T 797142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 68 T 803142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE # channel 69

http://www.linuxtv.org/wiki/index.php/I ... ency_Table

Using the scan software against this frequency table I obtained my channels.conf

Code: Select all

$scan ch.conf > channels.conf

Channels.conf

Code: Select all

RECORD BAHIA 1SEG:515142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:0:0:9464 RECORD BAHIA HD:515142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:0:0:9440 TV ARATU DIGITAL:539142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:4097:4099:9472 TV ARATU DIGITAL:539142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:4113:4115:9496 TVBA HDTV:563142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:273:274:9536 TVBA MOBILE:563142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:529:530:9560 Rede Vida 1Seg:647142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:500:510:60376 Rede Vida HD:647142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:501:511:60352 BAND BA:665142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:529:530:9529 BAND BAHIA HD:665142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:273:274:9504

[hobbes_ba]

The "Brazilian & South/Central American ISDB-T" is slightly different from the Japanese. Offcially it is called ISDB-Tb.

I.e: It uses MPEG-4 instead of MPEG-2.

Here you can read more about it: http://en.wikipedia.org/wiki/SBTVD

[Rémi Denis-Courmont]

According to this viewtopic.php?f=13&t=99397 thread, ISDB-Tb works, but you need VLC 2.0 and a recent kernel.

[hobbes_ba]

Sorry, I only now realized that I made a typo. I meant to say VLC 2.0 / 2.1.

That being said.

First, thanks for the tip.

I updated my kernel to the latest released mainline kernel on Ubuntu (3.3.0-030300rc7-generic) and it worked.

Well, sort of. On this machine which isn't exactly new I do 1080p movies without a hiccup. But, somehow it can't do the same with ISDB-Tb streams. I got freezes.

I noticed that on the output:

[0x7f415c00db98] dtv access error: obsolete user API version running on a new kernel
[0x7f415c00db98] dtv access: please recompile vlc 2.1.0-git

I'm running a build from the Master Daily PPA (Ubuntu).

I'll keep trying out the new builds as they come.

Hope that shed some light on that performance issue.

Thanks for reading.

[Rémi Denis-Courmont]

It seems you're running a kernel (>= 3.3) that's more recent than the kernel headers (<= 3.2) that VLC was compiled with. This should not affect performance though.

[crotalus]

I am running vlc 2.0.1 in a quadcore Q9600 with an nvidia GT 240 card (plus the proprietary driver 295.20), and I have no issue with the performance
with ISDB-TB. I have vdpau-video installed, so vlc can use the hardware acceleration, but even turnning it off, I still have no issue.
I also leave the deinterlace mode in auto, because the signal is 1080i, and everything is smooth (cpu usage less than 60% most of the time).

However, watching avi videos (xvid, mp4, etc...) with the hardware acceleration on, the video stutters, and I have to I turn it off, so everything is back to normal. Unfortunately, vdpau-video has not been updated for a long time (http://www.splitted-desktop.com/static/ ... pau-video/)
and it really amazes me it still working for decoding my TV video signal. Noneteheless, this is an ffmpeg issue, I guess (I use version 0.10.2).
With the hardware acceleration on, I get a series of

[mpeg4 @ 0x7f68c4c2b5e0] marker does not match f_code
[mpeg4 @ 0x7f68c4c2b5e0] marker does not match f_code

messages on the console, when playing videos.

Anyway, if you use hardware acceleration, it is a godd idea to try without it ...

[hobbes_ba]

I am running vlc 2.0.1 in a quadcore Q9600 with an nvidia GT 240 card (plus the proprietary driver 295.20), and I have no issue with the performance
with ISDB-TB. I have vdpau-video installed, so vlc can use the hardware acceleration, but even turnning it off, I still have no issue.
I also leave the deinterlace mode in auto, because the signal is 1080i, and everything is smooth (cpu usage less than 60% most of the time).

However, watching avi videos (xvid, mp4, etc...) with the hardware acceleration on, the video stutters, and I have to I turn it off, so everything is back to normal. Unfortunately, vdpau-video has not been updated for a long time (http://www.splitted-desktop.com/static/ ... pau-video/)
and it really amazes me it still working for decoding my TV video signal. Noneteheless, this is an ffmpeg issue, I guess (I use version 0.10.2).
With the hardware acceleration on, I get a series of

[mpeg4 @ 0x7f68c4c2b5e0] marker does not match f_code
[mpeg4 @ 0x7f68c4c2b5e0] marker does not match f_code

messages on the console, when playing videos.

Anyway, if you use hardware acceleration, it is a godd idea to try without it ...

It seems you're running a kernel that's more recen than the kernel headers that VLC was compiled with. This should not affect performance though.

So it is probably a decoding performance issue. Because, just like I said, it can play 1080p without problems.

I have a Pentium D 2.80 GHz with a X1600 pro. Unfortunately It doesn't have video hardware acceleration (yet) ( I use the radeon opensource driver)

It not exactly new. But even without hardware acceleration, believe me: it can deliver Full HD movies smoothly. (MKV, MP4 files ..) and AFAIK 1080p should be harder to decode than 1080i.

Thanks.

[hobbes_ba]

i've noticed a pattern. At the moment the ISDB-Tb stream playback starts to freeze, this output occur:

[h264 @ 0x7fd5e40fd820] mmco: unref short failure
[h264 @ 0x7fd5e4153420] mmco: unref short failure
[h264 @ 0x7fd5e4153420] mmco: unref short failure
[h264 @ 0x7fd5e4019620] mmco: unref short failure
[h264 @ 0x7fd5e4019620] mmco: unref short failure

I hope that shed some light.

Thanks for reading.

[Jean-Baptiste Kempf]

This is a decoding problem.

[hobbes_ba]

Another pattern. VLC continuous to play, actually trying to play until it hangs. (It becomes unresponsive, the only option is to kiil it manually.)

Here is the output:

libdvbpsi error (misc PSI): Bad CRC_32 (0xcbdde0c1) !!!
libdvbpsi error (misc PSI): Bad CRC_32 (0xd8125783) !!!
libdvbpsi error (misc PSI): Bad CRC_32 (0x8663899a) !!!
libdvbpsi error (misc PSI): Bad CRC_32 (0x6e12c9e4) !!!
libdvbpsi error (misc PSI): Bad CRC_32 (0x7d656bff) !!!

Thanks for reading.

[Rémi Denis-Courmont]

Looks like corrupt input, possibly due to bad SNR.

[hobbes_ba]

Looks like corrupt input, possibly due to bad SNR.

Do you mean a weak signal?

Because here I'm using the antenna of my building.

I've updated my kernel to the very latest 3.4-RC1, my Xorg to experimental and the performance improved a bit. (VLC 2.1.0-git from the vlc-master ppa)

I mean, am still not able to watch it in full seg. The difference now is that it takes more time to freeze the image.

This is a performance issue.

Like I said before, my rig isn't exactly new, but it does play 1080p (even at 1:85:1)

One thing.. that is strange to me, at one particular channel, the performance is even better, it doesn't freeze. It is almost watchable (if you don't mind the skipped frames)

[Rémi Denis-Courmont]

Broken CRC is not a performance issue. Broken CRC is a broken signal.