New EVENT : Video Fast Update

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

New EVENT : Video Fast Update

luiverco
Hi all

We are planning to add support in our video codecs for the fast update
commands defined in H.245 recommendation. This is also functionally
similar to what is required by the RTP/AVPF spec (RFC4585).


I would like to start the discussion in the mailing list on how to
implement this
 so that we can do something that eventually will be defined by GStreamer and
not proprietary to the codecs in our platforms.

My current proposal tries to be general enough to cover what is required by
both recommendations

- New upstream event
 GST_EVENT_VIDEO_FAST_UPDATE
   A feedback message from decoder to encoder. Contains information of the type
   of feedback the decoder is producing.  Event travels up to rtpbin
where it is
   formatted and sent via the RTCP channel

- New structures to be attached to the event:

Name: PictureLoss
 Empty stuct

Name: SliceLoss
 *Key: (type) value*
 First: (guint) address of the first MB(MacroBlocks) where corruption
was detected
 Number: (guint) number of MB's corrupted
 PictureID:(guint) codec specific picture identifier

Name: ReferencePictureSelection
*Key:(type)value*
 Native_info: (guint*) array with a codec specific bitstring that
defines the current reference picture/slices in used by the decoder
 Length: (guint) length of the bitstring


Regards

Miguel

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: New EVENT : Video Fast Update

Olivier Crête-2
Hi,

On Tue, 2010-09-07 at 14:12 +0300, Miguel Verdu wrote:
> We are planning to add support in our video codecs for the fast update
> commands defined in H.245 recommendation. This is also functionally
> similar to what is required by the RTP/AVPF spec (RFC4585).

I've already started to implement RTP/AVPF, code at:
http://git.collabora.co.uk/?p=user/tester/gst-plugins-good.git;a=shortlog;h=refs/heads/avpf-timing


> My current proposal tries to be general enough to cover what is required by
> both recommendations
>
> - New upstream event
> Name: PictureLoss
>  Empty stuct

There is already a "GstForceKeyUnit" event defined for that, and it is
implemented by most of the relevant open source encoder (x264enc,
gst-ffmpeg and theoraenc) elements. My AVPF branch produces that
GstForceKeyUnit event on the relevant AVPF RTCP messages.

Documented at:
http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/docs/design/draft-keyframe-force.txt


> Name: SliceLoss
> Name: ReferencePictureSelection

As for the two other types, I agree that we should have new events for
those. Maybe extend GstForceKeyUnit for the slice loss. But
ReferencePictureSelection probably requires a new custom event type.

And don't feel too bad, I just re-implemented something that had existed
for like a year ;)

--
Olivier Crête
[hidden email]

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New EVENT : Video Fast Update

Stefan Sauer
On 07.09.2010 14:33, Olivier Crête wrote:

> Hi,
>
> On Tue, 2010-09-07 at 14:12 +0300, Miguel Verdu wrote:
>  
>> We are planning to add support in our video codecs for the fast update
>> commands defined in H.245 recommendation. This is also functionally
>> similar to what is required by the RTP/AVPF spec (RFC4585).
>>    
> I've already started to implement RTP/AVPF, code at:
> http://git.collabora.co.uk/?p=user/tester/gst-plugins-good.git;a=shortlog;h=refs/heads/avpf-timing
>
>
>  
>> My current proposal tries to be general enough to cover what is required by
>> both recommendations
>>
>> - New upstream event
>> Name: PictureLoss
>>  Empty stuct
>>    
> There is already a "GstForceKeyUnit" event defined for that, and it is
> implemented by most of the relevant open source encoder (x264enc,
> gst-ffmpeg and theoraenc) elements. My AVPF branch produces that
> GstForceKeyUnit event on the relevant AVPF RTCP messages.
>
> Documented at:
> http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/docs/design/draft-keyframe-force.txt
>
>
>  
>> Name: SliceLoss
>> Name: ReferencePictureSelection
>>    
> As for the two other types, I agree that we should have new events for
> those. Maybe extend GstForceKeyUnit for the slice loss. But
> ReferencePictureSelection probably requires a new custom event type.
>
> And don't feel too bad, I just re-implemented something that had existed
> for like a year ;)
>
>  
And we should move the event to e.g. the video libarry to have it
documented so that people find it :)
https://bugzilla.gnome.org/show_bug.cgi?id=607742

Stefan

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel