Re: [FFmpeg-user] ffmpeg x265 profile Main10
On 21/07/15 09:15, Osztrovszky Zsolt wrote: > Hello Guys, > I’d like to create an h265 video with Main10 profile (10 bits). > However ffmpeg keeps saying that profile=main10 is an unknown option. ISTR that x265 profiles are not yet supported, however you can still make a MAIN10 file by setting other parameters. for example:- -c:v libx265 -pix_fmt yuv420p10le \ -preset fast \ -x265-params level=5.2:vbv-bufsize=6:vbv-maxrate=6:crf=20 Prodcued some thing that when probed shows:- Stream #0:0(und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv), 3840x2160. > My command: > ffmpeg -i vid.ts -c:v libx265 -preset medium -x265-params > “profile=main10:crf=30” -c:a aac strict experimental -b:a 128k output.mp4 > > please help me > > cheers, > Zsolt > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] ffmpeg x265 profile Main10
On 21/07/15 13:28, Moritz Barsnick wrote: > Hi Zsolt, > > On Tue, Jul 21, 2015 at 14:10:13 +0200, Osztrovszky Zsolt wrote: >> As you can see in line 20, the input video is hevc Main 10, but the encoder >> still coding it to Main profile, 8 bit (line 27). >> It also says in line 23: incompatible pixel format 'yuv420p10le' for libx265. >> What am I missing here? > > I think you have to compile libx265 with 10 bit support. (libx264 > suffers the same restriction.) Unfortunate, but that's the way it is. Indeed you need the cmake option "HIGH_BIT_DEPTH:BOOL=ON" This gives you up to 16 bit support, so not quite the same as x264. > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] FFMPEG MXF Issue
On 16/09/15 07:12, Irfan Saleem wrote: > Hi, > > I am facing a issue while playing and converting a media taken from Ikegami > GFPack. Please find below FFPLAY and FFMPEG consoles: > > *FFPLAY: * > C:\Program Files\ffmpeg\ffmpeg-20150629\bin>ffplay.exe > "D:\data\irfans\Downloads > \0001V002(1).MXF" > ffplay version N-73245-gca3b274 Copyright (c) 2003-2015 the FFmpeg > developers > built with gcc 4.9.2 (GCC) > [...] > Failed to open file 'D:\data\irfans\Downloads\0001V002(1).MXF' or configure > filt > ergraph > I would take a guess that the material is J2K given the filtergraph part of the comment, and perhaps in a different layout than that expected. Can you provide a small sample? > *FFMPEG:* > C:\Program Files\ffmpeg\ffmpeg-20150629\bin>ffmpeg.exe -i > "D:\data\irfans\Downlo > ads\0001V002(1).MXF" -vcodec copy -b:v 100M "D:\data\irfans\My > Documents\Testing > \test.mov" specifying a bit rate when you are doing a stream copy makes no sense at all. > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Link to sources on evermeet.cx/ffmpeg/
On 17/11/15 18:12, Leonard Bogard wrote: > Looks like you're not blind as I also can't find a download link to the > source he's using to compile the binaries on his site. > > On Tue, Nov 17, 2015 at 9:55 AM, John Pilgrim wrote: > >> Thanks, but I'm looking for the source code not the binaries. >> It's my understanding that the source code needs to be distributed with >> the binary. >> I'm not trying to police this on evermeet.cx, but rather comply with the >> license terms myself as I use evermeet.cx's binaries. >> John >> Although the source code is not directly linked to. The binaries are clearly labelled with the git checkout hash used as the source to build them, and can therefore be obtained by checking out that hash from the main git repo. Since the Evermeet site is linked to from the main ffmpeg.org one, presumably this enough to comply with the requirements of the GPL, at this stage. If you are wishing to redistribute with source, then You will need to checkout the relevant version from the main repo. All AIUI, and IANAL. >> >> On Nov 17, 2015, at 9:38 AM, Leonard Bogard wrote: >> >>> Looks like the downloads are the big green buttons with the icon of a >> cloud >>> with a down arrow in it. >>> >>> On Tue, Nov 17, 2015 at 9:35 AM, John Pilgrim >> wrote: >>> I must be bad at reading... Where on https://evermeet.cx/ffmpeg/ is the link to the sources from which the binaries were compiled? Thanks, John [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] rake failed
On 09/12/15 08:43, 浪漫﹀ァ旋律 wrote: > I'm sorry, my English is not good.The error information in the appendix.For > help I'm not sure what your build system is, but rake is a ruby program and nothing to do with ffmpeg. As such this must be a specialist set up, and you are unlikely to find anyone here with knowledge of your system. I would suggest you contact the maintainers of whatever build system you are using, which I suspect is homebrew. I notice you are trying to cross compile for arm, is that even supported in the build system? > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to change video fps from 29.970 to 25?
On 02/09/14 17:11, Andy Young wrote: >>> On Tuesday, September 2, 2014 2:21 AM, Damian Głodny >>> wrote: > >>> Hi, Arno. Thank you for advice, I will check it. I also found some >>> information >>> about converting videos from 29.970 to 23.976: >>> >>> https://documentation.apple.com/en/finalcutpro/usermanual/index.html#chapter=E%26section=2%26tasks=true >>> >>> In document above you can find some techniques to convert your videos. >>> There are >>> methods for conversion from 29.970 to 23.976 called: >>>- 3:2 Pulldown Removal, >>>- 2:3:3:2 Pulldown Removal >>>- Duplicate Frame Removal (bad) >>> >>> Is it possible to use them in FFMPEG? > >> Yes but it won't help you. These methods are for undoing telecined material. >> That is material that was originally 24 fps and was "telecined" into 30 fps. >> They will not work on your material. There are in >ffmpeg at "pullup" and >> "fieldmatch." I think you are going in circles. > >> ffmpeg cannot do what you want, unless someone adds this "optical flow" >> stuff, you are out of luck in using ffmpeg directly. > > I hope this is not "bad form" to offer an alternative to ffmpeg on this > mailing list, but in case it helps > > The ffmpeg fork, ffmbc, purports to have an interpolating frame rate filter: > > @section framerate > > Change the frame rate by interpolating new video output frames from the source > frames. > That is interpolating individual pixel values, i.e. frame blending rather than motion vector interpolation as per slowmoVideo or Alchemist. > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Change frame rate without dropping/adding frames
On 03/09/14 16:59, Elliott Balsley wrote: > Hello, > I want to take a video at 60fps and convert it to 24fps, without adding or > dropping frames. So the duration would be 2.5 times longer and the video > would play in slow motion. I realize the setpts filter can do this, but I’d > like to avoid re-encoding. This is possible in most NLE software, like Adobe > Premiere or Apple Cinema Tools; is there a way to do it in ffmpeg? When I > try setpts with “vcodec copy” I get the error “Filtering and streamcopy > cannot be used together”. Most NLE's eventually recode when exporting though... As the error says, you cannot use filters and stream copy together. So no you cannot do it. If your file is a .mov then Cinema tools is your friend. >[...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Change frame rate without dropping/adding frames
On 07/09/14 15:01, Carl Eugen Hoyos wrote: > Elliott Balsley gmail.com> writes: > >> I want to take a video at 60fps and convert it to 24fps, >> without adding or dropping frames. > > Use the input option -r. > which is ignored if using stream copy... or was in my testing:- ffmpeg -r 25 -i "FILE0307.mov" -r 25 -vcodec copy -acodec copy -y "FILE0307-25-slow.mov" turned:- Stream #0.0(eng): Video: h264 (Main), yuv420p, 1920x1080p [PAR 1:1 DAR 16:9], 6051 kb/s, 29.97 fps into:- Stream #0.0(eng): Video: h264 (Main), yuv420p, 1920x1080p [PAR 1:1 DAR 16:9], 6051 kb/s, 30.03 fps ) > Carl Eugen > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Change frame rate without dropping/adding frames
On 08/09/14 09:19, Carl Eugen Hoyos wrote: > tim nicholson ffmpeg.org> writes: > >>>> I want to take a video at 60fps and convert it >>>> to 24fps, without adding or dropping frames. >>> >>> Use the input option -r. >> >> which is ignored if using stream copy... > > Use avi as intermediate container. > (The OP originally didn't say what exactly he > needs, input option -r does change the frame > rate without dropping or adding frames.) > So if he is happy with the 2 stage process (or piping avi format out into a second ffmpeg instance stream copying back to mov) then it looks like he has a workflow. h264 in avi is not going to be understood by much other than ffmpeg... > Carl Eugen > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Change frame rate without dropping/adding frames
On 10/09/14 07:59, Carl Eugen Hoyos wrote: > Dave Rice dericed.com> writes: > >>> h264 in avi is not going to be understood >>> by much other than ffmpeg... > > Since this was quoted a few times, I'd like to > repeat that H264 in avi works fine with WMP. > (Contrary to any other output container that > would also work fine with the input option -r). > My original comment related more to media processors than media players, if all you want to do is play then fine. If someone wants to change the frame rate its usually because they want it at that different frame rate in order to do something further with it (as was the case for the original query). In those circumstances I do not think the original comment was inaccurate, but I apologise for not being precise enough. (and you could argue that only one other app falls within the "not much" category) >>[...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] ffprobe: Not using full CPU, regardless of "-threads" parameter
On 17/09/14 11:05, Peter B. wrote: > Hello, > > I've noticed that using ffprobe to analyze an FFV1/AVI file, it only > utilizes a part of the available CPU power. > For example, the following command: > > //-- > $ ffprobe_git -f lavfi -i > "movie=qctools.avi,signalstats=stat=tout+vrep+brng,cropdetect=reset=1,split[a][b];[a]field=top[a1];[b]field=bottom[b1],[a1][b1]psnr" > -show_frames -show_versions -of xml=x=1:q=1 -noprivate -threads auto > -loglevel info > qctools.avi.qctools.xml > //-- > > > According to my CPU graph monitor, there is no difference between > "-threads 1", "-threads 8" or "-threads auto". > > > However, when I decode the same video with ffmpeg, the whole CPU is > used, so I'd say the disk ain't the bottleneck: > //-- > $ ffmpeg_git -i qctools.avi -an -f framemd5 delme.xxx > //-- > > > Is there a way of have ffprobe use the whole CPU, too? > Try using a simpler ffprobe command and compare like with like. Your example includes a complex filter chain and not all filters multi-thread afaik. > > Thanks in advance, > Pb > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Duplicate frame when use seek option.
On 23/09/14 19:47, Carl Eugen Hoyos wrote: > César Sepúlveda mediastre.am> writes: > >> $ ffmpeg -y -i gop_10.mp4 -acodec aac -strict -2 >> -vcodec libx264 -ss 5.00500 -vframes 60 -level 31 >> -profile:v baseline 1.mp4 > > You may try -vsync 0 or another container because > our mov muxer tends to duplicate the first frame > to produce cfr output. > Interesting. I have just been trying to pin down a similar issue. I have also found using vframes problematical in that you tend to get inconsistent mvhd and mdhd atoms unless you also use -shortest, while using -t is fine. Trying to understand why it should need to duplicate a frame to get cfr though. Sounds like it could do with a patch. > Carl Eugen > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Duplicate frame when use seek option.
On 25/09/14 22:16, Carl Eugen Hoyos wrote: > tim nicholson ffmpeg.org> writes: > >> I have also found using vframes problematical in that >> you tend to get inconsistent mvhd and mdhd atoms unless >> you also use -shortest, while using -t is fine. > > This doesn't sound familiar to me. Did you report this? > We had a discussion on this a while back and there was a general consensus that using frame counts could have issues, which is why I switched to -t. >> Trying to understand why it should need to duplicate a >> frame to get cfr though. > > This is just the usual issue that the FFmpeg mov muxer > can't do variable frame rate. Yes, looking at my source material, it seems like the first frame has a non standard duration, which I guess ffmpeg is trying to 'correct', it only seems to be an issue if you specify -ss 0, if you leave that option off its fine. The trouble is knowing if the duration figure is wrong, or the file really has this duration anomaly on the front, and therefore which setting is best to maintain av sync. It seems to be a common issue at the front of files that were created from video tape using a Pipeline. I have long been used to the cruft they leave at the end, with the individual media streams being longer than the flagged duration. It looks like they could do with some tlc at the front as well...:( > >> Sounds like it could do with a patch. > Or maybe just a better understanding of what is going on, and the most likely best parameters to get a satisfactory result. > Certainly. > > Carl Eugen > -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Using ffprobe or ffmpeg to view atom metadata
On 25/09/14 21:05, Steve Smith wrote: > Is there a way using ffprobe or ffmpeg to view the atom metadata that is > viewable using the AtomicParsley utility? I have a mp4 file that is causing > AtomicParsley to crash when I try to pull the metadata. I've opened the file > in a hex editor and I can see the metadata values there. > [..] Boxdumper should do the trick for you, ffmpeg does not expose the atoms in a user readable way, only certain extracted metadata. -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] MXF encoding, right audio channel delayed
On 09/10/14 15:16, Alex wrote: > Ok, I've found the cause. Sometimes it is nesscary to trim the first 5 > seconds of videofile. Therefor I use "-ss 00:00:05". The result is: > > Output #0, mxf, to 'C:\Users\FiebigA\Desktop\File_MXF.mxf': > Metadata: > encoder: FFmbc 0.7 Two observations, firstly this is the ffmpeg mail list *not* ffmbc so not really the place to ask such questions. The common codebase for the two projects is some way back so what is relevant for one may not be relevant for the other. Secondly, is your source file by any chance a .mov? Some files in this format created by ingesting from tape have the first (and may be more) frame flagged as being of a different duration to the actual value calculated from the frame rate. This can cause issues for ffm*. If you drop the whole '-ss 0' is there a difference? > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Right audio channel shifted
On 10/10/14 23:46, Alex wrote: > Thats absolutely clear, but I want to use ffmpeg to solve that issue. > Have you actually tried a later version of ffmbc? Baptiste said the issue would be fixed in the next version... > Alex > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] WAS Right audio channel shifted
On 14/10/14 13:07, Celal Yasar Sahinoz wrote: > Dear All, > Just joined the mailing list. Then please take a moment to check on the ml etiquette. Specifically please do not:- 1/. top post 2/. Hijack existing threads In order to avoid further pollution of the existing thread please do *not* reply to this message, but submit a new message with your original request again. > Looking for a video player in a browser, that will play: > mp4 video codec, aac audio codec, and floor audio, en, fr, ger, tr > translations. > Each audio channel will be selected in the browser in most platforms. > I have managed to: > ffmpeg -i 00.mp4 -i 01.mp4 -i 02.mp4 -i 03.mp4 -map 0:0 -map 0:1 -map 1:0 > -map 2:0 -map 3:0 -acodec copy -vcodec copy output.mp4 > where output.mp4 is the video file with 4 audio stream muxed together. Now > how can i play it in a browser. > Regards, > Celal Yasar Sahinoz > >> Date: Tue, 14 Oct 2014 13:59:41 +0200 >> From: barsn...@gmx.net >> To: ffmpeg-user@ffmpeg.org >> Subject: Re: [FFmpeg-user] Right audio channel shifted >> >> Hi Alex, >> [ hi jacked thread] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
[FFmpeg-user] compiling with libx265
Thought I'd have a go at this, but suffered an odd epic fail.
x265 builds and installs fine, and the standalone at least responds to
x265 -h.
there are the expected:-
/usr/local/lib64/x265.a
/usr/local/lib64/pkgconfig/x265.pc
/usr/local/include/x265.h
/usr/local/include/x265_config.h
however ./configure reports:-
"ERROR: x265 not found"
This is a lie as the end of config log shows it is found, but throws up
lots of "undefined reference to " errors:-
check_pkg_config x265 x265.h x265_encoder_encode
pkg-config --exists --print-errors x265
check_func_headers x265.h x265_encoder_encode -I/usr/local/include
-L/usr/local/lib64 -lx265
check_ld cc -I/usr/local/include -L/usr/local/lib64 -lx265
check_cc -I/usr/local/include -L/usr/local/lib64
BEGIN /tmp/ffconf.8IJVvbxA.c
1 #include
2 long check_x265_encoder_encode(void) { return (long)
x265_encoder_encode; }
3 int main(void) { return 0; }
END /tmp/ffconf.8IJVvbxA.c
gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -I/usr/local/include
-static -std=c99 -fomit-frame-pointer -pthread
-I/mnt/msds-store-0/tims/ffmpeg-tux/usr/local/include/freetype2
-I/mnt/msds-store-0/tims/ffmpeg-tux/usr/local/include
-I/usr/local/include -I/usr/local/include -L/usr/local/lib64 -c -o
/tmp/ffconf.1n1Ue3xn.o /tmp/ffconf.8IJVvbxA.c
gcc -L/usr/local/lib64 -static -ldl -Wl,--as-needed -Wl,-z,noexecstack
-I/usr/local/include -L/usr/local/lib64 -o /tmp/ffconf.QTquSvyv
/tmp/ffconf.1n1Ue3xn.o -lx265 -L/usr/local/lib64 -lx264 -lpthread -lm
-L/mnt/msds-store-0/tims/ffmpeg-tux/usr/local/lib64 -lfreetype -lfdk-aac
-lfaac -lm -lz -pthread
/usr/local/lib64/libx265.a(bitcost.cpp.o): In function
`x265::BitCost::CalculateLogs()':
bitcost.cpp:(.text+0x26): undefined reference to `operator
new[](unsigned long)'
[. lots more undefined reference to ...]
/usr/local/lib64/libx265.a(wavefront.cpp.o): In function
`x265::WaveFront::~WaveFront()':
wavefront.cpp:(.text+0x4e): undefined reference to `operator delete(void*)'
/usr/local/lib64/libx265.a(wavefront.cpp.o):(.data.rel.ro._ZTIN4x2659WaveFrontE[_ZTIN4x2659WaveFrontE]+0x0):
undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
/usr/local/lib64/libx265.a(wavefront.cpp.o):(.data.rel.ro._ZTVN4x2659WaveFrontE[_ZTVN4x2659WaveFrontE]+0x28):
undefined reference to `__cxa_pure_virtual'
/usr/local/lib64/libx265.a(deblock.cpp.o): In function
`x265::Deblock::getBoundaryStrength(x265::CUData const*, int, unsigned
int, unsigned char const*)':
deblock.cpp:(.text+0x488): undefined reference to `__cxa_guard_acquire'
deblock.cpp:(.text+0x502): undefined reference to `__cxa_guard_release'
collect2: error: ld returned 1 exit status
ERROR: x265 not found
all with a fresh clone of x265 and ffmpeg ea38e5a... on gcc 4.8.3
--
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] compiling with libx265
On 28/11/14 09:55, Carl Eugen Hoyos wrote: > tim nicholson ffmpeg.org> writes: > >> Thought I'd have a go at this, but suffered an odd epic fail. > > Use this patch as a work-around: > http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/178167 > thanks Carl, not sure if it will work for me, as I am trying to make a static build and the above thread has made me realise I am missing the glibcpp static libraries, only having the glibc ones... but at least I now understand why it was such an epic fail > Carl Eugen > -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] (no subject)
On 28/11/14 14:50, Guido Holz wrote: > my problem is after exporting from Adobe Premiere and postwork with ffmpeg > I get more frames of each mp4-footage. I minimalized it to the following > example: > > [...] > :\> ffmpeg.exe -i before.mp4 > [...] > Duration: 00:02:00.00, start: 0.04, bitrate: 70 kb/s > [..] > ffmpeg.exe -i after.mp4 > [..] > Duration: 00:02:00.04, start: 0.00, bitrate: 17 kb/s It looks like your original file is 00:02:00.04 long, but has a start marker 0.04 in to give the 00:02:00.00 viewed duration. ffmpeg ignores such markers and so has transcoded all the frames it found. -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] compiling with libx265
On 28/11/14 09:55, Carl Eugen Hoyos wrote:
> tim nicholson ffmpeg.org> writes:
>
>> Thought I'd have a go at this, but suffered an odd epic fail.
>
> Use this patch as a work-around:
> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/178167
>
Whilst acknowledging that this patch works (thanks), I am trying to
understand why package config is failing in this case,
looking at x265.pc it has:-
Libs: -L${libdir} -lx265
Libs.private: -lstdc++ -lm -lrt
so should cover the requirements from their default location surely?
> Carl Eugen
> [..]
--
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] compiling with libx265
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/14 16:09, Nicolas George wrote: > Le primidi 11 frimaire, an CCXXIII, tim nicholson a écrit : >> Whilst acknowledging that this patch works (thanks), I am trying to >> understand why package config is failing in this case, > > I just tested on a fresh clone of x265 and current Debian Testing, and it > works. > > If it still does not work for you, I suggest you post the exact linking > commands, the one that fails and the one that succeeds with the workaround. > well originally its not so much the linking that fails, as failing to include libstdc++ so configure tests failing to compile, as per my original snippet. gcc -L/usr/local/lib64 -static -ldl -Wl,--as-needed -Wl,-z,noexecstack - -I/usr/local/include -L/usr/local/lib64 -o /tmp/ffconf.QTquSvyv /tmp/ffconf.1n1Ue3xn.o -lx265 -L/usr/local/lib64 -lx264 -lpthread -lm - -L/usr/local/lib64 -lfreetype -lfdk-aac - -lfaac -lm -lz -pthread /usr/local/lib64/libx265.a(bitcost.cpp.o): In function `x265::BitCost::CalculateLogs()': bitcost.cpp:(.text+0x26): undefined reference to `operator new[](unsigned long)' as oppsoed to:- gcc -L/usr/local/lib64 -static -ldl -Wl,--as-needed -Wl,-z,noexecstack - -o /tmp/ffconf.ilO1iAil /tmp/ffconf.ciiYw0OX.o -lx265 -lstdc++ - -L/usr/local/lib64 -lx264 -lpthread -lm -L/usr/local/lib64 -lfreetype - -lfdk-aac -lfaac -lm -lz -pthread > Regards, > [..] - -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJUfJtsAAoJEAwL/ESLC/yDcNkIALYakwsRRKof/576t/sKsfAC +Iy5r2ZZ0WmMOEdm1Acrvu7BnH9AcJkLvCsuJC5FAr3Ge81Vj5uRq8GLZkhEaoZq QhMsmaEfra3nZFDxE618BZbalZGYxNkQsyHXZKIdvh0uV0EICNkBLdbxGRbuTJ9c yBmSGlkRUAcxIIfOx7vU7//M1KjwPLgcXeSJT7mkSjH8Knn/qZqKWN69V9XOQEXL LvItwCEIFfQ755vg5jgqxeeJgGfTzLwLY8Dg6g++w/AxylYkhb/hPscJrk69FBBF RZtqpKwJAUoL7or9vK5HcWsOxCwSnYmdCpKtTiOAcjSKKZocdpaAh8C8kKMo/Wk= =go8W -END PGP SIGNATURE- ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] (no subject)
On 01/12/14 16:35, Guido Holz wrote: > Thanks! > Please do not top post, it makes following things harder. > but is there any way to avoid that with ffmpeg? Uae -ss wiith the same value as the original file start time > What is the reason to get an export of Premiere with another starttime than > zero? I suspect its just convenient for Premiere to do it that way, maybe due to where an I frame sits on the originsal material. > > it's not always trivial to me :-) > > thanks > > 2014-12-01 8:49 GMT+01:00 tim nicholson : > >> On 28/11/14 14:50, Guido Holz wrote: >>> my problem is after exporting from Adobe Premiere and postwork with >> ffmpeg >>> I get more frames of each mp4-footage. I minimalized it to the following >>> example: >>> >>> [...] >>> :\> ffmpeg.exe -i before.mp4 >>> [...] >>> Duration: 00:02:00.00, start: 0.04, bitrate: 70 kb/s >>> [..] >>> ffmpeg.exe -i after.mp4 >>> [..] >>> Duration: 00:02:00.04, start: 0.00, bitrate: 17 kb/s >> >> It looks like your original file is 00:02:00.04 long, but has a start >> marker 0.04 in to give the 00:02:00.00 viewed duration. >> >> ffmpeg ignores such markers and so has transcoded all the frames it found. >> >> -- >> Tim. >> Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 >> ___ >> -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] compiling with libx265
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/14 18:39, Nicolas George wrote:
> Le primidi 11 frimaire, an CCXXIII, tim nicholson a écrit :
>> Whilst acknowledging that this patch works (thanks), I am trying to
>> understand why package config is failing in this case,
>
> Your first snippet shows:
>
>>>> /usr/local/lib64/libx265.a(bitcost.cpp.o):
>
> That means you are trying to compile with static libx265.a; the default
> seems to be shared libx265.so. Do you know how you achieved this? Maybe
> "cmake -DENABLE_SHARED=OFF"?
>
I used default values except for the install paths. According to the
docs "The Makefile/solution builds a static encoder.lib library and a
standalone x265 executable". Although I found the standalone used a
dynamic library that is also created so you get both the .a and .so.
Static ffmpeg compile is by design.
>> looking at x265.pc it has:-
>>
>> Libs: -L${libdir} -lx265
>> Libs.private: -lstdc++ -lm -lrt
>>
>> so should cover the requirements from their default location surely?
>
> This happens even if -DENABLE_SHARED=OFF was set, and I believe this is
> wrong. Compare with what x264 produces:
>
> * With --enable-shared:
>
> Libs: -L${exec_prefix}/lib -lx264
> Libs.private: -lpthread -lm -ldl
>
> * With --enable-static:
>
> Libs: -L${exec_prefix}/lib -lx264 -lpthread -lm -ldl
> Libs.private:
>
> So my diagnosis is that x265's .pc file is wrong when x265 is built with
> shared libraries disabled.
Ahh so for static the libs move from Libs.private to Libs?
I will have a play with this, and the the suggestions regarding '
- --pkg-config-flags="--static" ' from the thread Clément suggested.
>
> Regards,
>
- --
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBAgAGBQJUfXsXAAoJEAwL/ESLC/yDn0sH/05gcwFvKZqnzZDx1otg2OvK
5J1gWXVf7ckgj6qqJCnWrkS/m76R7iuBpZZkrb9QqYiFIgJLaTbStPgWkkb60nOC
Ne4oZk0uCLSIoTyJ8qBtiXIcaoLBIee8VTZdRPlKN7TENVVDiAyqKAnsErUeEnIf
bG94etq2syV7XnBg4tQikbtD2Qt7dnoIx6jdWb312JNOb9JK61IehiQvp9h02z3M
4kYQZwhWnjluoURDhE7KjSdSWhPBmYHgW94qoiqJXGUwPJXG//czZbFRI6SA5lAf
JqsrGqw7mPn9bpgiu3kwmgedWM5JXXRHIbkBnRw3BimcRpeEjWHtvkeZ9y/vnCA=
=8nEV
-END PGP SIGNATURE-
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] compiling with libx265
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/14 19:02, Clément Bœsch wrote: > On Mon, Dec 01, 2014 at 08:01:13PM +0100, Clément Bœsch wrote: >> On Mon, Dec 01, 2014 at 04:46:36PM +0000, tim nicholson wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 01/12/14 16:09, Nicolas George wrote: >>>> Le primidi 11 frimaire, an CCXXIII, tim nicholson a écrit : >>>>> Whilst acknowledging that this patch works (thanks), I am trying to >>>>> understand why package config is failing in this case, >>>> >>>> I just tested on a fresh clone of x265 and current Debian Testing, and it >>>> works. >>>> >>>> If it still does not work for you, I suggest you post the exact linking >>>> commands, the one that fails and the one that succeeds with the workaround. >>>> >>> >>> well originally its not so much the linking that fails, as failing to >>> include libstdc++ so configure tests failing to compile, as per my >>> original snippet. >>> >>> gcc -L/usr/local/lib64 -static -ldl -Wl,--as-needed -Wl,-z,noexecstack >> >> So you have -static here... >> >>> - -I/usr/local/include -L/usr/local/lib64 -o /tmp/ffconf.QTquSvyv >>> /tmp/ffconf.1n1Ue3xn.o -lx265 -L/usr/local/lib64 -lx264 -lpthread -lm >>> - -L/usr/local/lib64 -lfreetype -lfdk-aac >>> - -lfaac -lm -lz -pthread >>> /usr/local/lib64/libx265.a(bitcost.cpp.o): In function >> >> ...and it's indeed picking the .a >> >> So: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/178167 >> > > Sorry, http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/178200 > Indeed, since ffmpeg tends not to use pkgconfig, and for those libs that I need that do I had built static only with matching pc files, the missing flag had not bitten me before. Thanks to all for your input and helping me understand build options better. - -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJUfYAiAAoJEAwL/ESLC/yDpUgH/3+9YHFG641zdQdkBeomb98o 1D1GsU18O/vn07JPV2CHIVdYSvIMOyLB8L9fMe7h5atireE5FPGVtThJgFBkcNlC WQZMhYOQBcllopixZ6vVXqcrHqTCOBR0PrjcjfVji4xREFuTiuvHjbvv6+3wJraC QNWvvwoxTWyESZkUcyrhhJJR2zpWUFYC/K5cjkZqQjjip4LENowlfUavxoz5Tara KBOVnhCbjtgDh1Rf9701pwArT5OewI24PDVXyyKYXSuq6znKkVKQdmdcjpvZAzkq W4uLIb0d/PtoS6T+rhCrFhugDW8U82i7deU1GSwumIPNJK82A5e7zHFFb4vpY1s= =4tad -END PGP SIGNATURE- ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] ffmpeg & MPEG-2 GOP structure
On 09/01/15 10:06, Valentin NOEL wrote: > Hi to all, > > I would like to encode MPEG-2 video with closed GOP of 12 frames, and a > structure like IBBPBBPBBPBB. > > For doing this, I am using these options : > *-g 12* to set the GOP size > *-bf 2* to set the max B frames between reference frames > *-flags +cgop* to use Closed GOP > *-sc_threshold 10* to disable scene change detection > *-b_strategy 0 *to disable adaptive number of B-frames > *-mpv_flags +strict_gop* to enforce GOP size (mpegvideo private flag) > > The resulting command is : > ffmpeg -i input.mxf -vcodec mpeg2video -g 12 -bf 2 -flags +cgop -b_strategy > 0 -mpv_flags +strict_gop -sc_threshold 10 -map 0:0 -y output.mxf > > However, the result is a GOP of 12 frames IBBPBBPBBPB*P*, with an ending > P-frame. > > It seems the problem comes from these lines : > https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpegvideo_enc.c#L1491 > > How can I do to fix this ? Is there a way to enforce GOP finishing by a > B-frame ? Is there something missing ? > Consider the last GOP of the file, you cannot end on a B frame as there is no forward frame to interpolate from. I wonder therefore if you need to add " -flags +cgop " > Thanks. > > Valentin > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] ffmpeg & MPEG-2 GOP structure
On 09/01/15 12:24, Valentin NOEL wrote: > Thanks for your answer, > Please do not top post on this forum > but actually the ITU-T recommendation for H.262 (ISO/IEC 13818-2, CODING OF > MOVING PICTURES AND ASSOCIATED AUDIO, 1995) specifies B-frames definition : > >> *B-picture; bidirectionally predictive-coded picture: A picture that is >> coded using motion compensated prediction from past and/or future reference >> fields or frames.* >> > The "and/or" means that a only backward reference is possible. > > The same document also specifies that, for closed GOP : > >> >> *closed_gop -- This is a one-bit flag which indicates the nature of the >> predictions uses in the B-pictures (if any) immediately following the first >> coded I-frame following the group of picture header .closed_gop is set to >> “1” to indicate that these B-pictures have been encoded using only backward >> prediction.* >> > It also means that B-frame may use backward prediction only. > > So, does that mean that FFmpeg does not allow only backward prediction for > B-frame, and that a patch is needed ? > It means that I was making a pragmatic suggestion for something you could try immediately to solve your issue, rather than trying to get bogged down in technical details too early. > Thanks. > > 2015-01-09 12:56 GMT+01:00 tim nicholson : > >> On 09/01/15 10:06, Valentin NOEL wrote: >>> Hi to all, >>> >>> I would like to encode MPEG-2 video with closed GOP of 12 frames, and a >>> structure like IBBPBBPBBPBB. >>> >>> For doing this, I am using these options : >>> *-g 12* to set the GOP size >>> *-bf 2* to set the max B frames between reference frames >>> *-flags +cgop* to use Closed GOP >>> *-sc_threshold 10* to disable scene change detection >>> *-b_strategy 0 *to disable adaptive number of B-frames >>> *-mpv_flags +strict_gop* to enforce GOP size (mpegvideo private flag) >>> >>> The resulting command is : >>> ffmpeg -i input.mxf -vcodec mpeg2video -g 12 -bf 2 -flags +cgop >> -b_strategy >>> 0 -mpv_flags +strict_gop -sc_threshold 10 -map 0:0 -y output.mxf >>> >>> However, the result is a GOP of 12 frames IBBPBBPBBPB*P*, with an ending >>> P-frame. >>> >>> It seems the problem comes from these lines : >>> >> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpegvideo_enc.c#L1491 >>> >>> How can I do to fix this ? Is there a way to enforce GOP finishing by a >>> B-frame ? Is there something missing ? >>> >> >> Consider the last GOP of the file, you cannot end on a B frame as there >> is no forward frame to interpolate from. >> >> I wonder therefore if you need to add " -flags +cgop " >> >> >>> Thanks. >>> >>> Valentin >>> [..] >> >> >> -- >> Tim. >> Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 >> ___ >> ffmpeg-user mailing list >> ffmpeg-user@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >> > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] ffmpeg & MPEG-2 GOP structure
On 09/01/15 15:30, Valentin NOEL wrote: > 2015-01-09 15:29 GMT+01:00 tim nicholson : > >> [...] >> It means that I was making a pragmatic suggestion for something you >> could try immediately to solve your issue, rather than trying to get >> bogged down in technical details too early. >> > > Actually, I need to add this flag "+cgop" because I need to generate closed > GOP. > Other encoders allow finishing closed GOP with B-frames (with only backward > reference), so I wonder whether FFmpeg cannot allow doing this, or whether > I do not use it correctly. > Well does toggling that option off change things at all? (Notwithstanding that for real use you need it, just trying to see what might affect the result as I know chaging this can affect the bframe count). -b_strategy 0 is the default so that setting should be doing nothing, have you experimented with different values? > >>> Thanks. >>> >>>[] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Color conversion - 709 to 601
On 22/01/15 14:04, Kevin Wells wrote: > Hi, I am downscaling an HD movie from 1920x1080 to 720x576 and want to make > sure the color conversion is done correctly, which with my current settings I > am sure it is not. I am coming from an HD Prores HQ, going to an SD Prores > HQ.With my current command (below) it is introducing a very faint green > pattern / interference, I can see this when zooming into the video. If remove > the colormatrix=bt709:bt601 altogether then the very faint green pattern / > interference goes. So my question is do I need any color conversion (is > ffmpeg already doing this for me) and if I do, what would be the correct way > to apply this? > Here is my current command: > ffmpeg -r 25 -i "/Volumes/tmp/test.mov" -t 20 -af atempo=1.0416667 -map > 0:0 -vf scale=720:576,colormatrix=bt709:bt601 -map 0:1 -map 0:2 -map 0:3 -map > 0:4 -map 0:5 -map 0:6 -map 0:7 -vcodec prores -profile:v 3 -c:a pcm_s16le -y > "/Volumes/tmp/testOut.mov" > Here is the output: > ffmpeg -r 25 -i "/Volumes/tmp/test.mov" -t 20 -af atempo=1.0416667 -map > 0:0 -vf scale=720:576,colormatrix=bt709:bt601 -map 0:1 -map 0:2 -map 0:3 -map > 0:4 -map 0:5 -map 0:6 -map 0:7 -vcodec prores -profile:v 3 -c:a pcm_s16le -y > "/Volumes/tmp/testOut.mov"ffmpeg version 2.5.3-tessus Copyright (c) 2000-2015 > the FFmpeg developers built on Jan 10 2015 01:19:50 with Apple LLVM version > 6.0 (clang-600.0.56) (based on LLVM 3.5svn) configuration: > --cc=/usr/bin/clang --prefix=/Users/tessus/data/ext/ffmpeg/sw --as=yasm > --extra-version=tessus --disable-shared --enable-static --disable-ffplay > --enable-gpl --enable-pthreads --enable-postproc --enable-libmp3lame > --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libx265 > --enable-libxvid --enable-libspeex --enable-bzlib --enable-zlib > --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libxavs > --enable-libsoxr --enable-libwavpack --enable-version3 --enable-libvo-aacenc > --enable-libvo-amrwbenc --enable-libvpx --en ab > le-libgsm --enable-libopus --enable-libmodplug --enable-fontconfig > --enable-libfreetype --enable-libass --enable-libbluray --enable-filters > --disable-indev=qtkit --disable-indev=x11grab_xcb --enable-runtime-cpudetect > libavutil 54. 15.100 / 54. 15.100 libavcodec 56. 13.100 / 56. > 13.100 libavformat56. 15.102 / 56. 15.102 libavdevice56. 3.100 / > 56. 3.100 libavfilter 5. 2.103 / 5. 2.103 libswscale 3. 1.101 > / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 libpostproc53. > 3.100 / 53. 3.100Input #0, mov,mp4,m4a,3gp,3g2,mj2, from > '/Volumes/tmp/test.mov': Metadata:major_brand : qt > minor_version : 537199360compatible_brands: qt creation_time : > 2014-12-23 17:56:48 Duration: 01:26:48.54, start: 0.00, bitrate: 167427 > kb/sStream #0:0(eng): Video: prores (apch / 0x68637061), > yuv422p10le(bt709), 1920x1080, 158160 kb/s, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, > 24 tbn, 24 tbc (default)Metadata: creation_ti me > : 2014-12-23 17:56:48 handler_name: Apple Alias Data Handler > encoder : Apple ProRes 422 HQ timecode: 00:00:00:00 > Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, 1 channels > (FL), s32 (24 bit), 1152 kb/s (default)Metadata: creation_time : > 2014-12-23 17:56:48 handler_name: Apple Alias Data HandlerStream > #0:2(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, 1 channels (FR), > s32 (24 bit), 1152 kb/s (default)Metadata: creation_time : > 2014-12-23 17:56:48 handler_name: Apple Alias Data HandlerStream > #0:3(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32 (24 > bit), 1152 kb/s (default)Metadata: creation_time : 2014-12-23 > 17:56:48 handler_name: Apple Alias Data HandlerStream #0:4(eng): > Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, 1 channels (LFE), s32 (24 > bit), 1152 kb/s (default)Metadata: creation_time : 2014-12-23 > 17:56:4 8 > handler_name: Apple Alias Data HandlerStream #0:5(eng): Audio: > pcm_s24le (in24 / 0x34326E69), 48000 Hz, 1 channels (BL), s32 (24 bit), 1152 > kb/s (default)Metadata: creation_time : 2014-12-23 17:56:48 > handler_name: Apple Alias Data HandlerStream #0:6(eng): Audio: > pcm_s24le (in24 / 0x34326E69), 48000 Hz, 1 channels (BR), s32 (24 bit), 1152 > kb/s (default)Metadata: creation_time : 2014-12-23 17:56:48 > handler_name: Apple Alias Data HandlerStream #0:7(eng): Audio: > pcm_s24le (in24 / 0x34326E69), 48000 Hz, downmix, s32 (24 bit), 2304 kb/s > (default)Metadata: creation_time : 2014-12-23 17:56:48 > handler_name: Apple Alias Data HandlerStream #0:8(eng): Data: none > (tmcd / 0x64636D74) (default)Metadata: creation_time : 2014-12-23 > 18:06:00 handler_name: Apple
Re: [FFmpeg-user] Error encoding to DNxHD
On 23/01/15 16:14, Christian Foerster wrote: > Hi all, > > > I'm trying to convert a file to DNxHD 120 (as DNxHD 85 doesn't seem to be > supported). It fails because I'm apparently using some wrong parameter. Can > anyone point me to where I went wrong? > > Thanks a lot, > Christian > > > This is my command: > > ffmpeg -i schuerrle.mp4 -c:v dnxhd -b:v 120m -s 1920x1080 -pix_fmt yuv422p > -r 25 -c:a pcm_s16le -ar 48000 schuerrle_dnxhd.mov > > This is what ffmpeg returns: > > [...] > > [dnxhd @ 0x7fa37d000600] Frame size: 1920x1080i; bitrate: 120Mbps; pixel > format: yuv422p; framerate: 25/1 > > [...] Your bitrate needs to be 120M not 120m I think. -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] removing logo
On 03/02/15 08:23, Moritz Barsnick wrote: > Hi Hany, > > On Tue, Feb 03, 2015 at 01:01:57 +, Eng.Hany Ahmed wrote: > >> Helloi have videos have logo in the top of the corner i want make >> pixelate blur for this logo like in the photo > > In which photo? > >> i tried to using water mark but i have 2 problems 1- it's take many >> resources of the cpu when re encoding and i can use copy method 2 - >> it's very bad view with the new logo > > ffmpeg has quite good x264 coding performance, your expectations may be > wrong. You don't tell us what you're expecting and what you're getting > though. > >> the command line " ffmpeg -i "kides.ts" -vprofile baseline -threads 5 >> -bufsize 2300k -c:v libx264 -b:v 1200k -preset fast -acodec aac -ar 44100 >> -ab 128k -strict experimental -vf "movie=/root/watermarklogo.png >> [watermark]; [in][watermark] overlay=10:10 [out]" -f flv kids.flv " Why not use the delog filter? e.g:- -vf "delogo=x=920:y=692:w=275:h=23:t=4:show=0" > > Please also show us the complete, uncut console output from this > command. And perhaps a screenshot of the result, explaining to us why > you think it is wrong. > > The console output would also help us to see how fast ffmpeg should be, > because we could observe the dimensions of the video, its length, ... > Quite > Moritz > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Questions about readout important metadata from DPX files ("logarthmic/linear") and recreate DPX with same metadata
On 12/03/15 16:09, Christoph Gerstbauer wrote: > > [..] > There exist one DPX metadata reader/editor only for MAC OS. > Which this tool I checked the FrameRate values in the DPX: most DPX had > no value written, so ffmpeg GUESSES the fps I think. > One DPX had the value 24fps, but FFmpeg also showed me "25fps". > Anyhow: I am not shure if this metadata reader is THE reference > application for DPX. :/ I just mentioned it that there are more > informations in the DPX than ffprobe is able to show me. > ISTR that imagemagick/graphicsmagick have quite good DPX metadata extraction "$ [gm] identify -verbose some-file.dpx" see:- http://www.imagemagick.org/script/motion-picture.php and http://www.graphicsmagick.org/motion-picture.html#dpx-attributes Note that there are both film and television frame rate values that may not match! > br > Christoph >[..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Questions about readout important metadata from DPX files ("logarthmic/linear") and recreate DPX with same metadata
On 14/03/15 11:35, Christoph Gerstbauer wrote: >> ISTR that imagemagick/graphicsmagick have quite good DPX metadata >> extraction >> >> "$ [gm] identify -verbose some-file.dpx" >> >> see:- >> >> http://www.imagemagick.org/script/motion-picture.php >> >> and >> http://www.graphicsmagick.org/motion-picture.html#dpx-attributes >> >> Note that there are both film and television frame rate values that may >> not match! >> > Hello Tim! > > thank you, thats a very good tool, especially graphics magick :) > > But I can find just one frameratein the list: > > dpx:mp.frame.rate > > > Where is the second one you were talking about? > Imagemagick claims to support:- dpx:film.frame_rate dpx:television.frame_rate Graphicsmagick:- dpx:mp.frame.rate > Best Regards > Christoph > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Questions about readout important metadata from DPX files ("logarthmic/linear") and recreate DPX with same metadata
On 16/03/15 11:17, Christoph Gerstbauer wrote: >> Imagemagick claims to support:- >> >> dpx:film.frame_rate >> dpx:television.frame_rate >> >> Graphicsmagick:- >> >> dpx:mp.frame.rate >> > Thank you, Tim! > > I found also two at graphics magick: > > dpx:mp.frame.rate > tv.temporal.sampling.rate Yes, smpte S268 refers to field 66 as "Temporal sampling rate or frame rate (Hz)". Pity the two projects use different labels for the standard fields its easy to miss which matches what as it stands > > It quite interessting: sometime the first (dpx:mp.frame.rate > ), sometime the second (tv.temporal.sampling.rate > ) has a useable value. > > I made different tests. > For example AFTER EFFECTS and ARRISCAN Filmscanner always writes into > "tv.temporal.sampling.rate". > AJA Capturing cards write into "dpx:mp.frame.rate" (e.g. 25), into > "tv.temporal.sampling.rate" they write "4.60285e-041". > Both are 32bit real values, but that is a bizzarre figure that I assume must be digital detritus. I find AJA cards generally seem to "do their own thing" when it comes to metadata, some of their .mov fields are way different to everyone else's (like not setting the aspect ratio on HD ingests) > > Best Regards > Christoph > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Questions about readout important metadata from DPX files ("logarthmic/linear") and recreate DPX with same metadata
On 16/03/15 11:54, Christoph Gerstbauer wrote: >> Yes, smpte S268 refers to field 66 as "Temporal sampling rate or frame >> rate (Hz)". >> >> Pity the two projects use different labels for the standard fields its >> easy to miss which matches what as it stands >> >> > Do you have an more actual SMPTE S268 version? I have only 268M-1994. I have sight of S268m-2003. But as its not my copy I probably shouldn't share it. > > Best Regards > Christoph > _[..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 18/03/15 09:46, Christoph Gerstbauer wrote: > Hello > > I am testing with ffmpeg the IMX50 D10 encoding, and I am very close to > my target but I have to create 3 metadata values in the MXF header which > is standard in most IMX50 MXF ecndodings: > > + SIGNAL STANDARD = 1 (ITU 601) > + display y offset = 32 - I am encoding 720x608 sources with included > VBI area (32 lines high at the top) -> the offset 32 defines the active > picture -> 720x576 > + Color siting = 4 (Rec 601) > > Is it possible to encoded with ffmpeg in a way that these values can be > written? > If yes, which syntax should I add to my used syntax? > If no, could the option be implemented in future? > > My used ffmpeg syntax is: > ffmpeg -i -map 0:v -map 0:a -c:v mpeg2video -r 25 -pix_fmt > yuv422p -aspect 4:3 -minrate 5k -maxrate 5k -b:v 5k -intra > -flags +ildct+ilme+low_delay -intra_vlc 1 -non_linear_quant 1 -ps 1 > -qmin 1 -qmax 3 -top 1 -dc 10 -bufsize 200 -rc_init_occupancy > 200 -rc_buf_aggressivity 0.25 -tag:v mx5p -c:a pcm_s24le -ar 48000 > -f mxf_d10 > Don't know if its relevant but your coding parameters are slightly different to the one's I use for D10, and I wonder if this affects the automatic metadata insertion.. "-flags +ildct+ilme+low_delay" Well ilme seems kind of redundant for I frame only coding but probably harmless. "-tag:v mx5p" irrelevant for mxf, but again probably harmless. I use the following which you do not:- -rc_max_vbv_use 1 -rc_min_vbv_use 1 and you use the following that I do not:- "-qmax 3 -rc_buf_aggressivity 0.25" I don't know what difference, if any, those changes make, but the values I use create D10 files that BBC R&D looked at and thought were OK. Perhaps worth a try? > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 19/03/15 13:38, Christoph Gerstbauer wrote: >> Don't know if its relevant but your coding parameters are slightly >> different to the one's I use for D10, and I wonder if this affects the >> automatic metadata insertion.. >> >> >> "-flags +ildct+ilme+low_delay" >> >> Well ilme seems kind of redundant for I frame only coding but probably >> harmless. >> >> "-tag:v mx5p" >> >> irrelevant for mxf, but again probably harmless. >> >> I use the following which you do not:- >> >> -rc_max_vbv_use 1 >> >> -rc_min_vbv_use 1 >> >> and you use the following that I do not:- >> >> "-qmax 3 -rc_buf_aggressivity 0.25" >> >> I don't know what difference, if any, those changes make, but the values >> I use create D10 files that BBC R&D looked at and thought were OK. >> >> Perhaps worth a try? >> >>> [..] > > Additionally: > > I tried it again with all your mentioned syntax changes but without > changing the "-qmin 1 -qmax 3" -> now it works to encode. > > But the MXF metadata doesnt change (SIGNAL STANDARD = 1 (ITU 601) + > display y offset +Color siting = 4 (Rec 601). > > The only difference I saw with mediainfo is that the new MXF (your > syntax) has a CLOSED GOP structure and the old one (my syntax) had a > OPEN structure. > > Best Regards > Christoph > [..] Shame, don't understand the qmax issue. but if you look at:- tests/lavf_regression.sh line 90 you will see an IMX30 example which uses -qmax 12 and my other other parameters. However not sure what difference closed/open gop makes on I frame only, but being purist I can see how you might want to set closed gop! S356m makes no reference to it that I can see. Looks like we might need a patch for what you want. -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 19/03/15 15:48, Christoph Gerstbauer wrote: > >> Shame, don't understand the qmax issue. but if you look at:- >> >> tests/lavf_regression.sh line 90 >> >> you will see an IMX30 example which uses -qmax 12 and my other other >> parameters. However not sure what difference closed/open gop makes on I >> frame only, but being purist I can see how you might want to set closed >> gop! S356m makes no reference to it that I can see. >> >> Looks like we might need a patch for what you want. >> >> > > In fact, the most important metadata flag is the > > display y offset = 32 (high priority for patching, if possible) > Having a quick scan through mxfenc.c it looks like that UL is missing, as are some others. I have tracked them down in RP210 but am struggling with the local_tag values at the moment. It should be relatively straightformward to add in the relevant tag though. > > Without it, some programs like GRass Valley Edius misinterpret the IMX > files -> the VBI area is shown in the editing window: > > [..] > Best Regards > Christoph > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 20/03/15 09:19, tim nicholson wrote:
> On 19/03/15 15:48, Christoph Gerstbauer wrote:
>>
>>> Shame, don't understand the qmax issue. but if you look at:-
>>>
>>> tests/lavf_regression.sh line 90
>>>
>>> you will see an IMX30 example which uses -qmax 12 and my other other
>>> parameters. However not sure what difference closed/open gop makes on I
>>> frame only, but being purist I can see how you might want to set closed
>>> gop! S356m makes no reference to it that I can see.
>>>
>>> Looks like we might need a patch for what you want.
>>>
>>>
>>
>> In fact, the most important metadata flag is the
>>
>> display y offset = 32 (high priority for patching, if possible)
>>
>
> Having a quick scan through mxfenc.c it looks like that UL is missing,
> as are some others. I have tracked them down in RP210 but am struggling
> with the local_tag values at the moment.
>
> It should be relatively straightformward to add in the relevant tag though.
>
Attached is a quick hack that worked for me. Do you want to give it a spin?
--
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
>From 5944bf55fb2c5adc45959f1ac34c884189704ede Mon Sep 17 00:00:00 2001
From: Tim Nicholson
Date: Fri, 20 Mar 2015 15:18:24 +
Subject: [PATCH] libavformat/mxfenc.c: Add 'Presentation Y offset' metadata
Previously unset, and some software mishandles files if it is absent
---
libavformat/mxfenc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 898951c..0fd8846 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -399,6 +399,7 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
{ 0x3202, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x02,0x01,0x00,0x00,0x00}}, /* Stored Height */
{ 0x3209, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0C,0x00,0x00,0x00}}, /* Display Width */
{ 0x3208, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0B,0x00,0x00,0x00}}, /* Display Height */
+{ 0x320B, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0E,0x00,0x00,0x00}}, /* Presentation Y offset */
{ 0x320E, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x00,0x00,0x00}}, /* Aspect Ratio */
{ 0x3201, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x06,0x01,0x00,0x00,0x00,0x00}}, /* Picture Essence Coding */
{ 0x3212, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x03,0x01,0x06,0x00,0x00,0x00}}, /* Field Dominance (Opt) */
@@ -971,7 +972,7 @@ static void mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const UID ke
int stored_height = (st->codec->height+15)/16*16;
int display_height;
int f1, f2;
-unsigned desc_size = size+8+8+8+8+8+8+5+16+sc->interlaced*4+12+20;
+unsigned desc_size = size+8+8+8+8+8+8+8+5+16+sc->interlaced*4+12+20;
if (sc->interlaced && sc->field_dominance)
desc_size += 5;
@@ -996,6 +997,11 @@ static void mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const UID ke
mxf_write_local_tag(pb, 4, 0x3208);
avio_wb32(pb, display_height>>sc->interlaced);
+// presentation Y offset
+mxf_write_local_tag(pb, 4, 0x320B);
+avio_wb32(pb, (st->codec->height - display_height)/2);
+
+
// component depth
mxf_write_local_tag(pb, 4, 0x3301);
avio_wb32(pb, sc->component_depth);
--
1.9.1
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 20/03/15 15:21, tim nicholson wrote: > On 20/03/15 09:19, tim nicholson wrote: >> On 19/03/15 15:48, Christoph Gerstbauer wrote: >>> >>>> Shame, don't understand the qmax issue. but if you look at:- >>>> >>>> tests/lavf_regression.sh line 90 >>>> >>>> you will see an IMX30 example which uses -qmax 12 and my other other >>>> parameters. However not sure what difference closed/open gop makes on I >>>> frame only, but being purist I can see how you might want to set closed >>>> gop! S356m makes no reference to it that I can see. >>>> >>>> Looks like we might need a patch for what you want. >>>> >>>> >>> >>> In fact, the most important metadata flag is the >>> >>> display y offset = 32 (high priority for patching, if possible) >>> >> >> Having a quick scan through mxfenc.c it looks like that UL is missing, >> as are some others. I have tracked them down in RP210 but am struggling >> with the local_tag values at the moment. >> >> It should be relatively straightformward to add in the relevant tag though. >> > > Attached is a quick hack that worked for me. Do you want to give it a spin? > > [..] If it works for you I will submit a tidied up version, with revised fate checksums, but that will have to wait awhile as I'm away next week... -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 23/03/15 09:45, Christoph Gerstbauer wrote: >> >> If it works for you I will submit a tidied up version, with revised fate >> checksums, but that will have to wait awhile as I'm away next week... > > Hello Tim! > thank you, it works for PAL and NTSC (720x512/720x480) but there is a > just little bug for NTSC when encoding to 720x486 in "stored dimension"! My patch only deals with the addition of the display y offset metadata, it should not touch exisiting metadata, are you saying that the figures for 'Stored dimensions' are different with and without my patch? > I have made list of all encoding examples: > > > [..] > FOR NTSC IMX50: > > [..] > > When I set: -s 720x486 > > Signal standard : 0 (None) > Frame layout : 1 (Separate Fields) > Stored dimensions: 720x496<--- NOT correct, should be 720x486 > Display dimensions : 720x486<--- correct > Display x offset : 0 > Display y offset : 0 <--- correct >[..] > Best Regards > Christoph > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 30/03/15 08:33, Christoph Gerstbauer wrote: >>> Hello Tim! >>> thank you, it works for PAL and NTSC (720x512/720x480) but there is a >>> just little bug for NTSC when encoding to 720x486 in "stored dimension"! >> My patch only deals with the addition of the display y offset metadata, >> it should not touch exisiting metadata, are you saying that the figures >> for 'Stored dimensions' are different with and without my patch? >> > > Hello Tim, you are right. > I tried it with a non-patched ffmpeg version, and I got the same result: So possibly a different bug, or possibly even invalid frame sizes for IMX @NTSC, I will check the specs. > > [..] > Best Regards > Christoph > _[...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 30/03/15 09:44, tim nicholson wrote: > On 30/03/15 08:33, Christoph Gerstbauer wrote: >>>> Hello Tim! >>>> thank you, it works for PAL and NTSC (720x512/720x480) but there is a >>>> just little bug for NTSC when encoding to 720x486 in "stored dimension"! >>> My patch only deals with the addition of the display y offset metadata, >>> it should not touch exisiting metadata, are you saying that the figures >>> for 'Stored dimensions' are different with and without my patch? >>> >> >> Hello Tim, you are right. >> I tried it with a non-patched ffmpeg version, and I got the same result: > > So possibly a different bug, or possibly even invalid frame sizes for > IMX @NTSC, I will check the specs. > 720x486 is a very odd size. In particular 486 would need rounding up the next full macroblock size hence the additional 10 lines stored. Its the same for HD 1920x1080, if you look at the stored size its 1088. This usually gets done automatically by the coder for AVCI. As these padding lines are at the end and not the top the offset of 0 is correct. So I don't think this is wrong at all. >> >> [..] >> Best Regards >> Christoph >> _[...] > > -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 23/03/15 09:45, Christoph Gerstbauer wrote: >> >> If it works for you I will submit a tidied up version, with revised fate >> checksums, but that will have to wait awhile as I'm away next week... > > Hello Tim! > thank you, it works for PAL and NTSC (720x512/720x480) but there is a > [..] A (more) proper patch is now in git master. If you rely on pre built ffmpeg give it a day or so and it should be there. -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Smooth frame rate reduction?
On 31/03/15 17:11, Robert Krüger wrote: > On Tue, Mar 31, 2015 at 5:58 PM, Carl Eugen Hoyos wrote: > >> Robert Krüger lesspain.de> writes: >> >>> I think Mark mentioned once the intent to port it to >>> ffmpeg but I am not sure. If you're in a hurry, you >>> can apply it to ffmbc and use that (I hope I am >>> allowed to say that here but I would of course >>> favour this filter to be ported to ffmpeg). >> >> Where can I find your patch? >> >> > I know I practically begged for this response ;-) http://mdsh.com/patches/ffmbc_0.7rc8/FFmbc-0.7-rc8_vf_framerate-2013051301.patch http://mdsh.com/patches/ffmbc_0.7/FFmbc_0.7_vf_framerate_interpolate_and_debug.patch > __[..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Smooth frame rate reduction?
On 02/04/15 11:00, Carl Eugen Hoyos wrote: > tim nicholson ffmpeg.org> writes: > >> > http://mdsh.com/patches/ffmbc_0.7rc8/FFmbc-0.7-rc8_vf_framerate-2013051301.patch > > Is there a reason you are not sending a pull request > from your git repository? > (to ffmpeg-devel) Becasue I was supplying the link to the original ffmbc patch as I thought was requested by a previous post to facilate porting > > Carl Eugen > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] using -vtag on input files
On 02/04/15 13:56, Roee Kashi wrote: > Hi, > > back in 2012 I could use -vtag on an input rawvideo file, thus tell ffmpeg > the pixel format is YV12. > > at a certain point there was a regression in that feature so vtag is again > allowed only for outputs. > > currently since I have to convert YV12 rawvideo files to avi, I can only > use this version: > use -pix_fmt, valid for input/output >[,,,] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] using -vtag on input files
On 02/04/15 15:22, Roee Kashi wrote: > Hi, > > with the older ffmpeg version (described earlier), my command line looks > like this: > "ffmpeg.exe -f rawvideo -vcodec rawvideo -s 704x576 -r 25 -pix_fmt yuv420p > -vtag YV12 -i raw.yuv -f avi -qscale 0 out.avi" Ahh, so you are using the pix_fmt to specify the input... What happened on the older version if you left the -vtag off? I think its always only been an output only option, and istr a patch to fail options put in the wrong place. What happens if you move the option to the output side on a current build? > > with newer version, the output of the same command is: > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] using -vtag on input files
On 02/04/15 16:11, Roee Kashi wrote: > first, since my rawvideo input is YV12 and there's no such pix_fmt, yuv420p > without vtag results with a blue-pink video output. I guess because its decoding it as yuv not yvu > second, before vtag supported input files, i had to convert the file first > to avi with -vcodec copy, and then convert it to mpeg4 or something, which > takes forever. > Its odd that ffmpeg can handle yvu, without exposing a specific pix_fmt to match, even more so as yvu ordering is common in mpeg (which is probably why your workaround worked... > i think this thread could shed some light on this matter (last message is > the most important i think): > http://ffmpeg-users.933282.n4.nabble.com/convert-YV12-stream-to-ProRes-td4665890.html > Ahh so Carl added that in ffmpeg.c for sources in 6bca574a and then later on it was re-added in a merge of 746dca483a2f in 2014/02/24 but into ffmpeg_opt.c I wonder if that's where it all went wrong... > Roee. > > 2[..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] using -vtag on input files
On 02/04/15 16:45, Carl Eugen Hoyos wrote: > tim nicholson ffmpeg.org> writes: > >>> "ffmpeg.exe -f rawvideo -vcodec rawvideo -s 704x576 >>> -r 25 -pix_fmt yuv420p -vtag YV12 -i raw.yuv -f avi >>> -qscale 0 out.avi" >> >> Ahh, so you are using the pix_fmt to specify the input... >> >> What happened on the older version if you left the >> -vtag off? I think its always only been an output >> only option > > It was definitely an input- and output-option. > It is currently not possible to (easily) read > such streams. > So it was, I see you fixed it ages ago, sorry for causing confusion by misremebering. In oreder to make amends I think I have tracked the issue down It looks like the merge 5743095c line 3043 from avconv made it at output only option... needs an " OPT_INPUT | OPT_OUTPUT" instead of "OPT_OUTPUT" > One possible work-around is of course to remux > to nut with (output) option vtag. > > Carl Eugen > > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] using -vtag on input files
On 05/04/15 10:23, Roee Kashi wrote: > just mentioning, adding " | OUT_INPUT" to vtag option indeed sort it out. > i hope it will get into git-master one day :) > I think you will find it happened the same day :) > thanks > > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Faster vp9
On 07/04/15 15:18, Matt Zagrabelny wrote: > On Mon, Apr 6, 2015 at 11:10 PM, Andrew Sinclair wrote: >> Hi, >> >> Does anyone have any suggestions for faster vp9 encoding? > > Hi Andrew, > > I don't have the ffmpeg technical chops to analyze your command-line, > but I just came across a Google VP9 encoding guide: > > https://sites.google.com/a/webmproject.org/wiki/ffmpeg/vp9-encoding-guide > > Maybe that will be helpful. > I see it advises using 2 pass encoding with crf, which seems a bit odd to me given that "This (crf) provides maximum compression efficiency with a single pass" or is that only true of x264? I would have thought that it should be true for all coders that implement such a mode. > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] ffmpeg is slow to pick up udp
On 08/04/15 15:27, Thomas Seilund wrote: > Hi All > > What has this to do with "[FFmpeg-user] Faster vp9" ? If you want to start a new subject, then please start a new thread, do *not* hijack an existing thread and simply change the Subject, it confuses thread following email clients. If you want a reply please repost as described above. -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 13/04/15 08:34, Christoph Gerstbauer wrote: > > Hello Tim, > > do you think that these flags can also be implemented into the IMX > encoding of ffmpeg? > > + SIGNAL STANDARD = 1 > (ITU 601) > + Color siting = 4 > (Rec 601) > > [..] They could easily be hardcoded in, however they could then be wrong as asumptions are being made which might not be true, and are probably not verifiable. For example if you are recoding an SD YUV file, you might resonably assume that it is 601, but it might not be, and unless the source file explicitly defines it as such, and you carry that information forward you are just guessing, ffmpeg has no way of knowing the matrix used to generate the values. Therfore I think the only sane approach would be to have them as user settable flags which would take more careful thinking about... -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
On 13/04/15 11:48, Christoph Gerstbauer wrote: >> >> Therfore I think the only sane approach would be to have them as user >> settable flags which would take more careful thinking about... > Yes, sorry, I didnt said it detailed: Yes a flag which can be enabled by > the user would be the best solution for that. > > Do you think these 2 flags could be implemented in ffmpeg IMX encoding? > Only implementing for IMX feels wrong, and only including certain flags for certain formats could be kludgy. As I say it needs thinking about, and at the moment I am more involved in a deeper overhaul of the whole mxf UL handling to try and make things more transparent, and as I am about to go on holiday its not something that I have time to look at at the moment... > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] h264 lossless grayscale
On 23/04/15 09:54, Marco Porsch wrote: > Hi, > > when encoding an 8bit grayscale video using the commandline > # ffmpeg.exe -f rawvideo -vcodec rawvideo -pix_fmt gray -s 1280x960 -r 30 -i > out8.yuv -c:v libx264 -qp 0 -preset ultrafast -y out8.mkv > and decoding using > # ffmpeg.exe -i out8.mkv -f rawvideo -c:v rawvideo -pix_fmt gray -y > out8_decoded.yuv > I get two bit-identical .yuv files. Correct. > > When doing the same with a 16bit grayscale video using the command lines > # ffmpeg.exe -f rawvideo -vcodec rawvideo -pix_fmt gray16le -s 1280x960 -r 30 > -i out16.yuv -c:v libx264 -qp 0 -preset ultrafast -y out16.mkv > # ffmpeg.exe -i out16.mkv -f rawvideo -c:v rawvideo -pix_fmt gray16le -y > out16_decoded.yuv > the resulting files are not identical. > > Any explanation for this behavior? Am I doing something wrong? > > Best regards, > --Marco > > > D:\Users\Porsch\Develop\LoggingApp\tools\build\vs12\dl4log_mux>d:\Tools\ffmpeg-20150109-git-d1c6b7b-win32-shared\bin\ffm > peg.exe -f rawvideo -vcodec rawvideo -pix_fmt gray -s 1280x960 -r 30 -i > out8.yuv -c:v libx264 -qp 0 -preset ultrafast -y > out8.mkv > [...] > [libx264 @ 0093cfe0] profile High 4:4:4 Predictive, level 3.2, 4:4:4 8-bit > [...] > > D:\Users\Porsch\Develop\LoggingApp\tools\build\vs12\dl4log_mux>d:\Tools\ffmpeg-20150109-git-d1c6b7b-win32-shared\bin\ffm > peg.exe -f rawvideo -vcodec rawvideo -pix_fmt gray16le -s 1280x960 -r 30 -i > out16.yuv -c:v libx264 -qp 0 -preset ultrafa > st -y out16.mkv >[...] > [libx264 @ 0071d140] profile High 4:4:4 Predictive, level 3.2, 4:4:4 8-bit > [...] In both cases you have created an 8bit h264 file, why would you then expect the conversion back to be bit exact? (x264 supports 8 or 10 bit and needs compiling explicitely for the required bit depth) -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to generate IRT conform D10 IMX50 MXFs (and how to set the output color_range, -space, -transfer and primaries flags)
On 28/04/15 09:20, Christoph Gerstbauer wrote: > Hello > > I am making tests with IMX50/MXF encodings with FFMBC and FFMPEG. (with > 24bit audio) > The tests compare the final files with the IRT MXF Analyzer Pro tool to > be shure to be IRT conform. > (My used syntax is at the bottom of this mail) > > Both files (generated with ffmbc and ffmpeg) are working very well in > editing tools but there is a little difference: > > The IMX50 generated by ffmbc has no errors/warnings at IRT MXF Analyzer > (with16bit audio). It is really perfect. In fact I never had a clean > "green" MXF by testing other probes from other encoding tools. Only the > IRT probes itself are clean. So this MXF is IRT conform when using the > ffmbc standard target preset "imx50". > > The Analyzis of the IMX50/MXF generated by FFMPEG (latest build from > zeganoe) has 1 warning and 1 error: > > WARNING: > "Fill Item Key with a wrong RP210 (SMPTE Metadata Dictionary) version > number of 0x01. The correct version number is 0x02" > > ERROR: "The Sound Essence Descriptor signals that the number if > quantization bits is 24, which is higher than actually required (16) as > detemined by parsing the essence." > > > Due to the fact that I am producing 24bit audio I could prevent the > WARNING by producing 16bit audio. But is there a problem in the MXF when > producing 24bit? Sound works in editing tools. > Furthermore ffmbc produces for standard a IMX with 16bit -> If I force > ffmbc to do 24bit, I get the same error. > > Due to the warning: I found out that both files are different regarding > these values (by reading out via ffprobe - show_streams) > > FFMBC IMX FILE stream 0:0: > color_range=tv > color_space=smpte170m > color_transfer=bt709 > color_primaries=bt470bg > > > FFMPEG IMX FILE stream 0:0: > color_range=tv > color_space=unknown > color_transfer=unknown > color_primaries=unknown > > > So my questions are : > > 1.) How can I produce (with ffmpeg) the same output like ffmbc with > these 4 metadata flags: > color_range=tv > color_space=smpte170m > color_transfer=bt709 > color_primaries=bt470bg > I didnt found a answer to that in the ffmpeg documentation :/ Submit a patch that includes these flags. I'm not sure if ffmbc actually inspects the source material to check these figures are correct, or just hard codes them, I suspect the ffmpeg results are more "honest". > > 2.) Maybe somebody knows: Do these 4 metadata flags have a connection to > the Warning message of the MXF Analyzer? -> "Fill Item Key with a wrong > RP210 (SMPTE Metadata Dictionary) version number of 0x01. The correct > version number is 0x02" The UL version number is the version number where the UL first appeared in the defining registry* and is generally ignored in all UL parsing (certainly in ffmpeg). Its only really there for checking back when a particular UL appeared in the spec, and has no functional use. So no, I do not believe there is a connection. As errors go it is basically cosmetic. There are a number of questionable UL's in the ffmpeg code, and as they originate from a number of different standards, working out where they came from and checking them is somewhat tedious, which is why I am trying to rationalise them. Having said that an RP210 UL should be straightforward to check and correct, if the actual key is know (you do not provide it). > If nobody know this answer I could do the test for myself by be able to > encode with the upper params in 1.). > > 3.) Is there an syntax option in ffmpeg for 24bit audio encoding to > prevent this ERROR: > "The Sound Essence Descriptor signals that the number if quantization > bits is 24, which is higher than actually required (16) as detemined by > parsing the essence." This is more a warning than an error, if you are using 24bit it will be flagged as such, which is correct. however converting 16 -> 24 is usually done by padding with 0, so the analysis is simply warning that that you are wasting bits. You could try adding some noise I suppose ;) > > > Best Regards > Christoph > > > [...] * RP S336m Table 11 says "Version Number...Version of the Defined-Length Pack Register which first defines the item specified by the Defined-Length Pack Designator" -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] cutting iFrame only media
On 28/04/15 18:02, Mohammadtorabi wrote: > Hi,I have created an iFrame only MXF file by the command below using > [...snipped densely packed forest of words] Was there a question in there somewhere? I couldn't see the wood for the trees due to the lack of formating. -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How can I set in a D10 MXF (IMX50) file the flags for output color_range, -space, -transfer and primaries?
On 29/04/15 22:22, Christoph Gerstbauer wrote: > I found out that a IMX50 mxf file encoded with FFmbc and the IMX50 mxf > file encoded with actual ffmpeg builds are different in these mxf > metadata flags (by reading out via ffprobe - show_streams) > > FFMBC IMX FILE stream 0:0: > color_range=tv > color_space=smpte170m > color_transfer=bt709 > color_primaries=bt470bg > > > FFMPEG IMX FILE stream 0:0: > color_range=tv > color_space=unknown > color_transfer=unknown > color_primaries=unknown > > I want to set these metadata flags to the same values, but with FFmpeg. > How can I produce the same output like ffmbc with these 4 metadata flags? > I didnt found a answer to that in the ffmpeg documentation :/ > I think this is the third time you have asked this question in a slightly different way, and the answer has not changed. I refer you to my previous responses. > Best Regards > CHristoph > > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How to generate IRT conform D10 MXFs (IMX50) with FFmpeg?
On 30/04/15 07:20, Christoph Gerstbauer wrote: > Hello > > I am making tests with IMX50/MXF encodings with FFMBC and FFMPEG. (with > 24bit audio and 16bit audio) > [...] Reeatedly asking the same question in a new thread, without waiting a resonable time for a reply, is begining to get tedious and will not endear you to those who might otherwise respond in a useful manner. -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How can I set in a D10 MXF (IMX50) file the flags for output color_range, -space, -transfer and primaries?
On 30/04/15 22:03, Marton Balint wrote: > > On Wed, 29 Apr 2015, Christoph Gerstbauer wrote: > >> I found out that a IMX50 mxf file encoded with FFmbc and the IMX50 mxf >> file encoded with actual ffmpeg builds are different in these mxf >> metadata flags (by reading out via ffprobe - show_streams) Are you sure you mean specifically "mxf metadata flags"? See my comments below. >> >> FFMBC IMX FILE stream 0:0: >> color_range=tv >> color_space=smpte170m >> color_transfer=bt709 >> color_primaries=bt470bg >> >> >> FFMPEG IMX FILE stream 0:0: >> color_range=tv >> color_space=unknown >> color_transfer=unknown >> color_primaries=unknown >> >> I want to set these metadata flags to the same values, but with FFmpeg. >> How can I produce the same output like ffmbc with these 4 metadata flags? >> I didnt found a answer to that in the ffmpeg documentation :/ > > You can manually specify these settings to force them being set with > these parameters: > > -color_primaries 5 > -color_trc 1 > -colorspace 6 > > What does not work as far as I know in ffmpeg is to actually get these > settings from the source video, even if ffprobe detects them. > And what does not work as far as I know in ffmpeg is these values actually being written by the mxf muxer. At least I cannot find the relevant UL's listed in the "Generic Picture Essence Descriptor" section of mxfenc.c which is where I would expect to see them. Or any where else for that matter. Nor are they in ffmbc for that matter, so I suspect ffprobe is picking them up from the essence rather than the specific mxf UL's. (ffmbc sets the parameters Marton lists as part of the IMX target, which ffmpeg does not have) Given that "MXF encoders should encode Transfer Characteristic whenever possible" smpte S377-1, this is clearly an omission and I am surprised the IRT analyser doesn't spot it. Christoph do you actually require the mxf metadata setting (as it really ought to be, and what I thought you were after) or are you content with it in the essence, in which case, in the absence of a target preset, you will have to set the flags yourself. > Regards, > Marton > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How can I set in a D10 MXF (IMX50) file the flags for output color_range, -space, -transfer and primaries?
On 02/05/15 14:38, Christoph Gerstbauer wrote: > > > Am 01.05.15 um 11:21 schrieb tim nicholson: >> [..] >> Christoph do you actually require the mxf metadata setting (as it really >> ought to be, and what I thought you were after) or are you content with >> it in the essence, in which case, in the absence of a target preset, you >> will have to set the flags yourself. >> > As Marton Balint showed me the syntax, the setting of these 4 values > worked, but they dont affect the metadata in the MXF container. > The metadata flags: > Color Siting and Signal Standard werent changed by using the syntax. > Before this test I though I could change these 2 params with the syntax > descriped above. > But now I know that this is not working. > Furthermore I looked for a way to PASS the test with the IRT Analyzer. > > Regarding to the ticket: "How to set 3 specific metadata flags > (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding" > Yes I am still looking for a encoding option fot the mxf encoding of > ffmpeg to set MANUALLY (of course) the flags for Signal Standard and > Color Siting. > FFmpeg should never set it autmatically to any values, if the source > would have empty flags. > So if I know from which source the content is comming, I want to be able > to set the 2 mxf metadata flags, and also the 4 addional falg for the > essence (color_range, color_space, color_transfer and color_primaries). Setting the values to a specified values seems straightforward enough, now I have found the relevant UL's. The tricky bit is to decide what to do if the values aren't manually specified. According to the specs there is no "default" value, so we would have to "invent" one. This could be by inspecting the codec metadata to see if the corresponding stream flags are set. This looks like it would be tricksy, or using some predetermined value based upon some other parameters such as frame size, which could lead to disagreement as to what was appropriate. Making the writing of the metadata optional also adds complication in the muxer, so it needs some careful thought. As an interim solution for pristine mxf files, have you tired remuxing with bmxlib? > > My motivation to this whole issue is: > I want to generate a IMX50 file from an ffv or ffvhuff file were the > IMX50 target file has less transcoding loss as possible. > Most transcoders I use make an internal convertion from YUV422 to YUV422 > formats (e.g uncompress 4:2:2 to uncompressed 4:2:2) with an ADDIONAL > loss. I guess it is an internal RGB convertion: YUV422 source to RGB > (internal) to YUV422 target format. (anyway, these transcoders are black > boxes and I cannot know if this is the cause) > So when I transcode with these transcoders I have 2 LOSSY steps: > 1.) Avoidable LOSS of source is YUV422: addional chroma subsampling > (RGB->YUV422) > 2.) MPEG2 encoding loss > > FFmpeg does not do that: It keeps the yuv422 native format and just > encode it to mpeg2. -> And that would lead to better quality IMX files. > Therefore I want to switch from "professional" transcoders to ffmpeg for > generation IMX50. But I will still ned this metadata flag to do it > perfectly. > > Best Regards > Christoph Gerstbauer > >>> Regards, >>> Marton >>> [..] > > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How can I set in a D10 MXF (IMX50) file the flags for output color_range, -space, -transfer and primaries?
On 05/05/15 15:52, Christoph Gerstbauer wrote: > > > Am 05.05.2015 um 09:06 schrieb tim nicholson: >> [...] >> >> The tricky bit is to decide what to do if the values aren't manually >> specified. According to the specs there is no "default" value, so we >> would have to "invent" one. > Hm, so what is happening at the current ffmpeg encoding? If nothing is > defined what is going into the 2 mxf metadata flags? > At this time the following is readed out from mxf2raw: > Signal Standard = 0 (NONE) > Color Sitting = 255 (UNKNOWN) > So is ffmpeg writing this "0" into the mxf or is MXF2RAW showing me the > some standard value when it cannot regognize any value in this flags? > ffmpeg does not currently write that metadata at all in the mxf muxer so mxf2raw must be reporting the values corresponding to "unset" -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
[FFmpeg-user] DPX bit depth.
The default -pix_fmt for dpx when provided with a yuv422p10le source file appears to be rgb48be, which seems reasonable enough. However upon inspection of the created dpx it appears to be only rgb24 which is not what I would have expected. Can anyone shed light on this?:- >ffmpeg -i "prores-HD.mov" -ss 10 -t 1 -c:v dpx -y-an "dpx-HD-%04d.dpx" ffmpeg version N-70593-gf8f324c-by_Tim Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1) configuration: --extra-version=by_Tim --progs-suffix=_Mar-10 --prefix=/mnt/msds-store-0/tim/ffmpeg-tux/usr/local --libdir=/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/lib64 --extra-cflags='-I/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/include -static' --extra-ldflags='-L/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/lib64 -static -ldl' --pkg-config-flags=--static --enable-static --disable-shared --enable-runtime-cpudetect --enable-gpl --enable-nonfree --enable-version3 --samples=../fate-suite/ --disable-ffserver --disable-ffplay --enable-libfaac --enable-libfdk-aac --enable-libx264 --enable-libx265 --enable-libfreetype libavutil 54. 20.100 / 54. 20.100 libavcodec 56. 26.100 / 56. 26.100 libavformat56. 25.101 / 56. 25.101 libavdevice56. 4.100 / 56. 4.100 libavfilter 5. 12.100 / 5. 12.100 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 libpostproc53. 3.100 / 53. 3.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'prores-HD.mov': Metadata: major_brand : qt minor_version : 537199360 compatible_brands: qt creation_time : 2015-05-05 15:09:43 Duration: 00:02:48.29, start: 0.00, bitrate: 182792 kb/s Stream #0:0(eng): Video: prores (apch / 0x68637061), yuv422p10le(bt709), 1920x1080, 173565 kb/s, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 23976 tbn, 23976 tbc (default) Metadata: creation_time : 2015-05-05 15:09:43 handler_name: Apple Alias Data Handler encoder : Apple ProRes 422 (HQ) Output #0, image2, to 'dpx-HD-%04d.dpx': Metadata: major_brand : qt minor_version : 537199360 compatible_brands: qt encoder : Lavf56.25.101 Stream #0:0(eng): Video: dpx, rgb48be, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc (default) == >identify -verbose dpx-HD-0001.dpx Image: dpx-HD-0001.dpx Format: DPX (SMPTE 268M-2003 (DPX 2.0)) Geometry: 1920x1080 Class: DirectClass Type: true color Depth: 8 bits-per-pixel component Channel Depths: Red: 8 bits Green:8 bits Blue: 8 bits -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] DPX bit depth.
On 11/05/15 10:54, tim nicholson wrote: > The default -pix_fmt for dpx when provided with a yuv422p10le source > file appears to be rgb48be, which seems reasonable enough. > > However upon inspection of the created dpx it appears to be only rgb24 > which is not what I would have expected. Can anyone shed light on this?:- > I should add that ffprobe thinks the material is rbg48:- "Stream #0:0: Video: dpx, rgb48be, 1920x1080 [SAR 1:1 DAR 16:9], 25 tbr, 25 tbn, 25 tbc" but as graphicsmagik is pretty good I am wondering if it is a case of 8 bit in 10bit becoming 8 bit in 16bit. However i would expect the padding to be in the lsb not msb or the pictures would be very dark. > >> ffmpeg -i "prores-HD.mov" -ss 10 -t 1 -c:v dpx -y-an "dpx-HD-%04d.dpx" > ffmpeg version N-70593-gf8f324c-by_Tim Copyright (c) 2000-2015 the > FFmpeg developers > built with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1) > configuration: --extra-version=by_Tim --progs-suffix=_Mar-10 > --prefix=/mnt/msds-store-0/tim/ffmpeg-tux/usr/local > --libdir=/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/lib64 > --extra-cflags='-I/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/include > -static' > --extra-ldflags='-L/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/lib64 > -static -ldl' --pkg-config-flags=--static --enable-static > --disable-shared --enable-runtime-cpudetect --enable-gpl > --enable-nonfree --enable-version3 --samples=../fate-suite/ > --disable-ffserver --disable-ffplay --enable-libfaac --enable-libfdk-aac > --enable-libx264 --enable-libx265 --enable-libfreetype > libavutil 54. 20.100 / 54. 20.100 > libavcodec 56. 26.100 / 56. 26.100 > libavformat56. 25.101 / 56. 25.101 > libavdevice56. 4.100 / 56. 4.100 > libavfilter 5. 12.100 / 5. 12.100 > libswscale 3. 1.101 / 3. 1.101 > libswresample 1. 1.100 / 1. 1.100 > libpostproc53. 3.100 / 53. 3.100 > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'prores-HD.mov': > Metadata: > major_brand : qt > minor_version : 537199360 > compatible_brands: qt > creation_time : 2015-05-05 15:09:43 > Duration: 00:02:48.29, start: 0.00, bitrate: 182792 kb/s > Stream #0:0(eng): Video: prores (apch / 0x68637061), > yuv422p10le(bt709), 1920x1080, 173565 kb/s, SAR 1:1 DAR 16:9, 23.98 fps, > 23.98 tbr, 23976 tbn, 23976 tbc (default) > Metadata: > creation_time : 2015-05-05 15:09:43 > handler_name: Apple Alias Data Handler > encoder : Apple ProRes 422 (HQ) > Output #0, image2, to 'dpx-HD-%04d.dpx': > Metadata: > major_brand : qt > minor_version : 537199360 > compatible_brands: qt > encoder : Lavf56.25.101 > Stream #0:0(eng): Video: dpx, rgb48be, 1920x1080 [SAR 1:1 DAR 16:9], > q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc (default) > > == > >> identify -verbose dpx-HD-0001.dpx > Image: dpx-HD-0001.dpx > Format: DPX (SMPTE 268M-2003 (DPX 2.0)) > Geometry: 1920x1080 > Class: DirectClass > Type: true color > Depth: 8 bits-per-pixel component > Channel Depths: > Red: 8 bits > Green:8 bits > Blue: 8 bits > > -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] DPX bit depth.
On 11/05/15 12:32, Moritz Barsnick wrote: > On Mon, May 11, 2015 at 10:59:45 +0100, tim nicholson wrote: >>>> identify -verbose dpx-HD-0001.dpx >>> Image: dpx-HD-0001.dpx >>> Format: DPX (SMPTE 268M-2003 (DPX 2.0)) >>> Geometry: 1920x1080 >>> Class: DirectClass >>> Type: true color >>> Depth: 8 bits-per-pixel component >>> Channel Depths: >>> Red: 8 bits >>> Green:8 bits >>> Blue: 8 bits > > My age-old identify from ImageMagick says: > [...] > Type: TrueColor > Endianess: MSB > Colorspace: RGB > Depth: 16-bit > Channel depth: > red: 16-bit > green: 16-bit > blue: 16-bit > [...] > > I used this to create the file similar to what you did: > $ ffmpeg -loglevel debug -f lavfi -i testsrc,format=pix_fmts=yuv422p10le > -frames:v 1 -c:v dpx ~/tmp/test.dpx -y Using that same command line I still get a file that GraphicsMagick claims is 8 bit, *but* like you ImageMagick says 16bit! > >> 25 tbn, 25 tbc" but as graphicsmagik is pretty good I am wondering if it >> is a case of 8 bit in 10bit becoming 8 bit in 16bit. However i would >> expect the padding to be in the lsb not msb or the pictures would be >> very dark. > > "identify" shouldn't worry about whether only 8 MSBs or 8 LSBs of > available 16 bits are used, it should be your own problem if the image > is extremely dark. Unless the format has flags to indicate such usage. > Quite, but I was concerned that the somewhere in the process the image was being down converted to 8 bit. However it looks like its GraphicsMagick at fault here (I've tried BE and LE with same results). Interestingly if I execute "convert -depth 16 " ImageMagick gives me a 16bit file from the original , but GraphicsMagick reduces the file to a real 8 bit one! So its definitely got issues. Thanks for the confirmation that it s not ffmpeg. > Moritz > _[..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] DPX bit depth.
On 11/05/15 12:59, tim nicholson wrote: > Thanks for the confirmation that it s not ffmpeg. > >[..] In fact it is related to:- http://sourceforge.net/p/graphicsmagick/bugs/131/ and for some bizzare reason Ubuntu/Mint do not build it with 16 bit support, my SuSE box is fine... -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Numerical histogram output for checking typical broadcast ranges (16-235)
On 17/05/15 13:05, Carl Eugen Hoyos wrote: > Christoph Gerstbauer gmail.com> writes: > >>> do you realise that valid (specification-compliant) >>> broadcast-range video may contain values < 16 and > 235? >> >> Hello Carl, no, I don´t. >> Can you explain this to me? >> I always thought that SD broadcast levels has to >> be >16 and <235. > > I cannot explain the relevant specifications (and I > don't even know where to find them) to you but to the > best of my knowledge: > Just as "MPEG constant bitrate" does not mean constant > frame size, so a stream containing video frames of > different sizes is not necessarily "variable bitrate", > you cannot judge a video stream as being non-"broadcast > level" just because it contains values < 16 or > 235. > I would say a broadcast signal could quite reasonably contain values < 16 or > 235, that is the point of such values, it allows for over/undershoot transients resulting from analogue to digital conversion, or filtering. What you could reasonably say is that a broadcast signal to Rec601 or 709 etc has its black and white points defined at those values, and that anything outside that range should only be a transient, which those specs allow to be preserved in the interests of avoiding distortion. > Carl Eugen > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] In and out-range Scale option able to correct 0-255 video to 0-235?
On 19/05/15 22:06, Carl Eugen Hoyos wrote: > Christoph Gerstbauer gmail.com> writes: > >> C:\Windows\System32>ffmpeg -i >> C:\Users\Administrator\Desktop\big_buck_bunny_ffvhuff.avi -vf >> "scale=in_range=full:out_range=tv" -vcodec ffvhuff > > It seems to me that the scale filter is so smart > that it doesn't scale if the input and output > resolution and input and output colourspace > are identical. > > Even worse, both the filter and the software > scaler are smart enough to skip actual scaling, > so fixing the issue in the scale filter is not > sufficient... > > I am not 100% sure if this is a bug, but it > seems so;-) > This sounds vaguely familiar and istr it only works when going YUV->RGB, but my memory could be shakey. > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] In and out-range Scale option able to correct 0-255 video to 0-235?
On 21/05/15 09:05, Carl Eugen Hoyos wrote: > tim nicholson ffmpeg.org> writes: > >>> It seems to me that the scale filter is so smart >>> that it doesn't scale if the input and output >>> resolution and input and output colourspace >>> are identical. >>> >>> Even worse, both the filter and the software >>> scaler are smart enough to skip actual scaling, >>> so fixing the issue in the scale filter is not >>> sufficient... >> >> This sounds vaguely familiar and istr it only works >> when going YUV->RGB, but my memory could be shakey. > > It works fine here for YUV->YUV if I apply the vf_scale > patch I posted on -devel and if I disable the "smart" > detection in libswscale. > As my memory is from before your patch and without such smart disabling that sounds entirely reasonable. -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] IMX50 NTSC framesize differs to the SMPTE 356M-2001 Standard - why?
On 01/06/15 19:53, Michael Niedermayer wrote: > On Mon, Jun 01, 2015 at 04:43:12PM +0200, Christoph Gerstbauer wrote: >> Hello >> >> I am testing the standard "conformness" of ffmpegs IMX50 (Mpeg2 >> I-frame, MXF) encoder. >> >> I mentioned via ffprobe or via encoding that ffmpeg does encode a >> NTSC framesize of: "208542". >> But the SMPTE Standard 356M-2001 specifies this vlaue with "208541". >> For PAL there is no problem, both framesizes are "25". >> >> So at the encoding params I have to set the following: >> >> -bufsize 200 (set ratecontrol buffer size (in bits)) >> SMPTE for PAL: max coded frame size = 250,000 BYTES = 200 bits >> SMPTE for NTSC: max codec frame size = 208,541 BYTES = 1668328 bits >> -rc_init_occupancy 200 (number of bits which should be loaded >> into the rc buffer before decoding starts) >> SMPTE for PAL: max coded frame size = 250,000 BYTES = 200 bits >> SMPTE for NTSC: max codec frame size = 208,541 BYTES = 1668328 bits >> >> But at the NTSC encoding I get get there errors: >> >> C:\Users\gersti>ffmpegnew -i "C:\Users\gersti\D-10_NTSC.mxf" -map >> 0:v -map 0:a -c:v mpeg2video -r 3/1001 -pix_fmt yuv422p -aspect >> 4:3 -minr >> ate 5k -maxrate 5k -b:v 5k -g 1 -flags > > yes, this happens because 50mbit/sec is not correct > a max framesize of 208541 results in a bit rate of max > 49.999840 mbit/sec, IIUC thats what the spec means by 50mbit/sec The spec actually says "Up to 50Mb/s" and "Up to 208541" that being the highest value that comes out below the the 50Mb/s. So I tend to agree with Michael. > > check yourself: 208541 * 8 * 3/1001 > > > [...] > > -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Private Options for prores-ks
On 02/06/15 14:38, Moritz Barsnick wrote: > On Fri, May 22, 2015 at 14:53:52 +, Kevin Wells wrote: > >> [..] >> Output #0, mov, to 'out.mov': >> Metadata: >> major_brand : qt >> minor_version : 537199360 >> compatible_brands: qt >> encoder : Lavf56.33.101 >> Stream #0:0(eng), 0, 1/11988: Video: prores (prores_ks) (apch / >> 0x68637061), yuv422p10le, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, >> 23.98 fps, 11988 tbn, 23.98 tbc (default) >> Metadata: >> creation_time : 2015-05-22 11:00:20 >> handler_name: Apple Alias Data Handler >> timecode: 00:57:50:00 >> encoder : Lavc56.39.101 prores_ks > > Quicktime 7 Pro may be displaying the "encoder" metadata field of the > stream? That's exactly what you seem to be seeing, and that's where > your input file has the "Apple ProRes 422 HQ" you desire. > > If so, you can modify the stream metadata (or "kick" the default) by > adding this to your conversion: > -metadata:s encoder="Apple ProRes 422 HQ" > "Works for me(TM)" > When I tried this the first "encoder : La.." did not get replaced, only the second one. I also tried -metadata encoder="Apple ProRes 422 HQ" and that made no diffrence either. > Why do you want to lie, anyway? ;-) In my case I was using codec copy, so I was simply trying to represent the original coder, rather than just the muxer > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] How can I set in a D10 MXF (IMX50) file the flags for output color_range, -space, -transfer and primaries?
On 04/06/15 12:06, Kuban Altan wrote: > On Tue, May 5, 2015 at 8:41 AM, tim nicholson < > nichot20-at-yahoo@ffmpeg.org> wrote: > >> On 05/05/15 15:52, Christoph Gerstbauer wrote: >>> >>> >>> Am 05.05.2015 um 09:06 schrieb tim nicholson: >>>> [...] >>>> >>>> The tricky bit is to decide what to do if the values aren't manually >>>> specified. According to the specs there is no "default" value, so we >>>> would have to "invent" one. >>> Hm, so what is happening at the current ffmpeg encoding? If nothing is >>> defined what is going into the 2 mxf metadata flags? >>> At this time the following is readed out from mxf2raw: >>> Signal Standard = 0 (NONE) >>> Color Sitting = 255 (UNKNOWN) >>> So is ffmpeg writing this "0" into the mxf or is MXF2RAW showing me the >>> some standard value when it cannot regognize any value in this flags? >>> >> >> ffmpeg does not currently write that metadata at all in the mxf muxer so >> mxf2raw must be reporting the values corresponding to "unset" >> >>[..] > > I looked to ffmpeg tickets, for this feature, but could not find the ticket > for this. Has anyone opened a ticket for this? > Before opening a ticket I suggest you check the current git HEAD. > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Private Options for prores-ks
On 04/06/15 12:58, Carl Eugen Hoyos wrote: > tim nicholson ffmpeg.org> writes: > >>> Why do you want to lie, anyway? >> >> In my case I was using codec copy, so I was simply >> trying to represent the original coder, rather than >> just the muxer > > If remuxing prores with FFmpeg overwrites the encoder > metadata, that would be a bug: > How can I reproduce this? > My bad, I don't think it does, at the stream level it was already set to the correct value and I missed that, I was concentrating on the muxer level (the first one listed by ffprobe) and found it didn't overide the default as suggested. > (To write something else than lavf as muxer in the > mov metadata should really be avoided unless a > player of specification requests it.) > > Carl Eugen > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] IMX50 NTSC framesize differs to the SMPTE 356M-2001 Standard - why?
On 08/06/15 15:19, Christoph Gerstbauer wrote: > > > [..] > Hello Michael, hello Tim! > > I have still a little problem with IMX40 with NTSC: > > I need to set the paketsize (framesize) at IMX40 NTSC to 166833bits. > For that I need a bitrate of: 3920 > > FFmpeg fails because this bitrate is not allowed for IMX40. For IMX50 > the bitrate "4840" is allowed. This is to allow for the max coded frame size limit for NTSC to be met. For IMX40 one is already well below that limit so that 40M bit rate is all that is allowed. What is the use case for this 'slimmed down' IMX40 bit rate/framesize, I see nothing in S356m or S356m requiring this. > Is it possible to implement this bitrate (3920) to the allowed > bitrate values at the IMX40 NTSC encoding? > > Command Line output: > > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] IMX50 NTSC framesize differs to the SMPTE 356M-2001 Standard - why?
On 08/06/15 16:24, Michael Niedermayer wrote: > On Wed, Jun 03, 2015 at 04:28:48PM +0200, Christoph Gerstbauer wrote: yes, this happens because 50mbit/sec is not correct a max framesize of 208541 results in a bit rate of max 49.999840 mbit/sec, IIUC thats what the spec means by 50mbit/sec >>> The spec actually says "Up to 50Mb/s" and "Up to 208541" that being the >>> highest value that comes out below the the 50Mb/s. So I tend to agree >>> with Michael. >>> >> >> Hi, i have made a short excel calulation and I think that these >> settings/syntaxes should be the correct ones for PAL/NTSC D-10: >> Do you agree? >> >> >> >> >> >> >> >> >> minrate >> >> >> framerate max coded bits/byte bufsize >> maxrate >> >> >> >> framesize (Bytes) >> rc_init_occupancy video bitrate >> IMX50PAL 25 25 8 200 >> 5000 >> >> >> >> >> >> >> >> IMX40PAL 25 20 8 160 >> 4000 >> >> >> >> >> >> >> >> IMX30PAL 25 15 8 120 >> 3000 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> IMX50NTSC29,97003208541 8 1668328 >> 4840,16 >> >> >> >> >> >> >> > >> IMX40NTSC29,97003166833 8 1334664 >> 3920,08 > > i seem to have missed this reply, my question is basicylly the same > as tims, where does the limit resulting in 3920 come from ? > is there some specification that limits the VBV buffer size to a > lower value for "40mbit/sec" than "50mbit/sec" ? > The VBV size for 40M will be lower than for 50M as its limited to 1 frame which is smaller (by about 25/30), its more a question of why the NTSC bitrate figure is diferent to PAL when there is no other constraint as to the maximum frame size which we are nowhere near at this bit rate. The standard "Operating Points" only provide the nominal values. > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] IMX50 NTSC framesize differs to the SMPTE 356M-2001 Standard - why?
On 08/06/15 17:53, Christoph Gerstbauer wrote: > > > Am 08.06.15 um 17:24 schrieb Michael Niedermayer: >> On Wed, Jun 03, 2015 at 04:28:48PM +0200, Christoph Gerstbauer wrote: > yes, this happens because 50mbit/sec is not correct > a max framesize of 208541 results in a bit rate of max > 49.999840 mbit/sec, IIUC thats what the spec means by 50mbit/sec The spec actually says "Up to 50Mb/s" and "Up to 208541" that being the highest value that comes out below the the 50Mb/s. So I tend to agree with Michael. >>> Hi, i have made a short excel calulation and I think that these >>> settings/syntaxes should be the correct ones for PAL/NTSC D-10: >>> Do you agree? >>> >>> >>> >>> >>> >>> >>> >>> >>> minrate >>> >>> >>> framerate max coded bits/byte bufsize >>> maxrate >>> >>> >>> >>> framesize (Bytes) >>> rc_init_occupancy video bitrate >>> IMX50 PAL 25 25 8 200 >>> 5000 >>> >>> >>> >>> >>> >>> >>> >>> IMX40 PAL 25 20 8 160 >>> 4000 >>> >>> >>> >>> >>> >>> >>> >>> IMX30 PAL 25 15 8 120 >>> 3000 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> IMX50 NTSC 29,97003 208541 8 1668328 >>> 4840,16 >>> >>> >>> >>> >>> >>> >>> >>> IMX40 NTSC 29,97003 166833 8 1334664 >>> 3920,08 >> i seem to have missed this reply, my question is basicylly the same >> as tims, where does the limit resulting in 3920 come from ? > Hi, I compared different encoder IMX40 formats, and all of these format > has a pkt size of 166833bytes (=1 frame for IMX40). > -> 166833*8*(3/1001) = 3920bits Approximately! >> is there some specification that limits the VBV buffer size to a >> lower value for "40mbit/sec" than "50mbit/sec" ? > Maybe I didnt understand the using of the VBV buffer? > I thought the VBV buffer size is always ONE frame. So it differs in size > when using the 50, 40 or 30 mbit format. Is this wrong? I think this is correct, I think Michael's question was slighly confusing. > > from SMPTE S356M - 2001 - Type D-10 Stream Specifications: > > " The vbv_delay parameter shall be constrained to a *1-frame* delay for > each GOP by defining the following values: > > 525/60 systems > > – picture_header: vbv_delay = 0BBBh > > 625/50 systems > > – picture_header: vbv_delay = 0E10h" > But why does having a 1 frame delay, and therefore one frame buffer which requires different buffer sizes for PAL and NTSC due to the frame rate difference, require the bit rates to be different? The only reason this is the case for the nominal 50M Operating point is because having exactly 50M at 3/1001 would lead to frames larger than the maximum coded frame size. At lower bit rates this is not an issue. so buffer size = 4000 x 1001/3 = 1334667 (approx) Given the frame rates getting integer values all round is impossible and even your figures contain rounding errors. So there will always be some fudging somewhere. Quite how the coder copes with these slightly incomatible constraints I am unclear. > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] IMX50 NTSC framesize differs to the SMPTE 356M-2001 Standard - why?
On 14/06/15 22:39, Christoph Gerstbauer wrote: i seem to have missed this reply, my question is basicylly the same as tims, where does the limit resulting in 3920 come from ? >>> Hi, I compared different encoder IMX40 formats, and all of these format >>> has a pkt size of 166833bytes (=1 frame for IMX40). >>> -> 166833*8*(3/1001) = 3920bits >> Approximately! >> is there some specification that limits the VBV buffer size to a lower value for "40mbit/sec" than "50mbit/sec" ? >>> Maybe I didnt understand the using of the VBV buffer? >>> I thought the VBV buffer size is always ONE frame. So it differs in size >>> when using the 50, 40 or 30 mbit format. Is this wrong? >> I think this is correct, I think Michael's question was slighly >> confusing. >> >>> from SMPTE S356M - 2001 - Type D-10 Stream Specifications: >>> >>> " The vbv_delay parameter shall be constrained to a *1-frame* delay for >>> each GOP by defining the following values: >>> >>> 525/60 systems >>> >>> – picture_header: vbv_delay = 0BBBh >>> >>> 625/50 systems >>> >>> – picture_header: vbv_delay = 0E10h" >>> >> But why does having a 1 frame delay, and therefore one frame buffer >> which requires different buffer sizes for PAL and NTSC due to the frame >> rate difference, require the bit rates to be different? The only reason >> this is the case for the nominal 50M Operating point is because having >> exactly 50M at 3/1001 would lead to frames larger than the maximum >> coded frame size. At lower bit rates this is not an issue. >> >> so buffer size = 4000 x 1001/3 = 1334667 (approx) >> >> Given the frame rates getting integer values all round is impossible and >> even your figures contain rounding errors. So there will always be some >> fudging somewhere. Quite how the coder copes with these slightly >> incomatible constraints I am unclear. >> > Hello Tim, > > I am now very confused about this issue, I didnt get your point. You worked backwards from a defined frame size to derive an approxomate bit rate that was not exactly 40M (and not exactly the figure you gave). I was asking why not work forward from the exact bit rate to a dervived frame size. Neither calculation will produce an a non integer result so there will always be a conflict between specified/derived value somewhere which the coder will have to resolve. > 1.) Please can you tell me YOUR used syntaxes for IMX30/40/50 for PAL > and NTSC? I want to compare it to mine. Mine look remarkably similar to yours except for the ommission of 'ilme' which makes no sense for an I frame only format. I don't think I've ever used 40M, we either use 50 or 30 but my buffers/init_occupancy are 120 PAL and 1001000 NTSC at 30M > I just want to find THE syntax for IMX50/40/30 D-10 MXFs for the ffmpeg > encoding, so that it matches with the SMPTE D-10 standard paper. The SMPTE paper is not specific on some of the details you are concerned about, auch as exact frame size for 40M profile. > > 2.) Furthermore: For IMX30 and 40 -> Do you think I can always use > framebuffer size from the IMX50 format and no decoder will have a > problem with that? Not sure what you are asking, I use a frame buffer size comensurate with the calculated size for 1 frame a given bit rate. This is different therefore for each bit rate/frame rate > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] IMX50 NTSC framesize differs to the SMPTE 356M-2001 Standard - why?
On 15/06/15 09:39, Christoph Gerstbauer wrote: > >>> 1.) Please can you tell me YOUR used syntaxes for IMX30/40/50 for PAL >>> and NTSC? I want to compare it to mine. >> Mine look remarkably similar to yours except for the ommission of 'ilme' >> which makes no sense for an I frame only format. > > Maybe the ffmpeg documentation is not correct? > "ILME: Force interlacing support in encoder (MPEG-2 and MPEG-4 only). > Use this option if your input file is interlaced and you want to keep > the interlaced format for minimum losses. The alternative is to > deinterlace the input stream with-deinterlace, but deinterlacing > introduces losses." > >Our IMX50 source will be always interlaced. But what does ILME have >to to with Intra frame encoding (I-frame)? Does ILME only works for Hmmm. the docs describe 'ilme' twice; in Section 11 (Codec Options) it simply states:- ‘ilme’ Apply interlaced motion estimation. For an I frame only format motion estimation is not applicable. So I would say that ilme has nothing to do with Intra frame encoding. >GOP structures in MPEG2 and MPEG4? If yes, this should be explained >in the documentation, I think. But it isnt. > Unless the flag performs some other undocumented fuction as well it ought to be redundant. -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] IMX50 NTSC framesize differs to the SMPTE 356M-2001 Standard - why?
On 16/06/15 09:33, Christoph Gerstbauer wrote: > >>> 1.) Please can you tell me YOUR used syntaxes for IMX30/40/50 for PAL >>> and NTSC? I want to compare it to mine. >> Mine look remarkably similar to yours except for the ommission of 'ilme' >> which makes no sense for an I frame only format. >> >> I don't think I've ever used 40M, we either use 50 or 30 but my >> buffers/init_occupancy are 120 PAL and 1001000 NTSC at 30M > Hello Tim, > > for IMX30 PAL/NTSC I have the same values like you. > > whats your buffers/init_occupancy for IMX50 NTSC? > Not sure I've ever had to do it, but a colleague uses an exact 5000 bit rate which gives a 1668334 buffer and frame size of 208541 if all figures are rounded to integers. These files have generally been accepted the other side of the Atlantic. As I've said before, the coder has got to reconcile a conflicting set of integer values when dealing with NTSC frame rates. It would be itneresting to diff frames made using the values above to those made using your values derived by working back from the exact integer frame size instead of forward from the bit rate. > [...] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] IMX50 NTSC framesize differs to the SMPTE 356M-2001 Standard - why?
On 16/06/15 12:20, Christoph Gerstbauer wrote: >>> Hello Tim, >>> >>> for IMX30 PAL/NTSC I have the same values like you. >>> >>> whats your buffers/init_occupancy for IMX50 NTSC? >>> >> Not sure I've ever had to do it, but a colleague uses an exact 5000 >> bit rate which gives a 1668334 buffer and frame size of 208541 if all >> figures are rounded to integers. >> >> These files have generally been accepted the other side of the Atlantic. >> As I've said before, the coder has got to reconcile a conflicting set of >> integer values when dealing with NTSC frame rates. It would be >> itneresting to diff frames made using the values above to those made >> using your values derived by working back from the exact integer frame >> size instead of forward from the bit rate. > So I dont have to set the "buffers/init_occupancy" an general or just in > the NTSC case? > All what I have to set is the videobitrate itself? No, that is not what I said, let me try again. You requested a change to the accepted bit rate based upon working back wards from the max integer framesize to the nearest integer bit rate to provide more consistent values, however the parameters are still not mathematically consistent as they cannot all be integer values. I have suggested if you work forward from the exact bit rate you end up with a non integer frame size (in bytes) that is within 1 byte of the correct max value. So which ever way you do the maths you end up with a non integer value somewhere, so if you feed the system integer values for all parameters (which is all it accepts) one of the values cannot be adhered to absolutely. This is something the coder has to resolve, and I did ask if you had done checksums of frames coded with parameters derived from the alternative approaches to see if the coder actually resolved matters to the same end result. > > Current syntax part: > -minrate 4840 -maxrate 4840 -b:v 4840 -bufsize 1668328 > -rc_init_occupancy 1668328 > > Alternativ syntax: > -minrate 5000 -maxrate 5000 -b:v 5000 > > So there is no need to set "bufsize" and "rc_init_occupancy"? > I have never suggested that, and I do not believe it to be correct, they are important constraints that will affect the frame delay requirements. > Best Regards > Christoph > > >>> [...] > > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
