[issue1697] MSRTSP doesn't work with some Akamai streams

[Luca Abeni]

Luca Abeni  added the comment:

Ronald S. Bultje wrote:
> Ronald S. Bultje  added the comment:
> 
> Adding Luca and Luca. OK to apply? I've heard this come up several times now.

Regarding applying the patch or not, I do not know (this is Luca B. decision).
But I think the patch mixes cosmetic and functional changes.
And it seems to me that it silently changes the default to
RTP over RTSP.

_
FFmpeg issue tracker 

_

[issue1693] MKV Output format - FPS rate (default-duration) not set in header

[David Conrad]

David Conrad  added the comment:

Anything that relies on default duration for correct operation is 
wrong and should be fixed. It's an optional field and completely 
redundant. It's also not the fps field.

Anyway, I sent a patch to calculate the average fps, once that's 
approved I'll write it in the mkv header.

--
substatus: needs_more_info -> analyzed
type: bug -> feature_request

_
FFmpeg issue tracker 

_

[issue1697] MSRTSP doesn't work with some Akamai streams

[Luca Barbato]

Luca Barbato  added the comment:

The style could be cleaned up I think.

_
FFmpeg issue tracker 

_

[issue1693] MKV Output format - FPS rate (default-duration) not set in header

[ghost_zero5]

ghost_zero5  added the comment:

@cehoyos:
What do you mean it is not enough information and not reproducible.
It is perfectly reproducable.
You just have to create a mkv file with ffmpeg and it will not write the
default-duration information (FPS information) and it doesn't really matter
which options you use, it just isn't set.

e.g. if I exectue a command like this:
ffmpeg -i input.ts -vcodec copy -sameq -acodec copy -f matroska output.mkv

or even if I use
ffmpeg -i input.ts -vcodec copy -sameq -acodec copy -f matroska -r 50 output.mkv

It won't set the default-duration (which in the end specifies the FPS rate)
option in the matroska files metadata and therefore many players assume the
default 25 FPS - though I believe that is only what the display but in the end
they still use 50 FPS for playback because otherwise there would be terrible
audio/video sync "issues".

@roozhou:
I will try that patch later.
If it works I wonder if it will make it will be submitted into SVN.

_
FFmpeg issue tracker 

_

[issue1697] MSRTSP doesn't work with some Akamai streams

[Ronald S. Bultje]

Ronald S. Bultje  added the comment:

Adding Luca and Luca. OK to apply? I've heard this come up several times now.

--
nosy: +lu_zero, lucabe72

_
FFmpeg issue tracker 

_

[issue1697] MSRTSP doesn't work with some Akamai streams

[Alan Steremberg]

New submission from Alan Steremberg :

curl -i "http://www.fox970.com/cc-common/streaming_new/index.html?
refreshed=yes" | grep genasx  | grep src | cut -d \" -f 2
this will give you a playlist url - fetch this url, then you will get 
an ASX. Take the ASX and switch the mms to rtsp to reproduce the 
problem.

