[issue2272] yadif adds artifacts to top row of pixels

2010-10-04 Thread Lou 

Lou  added the comment:

Input sample:
http://samples.mplayerhq.hu/DV-raw/small_test2.dv

Had incomplete link in OP.


FFmpeg issue tracker

[issue2272] yadif adds artifacts to top row of pixels

2010-10-04 Thread Lou 

Lou  added the comment:

Output samples:
/MPlayer/incoming/issue2272/yadif-64.mp4
/MPlayer/incoming/issue2272/yadif-32.mp4


FFmpeg issue tracker

[issue2272] yadif adds artifacts to top row of pixels

2010-10-04 Thread Lou 

New submission from Lou :

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 Arch Linux and 32-bit Ubuntu Lucid.

Arch Linux 64-bit
$ ffmpeg -v 9 -loglevel 99 -i small_test2.dv -an -vf yadif -qscale 3 
yadif-64.mp4
FFmpeg version SVN-r25336, Copyright (c) 2000-2010 the FFmpeg developers
  built on Oct  4 2010 14:01:53 with gcc 4.5.1
  configuration: --prefix=/usr --enable-gpl --enable-libmp3lame --enable-libx264
--arch=x86_64
  libavutil 50.32. 1 / 50.32. 1
  libavcore  0. 9. 1 /  0. 9. 1
  libavcodec52.92. 0 / 52.92. 0
  libavformat   52.79. 0 / 52.79. 0
  libavdevice   52. 2. 2 / 52. 2. 2
  libavfilter1.48. 0 /  1.48. 0
  libswscale 0.12. 0 /  0.12. 0
[NULL @ 0x2d3b470] Probed with size=131072 and score=75
[dv @ 0x2d3b470] All info found
[dv @ 0x2d3b470] Estimating duration from bitrate, this may be inaccurate
Input #0, dv, from 'small_test2.dv':
  Duration: 00:00:02.84, start: 0.00, bitrate: 28800 kb/s
Stream #0.0, 1, 1/25: Video: dvvideo, yuv420p, 720x576, 1/25, 28800 kb/s,
PAR 16:15 DAR 4:3, 25 tbr, 25 tbn, 25 tbc
Stream #0.1, 1, 1/3: Audio: pcm_s16le, 32000 Hz, 2 channels, s16, 1024 
kb/s
Stream #0.2, 1, 1/3: Audio: pcm_s16le, 32000 Hz, 2 channels, s16, 1024 
kb/s
[buffer @ 0x2d41e50] w:720 h:576 pixfmt:yuv420p
[yadif @ 0x2d42270] mode:0 parity:-1
Output #0, mp4, to 'yadif-64.mp4':
  Metadata:
encoder : Lavf52.79.0
Stream #0.0, 0, 1/25: Video: mpeg4, yuv420p, 720x576 [PAR 16:15 DAR 4:3],
1/25, q=2-31, 200 kb/s, 25 tbn, 25 tbc
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
[dvvideo @ 0x2d3c720] AC EOB marker is absent pos=71bitrate=2529.0kbits/s
frame=   71 fps=  0 q=3.0 Lsize= 879kB time=2.84 bitrate=2535.5kbits/s
video:878kB audio:0kB global headers:0kB muxing overhead 0.149983%

$ ffplay -loglevel 99 yadif-64.mp4
FFplay version SVN-r25336, Copyright (c) 2003-2010 the FFmpeg developers
  built on Oct  4 2010 14:01:53 with gcc 4.5.1
  configuration: --prefix=/usr --enable-gpl --enable-libmp3lame --enable-libx264
--arch=x86_64
  libavutil 50.32. 1 / 50.32. 1
  libavcore  0. 9. 1 /  0. 9. 1
  libavcodec52.92. 0 / 52.92. 0
  libavformat   52.79. 0 / 52.79. 0
  libavdevice   52. 2. 2 / 52. 2. 2
  libavfilter1.48. 0 /  1.48. 0
  libswscale 0.12. 0 /  0.12. 0
[NULL @ 0x1b21830] Probed with size=2048 and score=100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x1b21830] ISO: File Type Major Brand: isom
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x1b21830] All info found
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'yadif-64.mp4':
  Metadata:
major_brand : isom
minor_version   : 512
compatible_brands: isomiso2mp41
encoder : Lavf52.79.0
  Duration: 00:00:02.84, start: 0.00, bitrate: 2535 kb/s
Stream #0.0(und), 1, 1/25: Video: mpeg4, yuv420p, 720x576 [PAR 16:15 DAR
4:3], 1/25, 2531 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
   4.81 A-V:  0.000 s:0.0 aq=0KB vq=0KB sq=0B f=0/0   0/0 

MPlayer's yadif does not introduce any artifacts:
mplayer -vf yadif -noborder small_test2.dv

--
messages: 12137
nosy: FakeOutdoorsman
priority: normal
status: new
substatus: new
title: yadif adds artifacts to top row of pixels
type: bug


FFmpeg issue tracker

[issue2271] LGPL violation "afreeca for iPhone"

2010-10-04 Thread Carl Eugen Hoyos 

Carl Eugen Hoyos  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 -> needs_more_info


FFmpeg issue tracker

[issue2137] AVI with DTS reports 5 channels when channelLayout reports 6

2010-10-04 Thread Carl Eugen Hoyos 

