1080i H264 Recordings - Random Corruption & Long load times

[sorrowuk]

These are HD 1080i ts recordings .

These never used to play and crashed after a few seconds until a fix was created here - https://github.com/raspberrypi/firmware ... t-10127642

Now the new raspberry pi firmware has this fix and these files play however I have 2 problems, which I don't know if they can be fixed ?

1. It takes a long time to load these files. Most of the time it takes 20-25 seconds on loading in xbmc before it starts playing. Non HD mpeg2 .ts files play within 5 seconds and 1080p mkv play in about 5 seconds.
Any reason why these files take so long to start playing?

2. The other problem is random video corruption/artifacts. Around every 1-2 minutes (its random) the video gets artifacts and loads of small squares appear for around a second then its fine again.
Any idea how this could be fixed.

[dom]

mkv files are indexed and you can read a small header to determine the duration, and a list of video/audio/subtitle tracks and properties.
program and transport streams (like .ts files) have no index. You can only determine what is in the file be reading and parsing packets. To find the duration you have to parse a timestamp packet, then seek to end and parse a timestamp packet. It will always be inefficient to identify what is in a ts file.

The "gray blocks" bug is in vdec3. We have an issue in our (Broadcom's) bug tracker and are wating for a fix.
(assuming your artifacts look like https://dl.dropbox.com/u/3669512/temp/gray_blocks.jpg)

[sorrowuk]

mkv files are indexed and you can read a small header to determine the duration, and a list of video/audio/subtitle tracks and properties.
program and transport streams (like .ts files) have no index. You can only determine what is in the file be reading and parsing packets. To find the duration you have to parse a timestamp packet, then seek to end and parse a timestamp packet. It will always be inefficient to identify what is in a ts file.

The "gray blocks" bug is in vdec3. We have an issue in our (Broadcom's) bug tracker and are wating for a fix.
(assuming your artifacts look like https://dl.dropbox.com/u/3669512/temp/gray_blocks.jpg)

Thanks for that explanation.

So the first point there's not much that can be done really, its just the way .ts files work. And because the limited processing power of the pi it takes longer than say a normal computer.

It does seem to be this gray blocks bug you mention. It only lasts about 0.5second so its hard to see exactly. It covers more of the screen than that picture though. Its the same thing that happens right at the start when you start playing a file.

Is there any estimated time on the fix for this ?

[dom]

Is there any estimated time on the fix for this ?

There is a potential fix posted on our bugtracker. It's not been through proper testing, but I've built it and it fixes my original "gray blocks" file, if you want to test it.

You need to be on the "next" firmware tree.
sudo rpi-update 788cddf57e1c9650f34b2cdea8c74410626805a9
will get you there.
sudo rpi-update 38511116574740386594d5a97d9e02e899c63090
will get you back to "master" tree.

Take a copy of your existing start.elf and fixup.dat. Rename this to start.elf and remove fixup.dat:
https://dl.dropbox.com/u/3669512/temp/start_gray.elf

[nickr]

mkv files are indexed and you can read a small header to determine the duration, and a list of video/audio/subtitle tracks and properties.
program and transport streams (like .ts files) have no index. You can only determine what is in the file be reading and parsing packets. To find the duration you have to parse a timestamp packet, then seek to end and parse a timestamp packet. It will always be inefficient to identify what is in a ts file.

The "gray blocks" bug is in vdec3. We have an issue in our (Broadcom's) bug tracker and are wating for a fix.
(assuming your artifacts look like https://dl.dropbox.com/u/3669512/temp/gray_blocks.jpg)

Thanks for that explanation.

So the first point there's not much that can be done really, its just the way .ts files work. And because the limited processing power of the pi it takes longer than say a normal computer.

It does seem to be this gray blocks bug you mention. It only lasts about 0.5second so its hard to see exactly. It covers more of the screen than that picture though. Its the same thing that happens right at the start when you start playing a file.

Is there any estimated time on the fix for this ?

You don't say whether the same files play well on xbmc on another computer. They may be glitches in the original recording, perhaps reception issues?

[sorrowuk]

You don't say whether the same files play well on xbmc on another computer. They may be glitches in the original recording, perhaps reception issues?

They do. Plus the files don't have the grey blocks glitches at the same point. If you rewind after its happened it then will play fine. Its just random and nothing to do with the actual recording or video file.

Will try that fix above dom, thanks for that and i'll let you know.

Not sure if it will work on raspbmc though, that's what I am using. They don't like you using rpi-update really

[dom]

You don't say whether the same files play well on xbmc on another computer. They may be glitches in the original recording, perhaps reception issues?

They do. Plus the files don't have the grey blocks glitches at the same point. If you rewind after its happened it then will play fine. Its just random and nothing to do with the actual recording or video file.

Will try that fix above dom, thanks for that and i'll let you know.

Not sure if it will work on raspbmc though, that's what I am using. They don't like you using rpi-update really

raspbmc is already on "next" firmware tree, so you may be able to just replace start.elf (and remove fixup.dat)

[sorrowuk]

You don't say whether the same files play well on xbmc on another computer. They may be glitches in the original recording, perhaps reception issues?

They do. Plus the files don't have the grey blocks glitches at the same point. If you rewind after its happened it then will play fine. Its just random and nothing to do with the actual recording or video file.

Will try that fix above dom, thanks for that and i'll let you know.

Not sure if it will work on raspbmc though, that's what I am using. They don't like you using rpi-update really

raspbmc is already on "next" firmware tree, so you may be able to just replace start.elf (and remove fixup.dat)

Cool, i'll try that and let you know if it fixes the problem.

Is there a command that can be typed in from terminal that tells you what firmware tree your on ?

[sorrowuk]

dom, just tried to use this on raspbmc and xbian but it didn't work. I tried just replacing the file first and removing fixup.dat then the raspberry pi wouldn't start so went back to original files.

Then tried running the rpi-update command you said. (sudo rpi-update 788cddf57e1c9650f34b2cdea8c74410626805a9)

And it comes up with

Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
Performing self-update
ARM/GPU split is now defined in /boot/config.txt using the gpu_mem option!
Downloading specific firmware revision (this will take a few minutes)
Using HardFP libraries
fatal: Not a git repository: '//root/.rpi-firmware/.git'

Any ideas?

[sorrowuk]

Managed to get it to install on the "next" firemware version. Got no errors.

Then replaced the file and now doesn't boot up.

Just stays with the red light on and does nothing. If I don't change this file works fine.

[dom]

sudo rpi-update dac765d9b21855a95496833cb876b08dd8d5f9c6

Now includes this fix, so no need to download the start_gray.elf.