- 01 Dec, 2016 1 commit
-
-
Philip Langdale authored
This function can return an error in certain situations. Fixes Coverity CID 703707.
-
- 02 Nov, 2016 10 commits
-
-
Philip Langdale authored
We don't need to document the horrible hacks that we removed.
-
Philip Langdale authored
The old code had to retain a partial frame across two calls in the case of separate interlaced fields. Now, we know that we'll get both fields within the same receive_frame call, and so we don't need to manage the frame as private state any more.
-
Philip Langdale authored
It's not possible to return EAGAIN when we've passed input EOF and are in draining mode. If do return EAGAIN, we're saying there's no way to get any more output - which isn't true in many cases. So let's handled these cases in an internal loop as best we can.
-
Philip Langdale authored
-
Philip Langdale authored
Now that we don't need to do ridiculous things to work out if a frame is interlaced or not, we don't need an extra h.264 parser.
-
Philip Langdale authored
This was needed to detect an interlaced failure case that doesn't happen with the new decode api.
-
Philip Langdale authored
It seems that without all the other 1:1 heuristics, we don't have a fundamental problem trusting the interlaced flag on output pictures. That's a relief.
-
Philip Langdale authored
I'm not sure why, but the mpeg4_unpack_bframes bsf is not interacting well with seeking. Looking at the code, it should be ok, with possibly one warning shown, but I see it getting stuck for an extended period of time after a seek where a packed frame is cached to be shown later. So, I gave up on that and went back to making the old hardware based path work. Turns out that it wasn't broken except that some samples have a 6 byte drop packet which I wasn't accounting for. Now it works again and seeks are good.
-
Philip Langdale authored
The new decode API allows for m:n decode patterns, which is what you need to use this hardware in a sane way. There are so many situations where 1:1 doesn't happen naturally that it's a miracle I got it working as well as I did. With this change, we can throw all of the crazy heuristics and sleeps(!) out, and things work correctly.
-
Philip Langdale authored
Why on earth the hardware returns garbage for the first sample of a decoded picture is anyone's guess. The simplest reasonable way to patch it up is to copy the first sample of the second line. This should result in the correct chroma values (because the data was original 4:2:0 upsampled to 4:2:2) even if the luma is isn't.
-
- 12 Oct, 2016 2 commits
-
-
Philip Langdale authored
The hardware handling of packed bframes was always questionable but it used to ok with my workaround. Today, not so much. But today we have a bsf to unpack the bframes, so let's just use that and be done with it.
-
Philip Langdale authored
With all the various refactorings that have happened over the years, the current pts logic is very broken for non-trivial cases (ie: ones where not every frame/field has a meaningful pts assocated with it). Generally, we do not want to write AV_NOPTS_VALUE as the output timestamp, regardless of anything else. It's better to pass zero if there's no other information. Additionally, interlaced content where the decoder returns each field separately can result in the first field carrying the timestamp and the second having AV_NOPTS_VALUE. It's clearly wrong to overwrite the valid timestamp. So, let's just never write AV_NOPTS_VALUE into an output frame. Empirically, this fixed playback of interlaced mpeg2 and h.264 and mpeg4-asp with packed b-frames in an avi container.
-
- 21 Sep, 2016 1 commit
-
-
Philip Langdale authored
Although the old API is supposed to be functional, the crystalhd decoder is currently not working for non-annex.b h.264 content. So, let's update to the modern API and make it work again. Signed-off-by: Philip Langdale <philipl@overt.org>
-
- 30 Oct, 2014 1 commit
-
-
Michael Niedermayer authored
this leaves some av_free() where the pointer is overwritten shortly later Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 08 Jul, 2014 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 18 May, 2014 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 04 Oct, 2013 1 commit
-
-
Clément Bœsch authored
See b2bed932.
-
- 13 Mar, 2013 3 commits
-
-
Clément Bœsch authored
-
Clément Bœsch authored
Coccinelle profile used: @@ expression r, ctx, f, loglevel, str, flags; @@ -if ((r = ff_get_buffer(ctx, f, flags)) < 0) { - av_log(ctx, loglevel, str); - return r; -} +if ((r = ff_get_buffer(ctx, f, flags)) < 0) + return r; @@ expression r, ctx, f, loglevel, str; @@ -if ((r = ff_reget_buffer(ctx, f)) < 0) { - av_log(ctx, loglevel, str); - return r; -} +if ((r = ff_reget_buffer(ctx, f)) < 0) + return r; @@ expression r, ctx, f, loglevel, str, flags; @@ -if ((r = ff_thread_get_buffer(ctx, f, flags)) < 0) { - av_log(ctx, loglevel, str); - return r; -} +if ((r = ff_thread_get_buffer(ctx, f, flags)) < 0) + return r; ...along with some manual patches for the remaining ones.
-
Philip Langdale authored
Signed-off-by: Philip Langdale <philipl@overt.org> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 05 Dec, 2012 1 commit
-
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
- 03 Nov, 2012 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 07 Aug, 2012 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 03 Aug, 2012 1 commit
-
-
Clément Bœsch authored
-
- 29 Jun, 2012 1 commit
-
-
Lou Logan authored
Also update some common misspelled words in patcheck Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 06 May, 2012 1 commit
-
-
Philip Langdale authored
Istvan Sebok provided a sample where field pair -> two fields content was being misdetected by the existing logic. I added an additional test to check the input picture type as identified by our h.264 parser. Signed-off-by: Philip Langdale <philipl@overt.org> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 17 Apr, 2012 2 commits
-
-
sebist authored
Signed-off-by: sebist <sebok.istvan@gmail.com> Reviewed-by: Philip Langdale <philipl@overt.org> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
sebist authored
Signed-off-by: sebist <sebok.istvan@gmail.com> Reviewed-by: Philip Langdale <philipl@overt.org> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 25 Mar, 2012 1 commit
-
-
Philip Langdale authored
With the flag in place, it's hard to actually use the decoder, and I'm happy with how it works, with the exception of DivX3 where I've never found a sample that worked that I was confident actually matched what the hardware claimed to support. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 22 Jan, 2012 2 commits
-
-
Philip Langdale authored
This was a regression that came in when I switched to using the h.264 annex b filter all the time. As the filter modifies extradata, its use violates the statelessness assumption that exists in the 'ffmpeg' command line tool, and maybe elsewhere. It assumes that a docoder can be reinitalised and pointed to an existing stream and get the same results. For now, the only way to meet this requirement is to backup the extradata. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Philip Langdale authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 17 Oct, 2011 1 commit
-
-
Clément Bœsch authored
-
- 22 Jun, 2011 3 commits
-
-
Philip Langdale authored
Now that we're converting all streams to Annex B format, we can identify them as such to the hardware. Signed-off-by: Philip Langdale <philipl@overt.org>
-
Philip Langdale authored
As we're now always running mp4 format streams through the annex b filter, it makes sense to pass the filtered stream down, as libcrystalhd would be doing the conversion internally anyway. Signed-off-by: Philip Langdale <philipl@overt.org>
-
Philip Langdale authored
Originally, we needed to restore the original extradata after initialising the mp4toannexb filter because mplayer would end up taking two passes through the init sequence for the same stream and end up miscategorising the stream. This doesn't seem to happen anymore, making the backup/restore process unnecessary. Signed-off-by: Philip Langdale <philipl@overt.org>
-
- 14 Jun, 2011 2 commits
-
-
Philip Langdale authored
The H.264 parser that we use to detect interlacing can only handle an Annex B stream, so we need to actually use the filter. This is unfortunate as the crystalhd library is already doing this conversion internally. A future change will reorganise the decode path more completely so that we can feed the converted stream into libcrystalhd and avoid the second conversion. Signed-off-by: Philip Langdale <philipl@overt.org>
-
Philip Langdale authored
In preparation for using the filter on the actual bitstream, we need to extend it's lifetime to match that of the decoder. Signed-off-by: Philip Langdale <philipl@overt.org>
-
- 30 Apr, 2011 1 commit
-
-
Philip Langdale authored
I still don't fully understand the cause but the difference between the samples that trigger the bug and the samples that don't is that the former uses delay frames and the later uses drop frames as placeholders for the packed frame. So, if we see the one type of frame, we can assume the bug will or won't be present. Right now, I'm detecting the frame types by size, which may not be safe in general, but given the specific codec and file type, I expect any scenario where we encounter these frames where they aren't being used for b-frame packing won't care one way or another whether the work around is in effect or not. Signed-off-by: Philip Langdale <philipl@overt.org>
-
- 24 Apr, 2011 1 commit
-
-
Philip Langdale authored
The CrystalHD hardware can do scaling, which is particularly desirable when dealing with some high resolution clips that take so long to decode and copy out that they end up playing back slower than realtime. By using scaling, we can make the output frames smaller and reduce the copy out time. This option takes the desired horizontal width in pixels, and the hardware will do an aspect-scale. Upscaling is not supported and the hardware will simply ignore any request to do so. Signed-off-by: Philip Langdale <philipl@overt.org>
-