Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Sun, Oct 03, 2010 at 10:29:18PM +, Carl Eugen Hoyos wrote:
This is no longer an MPlayer regression: The only samples that are still not
working are raw gsm. They were never supported, afaict.
We'd need a raw GSM demuxer.
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment:
Please produce your patch with svn diff, use tools/patcheck to test and
attach it to this issue.
--
status: new - open
substatus: analyzed - needs_changes
FFmpeg
Janos Barta linuxhe...@gmail.com added the comment:
Hello,
thanks for your answer, but I do not agree with you.
I think it would be a very important feature.
If you are a broadcaster, then you may have a couple of channels. One of these
channels is SD, others HD, and the rest are mixed
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment:
Patch pending on ffmpeg-devel:
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/118900
--
status: new - open
substatus: new - reproduced
FFmpeg issue tracker
New submission from Jin jins...@gmail.com:
Afreeca for iPhone is a live video recording app for Korean.
You can download this app from http://itunes.apple.com/us/app/id334185830?mt=8
I've found that this app uses FFmpeg software in their app, but there is NO
mention about it in the App or
Robert Schlabbach rober...@gmx.net added the comment:
Here is the SVN diff patch, tested with patcheck,
which only complained about a missing changelog entry.
But since the source file had no changelog entries at
all, I suppose that's ok?
Luca Barbato lu_z...@gentoo.org added the comment:
hi, the patch looks more or less ok (just a }; that should be } as Martin
noted on irc), do you have test samples for it? what's the producer?
FFmpeg issue tracker iss...@roundup.ffmpeg.org
Robert Schlabbach rober...@gmx.net added the comment:
The RTP/UDP multicast source which exposed this
problem is Deutsche Telekom's IPTV service (T-Home
Entertain) in Germany. If you happen to have a
developer amongst you who has this service, you can
reproduces this problem e.g. with:
Robert Schlabbach rober...@gmx.net added the comment:
Ok, here is a single RTP/UDP multicast packet showing
a RTP header extension of 8 32-bit words. Plus the 4
bytes of the header extension itself yields 36 bytes
to be skipped by the RTP decoder.
Wireshark does not autodetect it as RTP, so
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment:
Fixed by Benjamin Larsson in r25320.
--
status: open - closed
substatus: open - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment:
Could you upload the installer (or whatever file you were able to receive) to
ftp://ffmpeg.org/MPlayer/incoming/issue2271 (write-only, you have to create the
directory)?
--
status: new - open
substatus: new -
New submission from Lou l...@fakeoutdoorsman.com:
Using this sample as input:
http://samples.mplayerhq.hu/DV-raw/
yadif adds artifacts on the top row of pixels on Arch Linux 64-bit. These
artifacts appear with both ffplay and ffmpeg. The artifacts do not appear on
videos encoded with 32-bit
Lou l...@fakeoutdoorsman.com added the comment:
Output samples:
/MPlayer/incoming/issue2272/yadif-64.mp4
/MPlayer/incoming/issue2272/yadif-32.mp4
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2272
Lou l...@fakeoutdoorsman.com added the comment:
Input sample:
http://samples.mplayerhq.hu/DV-raw/small_test2.dv
Had incomplete link in OP.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2272
14 matches
Mail list logo