[rtsp @ 0x1002600]line='RTSP/1.0 200 OK'
[rtsp @ 0x1002600]line='Content-Type: application/sdp'
[rtsp @ 0x1002600]line='Vary: Accept'
[rtsp @ 0x1002600]line='X-Playlist-Gen-Id: 2471290'
[rtsp @ 0x1002600]line='X-Broadcast-Id: 1400245'
[rtsp @ 0x1002600]line='Content-Length: 7930'
[rtsp @ 0x1002600]line='Date: Mon, 18 Jan 2010 22:03:51 GMT'
[rtsp @ 0x1002600]line='CSeq: 2'
[rtsp @ 0x1002600]line='Server: WMServer/9.1.1.3862'
[rtsp @ 0x1002600]line='Supported: com.microsoft.wm.srvppair, 
com.microsoft.wm.sswitch, com.microsoft.wm.eosmsg, 
com.microsoft.wm.fastcache, com.microsoft.wm.packetpairssrc, 
com.microsoft.wm.startupprofile'
[rtsp @ 0x1002600]line='Last-Modified: Sat, 30 Dec 1899 00:00:00 GMT'
[rtsp @ 0x1002600]line='Cache-Control: x-wms-event-
subscription="remote-log", x-wms-stream-type="broadcast", no-cache, no-
user-cache, private'
[rtsp @ 0x1002600]line=''
[rtsp @ 0x1002600]sdp: v='0'
[rtsp @ 0x1002600]sdp: o='- 200910181740040811 200910181740040811 IN 
IP4 127.0.0.1'
[rtsp @ 0x1002600]sdp: s=''
[rtsp @ 0x1002600]sdp: c='IN IP4 0.0.0.0'
[rtsp @ 0x1002600]sdp: b='AS:38'
[rtsp @ 0x1002600]sdp: a='maxps:1518'
[rtsp @ 0x1002600]sdp: t='0 0'
[rtsp @ 0x1002600]sdp: 
a='control:rtsp://a120.l2006019966.c20060.g.lm.akamaistream.net/Akamai_
Live_19966/'
[rtsp @ 0x1002600]nbstream==0 code.. url is 
rtsp://a120.l2006019966.c20060.g.lm.akamaistream.net/Akamai_Live_19966/
[rtsp @ 0x1002600]sdp: a='etag:{9B423EA8-AE7E-E7B7-5F7C-88CA9C88DF86}'
[rtsp @ 0x1002600]sdp: a='range:npt=3.000-3.000'
[rtsp @ 0x1002600]sdp: a='type:broadcast'
[rtsp @ 0x1002600]sdp: a='recvonly'
[rtsp @ 0x1002600]sdp: a='pgmpu:data:application/x-wms-
contentdesc,8,language,31,0,,44,WMS_CONTENT_DESCRIPTION_SERVER_BRANDING
_INFO,31,12,WMServer/9.1,51,WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_STAR
T_OFFSET,3,4,3000,47,WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_DURATION,3,
1,0,58,WMS_CONTENT_DESCRIPTION_COPIED_METADATA_FROM_PLAYLIST_FILE,3,1,1
,42,WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_URL,31,37,19966&akcp=20060&a
kserial=120&fp=v001%0D%0A'
[rtsp @ 0x1002600]sdp: a='pgmpu:data:application/vnd.ms.wms-
hdr.asfv1;base64,MCaydY5mzxGm2QCqAGLObMMTBwECznX4e41G0RGNgg
Bgl8misiYAAgABAJ1/AAACAB8SAACh3KuMR6nPEY7kAMAMIFNlaAD92
0BcyVgBQ4R/Bf8E/3CT9RMAAABQVUvjGVDKAf8A
ALgLCQAAAO4FAADuBQAAvJEAALUDv18uqc8RjuMAwAwgU2UJEQAAABHS06u
6qc8RjuYAwAwgU2UGANsQAACpRkN84O/8S7IpOT7eQVyFJwABAAxlAG4ALQB1AH
MAAADLpeYUcsYyQ4OZqWlSBltaWAAAGH0AACsGA
AAAGH0AACsGzwUBy6XmFHLGMkODmalpUgZb
WlgAALgLAAC4CwAAALgLAAC4CwA
AAgAAAF2L8SaERexHn18OZR8EUskaAAIB6sv4xa9bd0
iEZ6qMRPpMynoAAgEADAACAAIAAABJAHMAVgBCAFIAAQA0B
gAAAEQAZQB2AGkAYwBlAEMAbwBuAGYAbwByAG0AYQBuAGMAZQBUAGUAbQBwAGwAYQB0AGUA
AABMADIAAAB01AYY38oJRaS6mqvLlqrocA8
AAA
sdp: m='audio 0 RTP/AVP 96'
[rtsp @ 0x1002600]sdp: b='AS:33'
[rtsp @ 0x1002600]sdp: b='X-AV:33'
[rtsp @ 0x1002600]sdp: b='RS:0'
[rtsp @ 0x1002600]sdp: b='RR:0'
[rtsp @ 0x1002600]sdp: a='rtpmap:96 x-asf-pf/1000'
[rtsp @ 0x1002600]sdp: a='control:audio'
[rtsp @ 0x1002600]sdp: a='stream:1'
[rtsp @ 0x1002600]sdp: m='application 0 RTP/AVP 96'
[rtsp @ 0x1002600]sdp: b='RS:0'
[rtsp @ 0x1002600]sdp: b='RR:0'
[rtsp @ 0x1002600]sdp: a='rtpmap:96 x-wms-rtx/1000'
[rtsp @ 0x1002600]sdp: a='control:rtx'
[rtsp @ 0x1002600]sdp: a='stream:65536'
[rtsp @ 0x1002600]sdp: m='application 0 RTP/AVP 96'
[rtsp @ 0x1002600]sdp: b='AS:5'
[rtsp @ 0x1002600]sdp: b='X-AV:3'
[rtsp @ 0x1002600]sdp: b='RS:0'
[rtsp @ 0x1002600]sdp: b='RR:0'
[rtsp @ 0x1002600]sdp: a='rtpmap:96 x-asf-pf/1000'
[rtsp @ 0x1002600]sdp: a='control:stream=2'
[rtsp @ 0x1002600]sdp: a='stream:2'

