[vlc-devel] vlc-devel Digest, Vol 62, Issue 10

toufik moad toufikmaod at gmail.com
Tue Jul 24 14:41:59 CEST 2012


Hello,
I am a student at the University of Rennes 1, France. I just installed the
codec vlc compilation mode. I looked at the file omxil.c which you are the
author. I want to extract the quantization  parameter QP. until now I have
not yet found. I find in the file OMX_Image.h, all data structures that
handle the compression process and understood QP. but these structures are
not used in the code of vlc. Please, do you have any ideas or a method  to
extract this  paramete, QP?
Thank you in advance.

--
Toufik

2012/7/10 <vlc-devel-request at videolan.org>

> Send vlc-devel mailing list submissions to
>         vlc-devel at videolan.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mailman.videolan.org/listinfo/vlc-devel
> or, via email, send a message with subject or body 'help' to
>         vlc-devel-request at videolan.org
>
> You can reach the person managing the list at
>         vlc-devel-owner at videolan.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vlc-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: [PATCH] HLS: Check for Segment in all hls streams.
>       (Frederic YHUEL)
>    2. Re: [PATCH] audioscrobbler: prevent an endless loop inside
>       the main loop (Rafa?l Carr?)
>    3. Re: [PATCH] HLS: Check for Segment in all hls streams.
>       (David Glaude)
>    4. Trying to fix wrong playback order after items are        rearranged
>       (David Fuhrmann)
>    5. [PATCH] OS/2: Add live555 supports (KO Myung-Hun)
>    6. Re: Trying to fix wrong playback order after items are
>       rearranged ( R?mi Denis-Courmont)
>    7. Re: [PATCH] HLS: Check for Segment in all hls streams.
>       (Frederic YHUEL)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 9 Jul 2012 15:16:17 +0200
> From: Frederic YHUEL <fyhuel at viotech.net>
> To: Mailing list for VLC media player developers
>         <vlc-devel at videolan.org>
> Subject: Re: [vlc-devel] [PATCH] HLS: Check for Segment in all hls
>         streams.
> Message-ID:
>         <
> CAKHNsC1oG1fvKTU7OCca4QmCuT_3FYUh9jaJXVK00LY5bpCLMg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Jul 9, 2012 at 2:43 PM, satish MR <satishmr123 at gmail.com> wrote:
> > Hi Frederic YHUEL,
> >
> > Thanks for the review.
> > Sorry for writing to your personal mail.
>
> No problem, but I reply to the ML.
>
> > I dont know how to reply to exact
> > thread of my patch.
> >
>
> Really?!
>
> > Sorry, I missed few codelines (handling of null values returned from
> > getsegment()) in the patch i sent.
> >
>
> That was not my point.
>
> > without this patch, Getsegment() will not search in all hls streams for
> > available segments.
>
> Yes it will, provided that hls_Get and segment_GetSegment don't return
> NULL.
>
> If hls_Get returns NULL, then it's probably better that Getsegment
> also returns NULL.
>
> If segment_GetSegment returns NULL, then I don't know... maybe it's
> better to continue, and look at other streams, indeed.
>
> > with that I could get things working for a live hls stream playback.
> >
>
> Could you share that stream?
>
> Best regards
> Fr?d?ric
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 09 Jul 2012 15:33:49 +0200
> From: Rafa?l Carr? <funman at videolan.org>
> To: Mailing list for VLC media player developers
>         <vlc-devel at videolan.org>
> Subject: Re: [vlc-devel] [PATCH] audioscrobbler: prevent an endless
>         loop inside the main loop
> Message-ID: <4FFADDBD.50201 at videolan.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Le 2012-07-05 16:52, Fabian Keil a ?crit :
> > Fabian Keil <freebsd-listen at fabiankeil.de> wrote:
> >
> >> R?mi Denis-Courmont <remi at remlab.net> wrote:
> >>
> >>> On Wed, 20 Jun 2012 13:28:45 +0200, Fabian Keil
> >>> <freebsd-listen at fabiankeil.de> wrote:
> >>>> The attached patch fixes a compiler warning and might fix the
> >>>> issue reported in: https://trac.videolan.org/vlc/ticket/6286.
> >>>>
> >>>> I don't have an account an thus couldn't test it, though.
> >>>
> >>> Might as well use INT64_MIN as initializer. That would be simpler.
> >>
> >> Thanks for the feedback.
> >>
> >> Grepping around in vlc, I couldn't find a single instance where
> >> INT64_MIN is used to initialize an mtime_t. The commonly used
> >> integers seem to be 0 and -1, and now that I know that mtime_t is
> >> signed, I prefer -1 as well.
> >>
> >> I also realized that the second chunk of my patch shouldn't be
> >> necessary. Attached is an updated version that only contains
> >> the first chunk and initializes with -1 instead of 0.
> >>
> >> Does this address your concern about simplicity, or do
> >> you still prefer INT64_MIN?
> >
> > Any opinions?
>
> Applied, thanks.
>
> Sorry for the delay
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 9 Jul 2012 17:07:14 +0200
> From: David Glaude <david.glaude at gmail.com>
> To: Mailing list for VLC media player developers
>         <vlc-devel at videolan.org>
> Subject: Re: [vlc-devel] [PATCH] HLS: Check for Segment in all hls
>         streams.
> Message-ID:
>         <
> CAEDB7ovOuLo7Shq0nsMfBj_2te6es-+n05R+thkVWT+i90oNSA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> May I ask if we are talking about the possible unavailability of some
> chunck/segment in one of the available bitrate of a stream?
>
> And the missing pieces would however be advertised in the playlist?
>
> While I can imagine possible scenario (like redundant encoder producing
> each different video bitrate of the same event and one of them failing), I
> feel it is very bad idea to advertise non-existing file.
>
> Do that kind of stream exist in the wild?
>
> I wonder how other player do deal with that scenario?
>
> David Glaude
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120709/da9103dd/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Mon, 9 Jul 2012 20:12:31 +0200
> From: David Fuhrmann <david.fuhrmann at googlemail.com>
> To: Mailing list for VLC media player developers
>         <vlc-devel at videolan.org>
> Subject: [vlc-devel] Trying to fix wrong playback order after items
>         are     rearranged
> Message-ID: <837A8D54-4084-488E-9A13-E4319F988003 at googlemail.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Guys,
>
> Currently, I'm trying to fix #4397. The problem is that if you rearrange
> playlist items in the osx gui while another item is playing, the new order
> is not taken into account.
>
> Comparing the code from the mac osx and qt gui, I noticed that qt uses
> playlist_TreeMoveMany for drag and drop handling, while the osx gui uses
> playlist_NodeRemoveItem and playlist_NodeInsert.
>
> To fix the issue for the osx gui (and probably all other modules which
> will use these functions), I came up with the below solution.
> But I don't know the core good enough, therefore I want to ask for
> opinions from the core experts here. Is this patch ok? Or should this
> problem be solved in another way (using another function, e.g. TreeMoveMany
> as in the qt ui)?
>
> Now, here is the diff:
>
> --- a/src/playlist/tree.c
> +++ b/src/playlist/tree.c
> @@ -222,6 +222,9 @@ int playlist_NodeInsert( playlist_t *p_playlist,
>                   i_position,
>                   p_item );
>      p_item->p_parent = p_parent;
> +
> +    pl_priv( p_playlist )->b_reset_currently_playing = true;
> +    vlc_cond_signal( &pl_priv( p_playlist )->signal );
>      return VLC_SUCCESS;
>  }
>
>
> Best regards,
> David
>
> ------------------------------
>
> Message: 5
> Date: Tue, 10 Jul 2012 15:47:55 +0900
> From: KO Myung-Hun <komh78 at gmail.com>
> To: vlc-devel at videolan.org
> Subject: [vlc-devel] [PATCH] OS/2: Add live555 supports
> Message-ID: <1341902875-36480-1-git-send-email-komh at chollian.net>
>
> ---
>  configure.ac |    9 ++++++++-
>  1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 1861e90..255125e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1581,7 +1581,12 @@ AS_IF([test "${enable_live555}" != "no" -a -n
> "${CXX}"], [
>    AC_LANG_PUSH(C++)
>    VLC_SAVE_FLAGS
>    AS_IF([test -z "${CONTRIB_DIR}"], [
> -    CPPFLAGS_live555="-I/usr/include/liveMedia -I/usr/include/groupsock
> -I/usr/include/BasicUsageEnvironment -I/usr/include/UsageEnvironment"
> +    AS_IF([test ${SYS} != "os2"], [
> +      CPPFLAGS_live555="-I/usr/include/liveMedia -I/usr/include/groupsock
> -I/usr/include/BasicUsageEnvironment -I/usr/include/UsageEnvironment"
> +    ], [
> +      CPPFLAGS_live555="-I/usr/lib/live/liveMedia/include
> -I/usr/lib/live/groupsock/include
> -I/usr/lib/live/BasicUsageEnvironment/include
> -I/usr/lib/live/UsageEnvironment/include"
> +      LDFLAGS_live555="-L/usr/live/lib/liveMedia
> -L/usr/live/lib//groupsock -L/usr/live/lib/BasicUsageEnvironment
> -L/usr/live/lib/UsageEnvironment"
> +    ])
>    ], [
>      CPPFLAGS_live555="-I${CONTRIB_DIR}/include/liveMedia
> -I${CONTRIB_DIR}/include/groupsock
> -I${CONTRIB_DIR}/include/BasicUsageEnvironment
> -I${CONTRIB_DIR}/include/UsageEnvironment"
>    ])
> @@ -1589,6 +1594,7 @@ AS_IF([test "${enable_live555}" != "no" -a -n
> "${CXX}"], [
>      CPPFLAGS_live555="${CPPFLAGS_live555} -DSOLARIS"
>    ])
>    CPPFLAGS="${CPPFLAGS} ${CPPFLAGS_live555}"
> +  LDFLAGS="${LDFLAGS} ${LDFLAGS_live555}"
>
>    AC_CACHE_CHECK([for live555 version 1324598400 or later],
> [ac_cv_live555], [
>      AC_PREPROC_IFELSE([AC_LANG_PROGRAM([
> @@ -1623,6 +1629,7 @@ You can get an updated one from
> http://www.live555.com/liveMedia .])
>      dnl We need to check for pic because live555 don't provide shared libs
>      dnl and we want to build a plugins so we need -fPIC on some arch.
>      VLC_ADD_CXXFLAGS([live555], [${CPPFLAGS_live555}])
> +    VLC_ADD_LDFLAGS([live555], [${LDFLAGS_live555}])
>      AC_CHECK_LIB(liveMedia_pic, main, [
>        VLC_ADD_PLUGIN([live555])
>        VLC_ADD_LIBS([live555], [-lliveMedia_pic ${other_libs_pic}])
> --
> 1.7.3.2
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 10 Jul 2012 10:02:19 +0300
> From: " R?mi Denis-Courmont" <remi at remlab.net>
> To: vlc-devel at videolan.org
> Subject: Re: [vlc-devel] Trying to fix wrong playback order after
>         items are       rearranged
> Message-ID: <201207101002.19872.remi at remlab.net>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
>    Hello,
>
> I don't think the playlist should change the current item when being
> sorted...
>
> On Monday 09 July 2012, David Fuhrmann wrote:
> > Hi Guys,
> >
> > Currently, I'm trying to fix #4397. The problem is that if you rearrange
> > playlist items in the osx gui while another item is playing, the new
> order
> > is not taken into account.
> >
> > Comparing the code from the mac osx and qt gui, I noticed that qt uses
> > playlist_TreeMoveMany for drag and drop handling, while the osx gui uses
> > playlist_NodeRemoveItem and playlist_NodeInsert.
> >
> > To fix the issue for the osx gui (and probably all other modules which
> will
> > use these functions), I came up with the below solution. But I don't know
> > the core good enough, therefore I want to ask for opinions from the core
> > experts here. Is this patch ok? Or should this problem be solved in
> > another way (using another function, e.g. TreeMoveMany as in the qt ui)?
> >
> > Now, here is the diff:
> >
> > --- a/src/playlist/tree.c
> > +++ b/src/playlist/tree.c
> > @@ -222,6 +222,9 @@ int playlist_NodeInsert( playlist_t *p_playlist,
> >                   i_position,
> >                   p_item );
> >      p_item->p_parent = p_parent;
> > +
> > +    pl_priv( p_playlist )->b_reset_currently_playing = true;
> > +    vlc_cond_signal( &pl_priv( p_playlist )->signal );
> >      return VLC_SUCCESS;
> >  }
> >
> >
> > Best regards,
> > David
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > http://mailman.videolan.org/listinfo/vlc-devel
> --
> R?mi Denis-Courmont
> http://www.remlab.info
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 10 Jul 2012 10:26:16 +0200
> From: Frederic YHUEL <fyhuel at viotech.net>
> To: Mailing list for VLC media player developers
>         <vlc-devel at videolan.org>
> Subject: Re: [vlc-devel] [PATCH] HLS: Check for Segment in all hls
>         streams.
> Message-ID:
>         <CAKHNsC3q3tS=U_8GCRfPtiUi+1nfPb=
> 4cNc2ixHd4zTqaEPeoA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Jul 9, 2012 at 5:07 PM, David Glaude <david.glaude at gmail.com>
> wrote:
> > May I ask if we are talking about the possible unavailability of some
> > chunck/segment in one of the available bitrate of a stream?
> >
> > And the missing pieces would however be advertised in the playlist?
> >
>
> I think that in the case Satish try to handle, the missing piece is
> not advertised. Like... one of the playlists is not updated anymore
> for some reason, and segment_GetSegment returns NULL.
>
>
> >
> > I wonder how other player do deal with that scenario?
> >
>
> Good question!
>
> Best regards
> Fr?d?ric
>
>
> ------------------------------
>
> _______________________________________________
> vlc-devel mailing list
> vlc-devel at videolan.org
> http://mailman.videolan.org/listinfo/vlc-devel
>
>
> End of vlc-devel Digest, Vol 62, Issue 10
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120724/92ec8f6b/attachment.html>


More information about the vlc-devel mailing list