VLC Build 0.8.5-test4 Won't play .ts files from BBC HD Trial

[pinnocchio]

The BBC HD Trial started transmitting in London, UK yesterday 8th May 2006.

The trial is using H.264 encoding in what appears to be an intra4x4 mode.

View Messages shows that VLC correctly detects the video PID to be 1502

ts debug: pid[1502] unknown
ts debug: pid[1505] unknown
ts debug: pid[600] unknown
ts debug: PATCallBack called
ts debug: new PAT ts_id=36868 version=16 current_next=1
ts debug: * number=0 pid=16
ts debug: * number=36932 pid=600
ts debug: PMTCallBack called
ts debug: new PMT program number=36932 version=7 pid_pcr=1502
ts debug: * es pid=1502 type=27 fcc=h264
main debug: selecting program id=36932
main debug: looking for decoder module: 27 candidates
ffmpeg debug: libavcodec already initialized
ffmpeg debug: postprocessing disabled
ffmpeg debug: ffmpeg codec (h264) started
main debug: using decoder module "ffmpeg"
main debug: looking for packetizer module: 17 candidates
main debug: using packetizer module "packetizer_h264"
main debug: thread 4504 (decoder) created at priority 0 (input/decoder.c:159)

and then goes on to identify the audio pid 1505 correctly as AC3

main debug: thread 4504 (decoder) created at priority 0 (input/decoder.c:159)
ts debug: * es pid=1505 type=6 dr->i_tag=0xa
ts debug: * es pid=1505 type=6 dr->i_tag=0x6a
ts debug: * es pid=1505 type=6 dr->i_tag=0x52
ts debug: * Stream Component Identifier: 8
ts debug: * es pid=1505 type=6 fcc=a52
main debug: looking for decoder module: 27 candidates
main debug: using decoder module "a52"
main debug: thread 4520 (decoder) created at priority 2 (input/decoder.c:159)
ts warning: first packet for pid=1502 cc=0x7
ts warning: first packet for pid=1505 cc=0x2
a52: A/52 channels:6 samplerate:48000 bitrate:384000
main debug: looking for audio output module: 3 candidates
waveout debug: channel reordering needed
waveout debug: device supports 5.1 channels
waveout debug: device supports 4 channels
waveout debug: device supports 2 channels
waveout debug: device supports 1 channel
waveout debug: device supports A/52 over S/PDIF
waveout debug: channel reordering needed
main debug: thread 4428 (waveOut Notification Thread) created at priority 15 (waveout.c:343)
main debug: using audio output module "waveout"
main debug: output 'fl32' 48000 Hz 3F2R/LFE frame=1 samples/24 bytes
main debug: mixer 'fl32' 48000 Hz 3F2R/LFE frame=1 samples/24 bytes
main debug: no need for any filter
main debug: looking for audio mixer module: 3 candidates
main debug: using audio mixer module "trivial_mixer"
main debug: input 'a52 ' 48000 Hz 3F2R/LFE frame=1536 samples/1536 bytes
main debug: filter(s) 'a52 '->'fl32' 48000 Hz->48000 Hz 3F2R/LFE->3F2R/LFE
main debug: looking for audio filter module: 23 candidates
main debug: using audio filter module "a52tofloat32"
main debug: found a filter for the whole conversion
main debug: filter(s) 'fl32'->'fl32' 52800 Hz->48000 Hz 3F2R/LFE->3F2R/LFE
main debug: looking for audio filter module: 23 candidates
main debug: using audio filter module "bandlimited_resampler"
main debug: found a filter for the whole conversion

However Video will not play correctly and crashes VLC with the following errors in the messages log