--
assignedto: rbultje
files: akamairtsppatch1.diff
messages: 8913
nosy: rbultje
priority: normal
status: new
substatus: new
title: MSRTSP doesn't work with some Akamai streams
topic: avformat
type: bug

_
FFmpeg issue tracker 

_

akamairtsppatch1.diff
Description: Binary data

[issue1688] AVPacket should provide a packet's source address

[Michael Niedermayer]

Michael Niedermayer  added the comment:

On Mon, Jan 18, 2010 at 02:41:49PM +, Jeremy Morton wrote:
> I am indeed thinking of exporting the source address in AVPacket.  As for 
> which
> demuxer(s) should support this - any that may get packets over a network
> connection?  The one that stands out to me is rtsp.c, but you probably know
> better than I do which ones are appropriate.
> 
> As you said, always ignoring packets from the 'wrong' address in udp.c might
> break some things, so I'd favour presenting it in AVPacket to let the calling
> code decide what to do with it.

I dont think i will accept a patch that bloats AVPacket with this. Its the
job of the protocols to make sure the data they accept is valid as far as
checkable. And beyond that there is iptables and various means to tunnel
insecure protocols over some secure channel.
AVPackets are sometimes used for small packets at a high rate, their size
can be a performance issue. And what you can check in your app you can
check in the protocol itself or in iptables, besides checking at the
app level would leave other apps vulnerable that makes no sense.

[...]

_
FFmpeg issue tracker 

_

[issue1688] AVPacket should provide a packet's source address

[Jeremy Morton]

Jeremy Morton  added the comment:

I am indeed thinking of exporting the source address in AVPacket.  As for which
demuxer(s) should support this - any that may get packets over a network
connection?  The one that stands out to me is rtsp.c, but you probably know
better than I do which ones are appropriate.

As you said, always ignoring packets from the 'wrong' address in udp.c might
break some things, so I'd favour presenting it in AVPacket to let the calling
code decide what to do with it.

_
FFmpeg issue tracker 

_

[issue1696] Encoding MP2 and muxing into AVI via ffmpeg causes later remuxing to AVI to complain about non-monotone timestamps

[Tomas Härdin]

Tomas Härdin  added the comment:

Oops, that should be revision 21282, not 30366. The latter is libswscale.

_
FFmpeg issue tracker 

_

[issue1696] Encoding MP2 and muxing into AVI via ffmpeg causes later remuxing to AVI to complain about non-monotone timestamps

[Tomas Härdin]

New submission from Tomas Härdin :

Taking any media file with AVI compatible video and transcoding the audio to
MP2, muxing into AVI and then remuxing (-acodec copy -vcodec copy) that into
another AVI causes the muxer to complain about non-monotone timestamps. If the
intermediate file is a MOV file then everything works all right. If transcoding
the intermediate file's audio to say pcm_s16le, aac or mp2 once more it also
works fine.
I'm using SVN revision 30366.

