question about dvd.dvd profile
May be we can add cin_bitrate=8000000 to it, so default will work better? (otherwise re-encoding for example dothack2.mpeg from samples.mplayerhq.hu without setting bitrate resulted in blocky encode)
Maybe I can test that today AFTER I finish testing removal of libavdevice from ffmpeg. I am having trouble getting video to be captured because of "bad file format" but got audio captured just fine. I am fairly certain that it can be removed, but I still want to make sure I can get the video capture to work anyway -- it reacts the same before and after the 0002-Remove libavdevice... patch is in. So it is just that I do not know what I am doing. On Thu, Mar 17, 2022 at 8:46 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
May be we can add cin_bitrate=8000000 to it, so default will work better? (otherwise re-encoding for example dothack2.mpeg from samples.mplayerhq.hu without setting bitrate resulted in blocky encode) -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Thursday, March 17, 2022, Phyllis Smith <[email protected]> wrote:
Maybe I can test that today AFTER I finish testing removal of libavdevice from ffmpeg. I am having trouble getting video to be captured because of "bad file format" but got audio captured just fine. I am fairly certain that it can be removed, but I still want to make sure I can get the video capture to work anyway -- it reacts the same before and after the 0002-Remove libavdevice... patch is in. So it is just that I do not know what I am doing.
are you capturing from tuner or webcam? some laptop webcams offer both mjpeg and yuvy (?) streams, so mjpeg one errors out (as I noticed in bugtracker) but yuy2 still works (if recording to ffmpeg-type video). also, webcams in the dark (like unlit room at evening) tend to provide only slow framerate....
On Thu, Mar 17, 2022 at 8:46 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
May be we can add cin_bitrate=8000000 to it, so default will work better? (otherwise re-encoding for example dothack2.mpeg from samples.mplayerhq.hu without setting bitrate resulted in blocky encode) -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew (off-topic from Subject line). Maybe I can test that today AFTER I finish testing removal of libavdevice
from ffmpeg. I am having trouble getting video to be captured because of "bad file format" but got audio captured just fine. I am fairly certain that it can be removed, but I still want to make sure I can get the video capture to work anyway -- it reacts the same before and after the 0002-Remove libavdevice... patch is in. So it is just that I do not know what I am doing.
are you capturing from tuner or webcam?
some laptop webcams offer both mjpeg and yuvy (?) streams, so mjpeg one errors out (as I noticed in bugtracker) but yuy2 still works (if recording to ffmpeg-type video).
Thanks for the "webcam" hint -- by changing the Video Driver to JPEG Webcam instead of Video4Linux2 JPEG, I am able to see the Video and hear the Audio correctly. But I have tried many, many combinations of FFmpeg, like mp4, y4m, and yuv and always still get "bad file format". Also, when trying without ffmpeg using "MPEG stream" (had to force this) and JPEG Sequence, and so on, still get bad file format. Running out of ideas to test on the laptop and do not want to boot the desktop where I saw it work a few years ago. In Preferences, Recording, if I just enable Audio, I can record to mp3 and flac and it creates the Audio file which then plays back just fine.
On Sunday, March 20, 2022, Phyllis Smith <[email protected]> wrote:
Andrew (off-topic from Subject line).
Maybe I can test that today AFTER I finish testing removal of libavdevice
from ffmpeg. I am having trouble getting video to be captured because of "bad file format" but got audio captured just fine. I am fairly certain that it can be removed, but I still want to make sure I can get the video capture to work anyway -- it reacts the same before and after the 0002-Remove libavdevice... patch is in. So it is just that I do not know what I am doing.
are you capturing from tuner or webcam?
some laptop webcams offer both mjpeg and yuvy (?) streams, so mjpeg one errors out (as I noticed in bugtracker) but yuy2 still works (if recording to ffmpeg-type video).
Thanks for the "webcam" hint -- by changing the Video Driver to JPEG Webcam instead of Video4Linux2 JPEG, I am able to see the Video and hear the Audio correctly. But I have tried many, many combinations of FFmpeg, like mp4, y4m, and yuv and always still get "bad file format". Also, when trying without ffmpeg using "MPEG stream" (had to force this) and JPEG Sequence, and so on, still get bad file format. Running out of ideas to test on the laptop and do not want to boot the desktop where I saw it work a few years ago.
it fails with may 2020 cin all the same on x86 Sandybridge-era laptop https://www.cinelerra-gg.org/bugtracker/view.php?id=590 i think proper way to fix this is to use new jpeg decompress vframe functions (introduced for reading jpeg compressed transitions), but I do not have even sketch for this....
In Preferences, Recording, if I just enable Audio, I can record to mp3 and flac and it creates the Audio file which then plays back just fine.
May be we can add cin_bitrate=8000000 to it, so default will work better? (otherwise re-encoding for example dothack2.mpeg from samples.mplayerhq.hu without setting bitrate resulted in blocky encode) --
The output from rendering using dvd as well as the output creating a dvd disc is the same, as one would expect. And on a video/audio file that is only about 1 minute long, there was no perceivable difference in time it took so it certainly is acceptable to add the mod. I will do a bigger test tomorrow and checkout the samples as provided above -- just rand out of time today. Current: ** rendered 1656 frames in 17.353 secs, 95.430 fps test #2 ** rendered 1656 frames in 17.292 secs, 95.767 fps With Mod ** rendered 1656 frames in 17.402 secs, 95.161 fps test #2 ** rendered 1656 frames in 16.808 secs, 98.525 fps
Seems good to me. I will check this into GIT next time I boot the desktop. I tested with a bigger test of Big Buck Bunny and really saw no difference but it might have been displaying more smoothly in the compositor. On Thu, Mar 17, 2022 at 8:46 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
May be we can add cin_bitrate=8000000 to it, so default will work better? (otherwise re-encoding for example dothack2.mpeg from samples.mplayerhq.hu without setting bitrate resulted in blocky encode) -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (2)
-
Andrew Randrianasulu -
Phyllis Smith