ffmpeg warning: top block unavailable for requested intra4x4 mode -1 at 1 0
(h264@00AD2BF0)
ffmpeg warning: error while decoding MB 1 0
(h264@00AD2BF0)
ffmpeg warning: top block unavailable for requested intra4x4 mode -1 at 1 12
(h264@00AD2BF0)
ffmpeg warning: error while decoding MB 1 12
(h264@00AD2BF0)
ffmpeg warning: top block unavailable for requested intra4x4 mode -1 at 1 24
(h264@00AD2BF0)
ffmpeg warning: error while decoding MB 1 24
(h264@00AD2BF0)
ffmpeg warning: top block unavailable for requested intra4x4 mode -1 at 1 36
(h264@00AD2BF0)
ffmpeg warning: error while decoding MB 1 36
(h264@00AD2BF0)
ffmpeg warning: top block unavailable for requested intra mode at 1 48
(h264@00AD2BF0)
ffmpeg warning: error while decoding MB 1 48
(h264@00AD2BF0)
ffmpeg warning: top block unavailable for requested intra4x4 mode -1 at 1 60
(h264@00AD2BF0)
ffmpeg warning: error while decoding MB 1 60
(h264@00AD2BF0)
ffmpeg warning: illegal short term buffer state detected
(h264@00AD2BF0)
ffmpeg debug: concealing 6120 DC, 6120 AC, 6120 MV errors
(h264@00AD2BF0)


A sample of the original .ts is available here

http://www.fordrs.nildram.co.uk/BBCHD1-DigiTV-2.ts

Please note the pid numbers are different in this sample.

Having looked at the H264.c code I think there's a TODO section in the code that may apply to the particular encoding technique being used by the BBC but my coding skills are not up to debugging this.

Can anyone help?

TIA

P

[pinnocchio]

Update....

Apparently this is due to MBAFF not being incorporated into the H264.c code properly (having looked through the source there are loads of 'FIX ME' comments).

Is there any chance this could be progressed to a bug fix/feature request with high priority possibly?

TIA

P

[DJ]

You Know that long nose always got you into trouble and kept you from becoming a real Boy!