Samples tested:
http://samples.mplayerhq.hu/V-codecs/CVID/lisa.avi
http://samples.mplayerhq.hu/V-codecs/MJPEGs/Minolta-MJPEG.mov
http://samples.mplayerhq.hu/V-codecs/MJPEGs/angels_480-mjpegcompress.avi

It probably doesn't matter much what kind of input is used though.
An example:

tjop...@callisto:~$ ffmpeg -i media/lisa.avi -vcodec copy -acodec mp2 -ab 192000
-ar 48000 output.avi
FFmpeg version SVN-r21282, Copyright (c) 2000-2010 Fabrice Bellard, et al.
  built on Jan 18 2010 13:19:18 with gcc 4.3.3
  configuration: --enable-shared
  libavutil 50. 7. 0 / 50. 7. 0
  libavcodec52.48. 0 / 52.48. 0
  libavformat   52.47. 0 / 52.47. 0
  libavdevice   52. 2. 0 / 52. 2. 0
  libswscale 0. 8. 0 /  0. 8. 0
Input #0, avi, from 'media/lisa.avi':
  Duration: 00:00:09.00, start: 0.00, bitrate: 562 kb/s
Stream #0.0: Video: cinepak, yuv420p, 320x240, 15 tbr, 15 tbn, 15 tbc
Stream #0.1: Audio: pcm_u8, 11025 Hz, 1 channels, u8, 88 kb/s
Output #0, avi, to 'output.avi':
Stream #0.0: Video: cvid / 0x64697663, yuv420p, 320x240, q=2-31, 15 tbn, 15 
tbc
Stream #0.1: Audio: mp2, 48000 Hz, 1 channels, s16, 192 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
Press [q] to stop encoding
Warning, using s16 intermediate sample format for resampling
frame=  121 fps=  0 q=-1.0 Lsize= 575kB time=8.07 bitrate= 583.4kbits/s
video:342kB audio:211kB global headers:0kB muxing overhead 3.861377%


tjop...@callisto:~$ ffmpeg -i output.avi -acodec copy -vcodec copy remuxed.avi
FFmpeg version SVN-r21282, Copyright (c) 2000-2010 Fabrice Bellard, et al.
  built on Jan 18 2010 13:19:18 with gcc 4.3.3
  configuration: --enable-shared
  libavutil 50. 7. 0 / 50. 7. 0
  libavcodec52.48. 0 / 52.48. 0
  libavformat   52.47. 0 / 52.47. 0
  libavdevice   52. 2. 0 / 52. 2. 0
  libswscale 0. 8. 0 /  0. 8. 0
Input #0, avi, from 'output.avi':
  Duration: 00:00:09.00, start: 0.00, bitrate: 522 kb/s
Stream #0.0: Video: cinepak, yuv420p, 320x240, 15 tbr, 15 tbn, 15 tbc
Stream #0.1: Audio: mp2, 48000 Hz, 1 channels, s16, 192 kb/s
Output #0, avi, to 'remuxed.avi':
Stream #0.0: Video: cvid / 0x64697663, yuv420p, 320x240, q=2-31, 15 tbn, 15 
tbc
Stream #0.1: Audio: mp2, 48000 Hz, 1 channels, 192 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
Press [q] to stop encoding
[avi @ 0x164c1f0]st:1 error, non monotone timestamps 1 >= 1
av_interleaved_write_frame(): Error while opening file

A short list of test cases and their results follows. I chose the smallest video
since I've been staring at vbindiff. Each line is formatted like "input ->
intermediate -> output", where intermediate and output are on the form
"container/-acodec argument". All non-

lisa.avi -> avi/mp2 -> avi/copy = [avi @ 0x15c9900]st:1 error, non monotone
timestamps 1 >= 1
lisa.avi -> mov/mp2 -> avi/copy = OK
lisa.avi -> avi/mp2 -> avi/aac  = OK
lisa.avi -> avi/mp2 -> avi/mp2  = OK
lisa.avi -> mov/aac -> avi/copy = OK
lisa.avi -> avi/mp2 -> mov/copy = [mov @ 0x8bb900]track 1: codec frame size is
not set
lisa.avi -> mov/mp2 -> mov/copy = OK
lisa.avi -> avi/aac -> avi/copy = OK
lisa.avi -> avi/ac3 -> avi/copy = OK
lisa.avi -> avi/wmav1 -> avi/copy = OK
lisa.avi -> avi/wmav2 -> avi/copy = OK
angels_480-mjpegcompress.avi -> avi/vorbis -> avi/copy = OK

