2011-07-19, 01:10
Well if its an ffmpeg issue from the ffmpeg main code tree (eg I would assume mpegvideo, h264 codec or flv format related) then the issue can be logged with the ffmpeg guys. Glad you persevered - most would not have.
2011-07-19, 13:54
Hey, no worries about perseverance - I thought that was the spirit of community development, after all! - plus I have a selfish interest in getting this fixed 
Just to put this beyond doubt, two successive commits:
PRE-11.0 GIT:4d8e27c PASS
and, the very next commit ("updated: internal ffmpeg to c3beafa0f1"):
PRE-11.0 GIT:1a6a927 FAIL
So that's where the problem began. Sadly, this commit covers "1,216 changed files with 70,821 additions and 35,441 deletions"...
I'll switch to ffmpeg now and see if I can either build something like ffplay with VDPAU to demonstrate the problem... or else just see if I can compile XBMC with external ffmpeg on the off-chance they've already fixed it in the ffmpeg trunk.
Thanks for all the thoughts to all who've helped track this one down. I'll let you know if I get anywhere further.
Cheers,
Ian
Just to put this beyond doubt, two successive commits:
PRE-11.0 GIT:4d8e27c PASS
and, the very next commit ("updated: internal ffmpeg to c3beafa0f1"):
PRE-11.0 GIT:1a6a927 FAIL
So that's where the problem began. Sadly, this commit covers "1,216 changed files with 70,821 additions and 35,441 deletions"...
I'll switch to ffmpeg now and see if I can either build something like ffplay with VDPAU to demonstrate the problem... or else just see if I can compile XBMC with external ffmpeg on the off-chance they've already fixed it in the ffmpeg trunk.
Thanks for all the thoughts to all who've helped track this one down. I'll let you know if I get anywhere further.
Cheers,
Ian
2011-07-19, 18:25
Great work tracking this down!
Have you had a look at ffmpeg repo:
http://git.videolan.org/?p=ffmpeg.git;a=...cd;hb=HEAD
They might have already fixed it.
Have you had a look at ffmpeg repo:
http://git.videolan.org/?p=ffmpeg.git;a=...cd;hb=HEAD
They might have already fixed it.
2011-07-19, 20:19
Yup, looking at that now - well, actually just building ffmpeg from git (d303e0a) before I try to recompile the current xbmc code (3d3b871) using external ffmpeg instead of the internal libraries. Which could be fun from some of the posts I've seen in the past. Let's see...!
And if that shows corruption... I guess I'll be heading back in ffmpeg time to see if I can find when the problem arose. I know that it appeared when XBMC's internal ffmpeg was updated to c3beafa0f1, as above - trouble is, I don't know what version of ffmpeg it had before that. If anyone knows, please sing out (although it may be SVN instead of git at that point, just to add to the fun).
My head hurts. And you guys do this for fun?
And if that shows corruption... I guess I'll be heading back in ffmpeg time to see if I can find when the problem arose. I know that it appeared when XBMC's internal ffmpeg was updated to c3beafa0f1, as above - trouble is, I don't know what version of ffmpeg it had before that. If anyone knows, please sing out (although it may be SVN instead of git at that point, just to add to the fun).
My head hurts. And you guys do this for fun?
2011-07-19, 21:01
Quote:I don't know what version of ffmpeg it had before that.Why not asking anssih? Does he already know about this problem?
2011-07-19, 21:02
Fair point - no, he probably doesn't - I'll ask!
2011-07-19, 21:15
I have added a note to the commit.
2011-07-19, 21:59
Thanks - I popped him an email as well to let him know this conversation is going on, so hopefully he can shed some light and join in here.
In the meantime, I'll carry on compiling!
In the meantime, I'll carry on compiling!
2011-07-20, 01:02
Nope, I surrender for the moment. I've tried compiling umpteen times with --enable-external-ffmpeg, and I keep getting the same issue when I come to compile xbmc, even though ffmpeg seems to have compiled and installed fine:
checking for FFMPEG... no
configure: error: Could not find a required library. Please see the README for your platform.
I've compiled ffmpeg and installed it with no problem. I've compiled it --enable-standalone, --enable-shared and every variation. I've manually moved .so libraries around, symlinked 'em and ldconfig-ed until I'm blue in the face.
I think it's time to quit for a while, I'll come back when I'm sober :p
checking for FFMPEG... no
configure: error: Could not find a required library. Please see the README for your platform.
I've compiled ffmpeg and installed it with no problem. I've compiled it --enable-standalone, --enable-shared and every variation. I've manually moved .so libraries around, symlinked 'em and ldconfig-ed until I'm blue in the face.
I think it's time to quit for a while, I'll come back when I'm sober :p
2011-07-20, 22:36
Okay, anssih has confirmed - it was r24229 previously. He also has a suspicion that XBMC will argue with recent ffmpeg builds, which might explain last night's problems... that means I might be able to go back in time to when the problem began, but not completely up-to-date to see if it's been fixed later on in e.g. ffmpeg 0.8.
So I'll have a think about how best to tackle this... it might be that using a lighter-weight and faster-to-compile VDPAU-supporting player (mplayer? VLC? ffplay?) is a more sensible way of nailing the fault if it is genuinely a pure ffmpeg problem. Some homework to do first.
So I'll have a think about how best to tackle this... it might be that using a lighter-weight and faster-to-compile VDPAU-supporting player (mplayer? VLC? ffplay?) is a more sensible way of nailing the fault if it is genuinely a pure ffmpeg problem. Some homework to do first.
2011-07-24, 10:57
Are you still trying external ffmpeg? Not sure if you noticed this:
https://github.com/opdenkamp/xbmc/issues/157
You may want to ask EricV how to compile with external ffmpeg.
https://github.com/opdenkamp/xbmc/issues/157
You may want to ask EricV how to compile with external ffmpeg.
2011-07-24, 15:44
Thanks for that - yes, I found out the hard way that ffmpeg 0.8 doesn't play nicely, although I'm having enough difficulty compiling against earlier versions of ffmpeg as well (with or without libswscale included). At the moment, I've started down the road of trying to replicate the problem in a non-XBMC, VDPAU-and-ffmpeg setup... if I can see it there, it's categorically ffmpeg at fault. If I can't replicate it, then *perhaps* it's something to do with the way in which XBMC calls libvdpau or similar (guessing).
Even then, finding something else seems to be easier said than done... looking...!
Even then, finding something else seems to be easier said than done... looking...!
2011-07-31, 19:36
I've managed to successfully build ffmpeg, but not yet got XBMC to compile properly to use it. Hopefully more success this week - I did drop EricV a note but no reply yet (I was pretty vague about what help I was after, so I can't blame the silence necessarily!).
However, I've since noticed the problem on an SD flv/h.264 stream from a different television channel catchup service (Channel 5, for anyone following along in the UK). So that's the first non-BBC, non-HD file I've seen the problem on. I did some homework and the only things I could see that separate these files from working alternatives (e.g. YouTube Flash/H.264/HD stream) are:
1. The PAR isn't 1:1 - it's 90:90 or 180:180. If you recode in HandBrake, this is one of the things that gets changed. However, using ffmpeg to re-wrap the flv into MP4 and then MP4Box to change the PAR in this file made no difference. I also demuxed the files into separate H.264 and AAC streams and remuxed, but that made no difference. Interestingly, though, the standalone H.264 video stream still shows the error when played in XBMC, so it's definitely an error in this stream (or how it interacts with VDPAU, anyway). It's nothing to do with the container ... I'd re-wrapped from flv to both mkv and mp4 containers anyway, but that proves it.
2. The TrackID numbering convention isn't the usual 1, 2, 3... MP4Box reports 201, 202... - again, though, demuxing and remuxing makes no difference (and, obviously, the demuxed H.264 stream is a single-track file anyway).
3. There *may* be some errors in the header about the applicable H.264 profile (L4.1 versus not recorded). I need to look into this further and see if it's relevant and/or follows the video to the H.264 stream.
Anyway, I'm aiming to build a new vanilla Lucid system this week (easiest way to get a window manager on boot without playing with xubuntu-desktop) and then see what VLC, Mplayer and their ilk make of the files. I have tried ffplay on the current build, and that seems to choke immediately, but that's probably more symptomatic of my compilation and the configure options!
Still digging. I want my HD iPlayer back
However, I've since noticed the problem on an SD flv/h.264 stream from a different television channel catchup service (Channel 5, for anyone following along in the UK). So that's the first non-BBC, non-HD file I've seen the problem on. I did some homework and the only things I could see that separate these files from working alternatives (e.g. YouTube Flash/H.264/HD stream) are:
1. The PAR isn't 1:1 - it's 90:90 or 180:180. If you recode in HandBrake, this is one of the things that gets changed. However, using ffmpeg to re-wrap the flv into MP4 and then MP4Box to change the PAR in this file made no difference. I also demuxed the files into separate H.264 and AAC streams and remuxed, but that made no difference. Interestingly, though, the standalone H.264 video stream still shows the error when played in XBMC, so it's definitely an error in this stream (or how it interacts with VDPAU, anyway). It's nothing to do with the container ... I'd re-wrapped from flv to both mkv and mp4 containers anyway, but that proves it.
2. The TrackID numbering convention isn't the usual 1, 2, 3... MP4Box reports 201, 202... - again, though, demuxing and remuxing makes no difference (and, obviously, the demuxed H.264 stream is a single-track file anyway).
3. There *may* be some errors in the header about the applicable H.264 profile (L4.1 versus not recorded). I need to look into this further and see if it's relevant and/or follows the video to the H.264 stream.
Anyway, I'm aiming to build a new vanilla Lucid system this week (easiest way to get a window manager on boot without playing with xubuntu-desktop) and then see what VLC, Mplayer and their ilk make of the files. I have tried ffplay on the current build, and that seems to choke immediately, but that's probably more symptomatic of my compilation and the configure options!
Still digging. I want my HD iPlayer back
2011-08-08, 18:14
Prof Yaffle Wrote:I've managed to successfully build ffmpeg, but not yet got XBMC to compile properly to use it. Hopefully more success this week - I did drop EricV a note but no reply yet (I was pretty vague about what help I was after, so I can't blame the silence necessarily!).
However, I've since noticed the problem on an SD flv/h.264 stream from a different television channel catchup service (Channel 5, for anyone following along in the UK). So that's the first non-BBC, non-HD file I've seen the problem on. I did some homework and the only things I could see that separate these files from working alternatives (e.g. YouTube Flash/H.264/HD stream) are:
1. The PAR isn't 1:1 - it's 90:90 or 180:180. If you recode in HandBrake, this is one of the things that gets changed. However, using ffmpeg to re-wrap the flv into MP4 and then MP4Box to change the PAR in this file made no difference. I also demuxed the files into separate H.264 and AAC streams and remuxed, but that made no difference. Interestingly, though, the standalone H.264 video stream still shows the error when played in XBMC, so it's definitely an error in this stream (or how it interacts with VDPAU, anyway). It's nothing to do with the container ... I'd re-wrapped from flv to both mkv and mp4 containers anyway, but that proves it.
2. The TrackID numbering convention isn't the usual 1, 2, 3... MP4Box reports 201, 202... - again, though, demuxing and remuxing makes no difference (and, obviously, the demuxed H.264 stream is a single-track file anyway).
3. There *may* be some errors in the header about the applicable H.264 profile (L4.1 versus not recorded). I need to look into this further and see if it's relevant and/or follows the video to the H.264 stream.
Anyway, I'm aiming to build a new vanilla Lucid system this week (easiest way to get a window manager on boot without playing with xubuntu-desktop) and then see what VLC, Mplayer and their ilk make of the files. I have tried ffplay on the current build, and that seems to choke immediately, but that's probably more symptomatic of my compilation and the configure options!
Still digging. I want my HD iPlayer back
Please post a link to your failing mkv version and I might get a chance to try it and debug ffmpeg a little further - I feel a little more confident with that than flv.
2011-08-12, 00:04
Thanks for the help: PM sent with a link to some file samples.
Some H.264 streams - SD or HD - play fine, and those that don't have problems whatever the file format. So it's clearly an issue with the video stream itself, or how ffmpeg/VDPAU is handling it, anyway. All I can say is that I've got it on streams from different sources, so it's not a unique encoding even if it's perhaps non-standard or similarly screwed up.
I stumbled across this recent patch for ffmpeg which I'm aiming to try, but there's no real information as to what problem it fixes. Clutching at straws, though, I know.
Thanks again...
Some H.264 streams - SD or HD - play fine, and those that don't have problems whatever the file format. So it's clearly an issue with the video stream itself, or how ffmpeg/VDPAU is handling it, anyway. All I can say is that I've got it on streams from different sources, so it's not a unique encoding even if it's perhaps non-standard or similarly screwed up.
I stumbled across this recent patch for ffmpeg which I'm aiming to try, but there's no real information as to what problem it fixes. Clutching at straws, though, I know.
Thanks again...
