- Aug 27, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Aug 12, 2014
-
-
have_data is not propagated from gst_ffmpegviddec_video_frame to gst_ffmpegviddec_frame. have_data is only set to 1 in gst_ffmpegviddec_frame if a frame pointer is passed. However, this is not true while draining, which means that have_data from libav will be ignored. https://bugzilla.gnome.org/show_bug.cgi?id=734608
-
- Aug 11, 2014
-
-
Sebastian Dröge authored
-
- Jul 19, 2014
-
-
Sebastian Dröge authored
-
- Jul 11, 2014
-
-
Sebastian Dröge authored
-
- Jun 28, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Jun 22, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Jun 21, 2014
-
-
Sebastian Dröge authored
After the recent addition of negotiation support for MPEG4 part 2 profiles via caps it can happen that the generated caps at this point still contain multiple profiles. For example if downstream does not care. Just fixate anything here and use those caps.
-
- Jun 06, 2014
-
-
Wim Taymans authored
Place the supported profiles in the srcpad caps of the mpeg4 encoder.
-
Wim Taymans authored
Remove x-xvid and x-3ivx. The last place where they were used are in the srcpad caps of the decoder but since the decoder will never actually output those caps we can safely remove them.
-
Wim Taymans authored
x-xvid is deprecated, we don't want to expose it on the encoder, just leave it only exposed on the decoder.
-
Wim Taymans authored
This reverts commit e066785a. x-xvid and x-3ivx are removed, we don't want to expose them again.
-
-
Vincent Penquerc'h authored
If audio_in is NULL, we'll send a NULL frame to libav, to flush the codec. In that case, we won't know how many samples the codec will have used, so we use -1 (for don't know) when letting the base class know about the buffer. Coverity 1195177
-
- Jun 02, 2014
-
-
Sebastian Dröge authored
Should fix CID 1219865, which looks like the code analysis algorithm was just confused.
-
- May 29, 2014
-
-
Wim Taymans authored
Always enable 4MV flag for MPEG4 Pare the profile property and enable more features for advanced-simple profile. video/x-xvid is advanced-simple profile so enable more features. We now also support encoding of video/x-xvid so add this to the caps. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=651320
-
Wim Taymans authored
We first want to complete negotiation before opening the encoder. Negotiation might configure flags and other things that might be needed when opening the encoder.
-
Wim Taymans authored
We previously mapped some caps to MPEG4 and codec_tag so we can use the codec_tag again to map to the original caps.
-
- May 26, 2014
-
-
Thiago Santos authored
To remove replicated code from all demuxers to a single standard way of aggregating flow returns
-
Thiago Santos authored
The 'no_buffer' error case is from the 0.10 era when a pad_alloc was made before decoding the data and avdemuxer could check again the flow returns for a not-linked. This isn't a valid use case anymore in 1.0
-
- May 21, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
From 211fa5f to 1f5d3c3
-
- May 19, 2014
-
-
As some libav encoders (such as MPEG2) use a thread_count parameter to control how many threads to use, and since it was always being set to 0 (which uses the default), suboptimal threading can sometimes be chosen. This extends the libav encoders to allow for a max-threads parameter which is passed into the internal structure to control this knob if applicable to the encoder. https://bugzilla.gnome.org/show_bug.cgi?id=726612
-
- May 16, 2014
-
-
gst_video_decoder_get_max_decding_time doesn't return a GstClockTime but a GstClockTimeDiff, and thus one needs to compare it against G_MAXINT_64. The returning of a boolean and the extra subsequent code in _video_frame was uselessly complicated. The previous behaviour led to artefacts when the decoder tried to hurry up. https://bugzilla.gnome.org/show_bug.cgi?id=730075
-
- May 14, 2014
-
-
Sebastian Dröge authored
-
- May 08, 2014
-
-
Nicolas Dufresne authored
As we don't know how many output buffers we need to operate, we need to avoid pool that can't grow. Otherwise the pipeline may stall, waiting for buffers. For now, we require it to be able to grow to at least 32 buffers, which I think is a fair amount of buffers for decoders. https://bugzilla.gnome.org/show_bug.cgi?id=726299
-
- May 03, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
From bcb1518 to 211fa5f
-
- Apr 30, 2014
-
-
Vincent Penquerc'h authored
While there, fix mixup in num/den with par (copied from fps, apparently, and fps inverts fps to time base). Coverity 1139696
-
Vincent Penquerc'h authored
and other nonsensical time base values while we're at it. Coverity 1139699
-
- Apr 29, 2014
-
-
Sebastian Dröge authored
AVPacket contains AVBufferRef which may leak unless unreffed properly. https://bugzilla.gnome.org/show_bug.cgi?id=726814
-
AVPacket contains AVBufferRef which may leak unless unreffed properly. https://bugzilla.gnome.org/show_bug.cgi?id=726814
-
- Apr 14, 2014
-
-
Edward Hervey authored
We can just re-use the encoder variable
-
- Apr 08, 2014
-
-
Edward Hervey authored
CID #1139943
-
Edward Hervey authored
CID #1139752
-