[Ffmpeg-devel] Re: ffmpeg-devel Digest, Vol 18, Issue 103
Rahul Ray
rahul.ray
Fri Sep 15 01:44:00 CEST 2006
is it possible to grab mpeg-4 video from live streaming by providing rtsp link ?
How ? Would you please suggest how I can play and grab video which is
mpeg 4 or quicktime ?
-best,
Rahul
On 9/14/06, ffmpeg-devel-request at mplayerhq.hu
<ffmpeg-devel-request at mplayerhq.hu> wrote:
> Send ffmpeg-devel mailing list submissions to
> ffmpeg-devel at mplayerhq.hu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> or, via email, send a message with subject or body 'help' to
> ffmpeg-devel-request at mplayerhq.hu
>
> You can reach the person managing the list at
> ffmpeg-devel-owner at mplayerhq.hu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ffmpeg-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH] new version (Andrew Voznytsa)
> 2. Re: [PATCH] new version (Michael Niedermayer)
> 3. Re: h264 playback performance (Corey Hickey)
> 4. API for encoding videos (mark)
> 5. Re: h264 playback performance (Loren Merritt)
> 6. Re: h264 playback performance (Corey Hickey)
> 7. Re: [PATCH] Split DV demuxer/muxer (Roman Shaposhnick)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 14 Sep 2006 22:25:31 +0300
> From: Andrew Voznytsa <andrew.voznytsa at gmail.com>
> Subject: Re: [Ffmpeg-devel] [PATCH] new version
> To: FFMpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <4509ACAB.1050304 at gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Michael Niedermayer wrote:
> > Hi
> >
> > On Thu, Sep 14, 2006 at 06:59:31PM +0300, Andrew Voznytsa wrote:
> >
> >> Michael Niedermayer wrote:
> >>
> >>> wont that break amr stored in containers with a sample_rate different from
> >>> that?
> >>>
> >>>
> >> As it was mentioned by Benjamin Larsson it is invalid, but as you say -
> >> possible.
> >>
> >> New, spears saving, patch attached. I'd notice that I need it in case
> >> when lavc is used without lavf. Also, for illegal use fans, it would be
> >> worth to change faad.c because sample_rate/channels are initialized
> >> using GA_DecoderSpecificInfo() (AKA extradata) instead preserving
> >> container values.
> >>
> >
> > i think channels can be set unconditionally and
> > please avoid the code duplication
> >
> >
> If this is so principal: according to RFC 3267 'stereophonic speech
> session' is possible. This RFC says that 'out-of-band signaling must be
> used to indicate the number of channels' . And 'Although AMR and AMR-WB
> codecs themselves do not support encoding of multi-channel audio content
> into a single bit stream, they can be used to separately encode and
> decode each of the individual channels'. IMO in such case number of AMR
> frames feed to decoder (and decoded) is equal to signaled number of
> channels. After decoding decoder should post process output data if
> required (i.e. interleave samples). Currently lavc's wrapper does not
> support this case. Then it would be right to check signaled number of
> channels and if it is 2+ return error saying that multichannel decoding
> not supported. Alternative way for decoding multichannel AMR would be to
> use a few instances of lavc's AMR decoder wrapper, but for user side it
> is a bit unusual use case when single track should be decoded using more
> than one decoder. Plus it is better to implement it once on lavc side
> (when required) then implementing it each time on user side.
>
> --
> Best regards,
> Andrew Voznytsa
>
> -------------- next part --------------
> Index: libavcodec/amr.c
> ===================================================================
> --- libavcodec/amr.c (revision 6252)
> +++ libavcodec/amr.c (working copy)
> @@ -107,6 +107,23 @@
> return(MR122);
> }
>
> +static void amr_decode_fix_avctx(AVCodecContext * avctx)
> +{
> + const int is_amr_wb = avctx->codec_id == CODEC_ID_AMR_WB;
> +
> + if(avctx->sample_rate == 0)
> + {
> + avctx->sample_rate = 8000 * is_amr_wb;
> + }
> +
> + if(avctx->channels == 0)
> + {
> + avctx->channels = 1;
> + }
> +
> + avctx->frame_size = 160 * is_amr_wb;
> +}
> +
> #ifdef CONFIG_AMR_NB_FIXED
> /* fixed point version*/
> /* frame size in serial bitstream file (frame type + serial stream + flags) */
> @@ -143,6 +160,15 @@
> av_log(avctx, AV_LOG_ERROR, "Speech_Decode_Frame_init error\n");
> return -1;
> }
> +
> + amr_decode_fix_avctx(avctx);
> +
> + if(avctx->channels > 1)
> + {
> + av_log(avctx, AV_LOG_ERROR, "amr_nb: multichannel decoding not supported\n");
> + return -1;
> + }
> +
> return 0;
> }
>
> @@ -345,6 +371,15 @@
> av_log(avctx, AV_LOG_ERROR, "Decoder_Interface_init error\r\n");
> return -1;
> }
> +
> + amr_decode_fix_avctx(avctx);
> +
> + if(avctx->channels > 1)
> + {
> + av_log(avctx, AV_LOG_ERROR, "amr_nb: multichannel decoding not supported\n");
> + return -1;
> + }
> +
> return 0;
> }
>
> @@ -596,6 +631,15 @@
> AMRWBContext *s = (AMRWBContext *)avctx->priv_data;
> s->frameCount=0;
> s->state = D_IF_init();
> +
> + amr_decode_fix_avctx(avctx);
> +
> + if(avctx->channels > 1)
> + {
> + av_log(avctx, AV_LOG_ERROR, "amr_wb: multichannel decoding not supported\n");
> + return -1;
> + }
> +
> return 0;
> }
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 14 Sep 2006 22:37:04 +0200
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] [PATCH] new version
> To: FFMpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20060914203703.GK17160 at MichaelsNB>
> Content-Type: text/plain; charset=us-ascii
>
> Hi
>
> On Thu, Sep 14, 2006 at 10:25:31PM +0300, Andrew Voznytsa wrote:
> > Michael Niedermayer wrote:
> > > Hi
> > >
> > > On Thu, Sep 14, 2006 at 06:59:31PM +0300, Andrew Voznytsa wrote:
> > >
> > >> Michael Niedermayer wrote:
> > >>
> > >>> wont that break amr stored in containers with a sample_rate different from
> > >>> that?
> > >>>
> > >>>
> > >> As it was mentioned by Benjamin Larsson it is invalid, but as you say -
> > >> possible.
> > >>
> > >> New, spears saving, patch attached. I'd notice that I need it in case
> > >> when lavc is used without lavf. Also, for illegal use fans, it would be
> > >> worth to change faad.c because sample_rate/channels are initialized
> > >> using GA_DecoderSpecificInfo() (AKA extradata) instead preserving
> > >> container values.
> > >>
> > >
> > > i think channels can be set unconditionally and
> > > please avoid the code duplication
> > >
> > >
> > If this is so principal: according to RFC 3267 'stereophonic speech
> > session' is possible. This RFC says that 'out-of-band signaling must be
> > used to indicate the number of channels' . And 'Although AMR and AMR-WB
> > codecs themselves do not support encoding of multi-channel audio content
> > into a single bit stream, they can be used to separately encode and
> > decode each of the individual channels'. IMO in such case number of AMR
> > frames feed to decoder (and decoded) is equal to signaled number of
> > channels. After decoding decoder should post process output data if
> > required (i.e. interleave samples). Currently lavc's wrapper does not
> > support this case. Then it would be right to check signaled number of
> > channels and if it is 2+ return error saying that multichannel decoding
> > not supported. Alternative way for decoding multichannel AMR would be to
> > use a few instances of lavc's AMR decoder wrapper, but for user side it
> > is a bit unusual use case when single track should be decoded using more
> > than one decoder. Plus it is better to implement it once on lavc side
> > (when required) then implementing it each time on user side.
> >
> > --
> > Best regards,
> > Andrew Voznytsa
> >
>
> > Index: libavcodec/amr.c
> > ===================================================================
> > --- libavcodec/amr.c (revision 6252)
> > +++ libavcodec/amr.c (working copy)
> > @@ -107,6 +107,23 @@
> > return(MR122);
> > }
> >
> > +static void amr_decode_fix_avctx(AVCodecContext * avctx)
> > +{
> > + const int is_amr_wb = avctx->codec_id == CODEC_ID_AMR_WB;
> > +
> > + if(avctx->sample_rate == 0)
> > + {
> > + avctx->sample_rate = 8000 * is_amr_wb;
> > + }
>
> AMR_NB will end up with a sample_rate of 0 here ...
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In the past you could go to a library and read, borrow or copy any book
> Today you'd get arrested for mere telling someone where the library is
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 14 Sep 2006 15:06:52 -0700
> From: Corey Hickey <bugfood-ml at fatooh.org>
> Subject: Re: [Ffmpeg-devel] h264 playback performance
> To: FFMpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <4509D27C.8030904 at fatooh.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Andreas ?man wrote:
> > Hi
> >
> > First of all, let me make you understand that the intention of
> > this mail is not to whine about the performance of ffmpeg.
> >
> > Now, during the summer my tv-provider did some trials with HDTV.
> > The video format used was CABAC-encoded h.264 in 720p @ 50Hz running
> > at approx 20Mbps.
> >
> > Sadly, i discovered that my current machine (Pentium-M w/ 2Mb cache @
> > 1.8Ghz) decodes a frame in ~33ms in average (which obviously is too
> > slow). I know that the CABAC encoding is quite CPU hungry so it's
> > not very surprising.
> >
> > I'm about to buy a new machine and I'm interested if anyone with
> > a "hot" CPU can try playing the clip I've uploaded and report back.
>
> I can't say for sure with such a short clip, but my system can almost
> handle what you uploaded.
>
> $ mplayer SVT\ HD\ Teaser-ac3-chopped.ts
> Triggers the "your system is too slow" message.
>
> $ mplayer SVT\ HD\ Teaser-ac3-chopped.ts -lavdopts skiploopfilter=nonref
> A-V desync fluctuates but remains below 0.3 seconds at all times.
>
> $ mplayer SVT\ HD\ Teaser-ac3-chopped.ts -lavdopts skiploopfilter=all
> The same as above.
>
> $ mplayer SVT\ HD\ Teaser-ac3-chopped.ts -ao pcm:fast:file=/dev/null \
> -vo null -benchmark
> BENCHMARKs: VC: 3.815s VO: 0.001s A: 0.064s Sys: 0.059s = 3.939s
> BENCHMARK%: VC: 96.8479% VO: 0.0140% A: 1.6306% Sys: 1.5075% = 100.0000%
>
>
> I have an Athlon64 3400+ Newcastle overclocked to 2.5 GHz.
>
> > Has there been any thoughts about making the h264-decoder
> > multithreaded? With the arrival of multi-core CPUs it would
> > seem like a wise thing to ponder.
>
> There's '-lavdopts threads=n'. I don't know how well it works, but it
> does run multithreaded.
>
> > I'd be happy to contribute to such a thing, though, it be
> > nice to get a few pointers or directions.
>
> If there's anything you can work on, somebody else might be able to give
> you suggestions.
>
> -Corey
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 14 Sep 2006 15:44:30 -0700
> From: mark <rkmr.em at gmail.com>
> Subject: [Ffmpeg-devel] API for encoding videos
> To: "FFMpeg development discussions and patches"
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID:
> <e04d2e90609141544y39ba2ff7wd4af62a38f489962 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi
> I am trying to encode an uncompressed raw bitstream to MPEG-2 I frame only.
> Does any one have an API / example program for using ffmpeg's library for
> encoding video?
> The example given in here
> http://www.inb.uni-luebeck.de/~boehme/using_libavcodec.html
>
> is only for decoding.
> Thanks a lot!
> mark
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 14 Sep 2006 15:46:22 -0700 (PDT)
> From: Loren Merritt <lorenm at u.washington.edu>
> Subject: Re: [Ffmpeg-devel] h264 playback performance
> To: FFMpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID:
> <Pine.A41.4.64.0609141543230.28574 at dante65.u.washington.edu>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, 14 Sep 2006, Corey Hickey wrote:
> > Andreas ?man wrote:
> >>
> >> Now, during the summer my tv-provider did some trials with HDTV.
> >> The video format used was CABAC-encoded h.264 in 720p @ 50Hz running
> >> at approx 20Mbps.
> >>
> >> Sadly, i discovered that my current machine (Pentium-M w/ 2Mb cache @
> >> 1.8Ghz) decodes a frame in ~33ms in average (which obviously is too
> >> slow). I know that the CABAC encoding is quite CPU hungry so it's
> >> not very surprising.
> >>
> >> I'm about to buy a new machine and I'm interested if anyone with
> >> a "hot" CPU can try playing the clip I've uploaded and report back.
> >
> > I can't say for sure with such a short clip, but my system can almost handle
> > what you uploaded.
> >
> > $ mplayer SVT\ HD\ Teaser-ac3-chopped.ts
> > Triggers the "your system is too slow" message.
> >
> > $ mplayer SVT\ HD\ Teaser-ac3-chopped.ts -lavdopts skiploopfilter=nonref
> > A-V desync fluctuates but remains below 0.3 seconds at all times.
>
> 20mbit/s, and it's still not low enough qp to elminate deblocking?
>
> >> Has there been any thoughts about making the h264-decoder
> >> multithreaded? With the arrival of multi-core CPUs it would
> >> seem like a wise thing to ponder.
> >
> > There's '-lavdopts threads=n'. I don't know how well it works, but it does
> > run multithreaded.
>
> The only lavc codecs that implement it are mpeg1/2.
>
> >> Can h264-slices be decoded independently ?
> >>
> >> Should one move the entropy-decoding to an individual thread
> >> and push decoded macro-blocks between the threads?
> >>
> >> Any other ideas?
>
> Possible multithreading modes:
> * 3 threads: cabac, mc+dct, deblocking.
> * Decode slices independently. Depends on the file having slices.
> * Decode frames simultaneously but synchronized. Increases decoding delay.
> * Decode frames independently. Depends on the file having non-referenced
> B-frames, and increases decoding delay.
> * Some combination of the above.
>
> --Loren Merritt
>
> ------------------------------
>
> Message: 6
> Date: Thu, 14 Sep 2006 16:08:13 -0700
> From: Corey Hickey <bugfood-ml at fatooh.org>
> Subject: Re: [Ffmpeg-devel] h264 playback performance
> To: FFMpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <4509E0DD.7060803 at fatooh.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Loren Merritt wrote:
> > On Thu, 14 Sep 2006, Corey Hickey wrote:
> >> Andreas ?man wrote:
> >>>
> >>> Now, during the summer my tv-provider did some trials with HDTV.
> >>> The video format used was CABAC-encoded h.264 in 720p @ 50Hz running
> >>> at approx 20Mbps.
> >>>
> >>> Sadly, i discovered that my current machine (Pentium-M w/ 2Mb cache @
> >>> 1.8Ghz) decodes a frame in ~33ms in average (which obviously is too
> >>> slow). I know that the CABAC encoding is quite CPU hungry so it's
> >>> not very surprising.
> >>>
> >>> I'm about to buy a new machine and I'm interested if anyone with
> >>> a "hot" CPU can try playing the clip I've uploaded and report back.
> >>
> >> I can't say for sure with such a short clip, but my system can almost
> >> handle what you uploaded.
> >>
> >> $ mplayer SVT\ HD\ Teaser-ac3-chopped.ts
> >> Triggers the "your system is too slow" message.
> >>
> >> $ mplayer SVT\ HD\ Teaser-ac3-chopped.ts -lavdopts skiploopfilter=nonref
> >> A-V desync fluctuates but remains below 0.3 seconds at all times.
> >
> > 20mbit/s, and it's still not low enough qp to elminate deblocking?
>
> I don't know; I haven't looked at it, but merely played it remotely. :)
> I'll have a look at the quality when I get home tonight.
>
> >>> Has there been any thoughts about making the h264-decoder
> >>> multithreaded? With the arrival of multi-core CPUs it would
> >>> seem like a wise thing to ponder.
> >>
> >> There's '-lavdopts threads=n'. I don't know how well it works, but it
> >> does run multithreaded.
> >
> > The only lavc codecs that implement it are mpeg1/2.
>
> Ah. I stand corrected.
>
> -Corey
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 14 Sep 2006 16:32:47 -0700
> From: Roman Shaposhnick <rvs at sun.com>
> Subject: Re: [Ffmpeg-devel] [PATCH] Split DV demuxer/muxer
> To: FFMpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <1158276767.1236.16.camel at work.sfbay.sun.com>
> Content-Type: text/plain
>
> On Thu, Sep 14, 2006 at 01:42:38PM +0200, Panagiotis Issaris wrote:
> > Hi,
> >
> > Op woensdag 6 september 2006 08:01, schreef Roman Shaposhnik:
> > > > [...]
> > > > I'm trying to keep the changes self-contained, so this patch does
> not contain the
> > > > fixes for the linking error when disabling DV.
> > >
> > > Guys,
> > >
> > > since I'm at Sun Tech Days in Seattle now, could I ask you
> > > to hold off the putback of this patch for a couple of days
> > > so that I can have a chance to coordinate it with the HDDV
> > > development and also frankly review it a bit more closely ?
> > Any words of approval or disapproval on your behalf regarding
> > this patch? :)
>
> Well, I'm still waiting for you to send out a result of
> a sequence of commands suggested by Michael. That'll make
> it much more easier to tell what's going on.
>
> Thanks,
> Roman.
>
>
>
> ------------------------------
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
> End of ffmpeg-devel Digest, Vol 18, Issue 103
> *********************************************
>
More information about the ffmpeg-devel
mailing list