I'm not sure whether this is a bug in libavcodec, libavformat, ffmpeg or all, so
I tagged this with all of them.
I've dug a bit into the code and ff_parse_specific_params() might be to blame.
That or some other part of the system causes frame_size and/or block_align to
eventually be read incorrectly. I'm fairly sure it's caused by either the AVI
muxer or the AVI demuxer.

--
messages: 8909
priority: normal
status: new
substatus: new
title: Encoding MP2 and muxing into AVI via ffmpeg causes later remuxing to AVI 
to complain about non-monotone timestamps
topic: avcodec, avformat, ffmpeg
type: bug

_
FFmpeg issue tracker 

_

[issue1587] Turkish Telecom's Wirofon infringes the GPL

[Burak Gurdag]

Burak Gurdag  added the comment:

As the development team of Wirofon application, we had mistakenly included the
listed libraries even though the application does not use them at all. The
Wirofon application currently does not have video call feature and also does not
support Speex codec. This can be easily confirmed by any user of the
application. The inclusion of these libraries is due to our experiments with
them and certainly is not meant for the production.

In order to clear the misunderstanding, we removed the installation package
under question (Namely, Wirofon-Client-0.1.0-rc2.exe) and have just repacked the
distribution without the libraries mentioned in this issue. You can check the
new package from the address below:

http://www.wirofon.com/assets/bin/Wirofon-Client-0.1.0-rc6.exe

We apologize for the inconvenience.

_
FFmpeg issue tracker 

_

[issue1688] AVPacket should provide a packet's source address

[Luca Abeni]

Luca Abeni  added the comment:

The UDP protocol code uses network addreeses. For example, see
udp_set_remote_url(). But I am not sure what you want to do, here. So, the
function I mentioned could be irrelevant.
If you want to export the source address in AVPacket (as the message title
suggests), then maybe the "priv" field can be used. But we should understand
which demuxer has to support this.

It depends by what the code wants to do with the address.
If you want to discard packets coming from a "wrong" address, maybe the
simplest thing to do is to modify udp.c to use recvfrom(), and to compare
the source address with the address that has been specified through
udp_set_remote_url().
(but I imagine this could break stuff in some situation where private
IP addresses and NAT are used)
If you have different requirements, different kinds of changes might
be needed (but I am not sure until I know the requirements)

_
FFmpeg issue tracker 

_

[issue1693] MKV Output format - FPS rate (default-duration) not set in header

[Zhou Zongyi]

Zhou Zongyi  added the comment:

It's easy to fix. I make this patch:

--- libavformat/matroskaenc.c   (revision 21281)
+++ libavformat/matroskaenc.c   (working copy)
@@ -610,6 +605,9 @@
 ret = mkv_write_codecprivate(s, pb, codec, native_id, qt_id);
 if (ret < 0) return ret;
 
+if (codec->codec_type == CODEC_TYPE_VIDEO)
+put_ebml_uint(pb, 0x23e383, lrint(codec->time_base.num * 
10. / codec->time_base.den));
+
 end_ebml_master(pb, track);
 
 // ms precision is the de-facto standard timescale for mkv 
files

_
FFmpeg issue tracker 

_

[issue1688] AVPacket should provide a packet's source address

[Jeremy Morton]

Jeremy Morton  added the comment:

A couple of questions:

1) Is there anywhere in the public ffmpeg API at the moment where calling code
is exposed to a network address?  If so, where?
2) If not, how would you go about exposing calling code to a network address via
the public API, in terms of the data structure(s) to use?

_
FFmpeg issue tracker 

_

[issue1514] Crash inside avi_read_packet() when demuxing dv in avi

[verem]

verem  added the comment:

I recently faced with same issue:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-January/081286.html

The only question i doubt is two audio tracks stored in DV 25 stream

_
FFmpeg issue tracker 

_