[FFmpeg-devel] How do I add the starttime and totalduration DOUBLE-type metadata to FLV files?
Google's standard for FLV (as used on older versions of YouTube player and Google Video player) involves at least 2 additional metadata tags. These are starttime and totalduration. The value for starttime should be 0, and totalduration should be equal to the official Adobe Flash Video standard "duration" metadata tag. But there's a problem. These tags are of type DOUBLE, not STRING, and FFMPEG only allows the insertion of STRING type metadata tags, at least from what I've seen. If this isn't already possible in FFMPEG, please consider this a feature request for future versions. FFMPEG developers, please hear my reasoning for this feature. This is important for making the FLV files work correctly in Google's old video players. I have a copy of one of those players (the actual SWF file, as downloaded from an archived copy of a video.google.com webpage on the Internet Archive Wayback Machine, archive.org). I've successfully embedded the player in a website I have hosted on my own PC via the Mongoose web server software. And I've managed to successfully make it play 2 FLV files. One is directly from the old Google Videos website (again archived on the Wayback Machine), and the other I got from converting (via FFMPEG) one of my own video files to the FLV format. The original Google FLV file works completely without glitches in the webpage embedded Google Video player. The one I got from converting another video file to FLV does play but it has issues. These issues are that it says NaN for both the start and stop times in the player's time display, and also that I can't seek at all in the video. I can only let the video play through all the way from beginning to end. If I could add the DOUBLE-type metadata tags starttime and totalduration, I would likely have a working FLV file, which would play perfectly in the Google Video player. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Bug in FFMPEG video filter TINTERLACE needs fixing
Problem is it's not as simple as just patching it to start at field 1 instead of field 2. It really depends on your signal source. If your signal source recorded all lines that contain at least some image signal (even if only half the line contains image signal), then the top line of the image is the first line of field 2 (the even field). However, if your signal source only recorded lines where the entire line contains image signal then the top line of the image is the first line of field 1 (the odd field). When using the TINTERLACE video filter (at least in MERGEX2 mode), one actually needs to be able to select which field comes first (odd field first, or even field first). This unfortunately is a much more in-depth patch to the software than just hardcoding a different starting field. You will need to add commandline option for the TINTERLACE filter in FFMPEG in order to allow for user-selection of OFF or EFF. On Sun, Jul 12, 2020 at 9:10 AM Paul B Mahol wrote: > On 7/12/20, Ben Hutchinson wrote: > > I was assuming it started from 1, because in the NTSC video standard > (which > > is of course where the concept of interlaced video originated), the first > > field is called field 1. Field 1 contains the first full line of > displayed > > video (though technically field 2 contains the first image data, one line > > above the first displayed line of field 1, although it's only the right > > half of that line). > > I sent patch to fix this. > > > > > On Sat, Jul 11, 2020 at 4:07 AM Paul B Mahol wrote: > > > >> On 7/11/20, Ben Hutchinson wrote: > >> > I was reading it directly from the official FFMPEG website. > >> > https://ffmpeg.org/ffmpeg-filters.html > >> > All the info about the TINTERLACE filter I got from reading the info > >> there. > >> > > >> > >> OK, lets try again, where have you read that first frame is always an > >> odd frame, one with 1 number. > >> FFmpeg counts from 0. > >> > >> > On Fri, Jul 10, 2020 at 2:14 AM Paul B Mahol > wrote: > >> > > >> >> On 7/8/20, Ben Hutchinson wrote: > >> >> > According to the documentation on the TINTERLACE video filter, the > >> >> > filter > >> >> > mode called MERGEX2 will "Move odd frames into the upper field, > even > >> >> > into > >> >> > the lower field, generating a double height frame at same frame > >> >> > rate." > >> >> But > >> >> > it doesn't do this, at least in some cases (not sure about all > >> >> > cases). > >> >> The > >> >> > first frame in a sequence should be considered frame one (an odd > >> frame) > >> >> for > >> >> > >> >> Where is this written? > >> >> > >> >> > the purpose of this interlacing algorithm. However, that is not > >> >> > what's > >> >> > happening in my experience. At least with raw video (using "-f > >> >> > rawvideo") > >> >> > it's treating the first frame as frame zero (an even frame) and > thus > >> my > >> >> > first frame (which contains top-field data) ends up getting put > into > >> the > >> >> > bottom-field of the output video, and this is messing up the > output. > >> >> Please > >> >> > fix this. > >> >> > ___ > >> >> > ffmpeg-devel mailing list > >> >> > ffmpeg-devel@ffmpeg.org > >> >> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> >> > > >> >> > To unsubscribe, visit link above, or email > >> >> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > >> >> ___ > >> >> ffmpeg-devel mailing list > >> >> ffmpeg-devel@ffmpeg.org > >> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> >> > >> >> To unsubscribe, visit link above, or email > >> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > >> > ___ > >> > ffmpeg-devel mailing list > >> > ffmpeg-devel@ffmpeg.org > >> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > > >> > To unsubscribe, visit link above, or email > >> > ffmpeg-devel-requ...@ffmpeg.org with
Re: [FFmpeg-devel] Bug in FFMPEG video filter TINTERLACE needs fixing
I was assuming it started from 1, because in the NTSC video standard (which is of course where the concept of interlaced video originated), the first field is called field 1. Field 1 contains the first full line of displayed video (though technically field 2 contains the first image data, one line above the first displayed line of field 1, although it's only the right half of that line). On Sat, Jul 11, 2020 at 4:07 AM Paul B Mahol wrote: > On 7/11/20, Ben Hutchinson wrote: > > I was reading it directly from the official FFMPEG website. > > https://ffmpeg.org/ffmpeg-filters.html > > All the info about the TINTERLACE filter I got from reading the info > there. > > > > OK, lets try again, where have you read that first frame is always an > odd frame, one with 1 number. > FFmpeg counts from 0. > > > On Fri, Jul 10, 2020 at 2:14 AM Paul B Mahol wrote: > > > >> On 7/8/20, Ben Hutchinson wrote: > >> > According to the documentation on the TINTERLACE video filter, the > >> > filter > >> > mode called MERGEX2 will "Move odd frames into the upper field, even > >> > into > >> > the lower field, generating a double height frame at same frame rate." > >> But > >> > it doesn't do this, at least in some cases (not sure about all cases). > >> The > >> > first frame in a sequence should be considered frame one (an odd > frame) > >> for > >> > >> Where is this written? > >> > >> > the purpose of this interlacing algorithm. However, that is not what's > >> > happening in my experience. At least with raw video (using "-f > >> > rawvideo") > >> > it's treating the first frame as frame zero (an even frame) and thus > my > >> > first frame (which contains top-field data) ends up getting put into > the > >> > bottom-field of the output video, and this is messing up the output. > >> Please > >> > fix this. > >> > ___ > >> > ffmpeg-devel mailing list > >> > ffmpeg-devel@ffmpeg.org > >> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > > >> > To unsubscribe, visit link above, or email > >> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Bug in FFMPEG video filter TINTERLACE needs fixing
I was reading it directly from the official FFMPEG website. https://ffmpeg.org/ffmpeg-filters.html All the info about the TINTERLACE filter I got from reading the info there. On Fri, Jul 10, 2020 at 2:14 AM Paul B Mahol wrote: > On 7/8/20, Ben Hutchinson wrote: > > According to the documentation on the TINTERLACE video filter, the filter > > mode called MERGEX2 will "Move odd frames into the upper field, even into > > the lower field, generating a double height frame at same frame rate." > But > > it doesn't do this, at least in some cases (not sure about all cases). > The > > first frame in a sequence should be considered frame one (an odd frame) > for > > Where is this written? > > > the purpose of this interlacing algorithm. However, that is not what's > > happening in my experience. At least with raw video (using "-f rawvideo") > > it's treating the first frame as frame zero (an even frame) and thus my > > first frame (which contains top-field data) ends up getting put into the > > bottom-field of the output video, and this is messing up the output. > Please > > fix this. > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Bug in FFMPEG video filter TINTERLACE needs fixing
According to the documentation on the TINTERLACE video filter, the filter mode called MERGEX2 will "Move odd frames into the upper field, even into the lower field, generating a double height frame at same frame rate." But it doesn't do this, at least in some cases (not sure about all cases). The first frame in a sequence should be considered frame one (an odd frame) for the purpose of this interlacing algorithm. However, that is not what's happening in my experience. At least with raw video (using "-f rawvideo") it's treating the first frame as frame zero (an even frame) and thus my first frame (which contains top-field data) ends up getting put into the bottom-field of the output video, and this is messing up the output. Please fix this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Please allow specific starting frame to be selected.
I have an MP4 video, and I'm trying to extract 100 frames starting from frame number 271. As of right now I can select duration by time using -t or by frame count by using -frames. And I can also select starting point by time by using -ss. However, I believe that as of now there is no command line switch to select the starting point by frame number. PLEASE add a feature such as a command line switch like "-sf" for "starting frame". I need to be able to select a range of video frames based entirely on frame numbers (not time stamps). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] fftools/ffmpeg: add support for per frame rotation and flip
Please unsubscribe me from this mailing list. It is filling up my inbox. Or
at least switch me to getting a daily digest from the mailing list. The way
it is set up now, I'm getting an email for every post, and my inbox is
cluttered.
On Thu, May 16, 2019 at 12:21 AM Jun Li wrote:
> Fix #6945
> Current implementaion for autorotate works fine for stream
> level rotataion but no support for frame level operation
> and frame flip. This patch is for adding flip support and
> per frame operations.
> ---
> fftools/cmdutils.c | 9 ++---
> fftools/cmdutils.h | 2 +-
> fftools/ffmpeg.c| 21 ++-
> fftools/ffmpeg.h| 2 +
> fftools/ffmpeg_filter.c | 81 ++---
> fftools/ffplay.c| 28 +++---
> 6 files changed, 126 insertions(+), 17 deletions(-)
>
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 9cfbc45c2b..b8bb904419 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size)
> return array;
> }
>
> -double get_rotation(AVStream *st)
> +double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
> {
> -uint8_t* displaymatrix = av_stream_get_side_data(st,
> -
> AV_PKT_DATA_DISPLAYMATRIX, NULL);
> double theta = 0;
> -if (displaymatrix)
> -theta = -av_display_rotation_get((int32_t*) displaymatrix);
> +
> +if (display_matrix)
> +theta = -av_display_rotation_hflip_get(display_matrix, hflip);
>
> theta -= 360*floor(theta/360 + 0.9/360);
>
> diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> index 6e2e0a2acb..dce44ed6e1 100644
> --- a/fftools/cmdutils.h
> +++ b/fftools/cmdutils.h
> @@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size);
> char name[128];\
> av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
>
> -double get_rotation(AVStream *st);
> +double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
>
> #endif /* FFTOOLS_CMDUTILS_H */
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 01f04103cf..9ea1aaa930 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2126,6 +2126,24 @@ static int
> ifilter_has_all_input_formats(FilterGraph *fg)
> return 1;
> }
>
> +static int ifilter_display_matrix_need_from_frame(InputFilter *ifilter,
> AVFrame* frame)
> +{
> +int32_t* stream_matrix =
> (int32_t*)av_stream_get_side_data(ifilter->ist->st,
> +
> AV_PKT_DATA_DISPLAYMATRIX, NULL);
> +// if we already have display matrix from stream, use it instead of
> extracting
> +// from frame.
> +if (stream_matrix) {
> +memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);
> +return 0;
> +}
> +
> +// cleanup the display matrix, may be from last frame
> +memset(ifilter->display_matrix, 0, 4 * 9);
> +av_display_rotation_set(ifilter->display_matrix, 0);
> +
> +return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
> +}
> +
> static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
> {
> FilterGraph *fg = ifilter->graph;
> @@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter *ifilter,
> AVFrame *frame)
> ifilter->channel_layout != frame->channel_layout;
> break;
> case AVMEDIA_TYPE_VIDEO:
> -need_reinit |= ifilter->width != frame->width ||
> +need_reinit |= ifilter_display_matrix_need_from_frame(ifilter,
> frame) ||
> + ifilter->width != frame->width ||
> ifilter->height != frame->height;
> break;
> }
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index eb1eaf6363..8331720663 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -251,6 +251,8 @@ typedef struct InputFilter {
> int channels;
> uint64_t channel_layout;
>
> +int32_t display_matrix[9];
> +
> AVBufferRef *hw_frames_ctx;
>
> int eof;
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 72838de1e2..1894f30561 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg,
> AVFilterInOut *in)
> fg->inputs[fg->nb_inputs - 1]->format = -1;
> fg->inputs[fg->nb_inputs - 1]->type = ist->st->codecpar->codec_type;
> fg->inputs[fg->nb_inputs - 1]->name = describe_filter_link(fg, in, 1);
> +av_display_rotation_set(fg->inputs[fg->nb_inputs -
> 1]->display_matrix, 0);
>
> fg->inputs[fg->nb_inputs - 1]->frame_queue = av_fifo_alloc(8 *
> sizeof(AVFrame*));
> if (!fg->inputs[fg->nb_inputs - 1]->frame_queue)
> @@ -807,22 +808,43 @@ static int configure_input_video_filter(FilterGraph
> *fg, InputFilter *ifilter,
> last_filter = ifilter->filter;
>
> if (ist->autorotate) {
> -double theta = get_rotation(ist->st);
> +int hflip = 0;
> +double theta =
Re: [FFmpeg-devel] [PATCH] avcodec/packet: initialize payload size to zero
How do I unsubscribe from ffmpeg-devel? On Tue, Apr 2, 2019 at 8:57 PM Andriy Gelman wrote: > From: Andriy Gelman > > --- > libavcodec/avpacket.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c > index 8f0603df78..6ae092ed31 100644 > --- a/libavcodec/avpacket.c > +++ b/libavcodec/avpacket.c > @@ -44,6 +44,7 @@ FF_ENABLE_DEPRECATION_WARNINGS > pkt->flags= 0; > pkt->stream_index = 0; > pkt->buf = NULL; > +pkt->size = 0; > pkt->side_data= NULL; > pkt->side_data_elems = 0; > } > -- > 2.21.0 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Bug in YUV decoder
On Fri, Mar 15, 2019, 11:34 PM Reto Kromer Ben Hutchinson wrote: > > >What is top posting? I'll try to avoid it if I know what it is. > > Then please "google" it. Thanks! > > https://ffmpeg.org/contact.html#MailingLists > https://en.wikipedia.org/wiki/Posting_style#Top-posting > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel Sorry about that. Posting from most email software automatically foes top posting it seems. I need to manually reposition the cursor. Did you also see the message I sent about the bug with the Color_range command line switch? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Bug in YUV decoder
So what you are saying is that "-pix_fmt yuv420p -color_range 2" should produce the same output as "-pix_fmt yuvj420p" (both producing YUV video with full range 0 to 255)? Unfortunately I tried that, and it doesn't work. I saved the FFMPEG outputs to "-f rawvideo" and then looked at the individual bytes of image data in a hex editor. There is absolutely no effect when using "-color_range", even though it should override the use of "j" or "non-j" YUV type in the "-pix_fmt" parameter. It does not override this. It seems that this is a bug. On Fri, Mar 15, 2019 at 5:21 PM Hendrik Leppkes wrote: > On Fri, Mar 15, 2019 at 10:13 PM Ben Hutchinson wrote: > > > > Also, on another note, why don't we have yuvj410p as a video format? Each > > chroma-subsampled versionof yuv (partial range YUV) format should have an > > equivalent chroma-subsampled version of yuvj (full range yuv). This would > > allow various experimental setups to be tested. > > > > The J formats are deprecated, you should specify the color range > independently using the appropriate color_range parameter, and new > ones will not be added. > > PS: > Please don't top post on this list. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Bug in YUV decoder
What is top posting? I'll try to avoid it if I know what it is. On Fri, Mar 15, 2019 at 5:21 PM Hendrik Leppkes wrote: > On Fri, Mar 15, 2019 at 10:13 PM Ben Hutchinson wrote: > > > > Also, on another note, why don't we have yuvj410p as a video format? Each > > chroma-subsampled versionof yuv (partial range YUV) format should have an > > equivalent chroma-subsampled version of yuvj (full range yuv). This would > > allow various experimental setups to be tested. > > > > The J formats are deprecated, you should specify the color range > independently using the appropriate color_range parameter, and new > ones will not be added. > > PS: > Please don't top post on this list. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Bug in YUV decoder
Also, on another note, why don't we have yuvj410p as a video format? Each chroma-subsampled versionof yuv (partial range YUV) format should have an equivalent chroma-subsampled version of yuvj (full range yuv). This would allow various experimental setups to be tested. On Fri, Mar 15, 2019 at 1:00 AM Gyan wrote: > > > On 15-03-2019 12:05 PM, Ben Hutchinson wrote: > > Note that it does not matter what pixel format the encoder uses (j or > > non-j). This bug is only present in the decoder, and only when I select > the > > non-j version of a yuv pixel format. This bug is present in the ffplay > > decoder (possibly also in the ffmpeg decoder, but I've not yet tested > that). > > Suspected bugs should be reported at trac.ffmpeg.org > > This is not a decoder bug. ffplay uses SDL to render video; SDL supports > a limited number of YUV texture formats. So, most YUV inputs are > converted to yuv420p. Due to how the format negotiation happens, the > YUVJ formats are converted to BGRA for display, which is of course, not > subsampled. To emulate the same result with yuv444p, modify ffplay > command to, > > ffplay -f rawvideo -pix_fmt yuv444p -framerate 10 -vf format=bgra -s > 640x480 - > > > Decoder bugs are best tested with some type of framehash muxer. > > > Gyan > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Bug in YUV decoder
Doesn't SDL support YUV444 as a YUV format? Or does it only support YUV420? Also, thanks for the tip about -vf format=bgra On Fri, Mar 15, 2019 at 1:00 AM Gyan wrote: > > > On 15-03-2019 12:05 PM, Ben Hutchinson wrote: > > Note that it does not matter what pixel format the encoder uses (j or > > non-j). This bug is only present in the decoder, and only when I select > the > > non-j version of a yuv pixel format. This bug is present in the ffplay > > decoder (possibly also in the ffmpeg decoder, but I've not yet tested > that). > > Suspected bugs should be reported at trac.ffmpeg.org > > This is not a decoder bug. ffplay uses SDL to render video; SDL supports > a limited number of YUV texture formats. So, most YUV inputs are > converted to yuv420p. Due to how the format negotiation happens, the > YUVJ formats are converted to BGRA for display, which is of course, not > subsampled. To emulate the same result with yuv444p, modify ffplay > command to, > > ffplay -f rawvideo -pix_fmt yuv444p -framerate 10 -vf format=bgra -s > 640x480 - > > > Decoder bugs are best tested with some type of framehash muxer. > > > Gyan > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Bug in YUV decoder
When I decode rawvideo yuv444p in ffplay that was encoded in ffmpeg (using the test source called "testsrc"), I notice there is blurring between adjacent colors (both horizontally and vertically), which would typically be present in yuv420p. I can avoid this by switching the decoder to use a pixel format of yuvj444p instead of yuv444p, but that makes the brightness levels incorrect if the image is encoded as yuv444p instead of yuvj444p (as one would expect). This problem of blurring the color of the image (equivalent to yuv420p) also happens in yuv422p (requiring me to switch the decoder's pixel format to yuvj422p to get it to only have a yuv422 blurring, which is horizontally blurred only). It seems that when I use the "j" version of yuv, it works fine, but when I use the "non-j" version of yuv it adds an extra chroma blurring filter on the decoder. Note that it does not matter what pixel format the encoder uses (j or non-j). This bug is only present in the decoder, and only when I select the non-j version of a yuv pixel format. This bug is present in the ffplay decoder (possibly also in the ffmpeg decoder, but I've not yet tested that). Here's some sample command lines that produce this bug: ffmpeg -re -f lavfi -i testsrc=r=10:s=640x480 -f rawvideo -pix_fmt yuv444p -frames 1 -|ffplay -f rawvideo -pix_fmt yuv444p -framerate 10 -s 640x480 - ffmpeg -re -f lavfi -i testsrc=r=10:s=640x480 -f rawvideo -pix_fmt yuv422p -frames 1 -|ffplay -f rawvideo -pix_fmt yuv422p -framerate 10 -s 640x480 - Here's some sample command lines that avoid the bug by using the "j" version of yuv in the decoder: ffmpeg -re -f lavfi -i testsrc=r=10:s=640x480 -f rawvideo -pix_fmt yuv444p -frames 1 -|ffplay -f rawvideo -pix_fmt yuvj444p -framerate 10 -s 640x480 - ffmpeg -re -f lavfi -i testsrc=r=10:s=640x480 -f rawvideo -pix_fmt yuv444p -frames 1 -|ffplay -f rawvideo -pix_fmt yuvj444p -framerate 10 -s 640x480 - The version of FFMPEG (and FFPLAY) that I discovered this bug in is: N-93298-g0ce759defd ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Feature request
I would like to be able to deinterlace a video by converting full-height frames into half-height fields (where each frame of the output represents one field of the input) at double the frame rate. The way this would work is it would take the top field (or bottom field) first and export it as the first frame in the output file, and then take the next field of the input and output it as the second frame in the output file. Then it moves on to the first field of the second input frame, and outputs this as the 3rd frame of the output. And this continues until the output file has twice as many frames as the input, at half the height of the input, and runs at twice the frame rate as the input. For example: Input Frame1 Field1 > Output Frame1 Input Frame1 Field2 > Output Frame2 Input Frame2 Field1 > Output Frame3 Input Frame2 Field2 > Output Frame4 I would also like to be able to do the reverse of this, take a video file who's frames represent fields, and then interlace them so that they actually are fields within frames in the output video, and at the same time cut the frame rate in half. For example: Input Frame1 > Output Frame1 Field1 Input Frame2 > Output Frame1 Field2 Input Frame3 > Output Frame2 Field1 Input Frame4 > Output Frame2 Field2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Feature suggestion for FFMPEG
FFMPEG should be able to output raw AAC audio stream, without any encapsulation, in the same way that a raw h264 video stream can be output from FFMPEG. Currently AAC audio can only be output within various container/encapsulation formats (such as MP4 or ADTS containers). If you try to output raw AAC by doing "-f aac" it gives the same error as if you selected any other invalid container format, like "-f abcxyz". Please add this feature so I can save a truly unencapsulated AAC audio stream. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