Carl Eugen Hoyos  added the comment:

Fixed by Benjamin Larsson in r25320.

--
status: open -> closed
substatus: open -> fixed


FFmpeg issue tracker

[issue2270] RTP parser fails on RFC 3550 header extensions

2010-10-04 Thread Robert Schlabbach 

Robert Schlabbach  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 you have 
to right-click the packet, select "Decode As..." and 
then "RTP" as the protocol.


FFmpeg issue tracker 



RTP_Header_Extension_Sample.cap
Description: Binary data

[issue2270] RTP parser fails on RFC 3550 header extensions

2010-10-04 Thread Ronald S. Bultje 

Ronald S. Bultje  added the comment:

a wireshark capture of one packet showing this type of data should be 
fine.


FFmpeg issue tracker

[issue2270] RTP parser fails on RFC 3550 header extensions

2010-10-04 Thread Robert Schlabbach 

Robert Schlabbach  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:

ffplay rtp://@239.35.129.11:1
or
ffplay rtp://@239.35.10.1:1

These two commands play the German TV station "Das 
Erste" and "Das Erste HD", respectively, and exhibit 
frequent video and audio glitches with the current 
ffmpeg code.

If you don't have anyone with DT's IPTV service, how 
can I submit a sample? Submitting a sample of the 
contained MPEG-2 Transport Stream would be pointless, 
as the issue is with the RTP encapsulation ;)

Would a Wireshark capture of the RTP multicast 
packages be sufficient? I don't know how you'd be able 
to play that back, though...


FFmpeg issue tracker

[issue2270] RTP parser fails on RFC 3550 header extensions

2010-10-04 Thread Luca Barbato 

Luca Barbato  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

[issue2270] RTP parser fails on RFC 3550 header extensions

2010-10-04 Thread Robert Schlabbach 

Robert Schlabbach  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?


FFmpeg issue tracker 

Index: ffmpeg/libavformat/rtpdec.c
===
--- ffmpeg/libavformat/rtpdec.c (.../svn://svn.ffmpeg.org/ffmpeg/trunk) 
(revision 25334)
+++ ffmpeg/libavformat/rtpdec.c (.../ffmpeg)(working copy)
@@ -416,6 +416,7 @@
 {
 unsigned int ssrc, h;
 int payload_type, seq, ret, flags = 0;
+int ext;
 AVStream *st;
 uint32_t timestamp;
 int rv= 0;
@@ -443,9 +444,36 @@
 }
 
 s->seq = seq;
+
+/* RFC 3550 Section 5.3.1 RTP Header Extension handling */
+
+// store RTP header extension bit
+ext = buf[0] & 0x10;
+
+// skip past RTP header
 len -= 12;
 buf += 12;
 
+// check for RTP header extension
+if (ext) {
+// retrieve header extension length (number of 32-bit words)
+ext = AV_RB16(buf + 2);
+
+// add header extension itself to extension length
+ext++;
+
+// convert header extension length to bytes
+ext <<= 2;
+
+// abort if extension length exceeds remaining buffer length
+if (len < ext)
+return -1;
+
+// skip past RTP header extension
+len -= ext;
+buf += ext;
+};
+
 if (!st) {
 /* specific MPEG2TS demux support */
 ret = ff_mpegts_parse_packet(s->ts, pkt, buf, len);

[issue2271] LGPL violation "afreeca for iPhone"

2010-10-04 Thread Jin 

New submission from Jin :

"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 their web site.

Author of this app is a company. 
Email address is afre...@nowcom.co.kr which is stated in the about page of app.

Below is strings I have found. 

> cat iPhoneAfreeca |strings |grep ff 
C\dffi
W0IffRI
[cuAff*
MffTqC!
ff`N
ff

[issue2269] aspect ratio has forbidden 0 value with mpeg1video output using yadif

2010-10-04 Thread Carl Eugen Hoyos 

Carl Eugen Hoyos  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

[issue2255] ffmpeg h264 wss

2010-10-04 Thread Janos Barta 

Janos Barta  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 resolutions. The mixed means,
sometimes the channel provides SD, other times HD resolution. In the last case
the PAR/DAR information is in a different elementary stream (if you have 
mpeg2ts). 
If you receive  it with a standard SetTopBox/mplayer/vlc, these devices can
display the stream with the correct aspect ratio, because they can read the
aspect information from the ES.

But if you want to display this stream with a special device, which does not
read the  VBI WSS ES, or you would like to transcode it (for example: you want
to make an iPhone stream), then you (the ffmpeg) need to handle the changes of
the resolution (eg. using the pillarbox, letterbox format).

We discussed about that on the doom forum, and I got an answer:
the libx264 does it, but there's no code that connects that support to
information provided by FFmpeg decoders.


What can I do now? Should I modify the status of the report (to feature
request), or should I close it?

Thanks,
Jani


FFmpeg issue tracker

[issue2270] RTP parser fails on RFC 3550 header extensions

2010-10-04 Thread Carl Eugen Hoyos 

Carl Eugen Hoyos  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 issue tracker

[issue113] GSM decoding broken with many samples

2010-10-04 Thread Reimar Döffinger 

Reimar Döffinger  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.
Which should be possibleto implement even with auto-detection, it has to check 
that
the highest 4 bits are 0xd every 33 bytes. Not sure how reliable it will
be though.


FFmpeg issue tracker