[issue2123] dca sample does not play, channels wrongly detected (regression)
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: The down-mixing problems were fixed in r24555 (thanks to Nick Brereton and Benjamin Larsson), the possibly remaining problems with channel ordering belong to issue 715, imo. -- status: open - closed substatus: reproduced - fixed FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2123
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: I'd like to move this discussion to ffmpeg-user. I answered there, using subject line video back-end in ffplay.c. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: On 07/30/2010 09:45 AM, scheutzo wrote: scheutzomike.scheut...@alcatel-lucent.com added the comment: I'd like to move this discussion to ffmpeg-user. I answered there, using subject line video back-end in ffplay.c. BTW: you have not said what u expected from the SDL overlay call in this particular scenario. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: BTW: you have not said what u expected from the SDL overlay call in this particular scenario. Yes, there is an SDL bug. SDL tells ffplay that it created a Y plane that is 1920x1080 pixels, at 1 byte/pixel, but then SDL allocates an actual buffer that is 1024x768 bytes. I would guess this is because your video hardware can support a maximum of 1024x768 bytes. Even if you get SDL to fix their bug, ffplay will *still* not work because SDL will likely return a buffer smaller than ffplay requested, which violates the ffplay design. You are fighting an uphill battle if you expect others to rewrite code to support old video hardware that almost nobody would attempt to play High Def on. Earlier in the thread, you even said you don't expect it to decode at full frame rate. You should be happy the -vf trick works, because otherwise you would not be able to see video at all. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: On 07/30/2010 11:13 AM, scheutzo wrote: You are fighting an uphill battle if you expect others to rewrite code to support old video hardware that almost nobody would attempt to play High Def on. Earlier in the thread, you even said you don't expect it to decode at full frame rate. So far there is no evidence that my hardware is involved at all. Or any hardware from anywhere. Or any deficiency in the hardware. So far the software crashes, which is inappropriate by any standard. FFPLAY will never know why it crashed, because it just does not check if the info, which appears to have been illegally gleaned from SDL, is appropriate for its own usage. So long as it does not crash, the developers appear to be quite content. Ya, in 2000, there was just the expectation that this laptop has just enough cpu to play a dvd without any hiccups. With avchd, my quad core amd @ 3.2Ghz/win 7 has just enough cpu to play it. Rendering video, my quadcore is just to sloo. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
Ronald S. Bultje rsbul...@gmail.com added the comment: FWIW, I can reproduce this. Whatever causes the bug should be fixed in ffplay.c. Please refrain from further bitchfighting and fix the actual bug. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