H.264 is still in a state of flux and about the only compatible systems are Ateme, Nero, x.264 (VLC's h.264), QuickTime, ffdshow, CoreAVC and I think ffmpeg. Most of the compatibility exists around the main profile and if you leave that you are on your own. If the BBC wants to forge forward then it must also supply a standard decoder. But these are tests and there is nothing to say that the tests will or won't succeed or that the files made today will play tomorrow without an updated decoder.

Perhaps one of the developers will make some comments here.

[pinnocchio]

Hi DJ

I'm aware that MBAFF isn't part of the baseline profile but it is defined as part of the extended profile and indeed H264.C includes code to cope with MBAFF. However the code looks incomplete for example (from H264.C)...

03560 // TODO deblock a pair
03561 // top
03562 s->mb_y--;
03563 tprintf("call mbaff filter_mb mb_x:%d mb_y:%d pair_dest_y = %p, dest_y = %p\n", mb_x, mb_y, pair_dest_y, dest_y);
03564 fill_caches(h, mb_type_top, 1); //FIXME don't fill stuff which isn't used by filter_mb
03565 filter_mb(h, mb_x, mb_y, pair_dest_y, pair_dest_cb, pair_dest_cr, linesize, uvlinesize);
03566 if (tmp != s->current_picture.data[1][384]) {
03567 tprintf("modified pixel 8,1 (1)\n");
03568 }
03569 // bottom

There are other examples like this through the code, the things to note are the TODO and FIXME comments.

The likelyhood is that the BBC Trial (which will run for a year) will continue to use MBAFF and indeed it will be implemented for the Live Service. None of the other H264 codecs out there at the moment support MBAFF either. This would be a perfect opportunity for the VLC team to get a leap on the commercial players as the Trial alone will be available to about 10m people via DVB-T, as well as the DVB-S transmission which will be available across Europe from the Astra Satellite. It's likely during the trial that major sporting events and other programming will be available FTA and it would be great if we could continue to use VLC to watch this programming.

TIA

P

[DJ]

I don't think you really have any argument from me! With 24 satellites in space by the end of next year with 24 stations per transponder H.264 is poised to be a great system when it is finalized. I think streaming, features and container type are still kind of up in the air (no pun intended) beside the standard itself. Probably the biggest argument is going to be by the professionals over retooling costs versus add ons for the MPEG container. From this stand point everyone is wondering about the HD DVD versus the Blue Ray. Do I need to retool twice? Does this make Main Concepts the early leader? Then what does the consumer really want from this new technology. Most couch potatoes would want a remote with PVR like features in real time. Any early adopters surely would have the jump on the rest as the first hurtle is finishing h.264 so that it streams well and maintains the quality, resolution, reliability and offers some wonderful features in the container. We all have great expectations for it. I still haven't seen any AAC S/PDIF answers and it seems to me this should be easier than finishing h.264

I would like to see VLC support the Matroska container for transcode functions so that we would have the opportunity to play with this using h.264 in streams. Although this may not prove be a good streaming solution. To me right now MPEG-TS is rather logical and PS for the optical disk, but you must realize that that statement does make Main Concepts theories appear correct.

[Guest]

H.264 is still in a state of flux and about the only compatible systems are Ateme, Nero, x.264 (VLC's h.264), QuickTime, ffdshow, CoreAVC and I think ffmpeg.

The likelyhood is that the BBC Trial (which will run for a year) will continue to use MBAFF and indeed it will be implemented for the Live Service. None of the other H264 codecs out there at the moment support MBAFF either.

AFAIK the MainConcept / Elecard and Cyberlink decoders are the only ones that support MBAFF today, but CoreAVC should add support for it next week.

I didn’t think QuickTime supported MBAFF at all? BTW, aren’t the Ahead/Nero and Ateme decoders one and the same? Come to think of it aren’t the MainConcept / Elecard and Intervideo / VideoSoft H.264 decoders just clones as well? Please correct we if I'm wrong guys, I'm just wondering if I’ve missed something???

Actually, hold on …dons asbestos flame suit… but aren’t VLC / x264 / FFDshow / FFMpeg all based on the same H.264 code??? What about Xine and Mplayer? They all seem to display the same problems with MBAFF decoding?

To me right now MPEG-TS is rather logical and PS for the optical disk, but you must realize that that statement does make Main Concepts theories appear correct.

I know the current container / demux situation is giving a lot of directshow developers a head ache. The MainConcept filters don’t seem to be half as stroppy about the mediatype IDs as the rest though so whatever theories they are working to it is helping, in the short term at least…

This would be a perfect opportunity for the VLC team to get a leap on the commercial players … it would be great if we could continue to use VLC to watch this programming.

Amen to that! I’m sure hundreds of others feel the same, we live in hope…

[DJ]

AFAIK the MainConcept / Elecard and Cyberlink decoders are the only ones that support MBAFF today, but CoreAVC should add support for it next week.

I haven't followed this since Feb or Mar 06. I have heard bits and pieces here and there, But nothing is working yet and compatibility here is the main issue. Main Concepts and Elcard do not seem to have compatibility with each other or with the VideoLAN x.264 and Ateme.

I didn't think QuickTime supported MBAFF at all? BTW, aren’t the Ahead/Nero and Ateme decoders one and the same? Come to think of it aren’t the MainConcept / Elecard and Intervideo / VideoSoft H.264 decoders just clones as well? Please correct we if I'm wrong guys, I'm just wondering if I’ve missed something???

Actually, hold on …dons asbestos flame suit… but aren’t VLC / x264 / FFDshow / FFMpeg all based on the same H.264 code??? What about Xine and Mplayer? They all seem to display the same problems with MBAFF decoding?

Yes! The source appears to be the same on both counts, but individually not collectively. IE Nero, QuickTime and Ateme are the same source Ateme and Mplayer, ffmpeg and VLC are the VideoLAN teem, except CoreAVC (I think). But they don't have an encoder yet. I haven't seen a working decoder from Interlink. They are advertising it!

I know the current container / demux situation is giving a lot of directshow developers a head ache. The MainConcept filters don’t seem to be half as stroppy about the mediatype IDs as the rest though so whatever theories they are working to it is helping, in the short term at least…

This is why I brought it up! Hopping that someone would start thinking about it. Rather than people like CoreAVC that don't seem to care or at least at the moment.

This would be a perfect opportunity for the VLC team to get a leap on the commercial players … it would be great if we could continue to use VLC to watch this programming.

Amen to that! I’m sure hundreds of others feel the same, we live in hope…

[Guest]

Either DJ had a heart attack whist replying to the last part of the message OR his silence indicates that he agrees with us whole-heartedly and will have MBAFF support finished by the morning....

Pinnocchio have you tried getting GPU aceleration working with the Cyberlink AVC decoder yet? BTW, I'm Nick [D]vB from the DS forum, in case you hadn't guessed...

[pinnocchio]

I'd guessed from your layout style Nick

[pinnocchio]

any chance of getting a developer to look at this pls?

P

[pinnocchio]

bump

[Guest]

I don't think you really have any argument from me! With 24 satellites in space by the end of next year with 24 stations per transponder H.264 is poised to be a great system when it is finalized. I think streaming, features and container type are still kind of up in the air (no pun intended) beside the standard itself. Probably the biggest argument is going to be by the professionals over retooling costs versus add ons for the MPEG container. From this stand point everyone is wondering about the HD DVD versus the Blue Ray. Do I need to retool twice? Does this make Main Concepts the early leader? Then what does the consumer really want from this new technology. Most couch potatoes would want a remote with PVR like features in real time. Any early adopters surely would have the jump on the rest as the first hurtle is finishing h.264 so that it streams well and maintains the quality, resolution, reliability and offers some wonderful features in the container. We all have great expectations for it. I still haven't seen any AAC S/PDIF answers and it seems to me this should be easier than finishing h.264

I would like to see VLC support the Matroska container for transcode functions so that we would have the opportunity to play with this using h.264 in streams. Although this may not prove be a good streaming solution. To me right now MPEG-TS is rather logical and PS for the optical disk, but you must realize that that statement does make Main Concepts theories appear correct.

when you refer to BR and HDDVD i assume
your refering to the MS owned open standard VC-1 and the fact that they will be that standard on both.
http://forum.digital-digest.com/showthread.php?t=65336

its rather odd that there dont seem to be Mpeg4/AVC dvd around yet though, especially considering the UK/EU comitment
to Mpeg4/AVC broadcasting.

for the better compression/etc Mpeg4/AVC standard, then it looks like both the old school amiga 3rd party companays
Main Concept and NewTek especially are leading the way in both hardware and software for the industry
http://www.mainconcept.com/site/index.php?id=4202
http://www.pluginz.com/news/513
NAB 1006 looks good for both companys
http://www.mainconcept.com/site/
but you should check out NewTeks NAB 2006 stuff
http://www.newtek.com/shows/nab/2006/
really top class if your a pro im told.

[Guest]

its rather odd that there dont seem to be Mpeg4/AVC dvd around yet though, especially considering the UK/EU comitment
to Mpeg4/AVC broadcasting.

for the better compression/etc Mpeg4/AVC standard, then it looks like both the old school amiga 3rd party companays
Main Concept and NewTek especially are leading the way in both hardware and software for the industry
http://www.mainconcept.com/site/index.php?id=4202
http://www.pluginz.com/news/513
NAB 1006 looks good for both companys
http://www.mainconcept.com/site/
but you should check out NewTeks NAB 2006 stuff
http://www.newtek.com/shows/nab/2006/
really top class if your a pro im told.

i ment to point you to vc1 doom thread for the standards announcment bit this will do.
http://forum.doom9.org/showthread.php?
t=111275&highlight=vc-1+decoder

heres a new basic mencoder Gui for x264
http://forum.doom9.org/showthread.php?t ... -1+decoder

i wish the rebol/view coders reading would make some far better
GUI's one day though.

were this new AVCHD "Sony and Panasonic announced today that they have co-developed a new high definition DVD format created specifically for camcorders. The new format, dubbed AVCHD, captures video onto 8cm DVDs using the MPEG4 AVC/H.264 compression system." fits into the puzzle is anyones guess for a home/non pro markets i assume.
http://forum.doom9.org/showthread.php?p ... post826860

[Nick [D]vB]

Sorry to drag this thread back on topic, but...

A living legend by the name of Pengvado has just coded MBAFF support for libavcodec!!!

http://students.washington.edu/lorenm/s ... aff.0.diff

I assume you already know about this but if not can you get it patched into VLC [win32] as soon as humanly possible.

I know lots of people are looking forward to testing it.

Thanks,
Nick

[Nick [D]vB]

Doh!

Please ignore my last post, I didn't realise it would make it into the nightly build that fast!!!

But it seems VLC is not quite there yet, The BBC streams now play but freeze after a few seconds.

Interestingly some 4Mbps SD resolution H.264 streams [also using MBAFF] taken from the French DVB-T trail all play perfectly!

Lets hope it gets fixed soon...

Cheers,
Nick

[Guigs]

Nick,

Sorry, i'm a beginner
But, could you tell me how to apply the contents of that .diff file to vlc directory to fix this bug (MBAFF)

Thank you for your help, I need to watch Roland Garros in HD

Guillaume

[Nick [D]vB]

It must be applied to h264.c, there are some other patches here:

http://students.washington.edu/lorenm/src/x264/?M=D

but it is already complied into the VLC nightly builds,

versions from the 28th onwards should all work:

http://nightlies.videolan.org/build/win32/?C=M;O=D

Or use this special FreeHD version:

http://download.videolan.org/pub/testing/freehd/

[Guest]

Nick,

Thank you for your quick answer but I don't understand well

I dont' have any h264.c directory in vlc folder
I only have a .dll named libh264_plugin.dll
Do I have to create a h264.c file or folder ?
If Yes, Where ?

I can't dl the already complied into the VLC nightly builds

I already know this :

http://download.videolan.org/pub/testing/freehd/

that's why I was asking how to complied ffh264_mbaff.1.diff in VLC


Thank you again

Guillaume

[Guest]

These diffs are for sourcecode files only, not for binary files.

[BritKat]

Hi Guys,
I'm trying to use vlc to view the BBC trials "live". I'm not too great on using vlc with DVB-T capture cards. I've opened up the capture device but can't see how I determine the channel to view. Any and all help would be appreciated.

Mark

[hfdragon]

I'm trying to build myself a linux version of vlc with this patch (since there is no linux build).

I downloaded the ffmepg source from vlc site, but I don't know how to apply this patch... any help ?

[charafe]

Hi, I am trying to convert a .TS H264 (MBAFF) file encoded by ATEME AVC kompressor into AVI. The problem is that VLC can read it but cannot uncompress it into AVI format. Do you know to do this or have any suggestion?

Thank you,

[Guest]

Nick,

Sorry, i'm a beginner
But, could you tell me how to apply the contents of that .diff file to vlc directory to fix this bug (MBAFF)

Thank you for your help, I need to watch Roland Garros in HD

Guillaume

[Guest]

Hi, I am trying to convert a .TS H264 (MBAFF) file encoded by ATEME AVC kompressor into AVI. The problem is that VLC can read it but cannot uncompress it into AVI format. Do you know to do this or have any suggestion?

Thank you,

The AVI muxer in VLC is considered broken. Personally I don't believe it was ever finished. So you will need to use another compatible format and encapsulation method in VLC or another program if you must have AVI. Try: videohelp.com